bmad-method 6.10.1-next.8 → 6.11.0

package/src/bmm-skills/4-implementation/bmad-quick-dev/SKILL.md

@@ -1,115 +0,0 @@
----
-name: bmad-quick-dev
-description: 'Implements any user intent, requirement, story, bug fix or change request by producing clean working code artifacts that follow the project''s existing architecture, patterns and conventions. Use when the user wants to build, fix, tweak, refactor, add or modify any code, component or feature.'
----
-
-# Quick Dev New Preview Workflow
-
-**Goal:** Turn user intent into a hardened, reviewable artifact.
-
-**CRITICAL:** If a step says "read fully and follow step-XX", you read and follow step-XX. No exceptions.
-
-Subagents, when the capability is available, are an important part of this workflow. Use them as directed by the workflow steps.
-If you need an explicit user instruction to run them, ask once now for the whole workflow run.
-
-## READY FOR DEVELOPMENT STANDARD
-
-A specification is "Ready for Development" when:
-
-- **Actionable**: Every task has a file path and specific action.
-- **Logical**: Tasks ordered by dependency.
-- **Testable**: All ACs use Given/When/Then.
-- **Complete**: No placeholders or TBDs.
-- **Sufficient**: No known requirement, acceptance, dependency, or implementation gaps remain unresolved.
-- **Coherent**: No unresolved ambiguities or internal contradictions.
-
-## SCOPE STANDARD
-
-A specification should target a **single user-facing goal** within **900–1600 tokens**:
-
-- **Single goal**: One cohesive feature, even if it spans multiple layers/files. Multi-goal means >=2 **top-level independent shippable deliverables** — each could be reviewed, tested, and merged as a separate PR without breaking the others. Never count surface verbs, "and" conjunctions, or noun phrases. Never split cross-layer implementation details inside one user goal.
-  - Split: "add dark mode toggle AND refactor auth to JWT AND build admin dashboard"
-  - Don't split: "add validation and display errors" / "support drag-and-drop AND paste AND retry"
-- **900–1600 tokens**: Optimal range for LLM consumption. Below 900 risks ambiguity; above 1600 risks context-rot in implementation agents.
-- **Neither limit is a gate.** Both are proposals with user override.
-
-## Conventions
-
-- Bare paths (e.g. `step-01-clarify-and-route.md`) resolve from the skill root.
-- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
-- `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
-
-## On Activation
-
-### Step 1: Resolve the Workflow Block
-
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
-
-**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
-
-1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
-
-Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
-
-### Step 2: Execute Prepend Steps
-
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
-
-### Step 3: Load Persistent Facts
-
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` -- load the referenced contents as facts. All other entries are facts verbatim.
-
-### Step 4: Load Config
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
-- `project_context` = `**/project-context.md` (load if exists)
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- Language MUST be tailored to `{user_skill_level}`
-- Generate all documents in `{document_output_language}`
-
-### Step 5: Greet the User
-
-Greet `{user_name}`, speaking in `{communication_language}`.
-
-### Step 6: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-- **Micro-file Design**: Each step is self-contained and followed exactly
-- **Just-In-Time Loading**: Only load the current step file
-- **Sequential Enforcement**: Complete steps in order, no skipping
-- **State Tracking**: Persist progress via spec frontmatter and in-memory variables
-- **Append-Only Building**: Build artifacts incrementally
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Read the entire step file before acting
-2. **FOLLOW SEQUENCE**: Execute sections in order
-3. **WAIT FOR INPUT**: Halt at checkpoints and wait for human
-4. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- **NEVER** load multiple step files simultaneously
-- **ALWAYS** read entire step file before execution
-- **NEVER** skip steps or optimize the sequence
-- **ALWAYS** follow the exact instructions in the step file
-- **ALWAYS** halt at checkpoints and wait for human input
-
-## FIRST STEP
-
-Read fully and follow: `./step-01-clarify-and-route.md` to begin the workflow.

package/src/bmm-skills/4-implementation/bmad-quick-dev/customize.toml

@@ -1,83 +0,0 @@
-# DO NOT EDIT -- overwritten on every update.
-#
-# Default customization values for bmad-quick-dev.
-# Override in _bmad/custom/bmad-quick-dev.toml or
-# _bmad/custom/bmad-quick-dev.user.toml.
-#
-# Merge rules:
-# - Strings replace the default.
-# - Lists append to the default list.
-# - Tables merge key by key.
-# - Arrays of tables merge by `id`: matching `id` replaces, new `id`s append.
-
-[workflow]
-
-# Extra instructions to run before config is loaded and before the user is greeted.
-
-activation_steps_prepend = []
-
-# Extra instructions to run after the greeting and before step 01.
-
-activation_steps_append = []
-
-# Facts kept in context for the whole run.
-# Entries are literal text or file references prefixed with "file:".
-# File entries may use globs and are loaded during activation.
-
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
-
-# Instruction run after Quick Dev completes.
-# Empty means no extra completion behavior.
-
-on_complete = ""
-
-# Review layers for the review step. `instruction` is the layer's whole
-# execution recipe — subagents by default, but an override may run anything
-# (e.g. an external reviewer via bash). {diff_output} is substituted at run
-# time. `when` (optional) gates a layer; empty `instruction` disables it.
-
-[[workflow.review_layers]]
-id = "blind-hunter"
-name = "Blind Hunter"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-adversarial-general` skill on this diff:
->
-> {diff_output}
-"""
-
-[[workflow.review_layers]]
-id = "edge-case-hunter"
-name = "Edge Case Hunter"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-edge-case-hunter` skill on this diff:
->
-> {diff_output}
-"""
-
-[[workflow.review_layers]]
-id = "verification-gap"
-name = "Verification Gap Reviewer"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-verification-gap` skill on this diff:
->
-> {diff_output}
-"""
-
-# Review layers for the one-shot route.
-
-[[workflow.oneshot_review_layers]]
-id = "blind-hunter"
-name = "Blind Hunter"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-adversarial-general` skill on the changed files.
-"""

package/src/bmm-skills/4-implementation/bmad-quick-dev/step-oneshot.md

@@ -1,82 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
----
-
-# Step One-Shot: Implement, Review, Present
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- NEVER auto-push.
-- All review subagents must run at the same model capability as the current session.
-- Run subagents synchronously: launch them together, then wait for all results before continuing.
-
-## INSTRUCTIONS
-
-### Implement
-
-Follow `./sync-sprint-status.md` with `{target_status}` = `in-progress`.
-
-Implement the clarified intent directly.
-
-### Review
-
-The review layers for this route are `{workflow.oneshot_review_layers}`, resolved during activation.
-
-Skip every layer whose `instruction` is empty or missing, and every layer whose `when` condition (if present) does not hold. If no layers remain, HALT with status `blocked` and blocking condition `no active review layers`. Execute all remaining layers in parallel wherever their execution methods allow, following each layer's `instruction` verbatim after substituting any runtime placeholders.
-
-If a layer's instruction requires subagents and none are available, generate one review prompt file per such layer in `{implementation_artifacts}` and HALT. Ask the human to run each in a separate session and paste back the findings.
-
-### Classify
-
-Deduplicate all review findings. Three categories only:
-
-- **patch** — trivially fixable. Auto-fix immediately.
-- **defer** — pre-existing issue not caused by this change. Append one new entry to `{deferred_work_file}` using this format. Do not modify existing entries or look for duplicates.
-  ```markdown
-  - source_spec: `{spec_file}`
-    summary: <one sentence>
-    evidence: <why this is real>
-  ```
-- **reject** — noise. Drop silently.
-
-If a finding is caused by this change but too significant for a trivial patch, HALT and present it to the human for decision before proceeding.
-
-### Generate Spec Trace
-
-Set `{title}` = a concise title derived from the clarified intent.
-
-Write `{spec_file}` using `./spec-template.md`. Fill only these sections — delete all others:
-
-1. **Frontmatter** — set `title: '{title}'`, `type`, `created`, `status: 'done'`. Add `route: 'one-shot'`.
-2. **Title and Intent** — `# {title}` heading and `## Intent` with **Problem** and **Approach** lines. Reuse the summary you already generated for the terminal.
-3. **Suggested Review Order** — append after Intent. Build using the same convention as `./step-05-present.md` § "Generate Suggested Review Order" (spec-file-relative links, concern-based ordering, ultra-concise framing).
-
-Follow `./sync-sprint-status.md` with `{target_status}` = `review`.
-
-### Commit
-
-If version control is available and the tree is dirty, create a local commit with a conventional message derived from the intent. If VCS is unavailable, skip.
-
-### Present
-
-1. Open the spec in the user's editor so they can click through the Suggested Review Order:
-   - Resolve two absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) `{spec_file}`. Run `code -r "{absolute-root}" "{absolute-spec-file}"` — the root first so VS Code opens in the right context, then the spec file. Always double-quote paths to handle spaces and special characters.
-   - If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead.
-2. Display a summary in conversation output, including:
-   - The commit hash (if one was created).
-   - List of files changed with one-line descriptions. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — this differs from spec-file links which use spec-file-relative paths.
-   - Review findings breakdown: patches applied, items deferred, items rejected. If all findings were rejected, say so.
-   - A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order.
-   - **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop."
-3. Offer to push and/or create a pull request.
-
-HALT and wait for human input.
-
-Workflow complete.
-
-## On Complete
-
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
-
-If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/bmm-skills/4-implementation/bmad-quick-dev/sync-sprint-status.md

@@ -1,19 +0,0 @@
-# Sync Sprint Status
-
-Shared sub-step for updating `sprint-status.yaml` during quick-dev. Called from any route (plan-code-review, one-shot, future routes) with a `{target_status}` parameter.
-
-## Preconditions
-
-Skip this entire file (return to caller) if ANY of:
-- `{story_key}` is unset
-- `{sprint_status}` does not exist on disk
-
-## Instructions
-
-1. Load the FULL `{sprint_status}` file.
-2. Find the `development_status` entry matching `{story_key}`. If not found, warn the user once (`"{story_key} not found in sprint-status; skipping sprint sync"`) and return to caller.
-3. **Idempotency check.** If `development_status[{story_key}]` is already at `{target_status}` or a later state (`review` is later than `in-progress`; `done` is later than both), return to caller — no write needed. Never regress a story's status.
-4. Set `development_status[{story_key}]` to `{target_status}`.
-5. **Epic lift (only when `{target_status}` = `in-progress`).** Derive the parent epic key as `epic-{N}` from the leading numeric segment of `{story_key}` (e.g., `3-2-digest-delivery` → `epic-3`). If that entry exists and is `backlog`, set it to `in-progress`. Leave it alone otherwise. Skip this sub-step entirely when `{target_status}` is not `in-progress`.
-6. Refresh `last_updated` to the current date.
-7. Save the file, preserving ALL comments and structure including STATUS DEFINITIONS and WORKFLOW NOTES.