AgentStack
SKILL verified MIT Self-run

Init

skill-vindm-dotclaude-init · by vindm

Lighter alternative to /dotclaude:bootstrap when you want Layer 6 domain kits only, skipping upstream layers. Orchestrates the relevant subset of domain skills (design / coding / planning / testing / data / ai-workflow) based on project shape — no identity / architecture / process / quality-bar / knowledge-graph / maintenance authoring. Use /dotclaude:init for incremental Layer 6 setup on partial…

No reviews yet
0 installs
6 views
0.0% view→install

Install

$ agentstack add skill-vindm-dotclaude-init

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Init? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

/dotclaude:init — Layer 6 meta-orchestrator

v2 context (read first — added 2026-05-21)

In v1.1, dotclaude introduced /dotclaude:bootstrap as the headline 7-layer setup command. Bootstrap walks project identity → architecture → process discipline → quality bar → knowledge graph → domain kits (this IS Layer 6) → maintenance, authoring CLAUDE.md + docs/ + .claude/ together.

/dotclaude:init is the v1 entry-point — preserved, now positioned as Layer-6-only. Use it when:

  • You already have a CLAUDE.md authored by hand and don't want bootstrap to touch it.
  • You want incremental Layer 6 setup on a partial-brownfield project (some .claude/ artifacts exist; you want to extend them).
  • The project doesn't need the upstream layers yet (early prototype; you want design discipline before deciding on long-term architecture).

Use /dotclaude:bootstrap instead when: greenfield project, no CLAUDE.md, want comprehensive AI dev infrastructure setup (~25–45 min wall-clock for typical 1–5 domain projects). See [README.md](../../README.md) §"How bootstrap works" for the full 7-layer walkthrough.

The two commands are complementary, not competing:

  • /dotclaude:bootstrap = full hierarchical setup (Layers 1–7).
  • /dotclaude:init = Layer 6 only (this skill).

For an even more targeted setup, the user can invoke a single domain skill directly:

  • /dotclaude:design — UI / IA / a11y / visual quality discipline ⭐
  • /dotclaude:coding — file size, code review, decomposition, voice
  • /dotclaude:planning — pre-impl validation, audit routing
  • /dotclaude:testing — test architecture + coverage
  • /dotclaude:data — DB integrity, query discipline, migrations
  • /dotclaude:ai-workflow — LLM workflow cost monitoring + eval discipline
  • /dotclaude:worktree — parallel-session isolation (blocking main-checkout hook + worktree lifecycle)

/dotclaude:init is the meta over those domain skills — it picks which of them flow. It does NOT author the upstream-layer artifacts (CLAUDE.md identity / architecture sections, docs/ knowledge graph, quality-bar/SKILL.md cross-cutting rubric, etc.) — those are bootstrap's lane.

Phase 1 — Project scan (do this BEFORE asking the user anything)

Read in order:

  1. README.md (or README* variant) — the user's own framing
  2. package.json / Cargo.toml / pyproject.toml / go.mod / equivalent — stack signal + dependencies + scripts
  3. Top-level directory structure (ls -la + one level deep) — look for: app/ pages/ src/ lib/ components/ ui/ ios/ android/ infra/ docs/ migrations/ tests/ __tests__/
  4. Existing CLAUDE.md / AGENTS.md / CONTRIBUTING.md — respect existing conventions
  5. git log --oneline -30 — what bug classes recur? "fix:" prefix is the signal
  6. One representative source file per major module — language idioms, conventions

Use these signals to decide which domain skills apply (next phase).

Phase 2 — Domain applicability check

For each domain, decide: does this project NEED this kind of discipline?

| Domain | Apply if project has… | Skip if… | |---|---|---| | design | UI surfaces (web, mobile, desktop, CLI TUI), components, theme files, design tokens | Pure backend / library / dev tool with no human-facing surface | | coding | Any code at all | Truly throwaway prototype | | planning | Multi-module / multi-file changes are common | Single-file utility | | testing | Tests exist OR should exist | Pure exploration / one-off script | | data | Database / persistent state / migrations | Stateless app / pure-compute lib | | ai-workflow | LLM / AI calls in production or eval suites | No AI in scope | | worktree | Several concurrent sessions (interactive + background / scheduled agents), lock files or session-coordination sections in CLAUDE.md, a history of clobbered parallel work | Solo single-session work — recommend AGAINST it explicitly (enforcement without a collision to prevent is pure friction) |

Default: apply most domains. Skip is the exception, with a stated reason.

Show the user the applicability matrix BEFORE running anything:

> "Based on the project scan, I'm planning to run: > - /dotclaude:design — your app/ has React Native screens > - /dotclaude:coding — universal > - /dotclaude:planning — your lib/ is multi-module > - /dotclaude:data — Postgres migrations under db/migrations > - SKIPPING /dotclaude:testing — no test directory found yet > - SKIPPING /dotclaude:ai-workflow — no LLM dependencies > > Confirm before I start, or adjust the list."

Wait for user confirmation.

Phase 3 — Run the domains in sequence

For each domain in the confirmed list, read its SKILL.md and execute its instructions:

  1. skills/design/SKILL.md (if applied)
  2. skills/coding/SKILL.md (if applied)
  3. skills/planning/SKILL.md (if applied)
  4. skills/testing/SKILL.md (if applied)
  5. skills/data/SKILL.md (if applied)
  6. skills/ai-workflow/SKILL.md (if applied)
  7. skills/worktree/SKILL.md (if applied — run LAST: its smoke run should see the other domains' staged artifacts, and its restart + live-fire handoff naturally closes the whole init)

Each domain skill is self-contained: it does its own interview (scoped to that domain), reads the relevant principles from ../../principles/, and authors artifacts to .claude-staging/ in the user's project.

You do NOT have to repeat the meta-level project scan inside each domain — each domain skill may do its own additional scoping reads, but the macro context you've built in Phase 1 stays loaded.

Token discipline: each domain interview should be 3-5 questions, not 10. The cumulative interview across 4-5 domains is what the user is signing up for when they invoke init rather than a targeted single skill.

Phase 4 — Cross-domain coordination

Some artifacts appear in multiple domains' applicability — e.g. forbidden-phrases.txt is referenced by both design (voice / tone) and coding (AI slop). When two domains both want to author the same file, the LAST one wins by default — but call this out:

> "Both /dotclaude:design and /dotclaude:coding proposed a forbidden-phrases.txt. I merged them — design's brand-voice phrases + coding's universal AI-slop phrases. The file is at .claude-staging/rules/forbidden-phrases.txt."

Domains should not stomp on each other silently.

Phase 5 — Final review + commit

After all domains finish, show the user the full .claude-staging/ inventory:

Authored:
  agents/      
  skills/      
  rules/       
  hooks/       

By domain:
  design       
  coding       
  planning     
  data         

Skipped at domain-applicability check: 
Cross-domain merges: 

Walk through 3-5 highlight artifacts and explain the reasoning ("I picked these design benchmarks because you named them in the interview; I added this DB-integrity check because your db/migrations/ shows you've been adding RLS recently").

Wait for explicit user approval, then move .claude-staging/.claude/ and commit with a structured message.

Non-negotiable rules

  1. Project scan first, always. Phase 1 reads happen before ANY question. A question whose answer is obvious from package.json is a wasted question.
  2. Show the domain plan before running. User has veto power. They may want to skip a domain you flagged as applicable, or add one you skipped.
  3. Each domain interview is scoped. Don't ask design questions inside the coding flow. The domain skill knows its own questions.
  4. Stage, never overwrite. All artifacts land in .claude-staging/ until user approves. Then move to .claude/.
  5. Author, do not copy. Domain skills enforce this. If you catch a domain authoring a template-substitute artifact, that's a bug in the domain skill — report it.
  6. A focused .claude/ of 5-10 well-tuned artifacts beats 25 sprawling ones. Resist comprehensiveness. The applicability matrix exists to keep scope tight.

Output format

When all domains complete + user approves, output:

✓ dotclaude:init complete

Domains run: 
Domains skipped: 

In .claude/:
  N agents:  
  N skills:  
  N rules:   
  N hooks:   

Recommended next steps:
  1. 
  2. 
  3. 

Commit the staged .claude/ when ready.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.