End-to-end TDD development workflow with multi-agent team review and skill-based quality gates. Plans, discusses, and implements features using strict RED-GREEN-REFACTOR test-driven development. Handles worktree-based branch isolation (from latest remote), PRD and technical requirements creation, plan-mode exploration, embedded team discussion at every deliverable phase, skill-agent quality gates (review-local, orch-qa, scenario-gen, pm-review, e2e-test), mandatory test case design via test-scenario skill, TDD implementation, fresh agent implementation review, conventional commits, optional PR creation with self-pr-review and address-pr-comments. Use when the user asks to implement a feature, fix a bug, refactor code, add tests, or any multi-step development task. Triggers on "implement X", "build Y", "add feature Z", "fix bug", "refactor", "implement with TDD", "add feature with tests", "build X following TDD", or when the user invokes /dev-workflow.
End-to-end TDD development workflow with multi-agent team review and skill-based quality gates. Plans, discusses, and implements features using strict RED-GREEN-REFACTOR test-driven development. Handles worktree-based branch isolation (from latest remote), PRD and technical requirements creation, plan-mode exploration, embedded team discussion at every deliverable phase, skill-agent quality gates (review-local, orch-qa, scenario-gen, pm-review, e2e-test), mandatory test case design via test-scenario skill, TDD implementation, fresh agent implementation review, conventional commits, optional PR creation with self-pr-review and address-pr-comments. Use when the user asks to implement a feature, fix a bug, refactor code, add tests, or any multi-step development task. Triggers on "implement X", "build Y", "add feature Z", "fix bug", "refactor", "implement with TDD", "add feature with tests", "build X following TDD", or when the user invokes /dev-workflow.
[!WARNING]
DEPRECATED (2026-06-01). Superseded by the upstream
mattpocock/skills workflow:
grill-me / grill-with-docs → to-prd → tdd →
improve-codebase-architecture (plus diagnose, triage, zoom-out,
prototype, handoff). This plugin is disabled globally and kept here
for reference only. Re-enable by flipping
dev-workflow@hideki-plugins back to true in ~/.claude/settings.json.
Not covered by the upstream replacement: multi-agent team review and
automated PR creation ( / ).
self-pr-review
address-pr-comments
Dev Workflow
End-to-end development with team review, skill agents, and strict TDD discipline.
Core Principles
Requirements First — PRD and Tech Req before any code
Team Discussion at Every Deliverable — Each phase that produces a deliverable gets its own agent team review
Always Confirm Agents — Present which agents will run, get user feedback before spawning
Tests Before Implementation — RED -> GREEN -> REFACTOR, always, no exceptions
Present the plan via ExitPlanMode for user approval
If rejected, iterate until approved
Phase 3: Test Case Design
Design comprehensive test cases before writing any implementation code.
Step 3a: Automated Test Outline (mandatory)
Present to user:
Test Design Agent: /test-scenario — generate rough test outline from plan
Proceed?
Invoke /test-scenario skill to generate a test outline from the approved plan.
Always show the generated test cases to the user.
Pass the feature description, acceptance criteria, and --bdd flag if set
The skill generates structured test cases covering happy path, edge cases, error handling, constraints, and data integrity
Merge with team discussion findings from prior phases
Read references/skill-agents.md for invocation details.
Step 3b: Manual Test Design (always)
Read references/test-design.md for the 9 test categories. Fill gaps not covered by the test-scenario outline, particularly categories 5-9 (Integration Points, Output Format, Security, Ordering, Resource Limits).
If --bdd is set, write test cases in Given/When/Then Gherkin format. Read references/bdd-guide.md.
Step 3c: Test Design Verification (mandatory)
Present to user:
Test Verification Agent: /test-scenario — verify combined test design for completeness
Proceed?
Invoke /test-scenario again to validate the combined test design.
Always show the verified test cases to the user.
Evaluates coverage against acceptance criteria, missing categories, test quality
User must approve the test design before proceeding to RED
If gaps found, iterate on the test design
Test-First Checklist (all must be true before proceeding):
All acceptance criteria have corresponding tests
Edge cases from team discussion are covered
Security concerns are tested
Error handling scenarios are tested
Tests compile but fail (RED state confirmed)
Phase 4: RED — Write Failing Tests
Create test file with all designed test cases
Use descriptive test names: MethodName_StateUnderTest_ExpectedBehavior
Structure each test with clear Arrange/Act/Assert (or Given/When/Then if --bdd)
Create minimal stub implementation that throws NotImplementedException (or equivalent)
Run tests — ALL MUST FAIL
If any test passes, the stub is too complete — simplify it
Commit: test: add failing tests for <feature>
Phase 5: GREEN — Make Tests Pass
Pick one failing test — start with the simplest
Write the minimum code to pass that test
Run tests: target passes, previous tests pass, remaining still fail
Repeat for each failing test
Do NOT add features not covered by tests
Apply security measures identified in prior phases
Wire up the implementation to the system (CLI, API, UI) as needed
When all tests pass, commit: feat: implement <feature>
If Critical issues found: return to Phase 6 (REFACTOR), fix, re-run.
Proceed only when clean or user explicitly approves.
Phase 8: Commit & PR
Commit Strategy:
Read references/commit-guide.md for full conventions.
git stash all uncommitted changes
For each logical group:
a. git checkout stash -- <file(s)> to restore specific files
b. If a file has multiple logical changes, apply edits manually then stage
c. git add <file(s)> and git commit
If confirmed: invoke /self-pr-review with PR number
If --address-comments true and comments remain: invoke /address-pr-comments
Report final PR status
Read references/skill-agents.md for invocation details.
Worktree Cleanup (always, as final step):
Change back to the main repo root: cd "$REPO_ROOT"
Remove the worktree: git worktree remove "$REPO_ROOT/.worktrees/<branch-name>"
If uncommitted changes remain, use --force
Verify cleanup: git worktree list
BDD vs TDD
TDD is always enforced. --bdd only changes test format: Method_State_Expected (TDD) vs Given/When/Then Gherkin (BDD). Use BDD when stakeholder communication matters.
Example Invocations
Standard Development
/dev-workflow
Task: Add a health check endpoint
Requirements:
- Return 200 with JSON status
- Include uptime and version info
BDD Mode
/dev-workflow --bdd true
Task: Implement user authentication flow
Quick Solo Mode
/dev-workflow --team false --approval false
Task: Fix date parsing bug
Scenario: Full workflow with PRD, tech req, and team review
Given the user asks to implement a feature
When the user invokes /dev-workflow
Then the skill creates a PRD, gets tech requirements, creates a worktree,
plans with team review, designs tests with /test-scenario,
executes RED-GREEN-REFACTOR, runs quality gates, gets approval,
reviews implementation with a fresh agent, commits, and cleans up
Scenario: PRD created from user request
Given the user invokes /dev-workflow with a task description
When Phase 0a runs
Then a PRD is created covering problem, goals, user stories, acceptance criteria
And the user reviews and approves the PRD before any technical work begins
Scenario: Technical requirements derived from PRD
Given the PRD is approved
When Phase 0b runs
Then the user is shown which agents will analyze the PRD
And agents produce a Technical Requirements Document
And the user approves the Tech Req Doc
Scenario: Branch created from latest remote
Given the user invokes /dev-workflow
When Phase 1 runs
Then git fetch origin <base-branch> runs before worktree creation
And the feature branch is based on origin/<base-branch> (latest remote state)
Scenario: Fetch failure falls back to local branch
Given the remote is unreachable
When Phase 1 attempts git fetch
Then the skill warns and branches from local <base-branch> instead
Scenario: Team discussion embedded in Plan phase
Given Phase 2 Plan is drafted
When --team true (default)
Then agents review the plan from architecture, security, resource, devil's advocate perspectives
And findings are synthesized and the plan is updated before user approval
Scenario: Test scenario skill generates and verifies tests
Given Phase 2 Plan is approved
When Phase 3 runs
Then /test-scenario generates a rough test outline (Step 3a, shown to user)
And manual test design fills gaps (Step 3b)
And /test-scenario verifies the combined design (Step 3c, shown to user)
And the user approves before RED
Scenario: Quality gates run with standard preset
Given Phase 6 REFACTOR completes
When Phase 6a runs (default --quality-gate standard)
Then user is shown which agents will run and confirms
And review-local and orch-qa+scenario-gen are spawned as parallel agent pairs
And Critical findings block progression until addressed
Scenario: Fresh agent reviews actual implementation before PR
Given Phase 7 Approval completes
When Phase 7a runs
Then a new agent reviews the actual code diff (not the plan)
And findings are presented to the user before Commit & PR
Scenario: Quality gates skipped with --quality-gate none
Given the user invokes /dev-workflow --quality-gate none
When Phase 6 completes
Then no quality gate skills are invoked
Scenario: Quick fix without team overhead
Given the user invokes /dev-workflow --team false --approval false
Then team discussion and approval are skipped but TDD and test-scenario still run
Scenario: Worktree isolation and cleanup
Given the workflow completes
Then the worktree is removed and git worktree list confirms no orphans
Scenario: Agent confirmation at every phase
Given any phase is about to spawn agents
Then the user is always shown which agents will run and can adjust before confirming
