agentleFS
bradautomatesbradautomates/second-brain/.claude/skills/start-second-brain/SKILL.md

start-second-brain

Skill217 starsChanged 8 months agoMITView on GitHub

Initialize a new Second Brain vault from a template repo — validate privacy, create folders, push, and onboard the user.

  • Installs packages

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 10 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run from the vault's root directory:

    line 12
  2. Distinctive:

    After the script finishes, present the obsidian-git plugin setup instructions:

    line 30
  3. Distinctive:

    If the user asks what these settings do, explain each one.

    line 44
  4. Distinctive:

    If they provide context:

    line 52
  5. Distinctive:

    Write all files in one pass, then confirm what was filled in

    line 55
  6. Distinctive:

    If they skip, move on.

    line 57
  7. Distinctive:

    All three converge through git.

    line 71
  8. Distinctive:

    After the walkthrough, ask if they want to set up their first farmer now:

    line 100
  9. Distinctive:

    If they have Slack channels in their watchlists, suggest the Slack farmer first

    line 104
  10. Distinctive:

    If they mentioned meetings or Fireflies, suggest the Fireflies farmer

    line 105
  11. Very specific:

    After creation, offer to schedule it with /schedule

    line 107
  12. Very specific:

    If they skip, that's fine — remind them they can run /create-farmer anytime

    line 108

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Start Second Brain

Set up a Second Brain vault after the user has created their repo from the GitHub template.

Usage

Run from the vault's root directory:

python3 .claude/skills/start-second-brain/scripts/init_vault.py

Phase 1: Init Script

The script handles mechanical setup:

  1. Privacy check — uses gh repo view to verify the repo is private. Exits with an error if public. Warns if it can't determine visibility.
  2. Creates vault folders — tasks, projects, people, ideas, context, daily, weekly, outputs (git doesn't track empty dirs, so these won't exist from the template)
  3. Creates template files — .gitignore, context/_index.md, context/watchlists.md (skips if they already exist)
  4. Initializes git — only if .git doesn't exist (backwards compatibility for non-template setups)
  5. Commits and pushes — commits the new folders/files, then pushes to origin to verify the full pipeline works

Phase 2: Obsidian-Git Setup

After the script finishes, present the obsidian-git plugin setup instructions:

Install the obsidian-git community plugin, then configure:

SettingValue
Auto pull on startupEnabled
Pull on interval (minutes)30
Auto commit-and-sync (minutes)10
Merge strategyRebase
Push on commit-and-syncEnabled

This keeps Obsidian in sync with cloud farmers and Claude Code sessions. Farmed content appears automatically when you open Obsidian each morning.

If the user asks what these settings do, explain each one. If they want to skip Obsidian setup, that's fine — move on.

Phase 3: Context Onboarding (optional, one question)

Ask one question:

"Want to seed your context files? Dump whatever you've got — role, company, tools, Slack channels you care about, key people, active projects — and I'll sort it into the right files. Or skip this and fill them in later."

If they provide context:

  • Parse their dump and distribute across context/business-profile.md, context/watchlists.md, and context/writing-style.md (only update writing style if they mention preferences, otherwise leave defaults)
  • Fill in the watchlists keyword signals with the defaults from the template (deadline, blocker, decision signals) — don't leave them commented out
  • Write all files in one pass, then confirm what was filled in

If they skip, move on.

Phase 4: How It All Works

Walk the user through how the system fits together. This is important. Present it conversationally, not as a wall of text. Cover:

The sync loop

Explain how three things keep the vault in sync:

  1. Claude Code sessions — when you use /new, /today, or any command, changes are auto-committed and pushed to the private GitHub repo
  2. Obsidian-git plugin — pulls those changes when you open Obsidian (and every 30 min), so farmed content and Claude edits appear automatically. Your manual Obsidian edits get committed and pushed too
  3. Cloud farmers — scheduled agents that clone the repo, read external sources (Slack, Fireflies, etc.), write findings into the vault, commit, and push. Next time Obsidian or Claude Code pulls, the farmed content is there

All three converge through git. No special sync service — just commits and pushes to the same private repo.

Available commands

Give a quick rundown of what they can do:

CommandWhat it does
/new <text>Quick capture — describe anything and it gets classified and filed as a task, project, person, or idea
/todayGenerates a daily plan from due tasks and active projects
/daily-reviewEnd of day — compare what you planned vs what happened
/historySee recent vault activity
/farm <name>Manually run a farmer (e.g., /farm slack)
/create-farmerSet up a new farmer for any connected service
/scheduleSchedule a farmer to run automatically on a cron
/delegate <task>Fork a task to a background terminal session

Context farmers

Explain what farmers are and how to set one up:

  • Farmers are scheduled agents that read external services and write relevant findings into your vault
  • Built-in farmers exist for Slack and Fireflies — or you can create custom ones for Gmail, Google Calendar, Firecrawl, etc.
  • To set one up: run /create-farmer, pick a service, configure what to watch, then /schedule to run it automatically
  • Farmers use your context/watchlists.md to know what channels, people, and keywords to monitor
  • Farmed content gets tagged with source: farmer/<name> so you can tell what was auto-captured vs manual

Phase 5: Farmer Setup

After the walkthrough, ask if they want to set up their first farmer now:

"Want to set up a context farmer now? If you added Slack channels or meetings to your watchlists, we can get those running. Just say which service — Slack, Fireflies, or something else — and I'll walk you through it with /create-farmer."

  • If they have Slack channels in their watchlists, suggest the Slack farmer first
  • If they mentioned meetings or Fireflies, suggest the Fireflies farmer
  • To set up a farmer, invoke /create-farmer which walks through the interactive wizard
  • After creation, offer to schedule it with /schedule
  • If they skip, that's fine — remind them they can run /create-farmer anytime

Edge Cases

  • Repo is public: Script exits with error and instructions to make it private
  • gh not installed: Script exits. Help the user install and authenticate:
    1. Install: brew install gh (macOS) or see cli.github.com for other platforms
    2. Authenticate: tell them to run ! gh auth login so it runs interactively in the terminal
    3. Once authenticated, re-run the init script
    • gh is required — privacy verification is not optional
  • Not a git repo: Runs git init (backwards compat for non-template setups)
  • No remote configured: Commits locally, warns that push failed with manual instructions
  • Context files already filled out: Skip onboarding for those files, or ask if user wants to update

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.