Help us improve
Share bugs, ideas, or general feedback.
From quangflow
Leads requirements brainstorming: asks clarifying questions in batches, identifies edge cases, splits milestones, suggests team composition. Use when entering project requirements phase.
npx claudepluginhub duongmquang/quangflow --plugin quangflowHow this skill is triggered — by the user, by Claude, or both
Slash command
/quangflow:1-brainstormThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are now entering Phase 1: Requirements Brainstorm.
Breaks down requirements into tasks via 4 researching AI agents (PM, UX, Tech, QA) for multi-perspective analysis. Quick parallel mode (~3min) or Deep serial mode (~8min) with iterative Q&A.
Transforms vague goals into structured requirements via systematic interview. Three phases: Interview, Extract, Cross-check. Outputs requirements.md consumed by /blueprint.
Conducts short adaptive interview (2-6 questions) to clarify feature intent and business context, then launches /team-feature with compiled brief. Use for vague requests or explicit pre-build discussions.
Share bugs, ideas, or general feedback.
You are now entering Phase 1: Requirements Brainstorm.
See _protocols/_shared.md → State Check Template. Required artifact: CONTEXT.md (from /qf:0-init).
If none found: "No project context found. Run /qf:0-init <idea> first."
Read CONTEXT.md to get: pm_mode, project_type, scan results, and feature slug.
Before starting the full brainstorm, analyze $ARGUMENTS for scope:
Signals of a small task (any 2+ of these):
If small task detected: "This sounds like a small task. I can handle it in quick mode (skip design, milestones, team setup) or run the full brainstorm.
/qf:quick {arguments} (single-pass, solo, fast)Which do you prefer?"
If user picks Quick: tell them to run /qf:quick {arguments} and stop.
If user picks Full: proceed below.
If ambiguous scope: proceed with full brainstorm (err on thorough side).
Check if REQUIREMENTS.md already exists for this feature slug.
If REQUIREMENTS.md exists with [M2]+ tags (subsequent milestone):
This is a scoped confirmation, NOT a full brainstorm. Skip:
Shortened flow:
Read REQUIREMENTS.md — find requirements tagged for the next unstarted milestone [M{N}]
Read CONTEXT.md — understand locked decisions from previous milestones
Present to user:
"Milestone-{N} requirements from Phase 1:
Context from previous milestones: {key locked decisions}
Any changes to these requirements? Or type APPROVE to proceed to design."
If user wants changes: accept additions/removals/modifications, update REQUIREMENTS.md
If user types APPROVE: proceed to Next Step (suggest /qf:2-design)
If no REQUIREMENTS.md exists: proceed with full brainstorm below.
Read pm_mode from CONTEXT.md.
autopilot: See _protocols/_autopilot.md → Phase 1. Business-only questions, skip technical edge cases.hands-on or not set: proceed with normal flow below.When a user's answer is vague, incomplete, or ambiguous, use AskUserQuestion to probe deeper.
Use AskUserQuestion with structured options + free-type:
{
"questions": [{
"question": "You mentioned 'large files'. What size range are we designing for?",
"header": "Clarification: File Size",
"options": [
{ "label": "< 10MB", "description": "Standard uploads, no special handling" },
{ "label": "10MB - 100MB", "description": "Chunked upload, progress bar needed" },
{ "label": "100MB - 1GB", "description": "Resumable upload, background processing" },
{ "label": "1GB+", "description": "Streaming upload, dedicated infra" }
],
"multiSelect": false
}]
}
⚠️ ASSUMPTION: {assumption}. Will revisit if wrong.Normal mode (hands-on):
Autopilot mode: See _protocols/_autopilot.md → Phase 1. Business-only checklist, skip technical edge cases.
Autopilot mode: Skip — see _protocols/_autopilot.md → Phase 1.
Normal mode: Before finalizing, you MUST challenge each requirement: "What assumption is this requirement making? What if that assumption is wrong?"
After requirements are understood, assess complexity:
If project is small enough for single milestone, say so. User decides.
Ask: "I recommend [1 | N] milestone(s). Here's the proposed split: [summary]. Do you agree, or want to adjust?"
Autopilot mode: See _protocols/_autopilot.md → Phase 1 review gate.
Normal mode:
Agent waits. Does nothing until user types APPROVE.
After APPROVE, analyze the approved requirements to suggest an execution mode.
Autopilot shortcut: See _protocols/_autopilot.md → Phase 1. Auto-select Solo/Team based on layer count.
Scan all approved requirements and identify which functional layers are involved:
| Layer | Detected when requirements mention... | Role |
|---|---|---|
| Backend | API, database, auth, server, models, migrations, webhooks, cron, queue | fullstack-developer focused on backend |
| Frontend | UI, pages, components, forms, dashboard, responsive, styling | fullstack-developer focused on frontend |
| Infrastructure | Docker, CI/CD, deployment, env config, cloud, monitoring | fullstack-developer focused on infra |
| Mobile | iOS, Android, React Native, Flutter, mobile app | fullstack-developer focused on mobile |
Based on the analysis, present:
"Based on the requirements, I identified these functional layers:
Suggested execution mode:
Type 1 for Solo or 2 for Agent Team."
If user picks Agent Team and there are distinct layers (e.g. backend + frontend), ask:
"Your project has distinct {layer-1} and {layer-2} code. How should dev agents be scoped?
dev-backend + dev-frontend agents. Each only reads/writes its own files. Lower token usage, faster per-agent.dev-fullstack agent handles both. Simpler coordination, but reads all files (higher token usage).Type 1 or 2."
dev-backend, dev-frontend, dev-mobile)dev-fullstack role owning all implementation filesAfter scoping decision, present:
| Role | Type | Focus | File Ownership |
|---|---|---|---|
| lead | Orchestrator | Coordinate team, user decisions | Main session |
| pm | Project Manager (always) | Track progress, resume context across sessions, report status | plans/{feature-slug}/milestone-{N}/STATUS.md |
| domain-engineer | Architect (recommended) | Module design docs, sequence flows, interface contracts (Mermaid) | plans/{feature-slug}/milestone-{N}/design/ |
| dev-{scope} | Developer | {focus per scoping choice} | {ownership per scoping choice} |
| tech-lead | Reviewer (optional) | Code review, tech debt, cross-dev integration | Read-only on all dev files |
| tester | Tester | Generate & run unit/integration/e2e tests based on requirements | tests/*, __tests__/* |
Pipeline: domain-engineer designs → devs implement (parallel) → [optional] tech-lead reviews → tester tests Cross-cutting: pm reports status at each checkpoint
"Any changes to the team composition, or looks good?"
planner agent, recommended for 2+ devs — designs modules before devs startcode-reviewer agent, optional — user decides at execution timeteam_mode: false into REQUIREMENTS.md metadatateam_mode: true
team_composition:
- role: lead
focus: "Orchestrator — coordinate team, user decisions"
type: main-session
- role: pm
focus: "Track progress, resume context across sessions, report status at checkpoints"
ownership: "plans/{feature-slug}/milestone-{N}/STATUS.md"
agent_type: project-manager
required: true
note: "Always present — session memory NPC. Updates STATUS.md at every checkpoint."
- role: domain-engineer
focus: "Module design, sequence flows (Mermaid), interface contracts"
ownership: "plans/{feature-slug}/milestone-{N}/design/*"
agent_type: planner
recommended: true
note: "Runs BEFORE devs. Produces design docs that devs follow."
# --- Dev roles: adapt based on agent scoping choice ---
# If SCOPED (separate agents per layer):
- role: dev-backend
focus: "API endpoints, database models, auth services"
ownership: "src/api/*, src/models/*, src/services/*"
agent_type: fullstack-developer
blocked_by: [domain-engineer]
- role: dev-frontend
focus: "UI components, pages, styling"
ownership: "src/components/*, src/pages/*, src/styles/*"
agent_type: fullstack-developer
blocked_by: [domain-engineer]
# If COMBINED (single fullstack agent):
# - role: dev-fullstack
# focus: "Full implementation — API, models, services, UI, pages"
# ownership: "src/*"
# agent_type: fullstack-developer
# blocked_by: [domain-engineer]
- role: tech-lead
focus: "Code review, tech debt, cross-dev integration"
agent_type: code-reviewer
optional: true
blocked_by: [dev-backend, dev-frontend]
- role: tester
focus: "Generate & run unit/integration/e2e tests based on requirements"
ownership: "tests/*, __tests__/*"
agent_type: tester
blocked_by: [tech-lead]
Write REQUIREMENTS.md to ./plans/{feature-slug}/REQUIREMENTS.md containing:
If multiple milestones, create milestone directories: ./plans/{feature-slug}/milestone-1/, milestone-2/, etc.
See _protocols/_shared.md → Output Rule.
See _protocols/_shared.md → Progress Tracking. Append Phase 1 row to plans/{feature-slug}/PROGRESS.md.
Key decisions to log: REQ count, milestone count, team mode (solo/team), question rounds.
Tell user: "Phase 1 complete. Draft saved to ./plans/{feature-slug}/REQUIREMENTS.md with [N] milestone(s)."
Then suggest next command:
**Next:** `/qf:2-design` — Explore architecture options for milestone-1
↳ Skip? Jump to `/qf:3-handoff` if you already know the architecture (not recommended for complex projects)
↳ Also available: `/qf:status` (check status), `/qf:status save` (save context)
Start by asking the first batch of clarifying questions about: $ARGUMENTS