Over the past few weeks, I built and ran a custom workflow loop within Cursor that lets me define a single sentence product outcome for my mobile app and delegate the development from spec creation to verified code through an orchestrator and multiple specialized subagents. So far, I’ve run ~130 features through this loop, generating ~125 specs and ~800 engineering tasks, including ~200 automated bug fixes caught by typechecking, bug review, and security review before I ever tested on a device.
I wanted a repeatable model where:
My input stays minimal - I type the outcome I want without defining the implementation steps every time
Specialized roles are delegated to agents - Subagents with specific roles (product, design, architecture, implementation, verification) evaluate, research, and define the implementation path on their own
Important gates and guardrails stay under my control - Application code and files can’t be touched until I can explicitly approve a spec or resolve any product blockers
QA and debugging is built in - Automated verification creates and implements targeted fix tasks before handing the build back to me
I also wanted to steer the setup away from one-off prototypes and toward a workflow I can refine over time that produces stable production code. Also, I wanted to spend more of my energy verifying the end experience and less on implementation mechanics while still allowing me to maintain familiarity with the codebase.
Chat Interaction
While in normal agent chat, I use custom slash commands to kick off a new feature or change and control important gates throughout the development.
I type a one sentence outcome (e.g. /fw new add a subtle haptic when the Send button is tapped)
Orchestrator creates an inbox task, infers its size, and runs Product, Design, and/or Architect subagents as needed to explore, research, and create a spec file
Once spec is ready, it pauses and asks me to review the file
I approve with a /fw approve command
Orchestrator decomposes work into specific queue tasks, runs Explore as needed, edits the codebase with Implement, and moves completed tasks to dedicated folders
Verifier runs across the diff and summarizes a targeted list of QA checks for me to test on my device
I accept the build and mark the task done with a command
Across the workflow, agents are instructed to reference living product and technical documentation within the project directory that define constraints I own and manage. In the scenario that the agent identifies an unstated tradeoff, it is instructed to not guess and escalate to me as a blocker with suggested options and recommendations. Before a spec is approved, I have an opportunity to review and resolve blockers within the chat before implementation.
If a bug is caught during verification, the Verifier subagent is instructed to first document a separate fix task with the exact reproduction details before surfacing to me for review. I have the option to approve implementing the fixes without adjusting or modifying the initial scope or spec while still tracking under the same feature scope or ticket queue.
Setup and Project Structure
| Primitive | Path | When it loads | Job |
|---|---|---|---|
| Always-on Rule | .cursor/rules/workflow.mdc | Every chat | Enforces any approval gates. Points commands to the skill |
| Dynamic Rule | .cursor/rules/fw-commands.md | When user types fw … or /fw-* | Normalizes command phrasing and delegates execution to an orchestrator |
| Skill | .agents/skills/spec-workflow/SKILL.md | On demand | Single source of truth for workflow, commands, loops, phases, reference to documentation |
| Subagents | .cursor/agents/*.md | When delegated via Task tool | Agent definition per role (Orchestrator, Product, Design, Architect, Explore, Implement, Verifier) |
| Slash Commands | .cursor/commands/fw-*.md | On /fw-* | Prompt triggers (fw-new, fw-resolve, fw-approve, fw-verify, fw-done, fw-status) |
| Hooks | .cursor/hooks.json | When subagent stops | Runs any tests and loops errors back |
Project File Layout
your-repo/
├── AGENTS.md # Doc authority order (Product > Architecture > Code comments)
├── docs/
│ ├── PRODUCT.md # Scope & explicit non-goals (hard stops)
│ ├── EXPERIENCE.md # User behavior & state
│ ├── UI.md # Design system & tokens
│ ├── ARCHITECTURE.md # Layers, invariants, boundaries
│ └── QA.md # Manual / device test scenarios
├── .agents/
│ └── skills/spec-workflow/SKILL.md # Workflow procedure
├── .cursor/
│ ├── hooks.json # Mechanical typecheck/lint gate
│ ├── hooks/verify-types.sh
│ ├── rules/
│ │ ├── workflow.mdc # Always-on code gate
│ │ └── fw-commands.mdc # Command router
│ ├── commands/ # fw-new.md, fw-approve.md, etc.
│ └── agents/ # orchestrator, product, design, architect,
│ # explore, implement, verifier
├── scripts/
│ └── check-spec-sync.py # Validates blocked decisions ↔ spec
└── work/
├── STATUS.md # Auto-maintained dashboard
├── inbox/ # Active parent outcomes (FEAT-001.md)
├── spec/ # Generated specs + templates
├── blocked/ # Unresolved blockers that require human decisions
├── decisions/rules.json # Optional phrase checks per decision label
├── queue/ # Engineering & fix tasks
│ └── processed/ # Completed tasks
└── done/ # Completed parent inbox files
Commands
| Command | Action |
|---|---|
fw new: <outcome> |
Allocates next FEAT-###, assigns size (small / medium / large, default medium), runs agents, writes spec, updates STATUS.md, and stops. |
fw resolve FEAT-### |
Walks through open blockers through structured questions and recommendations, updates spec, runs sync script. Never sets spec_approved. |
fw approve FEAT-### |
Runs check-spec-sync.py -> sets spec_approved: true -> creates queue tasks -> runs explore + implement -> runs verifier. |
fw verify FEAT-### |
Re-runs verifier + typecheck after fixes without requiring re-approval. |
fw done FEAT-### |
Moves work/inbox/FEAT-###.md -> work/done/ after human manual QA. Post-done bugs always start a fresh fw new: Fix .... |
fw status / fw show |
Scans work/ artifacts, rebuilds work/STATUS.md, and prints current state and next action. |
Learnings
Bottleneck shifted immediately from writing/maintaining codebase to human QA
Guardrails initially built into agent skill files drifted, but improved after moving into living product documentation within the project
For large features, requiring the workflow to move in series was slow but allowed the right level of control and oversight for me to maintain the codebase (not fully delegating just yet)
In a future edit, I will include the templates and prompts for each skill or file so that anyone can implement a similar workflow.