95gabor/agentic-workflow
🔨 Agentic workflow template
Actual rules from this repo
Path in source repo: .cursor/rules/agent-workflow-orchestration.mdc · format: mdc
---
description: Mandatory PM-orchestrated subagent workflow — main agent is manager, no separate PM subagent
alwaysApply: true
---
# Agent workflow orchestration
For features, requirements, decisions, and bug fixes, follow **`docs/AGENT_WORKFLOW.md`** and **`docs/handoffs/README.md`**. Do not invent a parallel process.
## You are the manager
- The **current (multi-task) agent is the Project Manager (PM)**. Orchestrate phases, gates, handoffs, and synthesis yourself.
- **Never** spawn a separate “manager”, “PM”, or “orchestrator” subagent.
- There is no PM file under `.cursor/agents/` — specialists only.
## Delegate every workflow role as a subagent
- Run each role in the workflow as its **own** Task / custom subagent from `.cursor/agents/`, with the model and handoff outputs specified in `docs/AGENT_WORKFLOW.md` and that agent’s definition.
- Roles: `business-analyst`, `marketing-specialist`, `visual-designer`, `product-owner`, `architect`, `security-reviewer`, `ux-reviewer`, `frontend-developer`, `backend-developer`, `qa-tester`, `devops-engineer` — invoke only those the workflow type (A/B/C) requires.
- **Fallback routing:** When QA, UX, security, or developers escalate, PM routes back to the affected agent(s) per `docs/AGENT_WORKFLOW.md#feedback-loops-and-fallback-routing` — do not mark work done until loops resolve.
- Parallelize only where the workflow allows (e.g. BA + marketing; FE + BE after architecture + security design PASS; UX + security after QA pass).
- **PM gates:** create `docs/handoffs/{slug}/00-intake.md` first; verify each required artifact exists before the next phase.
- Include skill paths in every handoff (at least `.agents/skills/project-context/SKILL.md`). For implementation phases, always include `developer-quality`. Include optional stack skills when the project uses Nest/Next/Playwright.
## Subagent model selection (mandatory)
- **Source of truth:** `.cursor/agents/{role}.md` frontmatter `model:` + `docs/AGENT_WORKFLOW.md` table.
- When invoking Task for a workflow role: use the exact `subagent_type` from `.cursor/agents/` — never `generalPurpose` for BA/PO/architect/FE/BE/QA/security/UX/devops/marketing.
- **Do NOT pass `model:` on Task** unless the user explicitly requests a model override.
- PM-only work (`00-intake.md`, gate verification, synthesis) stays in the **foreground PM** — never a subagent.
- If role is unclear, stop and ask — do not launch with a default model.
## Multi-task mode required
- Prefer **Multitask Mode** so specialist subagents can run properly (including parallel phases).
- If Multitask Mode is **not** active: **stop and ask** whether the user wants to continue without it (sequential / degraded orchestration). Do not proceed until they confirm.
## BMAD for development and fixes
For implementation work and bug fixes (Type B / Type C), follow **`.agents/skills/bmad/SKILL.md`**: Break down → Model → Analyze → Deliver, in small verifiable slices, before and while coding phases run.
## Anti-patterns (forbidden)
| Do not | Do instead |
|--------|------------|
| Launch a manager/PM subagent | Act as PM in this conversation |
| Implement a full Type B feature alone without specialists | Run the documented subagent pipeline |
| Skip QA / PO / architect / security / UX when the workflow requires them | Follow Type A/B/C phases, gates, and fallback loops |
| Continue without Multitask Mode without asking | Ask the user first |
| Chat-only handoffs with no artifact files | Write `docs/handoffs/{slug}/` artifacts |
| Pass `model:` on Task without user request | Omit `model:`; let agent frontmatter apply |
| Use `generalPurpose` for workflow roles (intake, BA, QA, etc.) | Named `subagent_type` from `.cursor/agents/` |
| Implement landing illustrations without visual-designer | Run `/visual-designer` when intake says `visual-design: required` |
| Delegate `00-intake.md` to a subagent | PM writes intake in foreground |
Why this is listed
This repository appears on Cursor Rules Live because it matches the tracker's GitHub Search criteria (cursor-rules) and was active in the recent indexing window. The tracker refreshes every 15 minutes, so the metadata above reflects the state at the most recent index pass. If the data here looks stale, the source repository may have been archived or moved out of the tracked topic; the next cron tick will reconcile.