Dev Process Toolkit

A Claude Code plugin that adds Spec-Driven Development (SDD) and TDD workflows to any project. Includes 16 commands, 8 agents, spec templates, and documentation.

Features

• Spec-Driven Development (SDD) — requirements, technical, testing, and plan files as the source of truth
• Multi-agent TDD orchestrator — /tdd runs RED → GREEN → REFACTOR → AUDIT via four forked subagents (tdd-test-writer, tdd-implementer, tdd-refactorer, tdd-spec-reviewer) with context isolation, a strict tdd-result YAML hand-off, and bounded retries; /implement invokes it inline per FR
• Bounded three-stage self-review — Stage A spec compliance → Stage B two-pass code-reviewer agent (Pass 1 spec compliance, Pass 2 code quality, fail-fast) → Stage C hardening, capped before human escalation
• Deterministic quality gates — 66 numbered /gate-check probes (typecheck + lint + test + spec/plan/frontmatter/branch hygiene) override LLM judgment
• Universal pre-commit branch gate — every commit-producing skill calls requireCommittableBranch; trunk-OK narrows to ci only, so chore/docs/feat cannot land on main accidentally
• Non-technical drafting (--no-tech) — /brainstorm and /spec-write skip the technical-design + testing interviews; FR ships with needs_technical_review: true and /implement refuses until a reviewer fills it in
• Topic-aware spec retrieval — spec-researcher Read-only Haiku subagent (invoked by /brainstorm and /spec-write via the spec-research fork) returns related FRs from active + archived specs as a fixed-shape ≤ 25-line block, no parent-context pollution
• Dependency docs catalog — /deps manages a git-tracked specs/deps.yaml manifest of sibling packages (add/edit/delete/list/sync); a deps-researcher Read-only Haiku subagent (invoked by /brainstorm and /spec-write via the deps-research fork) folds each sibling's docs/ tree into design context as a fixed-shape ≤ 25-line block, so consumer projects with several private packages stop rediscovering APIs
• Privacy-first incident reports — /report-issue bundles repo state + dev narrative, scrubs secrets via 7 patterns (Anthropic / OpenAI / GitHub PAT / AWS / JWT / generic / AWS-secret), previews before publish, then posts a secret GitHub gist; the URL round-trips into /brainstorm <gist-url> for self-debug
• Diátaxis docs generation — /docs stages fragments per FR (--quick), merges with human approval (--commit), or regenerates the canonical tree (--full)
• Task tracker sync — Linear, Jira, or none; auto-claim on FR start, auto-release on archive; adapter-agnostic Provider interface
• Conventional Commits v1.0.0 — local commit-msg hook (POSIX shell by default or opt-in commitlint)
• Atomic release commits — /ship-milestone enforces the multi-file Release Checklist + folds staged doc fragments into the canonical tree in one commit
• Spec lifecycle management — ULID-keyed FRs, /spec-archive for manual archival by ULID / tracker ID / M<N>, post-archive drift checks
• Browser-based UI verification — /visual-check via Chrome DevTools MCP
• Project-authored verification skills — declare a verify_skill in a ## Verification block and /implement's Phase 4b″ runs your project's own "does it actually run / look right?" check after the gate passes; /setup and /implement scaffold a stack-aware stub, or fall back to /visual-check (see plugins/dev-process-toolkit/docs/verification-skills.md)
• Stack-adaptive setup — auto-detects TypeScript, Flutter, Python, Kotlin; generates CLAUDE.md, settings, and the commit-msg hook

Install as Plugin

/plugin marketplace add nesquikm/dev-process-toolkit

/plugin install dev-process-toolkit@dev-process-toolkit

Then run the setup command in your project:

/dev-process-toolkit:setup

This detects your stack, generates a CLAUDE.md, configures settings, and optionally creates spec files — all adapted to your project.

Prerequisites

bun must be installed. The toolkit's adapters/_shared TypeScript helpers and tracker adapters — invoked by skills via bun run — execute on bun, regardless of your own project's stack. This is a requirement of the toolkit's own machinery, not of your code: a Flutter project still gates via fvm flutter, a Python project via its own toolchain. You do not rewrite your project in TypeScript or adopt bun for your own gates.

Install bun and verify:

curl -fsSL https://bun.sh/install | bash
bun --version

Workflow

The toolkit groups its 16 user-invoked skills into a four-phase lifecycle. Read left-to-right for the full path, or jump to whichever phase matches what you're doing now.

flowchart LR
    classDef spine fill:#e1f5e1,stroke:#2e7d32,stroke-width:3px,color:#000
    classDef secondary fill:#f5f5f5,stroke:#999,stroke-width:1px,color:#555
    subgraph Setup
        direction TB
        setup(["/setup"]):::spine
    end
    subgraph Plan
        direction TB
        brainstorm(["/brainstorm"]):::spine
        spec_write(["/spec-write"]):::spine
        brainstorm ~~~ spec_write
    end
    subgraph Build
        direction TB
        implement(["/implement"]):::spine
        tdd["/tdd"]:::secondary
        gate_check["/gate-check"]:::secondary
        debug["/debug"]:::secondary
        visual_check["/visual-check"]:::secondary
        simplify["/simplify"]:::secondary
        spec_review["/spec-review"]:::secondary
        report_issue["/report-issue"]:::secondary
        implement ~~~ tdd
        tdd ~~~ gate_check
        gate_check ~~~ debug
        debug ~~~ visual_check
        visual_check ~~~ simplify
        simplify ~~~ spec_review
        spec_review ~~~ report_issue
    end
    subgraph Ship
        direction TB
        spec_archive["/spec-archive"]:::secondary
        docs["/docs"]:::secondary
        pr["/pr"]:::secondary
        ship_milestone(["/ship-milestone"]):::spine
        spec_archive ~~~ docs
        docs ~~~ pr
        pr ~~~ ship_milestone
    end
    Setup --> Plan
    Plan --> Build
    Build --> Ship

Under the hood, /implement invokes the /tdd orchestrator inline per FR — /tdd forks four subagents (tdd-test-writer, tdd-implementer, tdd-refactorer, tdd-spec-reviewer) into isolated contexts and parses their tdd-result YAML hand-off. It runs gate commands inline (e.g., bun test) rather than invoking the /gate-check skill (which layers 66 probes on top of those commands), and invokes /docs --quick once per FR for the Phase 4b doc fragment. /brainstorm and /spec-write similarly fork the read-only spec-research skill (paired with the spec-researcher Haiku subagent) for topic-aware retrieval of related active + archived FRs. After self-review and human approval, /implement commits and stops — you open the PR via /pr separately. /ship-milestone invokes /docs --commit --full to fold staged fragments into the canonical docs tree before cutting the release commit.

Spine skills (bold, stadium-shaped) are the recommended invoke path; secondary skills (muted rectangles) are auxiliary tools and auto-invoked helpers.

Tracker integration (Linear, Jira, or mode: none) threads through Plan → Build → Ship: /spec-write files the FR, /implement claims it on entry and releases on success, and /ship-milestone archives the milestone group.

All commits in toolkit-managed repositories follow Conventional Commits v1.0.0, enforced locally by a commit-msg hook that /setup installs (a POSIX-shell hook by default; opt into --commitlint for projects with Node/Bun tooling).

The diagram above is a deliberately high-level lifecycle map. For the mechanics it omits — the TDD and self-review loops, the deterministic gates/evals, the spec-research / deps-research forks, and every artifact-write point — see docs/workflow-overview.md.

What You Get

Commands

Commands are invoked with the /dev-process-toolkit: plugin-namespace prefix in actual use; the prefix is omitted from the table for readability (matches the Agents-table convention below). The Args column mirrors each skill's argument-hint: frontmatter — surfaced here because Claude Code does not yet render argument hints in autocomplete for plugin-namespaced skills (upstream issue #43401).

Command	Purpose	Args
/setup	Set up SDD/TDD process for your project	[new or existing]
/brainstorm	Socratic design session before writing specs (for open-ended features)	[--no-tech] [<feature or problem description> | <gist-url>]
/spec-write	Guide through writing spec files (requirements, technical, testing, plan)	[--no-tech] [requirements | technical | testing | plan | all]
/implement	End-to-end feature implementation with TDD and bounded three-stage self-review (Stage A spec compliance → Stage B two-pass delegated review: Pass 1 spec compliance, Pass 2 code quality, fail-fast → Stage C hardening)	<milestone, task description, issue number, "next", or "all">
/tdd	RED → GREEN → REFACTOR → AUDIT cycle	<FR-id>
/gate-check	Deterministic quality gates (typecheck + lint + test)	[--fix to auto-fix lint issues]
/debug	Structured debugging protocol for failing tests or unclear gate failures	<failing test, error message, or symptom>
/spec-review	Audit code against spec requirements