dw-solo-skills

This is the thin lane: every skill here assumes one reader, and the loop carries only the ceremony a solo change actually pays for.

◆ What this lane is for

Every skill written here has to earn its place against one failure mode of agentic coding, at the smallest weight that still works:

• Context dies on /clear — the change lives in a tracked file under .ai/work/, not in the session, and is read back from disk rather than reconstructed from scrollback.
• The agent runs on a wrong assumption — a fuzzy idea gets interrogated into decisions before anything is written.
• The process outweighs the change — one artifact instead of spec + plan + notes, one gated pass instead of five auditors and a separate writer.
• A private repo rots — what's durable is kept on your yes: dw-next nominates a term or a decision in the commit that coined it, and dw-land puts each to you at close — the only gate on docs/decisions/ and CONTEXT.md — writes what you name, rewrites stale pointers, and reports the rest or, on your yes, files it to .ai/backlog/ before archiving the change doc (.ai/archive/). Without that you accumulate stale specs and lose the decisions worth keeping.
• Commits drift from your conventions — the scaffold ships a ## Git conventions block every session loads in full, and the hooks refuse what a regex can decide; no git skill sits between.

▸ Quick start

claude plugin marketplace add dominikwozniak/dw-solo-skills
claude plugin install dw-solo
claude plugin install dw-solo-setup
claude plugin install dw-solo-extras   # optional — off-loop skills

Then, in a project of your own: /dw-init scaffolds it, /dw-shape opens the first change.

◇ Task router — which skill for which task

A task may match several rows — read all that apply. ⭑ = explicit-invoke only: say its name (it never auto-fires). The phrases that trigger each skill live in its own description, and the arguments it takes in its own argument-hint — neither is copied here.

Explicit-only skills: dw-ship, dw-init, dw-grain, dw-handoff, dw-prune and dw-unslop. Marked ⭑ in the router; they never auto-fire — say the name. Being invisible to the model, no other skill can delegate to one; another skill suggesting you run it is the route in.

The loop — ? marks the opt-in steps; the spine and what it guarantees are in AGENTS.md.

Parallel changes: queue the ideas as .ai/backlog/ entries, then one worktree + session each — dw-shape asked for a worktree, or claude -w <slug> — and the entry is expanded on its own branch.

Off-loop — the dw-solo-extras plugin; reached for beside the loop, not on the way from shape to ship.

The same plugin ships two subagents, which are not skills and have no / form. Both are read-only — the tool list is Read, Grep, Glob — and the split between them is names against meaning:

• dw-docs-drift reads a repo's doc layer — AGENTS.md and its Task Router, docs/agents/, CONTEXT.md, docs/decisions/ — and reports every named referent that is absent or dead at a real file:line. Call it as @dw-solo-extras:dw-docs-drift, or just ask whether the docs are still true.
• dw-decisions reads what docs/decisions/ decides: which records govern a path, whether a nomination clears the bar it is handed, and which active records no longer hold or collide. Call it as @dw-solo-extras:dw-decisions, or ask what the project already settled.

Setup — the dw-solo-setup plugin; run once per repo.

⚙ How it works — the design in one screen

• Persistence in the skill, not a wrapper. Each SKILL.md writes its own .ai/ path as part of its procedure, so the change doc lands automatically and travels with the installed plugin — no .claude/commands/ glue layer.
• .ai/ is tracked, one folder per change, no central index. A registry becomes a merge-conflict magnet once tracked; discovery is by directory name + frontmatter, matched to the git branch.
• Persistent, then archived. The change doc is tracked so a /clear changes nothing, and moved to .ai/archive/ at merge so work/ doesn't accumulate stale specs, trimmed to a receipt: what the user got, and the PR that holds the worked state. What's genuinely durable is still promoted.
• One gate, not a skill boundary. The fuller workflow separates read-only auditors from the one writer so an auditor can't under-report what it couldn't fix. Here you read every finding yourself, so a single pass reports first and mutates only after explicit approval.
• Thin harness, fat skills. The process lives in the markdown, not in glue code — so every model upgrade improves the skills for free. (Inspired by "Fat Skills".)
• One always-loaded file, under a budget it declares itself. The scaffold writes a tracked AGENTS.md with CLAUDE.md symlinked at it — rules, a Task Router into docs/agents/, and the two command bullets the hooks read. Tracked because a gitignored memory file reaches neither a fresh clone nor a worktree; one file because a second always-loaded one forks the corpus. A shipped zero-dependency checker holds the budget and the router honest.
• Technology-agnostic. Test/lint/run commands are read from your project (AGENTS.md → manifests → the code), never hardcoded.

▤ Project structure

The layout, and the one rule that comes with it — a skill is edited at skills/<name>/SKILL.md and never through the plugins/… symlinks that point at it — are in AGENTS.md.

◆ Contributing

Layout, conventions and the gate live in AGENTS.md (CLAUDE.md is a symlink to it), which routes onward — the add-a-skill checklist is in docs/agents/skills-and-plugins.md.

▪ License

MIT