| name | agentic-workflow |
| description | The Structured Agentic Development Workflow — orchestrates brainstorm, write-plan, build-phase, 3p-review, handoff-summary, triage, test-driven-development, systematic-debugging, and verification-before-completion skills. Use when starting new work, switching between development phases, or when the user asks about the workflow. A dedicated build model uses the build-model workflow instead of this one. |
| user-invocable | false |
The Structured Agentic Development Workflow
You are operating under a structured workflow that treats you as a highly capable engineer that lacks object permanence. To produce senior-level results, you follow a rigid scaffolding of context, constraints, and deterministic planning.
Configurable Preferences
Some aspects of this workflow are user-configurable via /workflow-config. When a preference is set, it is stored in your agent's persistent memory. Check memory for these settings and respect them across all phases:
- Testing methodology: TDD (default) or BDD. When BDD is active, the build phase uses BDD-style test specifications (Given-When-Then, feature files) instead of unit-first TDD. The core rule — "test first, always" — applies regardless of methodology.
- Output style: Normal (default) or caveman (lite/full/ultra). When caveman is active, all workflow phases adapt their prose to the requested brevity level. Technical accuracy is never sacrificed — only verbosity changes. Caveman compatibility is built into this workflow and works independently of the separate Caveman skills package.
The Workflow Phases
Every significant change follows this cycle: Brainstorm → Plan → Build → 3rd-Person Review → Verify. You must never skip phases or collapse them together.
Phase Transitions
You MUST drive phase transitions forward automatically. Within the build loop (implement → test → self-review → next phase), do not wait for the user to tell you to proceed — own the process. For cross-phase transitions (e.g., brainstorm → plan), suggest and confirm. Use this guide:
| Current State | Signal to Transition | Suggest |
|---|
| Open-ended discussion | User describes a problem or feature need | → /brainstorm |
| Brainstorm complete | Options explored, decision audit passed, user has picked a direction | → /write-plan |
| Plan approved | Both plan-review passes complete, and user says "approved", "let's build", or "proceed" | Move plan from new/ to docs/plans/ with mv (plain shell — not git mv; the plan may not be tracked yet). → /build-phase |
| Implementing code | About to write production code | → /test-driven-development (default) or BDD-style tests (if BDD is configured in memory) |
| Build hits a plan defect | Plan is wrong, impractical, or fights the codebase — not merely ambiguous | /build-phase halts with the problem and a proposed fix → user amends the plan, overrules, or returns it to the planning model. Never build on a plan known to be wrong |
| Phase complete | Tests pass, self-review clear | → next /build-phase or "all phases complete" |
| All build phases complete (main model) | /build-phase reported completion, full suite passes | → /3p-review → /handoff-summary (build record) → /verification-before-completion |
| Dedicated build model session | User launched the session to build a plan with a smaller/faster model | This is not your workflow — use /build-model, which drives /build-phase → /3p-review → /handoff-summary → STOP |
| User returns with handoff summary | Build was done by a different model (e.g. a dedicated build model) | → /3p-review with the handoff summary as argument (review the full output and address all concerns from the summary), then /verification-before-completion |
| 3p-review found too much to fix in place |
The Rules
- Never jump to code during brainstorm. Brainstorm produces options and analysis, not implementations.
- Never implement without a plan. Plans are written to
docs/plans/new/ as versioned project assets.
- Plans decouple the planning agent from the building agent. The agent that brainstorms and plans does not have to be the agent that builds. Plans are the contract between them.
- Execute one phase at a time. Each phase goes through Read Plan → Test-First (TDD or BDD per config) → Test Suite → Self-Review before proceeding. The full
/3p-review runs after ALL phases are complete.
- Test first, always. No production code without a failing test first. Use
/test-driven-development by default, or BDD-style specifications if configured.
- 3rd-person review is a mindset, not a checkbox. The reviewer owns the code now — it must meet world-class standards.
- Debug systematically, not randomly. Use
/systematic-debugging — investigate root cause before proposing fixes.
- Evidence before claims. Use
/verification-before-completion before any "done" claim, commit, or PR — this step itself is never optional and is never skipped, regardless of model, time pressure, or confidence. It is not a second review — it is the honesty gate on the final claim. It adds two things /3p-review does not guarantee: (a) a fresh full-suite run at the actual moment of completion — review may have passed several edits ago; and (b) a line-by-line check against the plan's requirements — review judges completeness only qualitatively. The suite re-run (only (a)) may be satisfied by citing /3p-review's own run instead of re-running it, but only when review ran the identical command and git status/git diff show zero code changes since — state that explicitly, with the evidence. Any change since invalidates it. The requirements checklist (b) is never satisfied this way — it always runs fresh. It also covers the bug / quick-fix path, which skips full review.
- Triage minimizes context thrash. When recommending work, factor in what is already loaded in the current conversation context — don't suggest work that requires loading entirely different modules.
- Resume automatically after external execution. When the user returns after handing build to an external model (with a handoff summary or simply saying "it's done"), immediately pick up the workflow: run so it reviews the full feature AND addresses every concern from the summary. Then , then archive the plan. Do not wait to be told.
Plan Directory Lifecycle
docs/plans/new/ — Brainstormed and written, not yet started. Staging area.docs/plans/ — Active plan being executed.docs/plans/done/ — Completed plans, kept as audit trail.
Plans accumulate in new/ — this is intentional. With AI-assisted development, "later" means minutes or hours, not months. Accumulating plans is staging work for rapid parallel execution.
Task Selection Strategy
When tokens or context are constrained, pick bugs — they are small, self-contained, and don't require the full Brainstorm → Plan → Build cycle.
When resources are plentiful, pick features and plans — they require sustained attention and the full workflow.
Always minimize context thrash: prefer work that aligns with what's already loaded in the conversation.
Integration with Your Agent's Config
For best results, list the workflow skills in your project's config file (CLAUDE.md, .cursorrules, GEMINI.md, or .github/copilot-instructions.md) so they are loaded automatically:
## Workflow Skills
- `agentic-workflow` — orchestrates the structured development lifecycle
- `/workflow-config` — configure workflow preferences (TDD/BDD, caveman output style)
- `/brainstorm` — explore problem space, challenge the design, produce decision documents
- `/write-plan` — write phased plans to docs/plans/new/
- `/build-phase` — execute plan phases with test + self-review; produces a build completion report (no review/handoff)
- `/build-model` — dedicated build-model workflow: build-phase → 3p-review → handoff-summary → stop (alternative entry point to this workflow, for a smaller/faster build session)
- `/3p-review` — independent third-person code review (after all build phases)
- `/handoff-summary` — emit the fixed Build Handoff Summary artifact after review passes
- `/test-driven-development` — RED-GREEN-REFACTOR, test first always (from superpowers)
- `/systematic-debugging` — 4-phase root cause investigation (from superpowers)
- `/verification-before-completion` — evidence before claims (from superpowers)
- `/triage` — recommend next task minimizing context thrash
