plugins/development-harness/skills/development-harness/SKILL.md
Routes to the correct dh skill entry point by intent. Use when unsure which development-harness skill to invoke, starting a development workflow, or invoking /dh directly. Covers capture, groom, plan, execute, single task, quality gates, and milestone routing.
npx skillsauth add jamie-bitflight/claude_skills development-harnessInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill routes to the correct entry point for the development lifecycle. Read it to decide which skill to invoke — not to execute work.
/dh:add-new-feature ──> /dh:implement-feature ──> /dh:complete-implementation
(planning) (execution loop) (quality gates)
The development-harness plugin implements the structured development lifecycle for tracked backlog items. It spans capture through verified closure using a chain of skills backed by GitHub Issues as the source of truth and ~/.dh/projects/{slug}/ as the local state directory.
Skills available: /dh:create-backlog-item, /dh:groom-backlog-item, /dh:work-backlog-item, /dh:add-new-feature, /dh:implement-feature, /dh:complete-implementation, /dh:work-milestone
Plugin-level source copies exist at plugins/development-harness/skills/ for each skill.
flowchart TD
Start([What do you want to do?]) --> Q1{Intent?}
Q1 -->|Capture new work —<br>bug, feature idea, observation| Create["/dh:create-backlog-item<br>Modes: guided intake, quick title, --auto title<br>Writes to ~/.dh/projects/{slug}/backlog/"]
Q1 -->|Prepare an item for planning —<br>verify claims, map impact, estimate effort| Groom["/dh:groom-backlog-item {title|section|all}<br>RT-ICA + parallel swarm: fact-checker,<br>impact-analyst, rtica-assessor, classifier, groomer<br>Requires: item exists in backlog"]
Q1 -->|Plan AND execute a backlog item<br>end-to-end through closure| Work["/dh:work-backlog-item {title|#N|--auto}<br>Handles: auto-groom, RT-ICA gate, SAM planning,<br>GitHub sync, close, resolve<br>STOPS if item already has a Plan field"]
Q1 -->|Plan a feature — produce SAM artifacts<br>without executing| Plan["/dh:add-new-feature {feature description}<br>Phases: discovery → codebase analysis →<br>architecture spec → task decomposition →<br>validation → context manifest<br>Output: feature slug + P{id} task plan"]
Q1 -->|Execute an existing plan —<br>task plan already produced| Execute["/dh:implement-feature {plan path or slug}<br>Loops ready tasks, dispatches agents,<br>calls complete-implementation when all tasks COMPLETE"]
Q1 -->|Work a single specific task<br>inside an existing plan| Single["/dh:start-task {plan path} --task {task-id}<br>Used by implement-feature per-task dispatch —<br>invoke directly to target one task"]
Q1 -->|Run quality gates after<br>all tasks are COMPLETE| QG["/dh:complete-implementation {plan path|#N}<br>6-phase SAM path (with plan) or<br>3-phase proportional path (issue only):<br>code review → verification → integration →<br>doc drift → doc update → context refinement"]
Q1 -->|Work a full milestone<br>in parallel isolated worktrees| Milestone["/dh:work-milestone<br>Wave-based parallel execution — each item<br>gets its own worktree. Use /dh:groom-milestone first."]
flowchart TD
Capture["/dh:create-backlog-item<br>Per-item file in ~/.dh/.../backlog/"] --> Groom
Groom["/dh:groom-backlog-item<br>RT-ICA + impact radius + fact-check<br>Item status: needs-grooming → groomed"] --> Work
Work["/dh:work-backlog-item<br>Auto-groom gate → RT-ICA gate →<br>SAM planning via /add-new-feature<br>Attaches plan to backlog item"] --> Execute
Execute["/dh:implement-feature<br>SAM dispatch loop — ready tasks →<br>agents → hooks update task status"] --> QG
QG["/dh:complete-implementation<br>6 quality gate phases → status:verified label<br>Fixes #N commit — issue closure"] --> Done(["Item resolved"])
Work -.->|item already has Plan field| Execute
Work -.->|close or resolve mode| Done
Key invariants derived from the skill sources:
/dh:work-backlog-item stops immediately when the item already has a Plan field — use /dh:implement-feature instead/dh:work-backlog-item stops at the RT-ICA gate when MISSING conditions remain unresolved/dh:implement-feature must NOT include Fixes #N — that trailer is reserved for the final commit in /dh:complete-implementationstatus:verified label applied by /dh:complete-implementation is a prerequisite for /dh:work-backlog-item resolve| Situation | Skill |
|---|---|
| Item does not exist yet | /dh:create-backlog-item |
| Item exists, not yet groomed | /dh:groom-backlog-item {title} |
| Item is groomed, no plan yet | /dh:work-backlog-item {title} |
| Item has a Plan field | /dh:implement-feature {plan path or slug} |
| Plan is executing, one task needs focus | /dh:start-task {plan} --task {id} |
| All tasks complete, run quality gates | /dh:complete-implementation {plan path} |
| Issue number, no plan | /dh:complete-implementation #{N} (proportional gates) |
| Groomed item, skip to planning directly | /dh:add-new-feature {description} then /dh:implement-feature |
| Full milestone in parallel worktrees | /dh:groom-milestone then /dh:work-milestone |
| Dismiss without completing | /dh:work-backlog-item close {title} |
| Mark completed with evidence | /dh:work-backlog-item resolve {title} |
development
When an application needs to store config, data, cache, or state files. When designing where user-specific files should live. When code writes to ~/.appname or hardcoded home paths. When implementing cross-platform file storage with platformdirs.
testing
Enforce mandatory pre-action verification checkpoints to prevent pattern-matching from overriding explicit reasoning. Use this skill when about to execute implementation actions (Bash, Write, Edit) to verify hypothesis-action alignment. Blocks execution when hypothesis unverified or action targets different system than hypothesis identified. Critical for preventing cognitive dissonance where correct diagnosis leads to wrong implementation.
tools
Reference guide for the Twelve-Factor App methodology — 15 principles (12 original + 3 modern extensions) for building portable, resilient, cloud-native applications. Use when evaluating application architecture, designing cloud-native services, reviewing codebases for methodology compliance, advising on configuration, scaling, observability, security, and deployment patterns. Incorporates the 2025 open-source community evolution and cloud-native reinterpretations of each factor.
tools
Converts user-facing documentation (how-to guides, tutorials, API references, examples) in any format — Markdown, PDF, DOCX, PPTX, XLSX, AsciiDoc, RST, HTML, Jupyter notebooks, man pages, TOML/YAML/JSON configs, and plain text — into Claude Code skill directories with SKILL.md plus thematically grouped references/*.md files. Use when given a docs directory or mixed-format documentation to transform into an AI skill. Uses MCP file-reader server for binary formats.