bmad-plus 0.12.2 → 0.14.0

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/quick-dev.md

@@ -1,111 +1,59 @@
----
+---
 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.'
+description: Implement a bounded request with proportionate investigation and acceptance evidence.
 ---
 
-# 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.
-
-## 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.
-
-## 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.
-- `this skill directory` resolves to this skill's installed directory (where `agent configuration` 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
-
-<!-- Adapted for BMAD+: original script dependency removed -->
-
-**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. `this skill file` — defaults
-2. `{project-root}/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/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}/project config` 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)
-- CLAUDE.md / memory files (load if exist)
-- 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. Begin the workflow below.
-
-## 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.
+# Quick development
+
+Read the [execution guide](../../shared/execution.md) and
+[Oholiab's role](dev-agent.md).
+
+## Inputs
+
+A change request or supplied artifact describing the desired behavior. Inspect the
+selected project with host tools. If a current story already supplies the scope,
+reuse it rather than generating a competing specification.
+
+## Procedure
+
+1. Translate the request into an observable outcome and acceptance checks. Inspect
+   relevant code, project instructions and the working tree before estimating
+   scope. State material assumptions and preserve existing user edits.
+2. Trace the behavior through the actual implementation. Identify affected
+   interfaces, data, dependencies and a useful baseline check. Investigate an
+   essential ambiguity before changing the code; continue independent authorized
+   work while a necessary answer is pending.
+3. Choose a proportional implementation plan. A routine edit can use a brief
+   checklist. A cross-cutting change needs explicit boundaries and dependencies.
+   If the request contains independent deliverables, sequence them as separate
+   reviewable slices while retaining the user's overall objective.
+4. Implement the smallest coherent slice in the project's style. Add focused
+   regression coverage when it meaningfully protects changed behavior. Do not
+   introduce a framework, dependency upgrade or broad refactor without a concrete
+   reason tied to the task.
+5. Execute acceptance checks and required project validation. Inspect the final
+   diff, correct regressions caused by the change and record unavailable or
+   unrelated failing checks. Rerun a check only when changes or unresolved evidence
+   justify it.
+6. Deliver the changed artifacts and evidence. State which outcomes are verified,
+   which are implemented but unverified, and any remaining dependency. Follow
+   existing authorization for commit or publication; finishing code does not
+   grant permission for unrelated external actions.
+
+## Output and acceptance
+
+Write the report for quick-dev with request, baseline, compact plan, changed files,
+acceptance results and next action. Include a before/after example when it makes
+the result easier to review.
+
+Success requires the requested behavior and its applicable checks to be
+established. A plan alone is not an implementation, and a test command listed in
+the report is not an executed test. Do not impose a fixed document size or a
+mandatory full planning pipeline on a small change.
+
+## Continue
+
+Read the previous report and inspect current files before editing. Compare inputs,
+preserve completed valid work and reconcile interruptions or concurrent changes.
+Resume the next incomplete slice; do not reset the tree or repeat completed
+external effects to recreate a prior state.