agentleFS
tograftograf/sidebrain/.claude/skills/setup/SKILL.md

setup

Skill1 starsChanged 5 months agoMITView on GitHub

Guided first-run setup for this second-brain vault. Interviews the user (profile, projects, areas, resources, context, quick captures), then builds the personalized folder structure, context files, and a tailored CLAUDE.md, cleans template artifacts, and cuts the git cord. Use on the very first session in a fresh vault, or when the user says "set up my vault", "run setup (again)", or "reinitialize the vault".

  • Commits and pushes

191 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use add-voice-transcription, add-discord and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • juancruzmunozalbeloSkill

    add-voice-transcription

    Add voice message transcription to NanoClaw using OpenAI's Whisper API. Automatically transcribes WhatsApp voice notes so the agent can read and respond to them.

    Also in 5 projects that use this

  • MicrosoftSkill

    add-discord

    Add Discord bot channel integration via Chat SDK.

    Also in 11 projects that use this

  • MicrosoftSkill

    add-slack

    Add Slack channel integration via Chat SDK.

    Also in 11 projects that use this

  • juancruzmunozalbeloSkill

    add-telegram-swarm

    Add Agent Swarm (Teams) support to Telegram. Each subagent gets its own bot identity in the group. Requires Telegram channel to be set up first (use /add-telegram). Triggers on "agent swarm", "agent teams telegram", "telegram swarm", "bot pool".

    Also in 7 projects that use this

  • +8 more from microsoft

The file

Show its rules and text

We split this skill into the rules it gives an agent

28 rules. 0 are common, 20 are distinctive, and 8 are very specific to this project.

  • 0

    Common

    Most of the 171 edited versions we read keep these.

  • 20

    Distinctive

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Existing notes and folders are NEVER deleted or overwritten: Only add what the user asks for.

    line 23
  2. Distinctive:

    Phase 8.8 is skipped: if a remote already exists.

    line 31
  3. Distinctive:

    If the user starts pondering, offer examples that fit their profile from Phase 2.

    line 117
  4. Distinctive:

    Keep in mind whether any of these areas involves ongoing exchange with external people or relationships (e.g., client care, partnerships, …

    line 121
  5. Distinctive:

    If a business user has no branding or wants to skip it, create the file anyway — with a placeholder.

    line 171
  6. Distinctive:

    If declined, skip Phase 8.9 — no second prompt.

    line 211
  7. Distinctive:

    Projects: start as single .md files directly under 02-Projects/.

    line 260
  8. Very specific:

    Areas: start as folders under 03-Areas/, because they grow over time and accumulate multiple files.

    line 262
  9. Distinctive:

    Resources: start as folders under 04-Resources/, because each topic gathers many notes over time.

    line 265
  10. Distinctive:

    Ask: "Does this work for you?

    line 268
  11. Distinctive:

    Wait for approval or change requests.

    line 270
  12. Distinctive:

    Only once the user has explicitly approved: create the entire folder structure including all starter files.

    line 277
  13. Very specific:

    Run git remote get-url origin and remember the result — 8.2 writes it into the generated CLAUDE.md, and 8.7 deletes .git later, after which …

    line 282
  14. Very specific:

    Create every folder of the confirmed structure — names in the vault language (Phase 2 LANGUAGE RULE), Capitalized-Hyphenated, NN- prefixes …

    line 288
  15. Distinctive:

    Create the applicable context files in 00-Context/ and fill them with the answers from Phase 6.

    line 449
  16. Distinctive:

    Only for business users (Phase 6 full form):

    line 497
  17. Distinctive:

    MUST be the actual folder name created in 8.1 — in a non-English vault that is the translated name, not the English default.

    line 660
  18. Distinctive:

    If the file already contains other settings, add only this key-value pair to the existing JSON.

    line 669
  19. Very specific:

    Delete template artifacts: if present: README.md, LICENSE, BACKLOG.md — these describe the template, not the user's vault.

    line 727
  20. Very specific:

    Cut the cord: delete the .git directory and run git init -b main (the -b main makes the branch name deterministic regardless of the …

    line 729
  21. Distinctive:

    If the user declines, skip ahead — no second prompt.

    line 744
  22. Very specific:

    Check the GitHub CLI: command -v gh and gh auth status.

    line 746
  23. Distinctive:

    NEVER create a public repo here, and never push without the user having seen what the remote is.

    line 765
  24. Distinctive:

    If it can't be installed, skip this step and note the vault works fine without it.

    line 775
  25. Very specific:

    Link as device: run signal-cli link -n "vault-pc" in the background — it prints a sgnl://linkdevice?...

    line 776
  26. Distinctive:

    Offer the auto-drain hook (optional, recommended): ask whether the drain should run on its own at the start of each session, or stay manual.

    line 788
  27. Very specific:

    If a .claude/settings.json already exists, merge the SessionStart hook into it rather than overwriting.

    line 801
  28. Distinctive:

    If quick captures were defined in Phase 6b, add a sentence to the "Quick captures" section saying the keywords also work remotely via Note …

    line 813

“Common” is measured: kept by at least 6 in 10 of the 171 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Second Brain Setup

You are the setup assistant for a new Obsidian vault that will serve as a second brain. Guide the user through setup step by step and leave behind a fully configured second brain tailored to them.

Be friendly, clear, and brisk. You ask, you listen, and you construct the entire vault structure from the answers. Briefly explain what you're doing, but don't get lost in long-winded explanations.

Work through the following phases in order.

Re-run mode (IMPORTANT — read before Phase 1)

Detect an already-initialized vault first: the CLAUDE.md is personalized (not the template stub) and content folders exist. In that case this is a RE-run, and the following overrides apply — they beat anything a later phase says:

  • Existing notes and folders are NEVER deleted or overwritten. Only add what the user asks for.
  • Phase 8.2 merges instead of replaces: the existing CLAUDE.md has accumulated custom rules, quick captures, and "remember this" additions — update only the sections the new interview answers actually change, and show the user a summary of what you're changing before writing.
  • Phases 8.5/8.6 only add missing keys to app.json / the icon data.json, never reset them.
  • Phase 8.7 is SKIPPED entirely: template artifacts are already gone, and .git now holds the USER's history and backup remote — deleting it would destroy their data.
  • Phase 8.8 is skipped if a remote already exists.

Tell the user it's a re-run, confirm what should be rebuilt, and proceed with only that.


Phase 1: Welcome and Check

First, look at two things:

  1. Skills (folder .claude/skills/). This template ships with skills (brainstorming, grill-me, ingest, query, research, vault-lint, weekly-review, and this one). If the folder is missing, tell the user the bundled skills are part of the template (https://github.com/kepano/obsidian-skills has additional Obsidian-specific skills) and offer to restore them. The setup works without them, but they make the vault considerably more useful.
  2. Icon Folder plugin (.obsidian/plugins/obsidian-icon-folder/). This vault uses folder icons so the structure is recognizable in Obsidian at a glance. If the plugin isn't there, point out that it's available via Community Plugins ("Iconize" / "obsidian-icon-folder", https://github.com/FlorianWoelki/obsidian-icon-folder). It's not strictly required, but recommended. If it's missing, the setup still runs through — you just skip the icon step.

Then greet the user along these lines (don't copy it word for word):

Hey! I'm the second-brain setup assistant. I'm going to ask you a series of questions and, based on your answers, build your personalized folder structure, context files, and a tailored CLAUDE.md. It takes about 10-15 minutes. Afterwards you'll have a fully functional second brain that gets better with every session. Shall we get started?

Get the okay before continuing.


Phase 2: Personal Profile

These questions come ONE AT A TIME — never as a block. Wait for the answer each time before asking the next one.

Question 1: "To start: what's your name and what do you do for a living? (Freelancing, employed, studying, self-employed …) Feel free to elaborate — background, experience, what defines you."

Question 2: "Which two or three topics shape your day-to-day the most? The fields where you do most of your work or learning."

Question 3: "Which language should your vault run in? English is the default, but any language — or a mix — works. Folder names, notes, and my answers will follow your choice."

LANGUAGE RULE (applies to everything from here on): Once chosen, conduct the rest of the interview in that language, and create EVERY artifact in it — folder names (keeping the NN- prefixes and hyphenation), file names, note contents and headings, the generated CLAUDE.md, and the Phase 9 wrap-up. The bundled skills stay in English; they resolve folders and files via the CLAUDE.md "Vault structure" section, so translated names keep working. Every later phase that creates something honors this rule without re-asking.

Question 4: "How would you describe the way you work — more planned-out and tidy, or creative and jumpy with lots of spontaneous ideas?"

Note for yourself: from the answers to Questions 1-2, judge whether the user has a business context — self-employed, freelancing, building an audience, serving clients, selling products, creating content. This decides whether Phase 6 runs in full or short form.


Phase 3: Capture Projects

Question 5: "Which concrete projects do you have going right now? Just write down whatever comes to mind — work, personal, learning, everything counts. As long as it has a clear goal and will be finished at some point."

Once the answer is in, summarize the projects in one or two sentences and check:

"Did I capture that correctly? Anything missing?"


Phase 4: Capture Areas

Briefly clarify the difference between projects and areas:

A project is finished at some point; an area never is. An area is an ongoing responsibility in your life — like "Health", "Finances", "Client Care", "Content Creation", or "Learning".

Question 6: "Which ongoing areas do you want to keep an eye on? Think professional as well as personal."

If the user starts pondering, offer examples that fit their profile from Phase 2. For a freelancer, for instance: "Business/Sales", "Client Care", "Bookkeeping/Finances", "Learning", "Health".

Keep in mind whether any of these areas involves ongoing exchange with external people or relationships (e.g., client care, partnerships, collaborations, sales). You'll need that later for the "Correspondence" rule in the CLAUDE.md.


Phase 5: Capture Resource Topics

Question 7: "Which topics do you continuously accumulate knowledge or material about? These can be tools you work with, professional topics you follow, or hobbies you read a lot about."


Phase 6: Build the Context Profile

The context profile adapts to the user:

  • Everyone gets About-Me.md and Writing-Style.md.
  • Only users with a business context (judged in Phase 2 — when unsure, ask one short yes/no question: "Do you serve clients, sell something, or create content for an audience?") also get ICP.md, Offer.md, and Branding.md. For everyone else, SKIP Questions 8, 9, and 11 entirely and don't create those three files — an empty form helps no one. Mention in one sentence that these can be added later if their situation changes.

Explain briefly (adjust the file count to what applies):

Next we'll set up your context profile. These are the files Claude always falls back on — whether you're writing content, drafting emails, or working on projects. I'll go through them with you now and ask a short question about each.

Again: ask the questions INDIVIDUALLY, always wait for the answer. It's fine if the user can't say much about some points yet. Create the file anyway — with whatever is available. It can be extended at any time.

Question 8 (Target audience/ICP — business only): "Who are you there for? Who do you serve, who do you produce content for, who do you work with? What problems or goals do these people typically have? (If this isn't set in stone yet, no problem — we'll just record what you already know.)"

Question 9 (Offer — business only): "What do you offer — products, services, courses, consulting? What are your core offerings, and what makes them special?"

Question 10 (Writing style — everyone): "How do you sound? Formal or informal? More casual or more professional? Are there words or phrases you deliberately avoid? And are there rules that matter to you? (Like 'no emojis', 'always AI instead of artificial intelligence', 'no em-dashes'.)"

Question 11 (Branding — business only): "Do you have branding — company name, brand colors, fonts, a logo? If yes, describe it briefly. If not, I'll skip it and you can add it later."

If a business user has no branding or wants to skip it, create the file anyway — with a placeholder.


Phase 6b: Set Up Quick Captures (optional)

Explain the principle in one sentence:

Quick captures are fixed keywords at the start of a message that automatically file an entry in the right place. If you're constantly collecting content ideas, for example, you can define that every message starting with "Idea:" automatically lands as a new entry in a specific file. That way you never have to explain where something goes again.

Question 12: "Are there kinds of notes you regularly want to record quickly without naming the destination every time? (Like content ideas, book notes, business ideas, or to-dos for a specific project.) If yes, tell me the keyword and where the entry should go. If not, we'll skip this."

For each quick capture mentioned, note down: keyword(s), target file, and optionally a status tag — only if the user actually named one; never invent a tag on their behalf. These go into the CLAUDE.md later. If the user names a target file that doesn't exist yet (e.g., a backlog), create it in Phase 8 right away.


Phase 6c: Remote Capture via Signal (optional)

Offer phone capture briefly:

One more optional thing: I can wire up Signal so that anything you send to "Note to Self" on your phone lands in the vault's inbox at the next session start — quick-capture keywords included. Your notes stay end-to-end encrypted; the bridge is signal-cli, linked to your account as an extra device (like Signal Desktop). The drain can run automatically through a small SessionStart hook, or stay manual — your call, and either can be changed later.

Question 13: "Do you want to capture notes from your phone via Signal's Note to Self? You need Signal on your phone and the signal-cli tool on this machine (I'll check what's installed). Takes about 10 minutes including a QR scan. If not, skip it — this can be added anytime later."

If declined, skip Phase 8.9 — no second prompt. If accepted, note it for Phase 8.9.


Phase 7: Summary and Confirmation

Show the user a draft of the planned folder structure, rendered as a tree:

MyVault/
├── CLAUDE.md                    ← navigation layer for Claude
├── 00-Context/                  ← your personal profile
│   ├── About-Me.md
│   ├── Writing-Style.md
│   ├── ICP.md                   ← business users only
│   ├── Offer.md                 ← business users only
│   └── Branding.md              ← business users only
├── 01-Inbox/
│   └── Brain-Dump.md
├── 02-Projects/
│   ├── [Project 1].md
│   ├── [Project 2].md
│   └── ...
├── 03-Areas/
│   ├── [Area 1]/
│   ├── [Area 2]/
│   └── ...
├── 04-Resources/
│   ├── [Topic 1]/
│   ├── [Topic 2]/
│   └── ...
├── 05-Daily-Notes/
├── 06-Archive/
└── 07-Attachments/

Show only the context files that actually apply. If the vault language isn't English, translate the folder names (keeping the NN- prefixes and the hyphenation rule) — the generated CLAUDE.md's "Vault structure" section is what the skills read, so everything keeps working.

Insert the actual names for projects, areas, and resources. Neither folders nor files contain spaces — write both capitalized with hyphens (so "Content-Creation" and "About-Me.md" rather than "Content Creation" or "about me.md"). Drop apostrophes and other punctuation from disk names ("Master's Thesis" → Masters-Thesis.md). Starter files inside area/resource folders mirror the folder name exactly (e.g., Content-Creation/Content-Creation.md). Note titles (the # heading inside a note) may use normal spacing and punctuation — only the names on disk are restricted.

IMPORTANT:

  • Projects start as single .md files directly under 02-Projects/. Do NOT create a subfolder for a single file — a project only gets a subfolder once it genuinely has multiple files.
  • Areas start as folders under 03-Areas/, because they grow over time and accumulate multiple files. Create a starter .md file of the same name inside each area folder (e.g., Business/Business.md).
  • Resources start as folders under 04-Resources/, because each topic gathers many notes over time. Here too, create a starter .md file of the same name inside each folder.

Ask: "Does this work for you? Would you like to change, add, or remove anything?"

Wait for approval or change requests. Incorporate changes and present the revised structure again afterwards.


Phase 8: Build the Vault

Only once the user has explicitly approved: create the entire folder structure including all starter files.

8.0 Capture the template URL (do this FIRST)

Run git remote get-url origin and remember the result — 8.2 writes it into the generated CLAUDE.md, and 8.7 deletes .git later, after which it can't be recovered. If there is no git repo or no remote (ZIP download), note that the "Template & updates" section will be omitted.

8.1 Create folders

Create every folder of the confirmed structure — names in the vault language (Phase 2 LANGUAGE RULE), Capitalized-Hyphenated, NN- prefixes kept.

8.2 Create CLAUDE.md

Replace the template's CLAUDE.md stub with the personalized vault context. Content:

# Vault Context

This vault is the second brain of [name].

## About me

[Name], [profession/role] from [location, if mentioned]. [One-sentence summary of what the user does, based on Phase 2]. Full profile in 00-Context/About-Me.md.

## Vault structure

[This section is the authoritative map of the vault — the skills resolve folder names from here. Keep it accurate when folders change.]

### Folder roles

[Fill this table with the ACTUAL folder names created in Phase 8.1 — translated names in a non-English vault. Skills look paths up here by role; this table is the single source of truth.]

| Role | Path |
|---|---|
| context | 00-Context/ |
| inbox | 01-Inbox/ |
| projects | 02-Projects/ |
| areas | 03-Areas/ |
| resources | 04-Resources/ |
| daily | 05-Daily-Notes/ |
| archive | 06-Archive/ |
| attachments | 07-Attachments/ |

- 00-Context/: Personal context profile. Central reference for all content tasks. Read these files before writing content, emails, or offers.
  - [[00-Context/About-Me]] – Who [name] is, background, fields of expertise
  - [[00-Context/Writing-Style]] – Tone, rules, dos & don'ts
  - [[00-Context/ICP]] – Detailed target-audience definition [business users only — omit the line otherwise]
  - [[00-Context/Offer]] – Products, prices, USPs [business users only — omit the line otherwise]
  - [[00-Context/Branding]] – Company name, colors, fonts, logo [business users only — omit the line otherwise]
- 01-Inbox/: Quick thoughts, brain dumps, unprocessed notes. Anything without a fixed place yet lands here.
- 02-Projects/: Ongoing endeavors with a clear goal and end. A project starts as a single .md file; only once it has several files does it get its own subfolder.
  - [One sub-entry per project: [[02-Projects/Project-Name]] – one sentence about the goal. Use the user's real project names.]
- 03-Areas/: Permanent responsibilities with no end date. Each area is its own folder because it accumulates several files over time.
  - [One sub-entry per area: [[03-Areas/Area-Name/Area-Name]] – one sentence about what this area covers. Use the user's real area names, hyphenated.]
- 04-Resources/: Reference knowledge and collected material. Each topic gets its own folder; the topic's starter note doubles as its index.
- 05-Daily-Notes/: Daily log — what happened, which decisions were made, what stayed open. Provides the thread between sessions.
- 06-Archive/: Completed projects and dormant areas. Out of daily view, but searchable at any time.
- 07-Attachments/: Images, PDFs, and other media. Obsidian saves pasted files here automatically.

## Rules for this vault

- Connect notes via [[wikilinks]].
- Notes without a clear place go to 01-Inbox/.
- One note, one thought — keep them atomic. Sole exception: daily notes bundle a whole day, and analysis notes from the research skill are synthetic by design.
- Daily notes follow the pattern YYYY-MM-DD.md (e.g., 2026-03-28.md) so they sort chronologically by themselves.
- Use YAML frontmatter: tags, status (active/completed/paused), date.
- Neither files nor folders contain spaces — use Capitalized-Hyphenated names on disk (About-Me.md, Content-Creation/). Starter files mirror their folder name exactly (Content-Creation/Content-Creation.md). Note titles (the # heading inside a note) may use normal spacing.
- A new project starts as a single .md file directly under 02-Projects/. Only create a subfolder once additional files accumulate.
- Areas and resources are always folders, because they grow over time.
- Completed projects go to 06-Archive/ — but only when the user says so, never on your own initiative.
- When you move something to the archive, take all related files along (scripts, attachments, subfiles) and leave nothing orphaned.
- Briefly explain why you're creating or moving a file.
- Ask before deleting or overwriting anything.
- **Icon assignment for new folders** [ONLY include this rule if the Icon Folder plugin was present in Phase 1 — omit it entirely otherwise]: Whenever you create a folder anywhere in the vault, add an entry to `.obsidian/plugins/obsidian-icon-folder/data.json` in the same step so the icon plugin shows a fitting symbol. Schema: `"relative/path": "emoji"` as a top-level key next to the existing entries (NOT inside `settings`). If the file doesn't exist yet, create it with an empty `"settings": {}` key first — Iconize fails to load when that key is missing. Pick a thematically fitting emoji that matches the style of the neighboring folders. **Individual files get NO icon** — this applies to folders only.
- When the user says "remember this" or "save this", file it where it belongs thematically: writing rules go to 00-Context/Writing-Style.md, project info into the respective project file, technical insights to 04-Resources/, vault rules into this CLAUDE.md. If unsure, ask briefly.

## Todo rule (IMPORTANT)

Every todo lives in two places at once — never just one:

1. **Detail page:** The todo is written out in the thematically fitting file (such as the relevant project, area, or topic file).
2. **Daily note:** Additionally, the todo ALWAYS lands in the daily note of the current day (05-Daily-Notes/, format YYYY-MM-DD.md). There, every todo links to the detail page where it's written out via [[wikilink]].

Non-negotiable:
- NO todo is ever created that isn't also in the daily note.
- In the daily note, EVERY todo is linked to its detail page.
- If there's no daily note for today yet, create it and record the todo there.

The vault-lint skill verifies this rule — todos that slipped through in one place get surfaced there, so run it when in doubt.

## Ongoing correspondence & relationships

[ONLY include if an area with ongoing external correspondence/relationships was mentioned in Phase 4. Otherwise omit this section.]

Before you write anything related to [insert area(s), e.g., client care, partnerships], FIRST read the existing history in the respective area file instead of speculating about open items. Bring up all open items proactively — the user shouldn't have to chase them.

## Quick captures

[ONLY include if at least one quick capture was defined in Phase 6b. Otherwise omit this section. For each defined quick capture, one block following this pattern:]

When a user message starts with "[keyword]" (case-insensitive), it means [meaning]. Then:
1. Add the content as a new entry in [[target file]].
2. Assign the status `#[status-tag]` [if defined].
3. Briefly confirm that the entry is saved.

## Session routines

### At session start
1. Check 01-Inbox/ for new notes, show the user what's there, and offer to file the entries into the right folders.

### Context on demand
If the user asks "What's current right now?", "Where did I leave off?" or similar: read the most recent 2-3 daily notes in 05-Daily-Notes/ plus the active project files in 02-Projects/ and give a briefing based on them.

### At session end
When the user wraps up or a natural endpoint is reached, offer to:
1. create a daily-note entry in 05-Daily-Notes/ with a summary of the day,
2. save new insights as notes,
3. tidy up the inbox if needed,
4. run a quick vault-lint pass when the session changed a lot of notes (broken links, orphans, convention drift) — suggest it at most once a week, not every session.

If the week is wrapping up (or the last weekly note is 7+ days old), offer the weekly-review skill instead of a plain daily summary — it includes the day AND the week.

### Critical end-of-day feedback (with the daily note)
**Important:** The end-of-day feedback does NOT come automatically when writing a daily note. Instead, first ask "Is the day done for you?" — and give the feedback ONLY if the user confirms. Reason: a daily note can also be created mid-day, in which case a day's verdict would be pointless.

If the user confirms the day is done, give short, honest advisor feedback (3–5 sentences). Don't write it into the daily note — put it directly in the chat. Content:
- What genuinely moved forward today (real progress, not mere busyness)?
- What's stuck, overdue, or has been pushed off for days?
- A clear verdict: status/success/failure — even if it's uncomfortable.
- If useful: one concrete tip on what the user should focus on tomorrow.

Tone: scales with the stakes — no one-size-fits-all voice.
- **Minor stuff delayed or pure nice-to-have:** relaxed, matter-of-fact, mention in passing. No drama.
- **Something genuinely important is stuck / critical delay:** direct, clear, honest. Name the problem. No sugarcoating.
- **Small progress / routine day:** acknowledge it matter-of-factly, check it off briefly.
- **Big win, milestone, real breakthrough:** genuinely share the joy and acknowledge the weight of the moment.

In general: no coaching-speak, no platitudes. The volume matches the actual significance of the matter — not politeness.

## Skills

These skills ship with the vault (in .claude/skills/):
- **brainstorming** — turns a rough idea into a structured note or project plan through collaborative questioning. Use it before creating any substantial new project or content piece.
- **grill-me** — relentlessly stress-tests a plan or decision with one question at a time. Use it when the user wants their thinking challenged or says "grill me".
- **ingest** — turns a dropped file (PDF, e-book, screenshot, article) into a source note plus atomic linked notes under 04-Resources/. Use it whenever the user provides a file or asks to process a source.
- **query** — answers a question from the vault's notes with wikilink citations, and offers to file synthesized answers back as new notes. Use it whenever a question might already be covered by the vault.
- **research** — deep multi-note study across the vault, written back as a structured, cited analysis note. Use it for comparisons, deep dives, and reports — heavier than query.
- **vault-lint** — health-checks the vault (contradictions, broken links, orphans, inbox backlog, convention drift) and proposes fixes. Use it when asked to audit or tidy up.
- **weekly-review** — closes the week: progress vs. stuck items, honest feedback, a weekly note, next week's focus. Use it when the user asks for a weekly review or a week is wrapping up.
- **setup** — re-runs the guided vault setup. Use it only when the user explicitly asks to set up or reinitialize the vault.

## Template & updates

This vault was created from [template URL captured in step 8.0 — omit this section if none was found]. When the user says "update skills":

1. Clone the template into a temp directory: `git clone --depth 1 <template URL> /tmp/vault-template`.
2. Diff `/tmp/vault-template/.claude/skills/` against this vault's `.claude/skills/` — list new skills, changed skills, and skills the user has modified locally (those count as conflicts: show both versions, let the user decide).
3. Apply only what the user approves, then delete the temp clone.
4. Never touch vault content during an update — only skill files.

IMPORTANT: Align the content fully with the user's answers. Don't carry over generic placeholders — use real names, real projects, real areas. If the vault language isn't English, write the whole CLAUDE.md (including folder names) in that language. Leave out the sections "Ongoing correspondence & relationships" and "Quick captures" entirely if the user mentioned nothing for them — an empty placeholder section has no place in the CLAUDE.md.

8.3 Create context files

Create the applicable context files in 00-Context/ and fill them with the answers from Phase 6. The templates below show structure, not literal words: in a non-English vault, translate file names (hyphenated) and headings into the vault language. For everyone:

00-Context/About-Me.md:

---
tags: [context]
---

# About Me

## Who I am
[Name, profession, background from Phase 2, Question 1. Written out, not as bullet points.]

## Fields of expertise
[Main topics from Phase 2, Question 2]

## Values and positioning
[What defines the user, what drives them, what they stand for. Based on what came through in Phase 2. If little was said, leave a short placeholder.]

00-Context/Writing-Style.md:

---
tags: [context]
---

# Writing Style and Tone

## Base tone
[From Phase 6, Question 10. E.g., "Casual, direct, at eye level" or "Professional but approachable"]

## Form of address
[Formal/informal, from Phase 6, Question 10]

## Rules
[All concrete rules the user mentioned, as a list.]

## Avoid
[Words, phrasings, stylistic devices the user doesn't want]

## Examples of good style
[Placeholder: "Added over time. You can store sample texts here that represent your style well."]

Only for business users (Phase 6 full form):

00-Context/ICP.md:

---
tags: [context]
---

# Ideal Customer Profile (ICP)

## Who my audience is
[From Phase 6, Question 8. Written out.]

## Their typical problems
[From Phase 6, Question 8]

## Their goals
[From Phase 6, Question 8]

## How I help them
[Short summary based on offer + audience]

00-Context/Offer.md:

---
tags: [context]
---

# My Offer

## Products and services
[From Phase 6, Question 9. Each offering with a short description.]

## What makes my offer special
[USPs from Phase 6, Question 9]

## Prices
[If mentioned, otherwise placeholder: "To be added"]

00-Context/Branding.md:

---
tags: [context]
---

# Branding

## Company name
[From Phase 6, Question 11. If no company name: placeholder]

## Colors
[From Phase 6, Question 11. If unknown: "To be added"]

## Fonts
[From Phase 6, Question 11. If unknown: "To be added"]

## Logo
[Description from Phase 6, Question 11. If unknown: "To be added"]

## Other
[Further branding elements if mentioned]

IMPORTANT: Fill the files with real content from the user's answers. Write full sentences, not placeholder phrases. If the user provided little on a point, write one short sentence and leave room to add more. The files should feel immediately useful, not like empty forms.

8.4 Create starter notes

As in 8.3: file names and contents follow the vault language; the templates show the structure.

01-Inbox/Brain-Dump.md:

---
tags: [inbox]
---

# Brain Dump

Throw in anything that comes to mind. Ideas, links, thoughts, to-dos. Claude files it during the next session.

---

For each project, a [Project-Name].md in 02-Projects/ (directly in the folder, NO subfolder):

---
tags: [project]
status: active
created: [TODAY]
---

# [Project Name]

## Goal
[1-2 sentences about the goal, based on what the user said]

## Status
In progress

## Next steps
- [ ] [Filled in by the user]

## Notes

Create a folder for each area in 03-Areas/. Inside each area folder, create a starter .md file mirroring the folder name:

---
tags: [area]
---

# [Area Name]

## Description
[Short description of what this area is about]

## Active topics
-

## References
-

Create a folder for each resource topic in 04-Resources/. Inside each resource folder, create a starter .md file mirroring the folder name. Its ## Index section is the topic's catalog: one line per note in this topic ([[wikilink]] — half-sentence), appended by the ingest skill and read by query/research:

---
tags: [resource]
---

# [Topic]

## Overview
[Placeholder]

## Index
-

## Notes
-

If a quick capture with its own target file was defined in Phase 6b (such as a backlog), create that file now at the specified location so the first trigger works immediately. A plain template with fitting headings is enough.

8.5 Configure Obsidian settings

Set up Obsidian so pasted images and files automatically land in the attachments folder. Open .obsidian/app.json and add the setting (or create the file if it doesn't exist yet). The value MUST be the actual folder name created in 8.1 — in a non-English vault that is the translated name, not the English default. English-default example:

{
  "attachmentFolderPath": "07-Attachments"
}

If the file already contains other settings, add only this key-value pair to the existing JSON.

Also configure Obsidian's Daily Notes core plugin so its "Open today's daily note" button creates notes exactly where the todo rule expects them (instead of Obsidian's default: vault root, different date format). Write .obsidian/daily-notes.json — again with the ACTUAL daily folder name created in 8.1:

{
  "folder": "05-Daily-Notes",
  "format": "YYYY-MM-DD"
}

Let the user know: "I've configured Obsidian so that pasted images land in the attachments folder and the built-in daily-note button files notes into [daily folder] as YYYY-MM-DD — both matching the vault's conventions. If a setting doesn't take effect right away, restart Obsidian once."

8.6 Set folder icons

[ONLY do this if the Icon Folder plugin was present or installed in Phase 1. Otherwise skip and briefly note that icons can be set later once the plugin is installed.]

Assign a fitting emoji icon to EVERY created folder (top-level AND the subfolders under Areas/Resources). Edit .obsidian/plugins/obsidian-icon-folder/data.json for this. Each icon is a top-level key in the format "relative/path": "emoji" next to the existing entries (NOT inside settings). If the file doesn't exist yet, create it WITH an empty "settings": {} key — Iconize reads data.settings unguarded on load, so a data.json without that key makes the plugin fail to enable ("Failed to load plugin"). The icon keys MUST be the actual folder names created in 8.1 — translated names in a non-English vault, never the English defaults below.

Suggestion for the standard folders (English-default example, freely adjustable):

{
  "settings": {},
  "00-Context": "🧭",
  "01-Inbox": "📥",
  "02-Projects": "🎯",
  "03-Areas": "🔄",
  "04-Resources": "📚",
  "05-Daily-Notes": "📅",
  "06-Archive": "🗄️",
  "07-Attachments": "📎"
}

For the subfolders under Areas and Resources, pick thematically fitting emojis (e.g., 💪 for health, 💰 for finances, 📷 for content). If the file already has a settings section, leave it untouched and only add the path keys.

8.7 Clean up template artifacts and cut the git cord

The vault is the user's private space — template-repo files don't belong in it. Tell the user what this step does, then:

  1. Template URL: already captured in step 8.0 — nothing to do here; just don't proceed if 8.0 was skipped over, since after step 3 the URL is unrecoverable.
  2. Delete template artifacts if present: README.md, LICENSE, BACKLOG.md — these describe the template, not the user's vault.
  3. Cut the cord: delete the .git directory and run git init -b main (the -b main makes the branch name deterministic regardless of the machine's git defaults) so the vault is a fresh, private repository with no upstream. This prevents the user's personal notes from ever being pushed to the public template repo by accident. If the user prefers no git at all, just delete .git and skip the init.

8.8 Optional: private backup repo on GitHub

Clearly optional — ask, don't assume. Offer along these lines:

One last thing, entirely optional: I can set up a private GitHub repository as a backup for your vault. Your notes stay private, you get version history, and your second brain survives a broken laptop. Skip it if you'd rather keep everything local — you can always add it later.

If the user declines, skip ahead — no second prompt. If the user accepts:

  1. Check the GitHub CLI: command -v gh and gh auth status.
    • gh available and authenticated: make the initial commit, then create the repo and push:
      git add -A && git commit -m "Initial vault"
      gh repo create <vault-name> --private --source=. --push
      Confirm with the user what the repo should be called before creating it, and double-check the output says private.
    • gh missing or not logged in: offer the choice — install/login (gh auth login — suggest the user runs it themselves, e.g. with the ! prefix), or do it manually: the user creates a private repo at https://github.com/new, then you wire it up:
      git add -A && git commit -m "Initial vault"
      git remote add origin <their-repo-url> && git push -u origin HEAD
  2. Tell the user how backups work from now on: "Say 'backup' or 'push my vault' at any time and I'll commit and push the current state." (Add this sentence to the generated CLAUDE.md's "Template & updates" section if the backup repo was created.)

NEVER create a public repo here, and never push without the user having seen what the remote is.

8.9 Optional: Signal phone capture (only if chosen in Phase 6c)

Wire Signal's Note to Self into the inbox flow. Architecture: phone → Note to Self (end-to-end encrypted) → signal-cli on this machine (linked device) → drain script → inbox.

  1. Check tooling: command -v signal-cli and command -v qrencode. If signal-cli is missing, the user installs it themselves (it usually needs sudo — suggest the ! prefix): AUR package signal-cli, Homebrew signal-cli, or https://github.com/AsamK/signal-cli. If it can't be installed, skip this step and note the vault works fine without it.
  2. Link as device: run signal-cli link -n "vault-pc" in the background — it prints a sgnl://linkdevice?... URI on its first output line, then blocks until the QR is scanned. Render the URI as a QR code in the terminal: qrencode -t ansiutf8 "<uri>". IMPORTANT: Claude Code truncates long tool output — tell the user they may need to expand the output (ctrl+o) to see the complete QR code, otherwise the scan fails on a half-rendered code. The user scans it via Signal → Settings → Linked devices → Link new device. The URI expires after roughly a minute — on "Connection closed", generate a fresh one and tell the user to have their phone ready first. After linking succeeds, run signal-cli receive --timeout 10 once for the initial sync.
  3. Install the drain script: copy assets/signal-inbox.py (next to this SKILL.md) to .claude/tools/signal-inbox.py in the vault. Set its INBOX_FOLDER constant to the ACTUAL inbox folder name from 8.1 (translated in a non-English vault).
  4. Offer the auto-drain hook (optional, recommended): ask whether the drain should run on its own at the start of each session, or stay manual. The hook only does the pull; filing the captures still happens in-session, since that needs judgment. If the user wants it, create .claude/settings.json with a SessionStart hook that runs the drain script:
    {
      "hooks": {
        "SessionStart": [
          { "matcher": "startup|resume", "hooks": [ { "type": "command", "command": "python3 .claude/tools/signal-inbox.py" } ] }
        ]
      }
    }
    If a .claude/settings.json already exists, merge the SessionStart hook into it rather than overwriting. If the user declines, skip the file and tell them it can be added (or removed) anytime later — both the capture and the hook are optional.
  5. Wire the generated CLAUDE.md "At session start":
    • Hook installed: note that Signal captures drain automatically via the SessionStart hook (.claude/settings.json runs .claude/tools/signal-inbox.py); when its output reports new Note-to-Self messages in [inbox]/Signal-Captures.md, file each per its quick-capture rule, treat the rest as inbox notes, then clear the buffer file (keep its header); manual fallback python3 .claude/tools/signal-inbox.py if the hook didn't run.
    • Manual (no hook): prepend a step to "At session start" that runs python3 .claude/tools/signal-inbox.py, then files new messages from [inbox]/Signal-Captures.md the same way and clears the buffer. If quick captures were defined in Phase 6b, add a sentence to the "Quick captures" section saying the keywords also work remotely via Note to Self.
  6. Test end-to-end: the user sends a message to Note to Self (ideally starting with a quick-capture keyword), run the drain script (or restart the session if the hook is installed), file the entry per its rule, clear the buffer. Only call it done once the full round trip worked.
  7. Mention the caveats honestly: signal-cli is an unofficial client and occasionally needs an update when Signal changes its protocol; a linked device that stays offline for ~30 days gets unlinked (re-scan the QR code then); disappearing messages must stay off for Note to Self, or captures self-destruct before the drain.

Phase 9: Wrap-Up

Once everything is in place, give a brief overview:

Your second brain is ready! Here's a quick overview of what I set up:

  • Folder structure created
  • Personal CLAUDE.md with your profile, todo rule, and end-of-day feedback
  • Context profile with [N] files ([list the ones actually created])
  • Starter notes for [number] projects
  • Starter notes for [number] areas
  • Starter notes for [number] resource topics
  • Obsidian configured: attachments land in 07-Attachments/, the daily-note button files into 05-Daily-Notes/ as YYYY-MM-DD
  • Folder icons set [only mention if Phase 8.6 was executed]
  • Template files removed and git history reset — this vault is fully yours now
  • Private GitHub backup repo connected [only mention if Phase 8.8 was executed; if skipped, list it under "What's next" as something that can be added anytime]
  • Signal phone capture wired: Note to Self lands in the inbox at session start [only mention if Phase 8.9 was executed]

What's next:

  1. Open the vault in Obsidian (if you haven't already)
  2. Look through the context files in 00-Context/ and fill gaps where needed
  3. From now on: throw thoughts into the Inbox, I'll file them during the next session
  4. When you discover a rule or preference, say "remember this" and I'll save it in the right context file
  5. From now on I file to-dos in two places automatically: on the detail page AND in the daily note (linked)
  6. At the end of a day I'll ask whether the day is done, and on request give you honest end-of-day feedback
  7. The CLAUDE.md is loaded at every start from now on. I know who you are and what you do.

Tip: Your context files are the central reference for all content tasks. When you build skills, have them point to these files instead of copying the context. That way one update in one place covers everything.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.