Bootstrap

/dotclaude:bootstrap — thin generator over the consumable base

The base is consumed, not authored. Enabling the dotclaude plugin already gives the project the universal layer: the operating-discipline skill (how to work), the auditor agents (code-review, pre-flight, test-architect, skill-vs-code-audit, product-direction-validator, dispatchable as dotclaude:<name>), the process/knowledge skills (knowledge-layers, decomposition), and the universal guard hooks (git-safety, secret-leak, file-size, session-start git context, uncommitted-on-clear). The companion dotclaude-design plugin adds the design/UX auditors (a11y-audit, ux-audit, interaction-audit, flow-audit, pages-audit, design-token-audit, product-designer) and design-focused skills for projects with a human-facing surface. Bootstrap does NOT re-author any of these.

Bootstrap authors only what a shared file cannot carry — the project-specific layer:

The thin local CLAUDE.md is the headline change from older bootstrap: it carries identity + project routing + project verification, and points at the consumed operating-discipline skill for the universal "how you work" rather than restating ~250 lines of it.

Phase 0 — Enable the base (the consume step)

Before authoring anything, confirm the dotclaude plugin is enabled in this project (so the universal base is live). If it isn't, tell the user how to enable it and what it provides, and that bootstrap will author only the project-specific layer on top. The base is the floor; bootstrap adds the project's own facts.

Phase 1 — Project scan (before ANY question)

Read the project so the interview only asks what the code can't answer. Run these, mapping each to a downstream authored layer:

• Shape: ls -la, README.md head → project name, one-paragraph description, top-level dirs. (→ Identity, Architecture, Knowledge graph)
• Stack: package.json / pyproject.toml / Cargo.toml / go.mod (+ the scripts block) → language, framework, build/test/lint commands. (→ Architecture, the DoD verification commands, dotclaude.yml)
• Existing infra: read CLAUDE.md, AGENTS.md, .claude/, docs/ fully if present → the brownfield-vs-greenfield decision (modes below).
• Git: git log --oneline -30, contributors, age, commit-prefix conventions → maturity tag, solo-vs-team, the task-classification rows.
• Surfaces: UI files (components/, app/, pages/), DB (migrations/, ORM imports), AI deps, native (ios/, android/, expo) → which auditor agents the project will actually dispatch, what the quality bar covers.

End Phase 1 with a one-paragraph mental-model summary (name · stack · existing infra scale · maturity · UI/DB/AI/native present · operating mode). Skip any question whose answer is already in it.

Phase 2 — Author the project-specific layer (only)

Interview is short — only the un-shareable layers. Author to .claude-staging/ + docs-staging/ + CLAUDE.md.draft, confirm each before the next.

Identity → CLAUDE.md.draft opening

Vision (one sentence), ICP (wedge), production-vs-internal, stage, ## Moat (name what's NOT the moat), ## Anti-vision. Bar: ICP named specifically; moat names its own negation. (Identity is the most project-specific thing there is — no shared file can carry it.)

Architecture → CLAUDE.md.draft + project hooks + dotclaude.yml

• CLAUDE.md "Architecture": layer model, one-line-per-layer, boundary statements, constraints — each constraint with WHY + WHERE-ENFORCED. Add the trailing anchor comment: "new constraints accrue here as one bullet with WHY + WHERE-ENFORCED; graduate recurring memory lessons into constraints when they fire repeatedly."
• dotclaude.yml — config for the base's config-needing guard templates the project opts into (file-size ceiling, design-token theme path, import-boundary rules, console-log allow-paths). The universal guards already fire from the plugin; here you only configure the project-tunable ones. The file also carries an artifacts: map recording paths to domain-specific elicitations that consumed agents read at runtime:

  artifacts:
    code-anti-patterns: .claude/dotclaude/code-anti-patterns.md
    test-risk-model: .claude/dotclaude/test-risk-model.md
  

• Project boundary hooks — copy the relevant config-needing templates from the plugin's hook-templates/ into .claude-staging/hooks/ with the project's values (these are project-specific, so they're authored locally, not consumed). Do NOT re-author the universal guards — they come from the plugin.

Quality bar → .claude-staging/rules/<domain>-north-star.md (non-design only)

Bootstrap does NOT author the design north-star or the design-system reference — eliciting named visual/UX benchmarks (Tier-1 chrome reference + Tier-2 domain references + anti-references) is the companion dotclaude-design plugin's job, run via /dotclaude:design. It writes both .claude/rules/design-north-star.md and .claude/rules/design-system.md, which the design audit agents (ux-audit, a11y-audit, …) read at runtime. If Phase 1 found a human-facing UI surface, point the user at /dotclaude:design here rather than interviewing for visual benchmarks yourself.

Bootstrap still authors a non-design quality bar where one applies and the project has no UI to benchmark — e.g. api-north-star.md with named comparable-API references (React Query for hook ergonomics, Stripe for API design, etc.) + the demo test. No applicable non-design quality bar → skip (log the reason).

Knowledge graph → docs-staging/ + the task table

• docs-staging/README.md — reading order + authority hierarchy + naming/archive conventions (the conventions are universal; the instance is the project's). Make docs/archive/** Read-denied via .claude/settings.json.
• Subdirectory skeleton (brainstorms/ specs/ plans/ audits/ archive/...) + product/capabilities.md scaffold if opted in.
• The task-classification routing table → CLAUDE.md.draft "How You Work". This IS project-specific (it routes to the project's task types + names which dotclaude:<agent> to dispatch + project specialists). 5+ rows, an Ambiguous row mandatory, verb-led cells. (The principles of how to work are consumed from operating-discipline; the routing table is authored here because it's the project's own map.)
• Definition of Done → CLAUDE.md.draft, with this project's real verification commands (the lint/test commands from Phase 1) — so "verified" is unambiguous.

The methodology pointer (hybrid always-on)

The consumed operating-discipline skill is soft always-on (loads on task context). For a hard every-session guarantee, add ONE line near the top of CLAUDE.md.draft: "How you work: follow the operating-discipline skill (provided by the dotclaude plugin) — understand before building · reason to the right solution · goal-driven complete execution · depth by default, ceremony on demand." This is the hard-always-on hook that pulls the soft-loaded skill. Do NOT paste the full methodology — point at it.

Phase 3 — Stage → review → commit

Stage everything in .claude-staging/ + docs-staging/ + CLAUDE.md.draft. Present the inventory, walk the user through 3–5 distinctive authored elements explaining the reasoning ("I set your moat to X, anti-vision to Y, per Q-…"; "your task table routes UI features to dotclaude:product-designer"). Wait for explicit approval ("ship it" / "yes commit" — not silence / "ok"). On approval, move staged → project, merge into existing CLAUDE.md section-by-section in APPEND mode. Then output a summary: what was authored (project layer), what is consumed from the plugin (the base), and recommended next steps.

Brownfield handling

The Phase 1 infra read sets the mode:

• APPEND (existing CLAUDE.md < 50 LOC OR .claude/ < 5 artifacts): author only the missing project-specific layers; never stomp; final CLAUDE.md merge is section-by-section with per-section approval.
• REFUSE + recommend (existing CLAUDE.md > 200 LOC AND structured AND .claude/ > 10 artifacts): don't run end-to-end. Recommend per-layer commands or an audit. Offer fresh-overwrite only on a double-confirmed explicit request. The recommendation IS the value-add.
• FRESH (no existing infra): full project-specific authoring.

A comprehensive existing project is often a /distill candidate (push its universal lessons UP into the base), not a bootstrap target — surface that.

Non-negotiable rules

1. Consume, don't re-author. The base (operating-discipline, the auditor agents, the universal hooks, the process/knowledge skills) comes from the plugin. Authoring local copies defeats consume-direct and creates drift. If a project needs to amend a base artifact, it shadows it by same-name — a deliberate exception, not the default.
2. Project scan before any question. A question answerable from Phase 1 is a wasted question.
3. Stage before commit; explicit approval gate ("ship it", not silence).
4. The thin CLAUDE.md points at the methodology, never restates it. Identity + architecture + task table + DoD + the one-line operating-discipline pointer. Not 250 lines of how-to-work.
5. Never stomp existing content — APPEND/REFUSE are binding.
6. The task-classification table's Ambiguous row is mandatory.
7. Anonymization is not bootstrap's concern — it authors project-owned content into the user's own repo. (Anonymization governs /distill writing UP into the public plugin, not bootstrap writing DOWN into a project.)

See also

• interview.md — the short interview (identity / architecture / quality-bar / knowledge-graph only; process / domain / maintenance are consumed, not interviewed).
• Why bootstrap shrank: the consume-direct model, the balanced split, and the plugin-mechanics constraints (rules aren't pluggable → methodology is the operating-discipline skill).
• The consumable base lives in ../ (the plugin's agents/, skills/, hooks/).