The Agentic Workflow System: 18 Commands That Build Anything

Why Workflows Exist

Building software without a process produces inconsistent results. Some features are well-tested. Others aren't. Some phases have clear plans. Others are improvised. Quality becomes random.

The Agentic Workflow System eliminates randomness. It's 18 executable workflows — stored in the .agent/workflows/ directory of every project — that define how work gets done from initial planning to final verification.

This is Step 11 of the Context-First methodology. It's the operational backbone that agents follow to produce consistent, high-quality output across every project, every phase, and every session.

The Core Loop

The heart of the system is a 7-step execution loop. Every phase of every project passes through it:

1. /discuss-phase — Extract Decisions

Before planning, discuss. This workflow surfaces the gray areas — the ambiguous requirements, the competing priorities, the technical trade-offs that need human decisions before planning begins.

Output: A CONTEXT.md file that captures every decision with its rationale. When the plan is written, every gray area has been resolved.

2. /research-phase — Investigate Before Building

Before planning, research. This workflow examines technical feasibility, identifies existing patterns, discovers potential pitfalls, and evaluates tool options.

Output: A RESEARCH.md file documenting findings, recommendations, and risks. Plans built without research produce elegant solutions to the wrong problems.

3. /plan-phase — Break Into Atomic Plans

Planning breaks a phase into numbered, sequential, executable plans. Each plan is atomic — small enough to complete in one session, specific enough to verify completion.

Output: Numbered plan files (04-01-PLAN.md, 04-02-PLAN.md, etc.), each containing:

• Objective and success criteria
• Specific tasks with acceptance tests
• Files that will be created or modified
• Dependencies on previous plans
• Estimated scope (small/medium/large)

4. /analyze-gaps — Catch What Planning Missed

After planning, audit. This workflow reviews all plans against the phase context, research findings, and project requirements to identify gaps before execution begins.

Output: A GAP-ANALYSIS.md file listing every gap found, its severity, and the resolution. Gaps caught here cost minutes to fix. Gaps caught during execution cost hours.

5. /execute-phase — Build With Guardrails

Execution runs each plan in sequence. The workflow handles:

• Loading the plan and its dependencies
• Tracking progress task by task
• Handling deviations (when reality differs from the plan)
• Writing summary files after each plan completes
• Atomic commits after each plan

Output: Completed code, plus SUMMARY.md files documenting what was done, what deviated, and what to know for the next plan.

6. /verify-work — Prove It Works

After execution, verify. This workflow uses goal-backward methodology — starting from the phase objectives and working backward to confirm every requirement was met.

Output: Verification results documenting test commands run, build status, route generation, and any issues found.

7. Commit and State Update

After verification, commit with an atomic message referencing the plan number. Update STATE.md to reflect the current project status.

The Supporting Workflows

Beyond the core loop, 11 additional workflows handle specialized needs:

Project Initialization

• /plan-project — Start a new project from scratch. Deep questioning, research, requirements, and roadmap generation. This produces the project's .planning/ directory structure.
• /map-codebase — Analyze an existing codebase into structured reference documents. For brownfield projects where you're joining an existing system.

Session Management

• /context — Load project context at the start of every session. Ensures the agent has full situational awareness before doing any work.
• /clear — Save state and prepare for a fresh context window. The equivalent of a structured handoff when a conversation gets long.
• /pause-work — Create a handoff file preserving complete work state for seamless session resumption.
• /resume-project — Restore full project context across sessions. Reads STATE.md, finds incomplete work, routes to the next action.
• /progress — Check current project status. Where we are, what's done, what's next.

Quick Execution

• /quick — Quick task execution with planning guarantees but without full phase ceremony. For small, well-understood tasks that don't warrant a full phase cycle.

Issue Resolution

• /diagnose-issues — Investigate root causes of gaps before planning fixes. Diagnose why things are broken, not just what.

Infrastructure

• /setup-environment — Set up the local development environment (Step 1 of the methodology).
• /setup-cli — Set up the integration layer with CLIs, API wiring, and dashboards (Step 2).

What the .planning/ Directory Looks Like

Every project that uses the workflow system has a structured .planning/ directory:

.planning/
├── STATE.md                    # Current project status
├── BRIEF.md                    # Original project brief
├── REQUIREMENTS.md             # Full requirements document
├── ROADMAP.md                  # Phase-level roadmap
├── phases/
│   ├── 01-foundation/
│   │   ├── 01-CONTEXT.md       # Discussion decisions
│   │   ├── 01-RESEARCH.md      # Technical research
│   │   ├── 01-GAP-ANALYSIS.md  # Gap audit
│   │   ├── 01-01-PLAN.md       # Plan 1
│   │   ├── 01-01-SUMMARY.md    # Plan 1 results
│   │   ├── 01-02-PLAN.md       # Plan 2
│   │   ├── 01-02-SUMMARY.md    # Plan 2 results
│   │   └── ...
│   ├── 02-core-pages/
│   └── ...

This structure is the project's complete build history. Every decision, every task, every deviation, every verification result — all documented, all traceable.

eComX: A Living Example

eComX used this workflow system across 4 phases:

121 commits across 4 phases, each traceable to a specific plan, each with a summary explaining what was done and why. That's not just code — it's a documented build history that tells the full story.

Phase 3 is particularly instructive. Eight plans executed in sequence:

1. Stripe product catalog and payment intents
2. Resend email infrastructure and templates
3. Cookie-based authentication and debug dashboard security
4. Sequence engine (drip email campaigns via Vercel cron)
5. Post-purchase activation flows
6. Analytics and tracking
7. Form hardening and CSRF protection
8. Build verification and gap resolution

Each plan had specific tasks. Each task had acceptance criteria. Each deviation was documented. Each completion produced a summary. The workflow system turned "build a payment infrastructure" from an ambiguous goal into a verified, documented, 47-commit delivery.

The Compound Effect

One workflow execution is efficient. Hundreds of workflow executions across 7 projects create a compound effect:

• Pattern recognition: After planning 20+ phases, the /plan-phase workflow produces better plans because it's learned from previous phase structures
• Gap detection: After analyzing 15+ gap reports, the /analyze-gaps workflow catches subtler issues
• Execution speed: After executing 30+ plans, the /execute-phase workflow handles deviations more gracefully
• Verification rigor: After verifying 20+ phases, the /verify-work workflow tests more thoroughly

The workflows don't just execute work. They accumulate operational wisdom. And because they're documented in .planning/ directories, that wisdom is accessible to anyone — human or agent — who reads the project history.

Why 18 and Not 5

You could condense the workflow system to "plan → build → test." Three steps. Simple.

But simplicity at the workflow level produces complexity at the execution level. When "plan" is one big step, you get plans that skip research, miss edge cases, and don't resolve gray areas before building begins.

The 18-workflow system adds friction in the right places. The friction of discussing before planning catches requirements issues early. The friction of gap analysis after planning catches design issues early. The friction of structured verification after execution catches bugs early.

Early friction is cheap. Late friction is expensive. The workflow system optimizes for catching problems when they're cheap to fix — not when they're deployed to production and customers are affected.