fix(quick-dev): correct commit ordering, add loopback directive, fix typo (#1876)
* fix(quick-dev): correct commit ordering, add loopback directive, fix typo - step-05: set spec status to done before committing so the commit captures the final state - step-04: add explicit read-and-follow directive to intent_gap loopback matching the pattern used by bad_spec - SKILL.md: fix missing apostrophe in description * fix(quick-dev): remove stray commit instruction from review step The review step (step-04) had a bare "4. Commit." line that conflicted with commit responsibility belonging solely to step-05-present. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
parent
6292b0323f
commit
874ae40bb2
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
name: bmad-quick-dev-new-preview
|
||||
description: 'Implements any user intent, requirement, story, bug fix or change request by producing clean working code artifacts that follow the projects existing architecture, patterns and conventions. Use when the user wants to build, fix, tweak, refactor, add or modify any code, component or feature.'
|
||||
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.'
|
||||
---
|
||||
|
||||
Follow the instructions in [workflow.md](workflow.md).
|
||||
|
|
|
|||
|
|
@ -43,13 +43,11 @@ Do NOT `git add` anything — this is read-only inspection.
|
|||
- **defer** — pre-existing issue not caused by this story, surfaced incidentally by the review. Collect for later focused attention.
|
||||
- **reject** — noise. Drop silently. When unsure between defer and reject, prefer reject — only defer findings you are confident are real.
|
||||
3. Process findings in cascading order. If intent_gap or bad_spec findings exist, they trigger a loopback — lower findings are moot since code will be re-derived. If neither exists, process patch and defer normally. Increment `{specLoopIteration}` on each loopback. If it exceeds 5, HALT and escalate to the human. On any loopback, re-evaluate routing — if scope has grown beyond one-shot, escalate `execution_mode` to plan-code-review.
|
||||
- **intent_gap** — Root cause is inside `<frozen-after-approval>`. Revert code changes. Loop back to the human to resolve, then re-run steps 2–4.
|
||||
- **intent_gap** — Root cause is inside `<frozen-after-approval>`. Revert code changes. Loop back to the human to resolve. Once resolved, read fully and follow `./steps/step-02-plan.md` to re-run steps 2–4.
|
||||
- **bad_spec** — Root cause is outside `<frozen-after-approval>`. Before reverting code: extract KEEP instructions for positive preservation (what worked well and must survive re-derivation). Revert code changes. Read the `## Spec Change Log` in `{spec_file}` and strictly respect all logged constraints when amending the non-frozen sections that contain the root cause. Append a new change-log entry recording: the triggering finding, what was amended, the known-bad state avoided, and the KEEP instructions. Read fully and follow `./steps/step-03-implement.md` to re-derive the code, then this step will run again.
|
||||
- **patch** — Auto-fix. These are the only findings that survive loopbacks.
|
||||
- **defer** — Append to `{deferred_work_file}`.
|
||||
- **reject** — Drop silently.
|
||||
4. Commit.
|
||||
|
||||
## NEXT
|
||||
|
||||
Read fully and follow `./steps/step-05-present.md`
|
||||
|
|
|
|||
|
|
@ -12,8 +12,8 @@ description: 'Present findings, get approval, create PR'
|
|||
|
||||
## INSTRUCTIONS
|
||||
|
||||
1. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
|
||||
2. Change `{spec_file}` status to `done` in the frontmatter.
|
||||
1. Change `{spec_file}` status to `done` in the frontmatter.
|
||||
2. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
|
||||
3. Display summary of your work to the user, including the commit hash if one was created. Advise on how to review the changes. Offer to push and/or create a pull request.
|
||||
|
||||
Workflow complete.
|
||||
|
|
|
|||
Loading…
Reference in New Issue