bootstrap-daemon
Skill0 starsChanged 6 days agoMITView on GitHub
Use when the user asks to "initialize daemon", "setup agent-daemon", "bootstrap daemon", "init daemon", "bootstrap the daemon memory", or "initialize agent-daemon in this project". Fully scaffolds and populates agent-daemon memory with real project context — not just empty templates.
- Reads credentials
In this repository174 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- ad-ci-readinessSkill
- ad-pre-pushSkill
- accessibilitySkill
- agent-evalSkill
- agent-harness-constructionSkill
- agentic-engineeringSkill
- agent-introspection-debuggingSkill
- agent-sortSkill
- ai-first-engineeringSkill
- ai-regression-testingSkill
- api-connector-builderSkill
- architecture-decision-recordsSkill
- article-writingSkill
- automation-audit-opsSkill
- autonomous-agent-harnessSkill
- autonomous-loopsSkill
- backend-patternsSkill
- benchmarkSkill
- blueprintSkill
- brand-voiceSkill
- browser-qaSkill
- bun-runtimeSkill
- canary-watchSkill
- cavemanSkill
- ckSkill
- claude-devfleetSkill
- click-path-auditSkill
- codebase-onboardingSkill
- code-tourSkill
- coding-standardsSkill
- content-engineSkill
- content-hash-cache-patternSkill
- context-budgetSkill
- continuous-agent-loopSkill
- continuous-learningSkill
- continuous-learning-v2Skill
- cost-aware-llm-pipelineSkill
- councilSkill
- crosspostSkill
- ad-harnessSkill
- ad-state-migrateSkill
- ad-tui-devSkill
- agent-daemon-memorySkill
- big-feature-flowSkill
- bug-flowSkill
- engine-upgradeSkill
- feature-flowSkill
- gepa-evolve-inlineSkill
- harness-troubleshootSkill
- orchestrate-teamSkill
- release-flowSkill
- session-closeSkill
- skill-authorSkill
- skill-installerSkill
- dashboard-builderSkill
- database-migrationsSkill
- deep-researchSkill
- deployment-patternsSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
17 rules. About 0 are common, 10 are distinctive, and 7 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.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 19
Run ad init in the project root.
- Very specific: line 20
Check if memory files contain {{ placeholders:
- Distinctive: line 24
If no placeholders found → memory is already populated.
- Distinctive: line 25
If placeholders exist → proceed to Phase 1.
- Distinctive: line 29
Read ALL sources that exist.
- Distinctive: line 50
Write each file using extracted content.
- Very specific: line 109
Check if ~/.agent-daemon/user.md exists and contains {{ placeholders.
- Distinctive: line 111
If already populated (no placeholders) → skip entirely
- Distinctive: line 112
If has placeholders → ask the user these 3 questions in ONE message:
- Very specific: line 122
Write ~/.agent-daemon/user.md with the user's answers + detected tools.
- Very specific: line 126
Run ad doctor — all checks should pass
- Distinctive: line 137
Do NOT ask for confirmation before reading each source file — just read them all
- Distinctive: line 138
Do NOT exceed the size limits noted for each memory file
- Distinctive: line 139
Do NOT populate gotchas or tech debt speculatively — leave them for the digest pipeline
- Very specific: line 140
Do NOT overwrite memory files that are already populated (no {{ placeholders)
- Very specific: line 141
Do NOT skip ad init — always run it first for idempotent scaffolding
- Distinctive: line 142
Do NOT put code samples in memory files — they're context docs, not code references
≈ “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.
Files
Bootstrap agent-daemon in a project
Full end-to-end initialization: scaffold files, read the project, populate memory with real context, verify.
Phase 0 — Scaffold
- Run
ad initin the project root. If.agent-daemon/already exists, it will report "already initialized." - Check if memory files contain
{{placeholders:grep -l '{{' .agent-daemon/memory/*.md 2>/dev/null - If no placeholders found → memory is already populated. Report "already bootstrapped" and STOP.
- If placeholders exist → proceed to Phase 1.
Phase 1 — Read the project
Read ALL sources that exist. Skip silently those that don't. Do NOT ask the user for each one.
| Source | How to find | Feeds into |
| Package manifest | package.json, Cargo.toml, pyproject.toml, go.mod | techContext (stack), projectbrief (name/description) |
README.md | Project root | projectbrief (what/who/why), techContext (dev setup) |
CLAUDE.md | Project root | systemPatterns (architecture, patterns), techContext (gotchas, env vars) |
CONVENTIONS.md | Project root | systemPatterns (patterns) |
| Directory structure | ls at root, then key subdirs (src/, lib/, app/, backend/, frontend/, etc.) | systemPatterns (key directories) |
| Git log | git log --oneline -20 | progress (recent work), activeContext (current focus) |
| Git branches | git branch -a | activeContext (in-flight branches) |
| Git status | git status --short | activeContext (uncommitted work) |
| Env templates | .env.example, .env.template, .env.sample | techContext (env vars) |
| CI config | .github/workflows/, Makefile, Dockerfile, docker-compose.yml | techContext (dev setup, verification commands) |
| Package scripts | scripts field in package.json or equivalent | techContext (verification commands) |
| Cross-agent rules | .cursor/rules/, .cline/rules/ | systemPatterns (patterns from other agents) |
Collect all this into working notes before writing any files.
Phase 2 — Populate memory files
Write each file using extracted content. Replace the template entirely — don't patch placeholders.
projectbrief.md (keep under 1KB)
Extract from manifest + README:
- What this project is — one paragraph from README or package description
- Who uses it — user roles inferred from README or codebase (routes, UI screens)
- Core problem — from README or infer from project purpose
- Non-goals — mark "TBD — will be refined over sessions" if not obvious
- Stage — infer: has CI + production config = "shipped"; few commits = "early-prototype"; else "beta"
techContext.md (keep under 4KB)
Extract from manifest + README + CLAUDE.md + env files:
- Stack table — language, framework, DB, hosting from dependencies
- Dev setup — commands from README or package.json scripts
- Env vars — from
.env.exampleor CLAUDE.md - Verification commands — from package.json scripts or CI config (typecheck, lint, test, build)
- Gotchas — from CLAUDE.md "gotchas" or "important" sections. If none found: "No gotchas captured yet — the digest pipeline will populate from session learnings."
- External services — from README/CLAUDE.md or mark "TBD"
systemPatterns.md (keep under 5KB)
Extract from directory structure + CLAUDE.md + code conventions:
- Architecture — from CLAUDE.md architecture section, or infer from directory layout
- Key directories — from
lsoutput, describe what each contains - Reusable utilities — scan for
lib/,utils/,helpers/,hooks/,shared/directories. List key exports if found - Recurring patterns — from CLAUDE.md conventions or code patterns
- ADRs — leave empty: "No ADRs recorded yet."
productContext.md (keep under 2KB)
Extract from README + CLAUDE.md:
- Before/after workflow — from README or infer from project purpose. Mark "TBD" if unclear
- Success metrics — infer from README or mark "TBD"
- Key product decisions — from CLAUDE.md or README design rationale
- Constraints — from CLAUDE.md directives or compliance mentions
- Stakeholders — mark "TBD" unless explicitly stated
activeContext.md (keep under 5KB)
Extract from git state:
- Current focus — from
git log -5messages +git status(what's being worked on now) - Recent decisions — leave empty: "Digest pipeline will populate from session learnings."
- In-flight branches — from
git branch -a, list non-main branches with last commit subject - Active blockers — leave empty
- Known temporary state — leave empty
progress.md (keep under 5KB)
Extract from git history:
- What works — infer from git log: features that appear shipped (merged PRs, "feat:", "add:" commits)
- In progress — from active branches
- Planned — "Check issue tracker" or leave empty
- Recently fixed — from git log: commits with "fix:" in last 30 days
- Known issues / tech debt — leave empty: "Will be populated by review-slice and audit-runner skills."
Phase 3 — User profile
Check if ~/.agent-daemon/user.md exists and contains {{ placeholders.
- If already populated (no placeholders) → skip entirely
- If has placeholders → ask the user these 3 questions in ONE message:
- "What's your name and role?" (e.g., "Asha, full-stack developer")
- "Any strong preferences for how I work?" (e.g., "be terse", "always show diffs", "Hindi-English mix is fine")
- "Anything I should never do?" (e.g., "don't auto-commit", "don't touch production files")
Then auto-detect installed tools:
node --version 2>/dev/null; python3 --version 2>/dev/null; go version 2>/dev/null; rustc --version 2>/dev/null; docker --version 2>/dev/null; gh --version 2>/dev/nullWrite ~/.agent-daemon/user.md with the user's answers + detected tools.
Phase 4 — Verify
- Run
ad doctor— all checks should pass - Show a 3-line summary:
Daemon bootstrapped for [project name]: - 6 memory files populated from [sources used] - User profile: [populated / already set / skipped] - Tell the user: "Memory is live. The digest pipeline will keep it updated as you work."
What NOT to do
- Do NOT ask for confirmation before reading each source file — just read them all
- Do NOT exceed the size limits noted for each memory file
- Do NOT populate gotchas or tech debt speculatively — leave them for the digest pipeline
- Do NOT overwrite memory files that are already populated (no
{{placeholders) - Do NOT skip
ad init— always run it first for idempotent scaffolding - Do NOT put code samples in memory files — they're context docs, not code references
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
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.

