BMAD-METHOD/src/modules/bmm/workflows/bmad-quick-flow/quick-dev/instructions.md

Quick-Dev - Flexible Development Workflow

Communicate in {communication_language}, tailored to {user_skill_level} Execute continuously until COMPLETE - do not stop for milestones Flexible - handles tech-specs OR direct instructions ALWAYS respect {project_context} if it exists - it defines project standards

Load and execute {advanced_elicitation}, then return Load and execute {party_mode_workflow}, then return Load and execute {create_tech_spec_workflow}

Check if {project_context} exists. If yes, load it - this is your foundational reference for ALL implementation decisions (patterns, conventions, architecture).

Parse user input:

Mode A: Tech-Spec - e.g., quick-dev tech-spec-auth.md → Load spec, extract tasks/context/AC, goto step 3

Mode B: Direct Instructions - e.g., refactor src/foo.ts... → Offer planning choice

Load tech-spec, extract tasks/context/AC step_3

Evaluate escalation threshold against user input (minimal tokens, no file loading):

Triggers escalation (if 2+ signals present):

• Multiple components mentioned (e.g., dashboard + api + database)
• System-level language (e.g., platform, integration, architecture)
• Uncertainty about approach (e.g., "how should I", "best way to")
• Multi-layer scope (e.g., UI + backend + data together)
• Extended timeframe (e.g., "this week", "over the next few days")

Reduces signal:

• Simplicity markers (e.g., "just", "quickly", "fix", "bug", "typo", "simple", "basic", "minor")
• Single file/component focus
• Confident, specific request

Use holistic judgment, not mechanical keyword matching.

**[t] Plan first** - Create tech-spec then implement **[e] Execute directly** - Start now

<check if="t">
  <action>Load and execute {create_tech_spec_workflow}</action>
  <action>Continue to implementation after spec complete</action>
</check>

<check if="e">
  <ask>Any additional guidance before I begin? (patterns, files, constraints) Or "go" to start.</ask>
  <goto>step_2</goto>
</check>

Load {project_levels} and evaluate user input against detection_hints.keywords Determine level (0-4) using scale-adaptive definitions

<!-- Level 0: Scale-adaptive confirms simple, fall back to standard choice -->
<check if="level 0">
  <ask>**[t] Plan first** - Create tech-spec then implement

[e] Execute directly - Start now

  <check if="t">
    <action>Load and execute {create_tech_spec_workflow}</action>
    <action>Continue to implementation after spec complete</action>
  </check>

  <check if="e">
    <ask>Any additional guidance before I begin? (patterns, files, constraints) Or "go" to start.</ask>
    <goto>step_2</goto>
  </check>
</check>

<check if="level 1 or 2 or couldn't determine level">
  <ask>This looks like a focused feature with multiple components.

[t] Create tech-spec first (recommended) [w] Seems bigger than quick-dev — see what BMad Method recommends (workflow-init) [e] Execute directly

  <check if="t">
    <action>Load and execute {create_tech_spec_workflow}</action>
    <action>Continue to implementation after spec complete</action>
  </check>

  <check if="w">
    <action>Load and execute {workflow_init}</action>
    <action>EXIT quick-dev - user has been routed to BMad Method</action>
  </check>

  <check if="e">
    <ask>Any additional guidance before I begin? (patterns, files, constraints) Or "go" to start.</ask>
    <goto>step_2</goto>
  </check>
</check>

<!-- Level 3+: BMad Method territory, recommend workflow-init -->
<check if="level 3 or higher">
  <ask>This sounds like platform/system work.

[w] Start BMad Method (recommended) (workflow-init) [t] Create tech-spec (lighter planning) [e] Execute directly - feeling lucky

  <check if="w">
    <action>Load and execute {workflow_init}</action>
    <action>EXIT quick-dev - user has been routed to BMad Method</action>
  </check>

  <check if="t">
    <action>Load and execute {create_tech_spec_workflow}</action>
    <action>Continue to implementation after spec complete</action>
  </check>

  <check if="e">
    <ask>Any additional guidance before I begin? (patterns, files, constraints) Or "go" to start.</ask>
    <goto>step_2</goto>
  </check>
</check>

Identify files to modify, find relevant patterns, note dependencies

Create mental plan: tasks, acceptance criteria, files to touch

For each task:

1. Load Context - read files from spec or relevant to change
2. Implement - follow patterns, handle errors, follow conventions
3. Test - write tests, run existing tests, verify AC
4. Mark Complete - check off task , continue

HALT and request guidance Fix before continuing

Continue through ALL tasks without stopping

Verify: all tasks [x], tests passing, AC satisfied, patterns followed

Update tech-spec status to "Completed", mark all tasks [x]

Implementation Complete!

Summary: {{implementation_summary}} Files Modified: {{files_list}} Tests: {{test_summary}} AC Status: {{ac_status}}

---

Before committing (Recommended): Copy this code review prompt to a different LLM

You are a cynical, jaded code reviewer with zero patience for sloppy work. These uncommitted changes were submitted by a clueless weasel and you expect to find problems. Find at least five issues to fix or improve in it. Number them. Be skeptical of everything.

You must explain what was implemented based on {user_skill_level}