Repository documents remain in their original published languages. This guide does not translate external pages.
01Agent install
Install with your agent
Copy the prompt for your agent. It will check the environment and conflicts before following the repository setup and verification instructions.
Help me set up Obsidian Codex Workbench from the public GitHub repository duxinrui9-gif/obsidian-codex-workbench. Read its README, installation instructions, license and source notices first. Check my environment, dependencies and existing same-name installations. Check Node and pnpm requirements. Start with an empty test Vault and read-only access. Never copy or commit my personal Vault or private configuration. Keep the local service off public networks. Do not overwrite existing files or expose personal data. Stop on conflicts, permission failures or uncertain sources. Run the repository's documented checks and report installation location, version, results and first-use instructions.What it helps with
The workbench connects Obsidian knowledge, project rules and Codex execution in a traceable workflow. Long-term project context survives beyond a single conversation.
Prepare
Start with an empty test Vault and a small project. Keep the public template separate from personal and client materials. Establish read-only access before considering any writes.
Install and start
Check Node and pnpm against the repository README. In a separate checkout, install the locked dependencies, copy the example environment configuration privately, choose a test Vault and keep writes disabled.
pnpm install --frozen-lockfile
pnpm devOpen the local address reported by the server. This is a local single-user tool, not a public-hosting or multi-user system. Do not expose it to a network.
First use
Connect only a small test scope. Create an entry note with its goal, current task, key materials and last update. Confirm those notes can be read without being copied into the template or public files.
Four capabilities
| Capability | Use |
|---|---|
| Ingest | Organize explicitly selected and approved input |
| Query | Answer from existing notes with evidence |
| Health check | Inspect links, structure and risk signals |
| Maturity audit | Assess sources, boundaries and reusability |
All four stay within selected scope. Automated organization does not certify a fact.
Minimal project context
Keep a README for startup and checks, AGENTS for boundaries, architecture for relationships, and handoff for current state. Have the agent read them before work and update handoff after each stage.
Organize knowledge by purpose
Use Inbox for unassessed input, Sources for provenance, Notes for reusable knowledge, Topics for maintained themes and Outputs for deliverables.
Record source, date, evidence status and scope. Publish only reviewed text; private attachments and internal examples remain private.
A daily rhythm
Collect input, query existing knowledge, define a task, execute within its boundaries, review and record the handoff. Each stage should make clear what material was used and how the result was checked.
Deletion, external messages and publication still require human authorization.
Check the setup
Confirm read-only access works, a small task can be completed, and the result is recorded in handoff. Run the repository’s type, test and build checks before expanding use.
Common questions
Can I connect my whole Vault immediately?
Start with a small read-only test. Understand the file boundaries before adding more.
When should I use a Skill?
When a task repeats with stable inputs, outputs and limits. Test new Skills on low-risk work.
Why keep a handoff?
It preserves what happened, what was checked and what still needs confirmation for the next session.
Source and license
MIT. Installation and reference documents remain in their original published languages; the repository also provides English onboarding.