Build an AI Second Brain With Claude Code as a Source-Linked Wiki
Build a small wiki from checked sources, open it in Obsidian, and give Claude Code a reusable skill for adding pages without losing the evidence.
Updated 5 min read
Build an AI second brain with Claude Code by turning a small set of reviewed sources into linked Markdown reference pages, then using a reusable skill to maintain those pages consistently. Keep original evidence, generated drafts, and approved wiki pages separate so readers can trace each important claim.
Obsidian can provide the reading and linking interface, while fenbs keeps the tasks, approved decisions, and progress that other connected assistants need. Your first deliverable should be a useful answer with working source links, not a huge collection of automatically generated pages.
What should the first wiki contain?
- Choose one project question that deserves a lasting reference page, such as how your team prepares a client handoff.
- Collect a few source documents that you are allowed to use. Identify their owners, dates, and whether they are current.
- Create separate folders for Sources, Drafts, and Wiki, plus an index explaining what the collection covers.
- Ask Claude Code to propose one page from named sources. Require claim references and a list of unresolved questions.
- Review the draft, approve its wording yourself, and check its links before adding it to the wiki index.
These folders are a suggested design, not required product names. Obsidian stores notes as plain-text Markdown files inside a local vault, and other editors can work with them, according to its storage guide (opens in a new tab). That makes a file-based collection practical without building a separate publishing application.
If the assistant is unfamiliar, read what Claude Code does first. This workflow asks it to construct reference pages from sources; it does not require you to build a new AI model.
How should a page point back to evidence?
Give each wiki page a narrow question to answer. State the answer briefly, explain the supporting evidence, and identify where a reader can verify it. A page that combines five unrelated topics becomes difficult to maintain when only one source changes.
| Page element | Purpose | Example content |
|---|---|---|
| Scope | Explain what the page answers. | Preparing a client website handoff after approval. |
| Reviewed answer | Summarize the supported process. | The files and checks required before transfer. |
| Sources | Show where the answer came from. | Named source notes and relevant headings. |
| Uncertainty | Preserve what is unresolved. | The support owner has not yet been chosen. |
| Review record | Show what a person checked. | Reviewer, review date, and the sources inspected. |
Use links close to the claims they support. Obsidian’s link documentation (opens in a new tab) describes links to notes and headings, which let a reader move from a wiki answer to a specific source section. Prefer stable, descriptive headings to references that depend on a note staying at the same line number.
A source link does not prove that a claim is accurate. Open the destination and check whether it supports the wording. If a page infers a recommendation from several sources, label the recommendation as an interpretation rather than pretending a source stated it directly.
How can a skill make page creation repeatable?
A skill is a saved set of instructions for a repeatable task. Use one to define how the assistant drafts a wiki page, what evidence it must include, and when it should stop for review. Keep current project facts in sources instead of embedding them in the reusable instructions.
Claude Code’s skills documentation (opens in a new tab) describes project skills in a folder such as .claude/skills/wiki-draft/SKILL.md. A skill includes descriptive information at the top and the instructions beneath it. The example below is a starting procedure that you should test on one small source collection.
--- name: wiki-draft description: Draft a source-linked reference page from named project sources. --- Read only the sources named in the request. Write the proposed page in Drafts, never over an original source. Answer one question per page. For important claims, include source paths and headings. Separate evidence from inference and show unresolved conflicts. List missing evidence and proposed links to existing wiki pages. Do not mark the page reviewed or publish it without a person’s approval.
Test whether the skill produces a clear page, real references, and a visible uncertainty section. Fix the procedure when the same omission recurs. A skill should reduce repeated instruction, not make you stop checking the result.
When the procedure itself needs to travel between supported AI apps, fenbs’s Skills and prompts can hold the shared instructions. Each assistant still needs the right sources and access for the work it performs.
How do you review the first generated page?
Read the page as if you were a colleague who had not seen the original request. Can you identify the question, understand the answer, and find the evidence? Then compare every material claim with its source, including any exceptions the summary might have omitted.
- Reject references to missing files, nonexistent headings, or sources outside the requested collection.
- Preserve disagreements instead of silently choosing the most convenient source.
- Check that proposed links connect related ideas rather than adding clutter.
- Keep a draft unapproved when an important claim needs a person’s answer.
Record the review date and the sources actually checked. Do not mark a page reviewed merely because Claude produced a confident result. A page about an unfinished process should be allowed to say that the process is unfinished.
For finding and reviewing notes already in a mature vault, see the Obsidian and Claude Code review routine. Keep this construction workflow focused on building durable reference pages.
What happens when a source changes?
Ask Claude Code which wiki pages reference the changed source, then inspect that list yourself. Update affected drafts before declaring the answer current. A change to a source does not automatically mean every linked page needs rewriting, but each affected claim deserves a check.
Keep a short index of open questions and pages awaiting review. If you repeatedly discover that readers need an answer absent from the wiki, add a page for that question. Avoid generating empty topic pages simply because a model can suggest many plausible headings.
The AI second brain explanation describes why retrieval and maintenance matter together. Your wiki is useful when it helps someone answer a real question and recover the evidence, not when its page count grows.
Keep wiki maintenance connected to real work
Use fenbs tasks for source checks and pages awaiting review, then record a person’s approved decisions separately from the wiki’s explanations. Save Where we left off before stopping so the next connected assistant can find the unfinished checks. Keep long source documents in the vault.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to do this with fenbs
- Create a free account, then add the project the wiki supports.
- Add tasks for the first source review, draft page, and unresolved evidence. Give each task a plan and a clear next step.
- Record the choices a person approves in Decisions and rules. Save a useful drafting procedure in Skills and prompts.
- Connect the supported AI apps you use through Integrations. Ask each one to read the project context and save progress when it stops.
fenbs is free for one person, with no credit card. It does not build or synchronize an Obsidian wiki for you. If your only need is to browse local reference notes, the vault can be enough; add fenbs when the work around those notes needs a shared record.
Explore the second brain topic for other structures. A successful first version has one reviewed page, traceable evidence, and an explicit maintenance task. That gives you a pattern worth repeating.