agentleFS
pankaj-mahaurpankaj-mahaur/Agent-Daemon/skills/daemon/bootstrap-daemon/SKILL.md

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

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
  1. Very specific:

    Run ad init in the project root.

    line 19
  2. Very specific:

    Check if memory files contain {{ placeholders:

    line 20
  3. Distinctive:

    If no placeholders found → memory is already populated.

    line 24
  4. Distinctive:

    If placeholders exist → proceed to Phase 1.

    line 25
  5. Distinctive:

    Read ALL sources that exist.

    line 29
  6. Distinctive:

    Write each file using extracted content.

    line 50
  7. Very specific:

    Check if ~/.agent-daemon/user.md exists and contains {{ placeholders.

    line 109
  8. Distinctive:

    If already populated (no placeholders) → skip entirely

    line 111
  9. Distinctive:

    If has placeholders → ask the user these 3 questions in ONE message:

    line 112
  10. Very specific:

    Write ~/.agent-daemon/user.md with the user's answers + detected tools.

    line 122
  11. Very specific:

    Run ad doctor — all checks should pass

    line 126
  12. Distinctive:

    Do NOT ask for confirmation before reading each source file — just read them all

    line 137
  13. Distinctive:

    Do NOT exceed the size limits noted for each memory file

    line 138
  14. Distinctive:

    Do NOT populate gotchas or tech debt speculatively — leave them for the digest pipeline

    line 139
  15. Very specific:

    Do NOT overwrite memory files that are already populated (no {{ placeholders)

    line 140
  16. Very specific:

    Do NOT skip ad init — always run it first for idempotent scaffolding

    line 141
  17. Distinctive:

    Do NOT put code samples in memory files — they're context docs, not code references

    line 142

≈ “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

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

  1. Run ad init in the project root. If .agent-daemon/ already exists, it will report "already initialized."
  2. Check if memory files contain {{ placeholders:
    grep -l '{{' .agent-daemon/memory/*.md 2>/dev/null
  3. If no placeholders found → memory is already populated. Report "already bootstrapped" and STOP.
  4. 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.

SourceHow to findFeeds into
Package manifestpackage.json, Cargo.toml, pyproject.toml, go.modtechContext (stack), projectbrief (name/description)
README.mdProject rootprojectbrief (what/who/why), techContext (dev setup)
CLAUDE.mdProject rootsystemPatterns (architecture, patterns), techContext (gotchas, env vars)
CONVENTIONS.mdProject rootsystemPatterns (patterns)
Directory structurels at root, then key subdirs (src/, lib/, app/, backend/, frontend/, etc.)systemPatterns (key directories)
Git loggit log --oneline -20progress (recent work), activeContext (current focus)
Git branchesgit branch -aactiveContext (in-flight branches)
Git statusgit status --shortactiveContext (uncommitted work)
Env templates.env.example, .env.template, .env.sampletechContext (env vars)
CI config.github/workflows/, Makefile, Dockerfile, docker-compose.ymltechContext (dev setup, verification commands)
Package scriptsscripts field in package.json or equivalenttechContext (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.example or 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 ls output, 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 -5 messages + 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:
    1. "What's your name and role?" (e.g., "Asha, full-stack developer")
    2. "Any strong preferences for how I work?" (e.g., "be terse", "always show diffs", "Hindi-English mix is fine")
    3. "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/null

Write ~/.agent-daemon/user.md with the user's answers + detected tools.

Phase 4 — Verify

  1. Run ad doctor — all checks should pass
  2. Show a 3-line summary:
    Daemon bootstrapped for [project name]:
    - 6 memory files populated from [sources used]
    - User profile: [populated / already set / skipped]
  3. 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

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.