fix(bmm): address third augment review batch on bmad skills

- step-03-triage: renumber the malformed `2b.` list item to a proper
  sequential step 3 (+ fix hanging indent) so the auto-mode
  "Verify against the code" step renders/parses as a list item.
- step-04-present (code-review): section 6 now says to update the spec's
  YAML frontmatter `status:` field (not an ambiguous "Status section"),
  matching automation-mode rule 8, quick-dev step-auto-finalize, the
  spec template, and the orchestrator's frontmatter status check.
- On Complete vs result.json-is-last-action: skip `## On Complete` /
  workflow.on_complete in auto mode. Removed the contradictory block
  from the auto-only step-auto-finalize; guarded the dual-mode
  code-review step-04-present block; added authoritative clauses to
  both automation-mode rulebooks (quick-dev rule 6, code-review rule 7).

Item on the 1600/4000 token threshold needed no change — step-02-plan
already inlines the {auto_mode} 4000 override and auto-splits.

validate:refs, validate:skills, lint:md all pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

src/bmm-skills/4-implementation/bmad-code-review/automation-mode.md

@@ -67,7 +67,9 @@ this workflow.
 7. **Act** (step-04): write findings to the spec file as usual; apply EVERY
    `patch` finding without asking; append `defer` findings to the
    deferred-work file following the format in `./deferred-work-format.md`;
-   skip the "Next steps" menu entirely.
+   skip the "Next steps" menu entirely. Skip the `## On Complete` step /
+   `workflow.on_complete` customization — result.json is the LAST action;
+   the orchestrator owns commit and everything after it.
 8. **Status updates** (step-04 section 6) run exactly as written: spec
    status (frontmatter `status:`) and sprint-status sync.
    `clean: true` in result.json must mean you set the spec to `done` —

src/bmm-skills/4-implementation/bmad-code-review/steps/step-03-triage.md

@@ -37,7 +37,7 @@
    checked against the current code before re-raising — the patch may already
    cover it.
 
-2b. **Verify against the code** (`{auto_mode}` only). For each surviving finding (except `static`
+3. **Verify against the code** (`{auto_mode}` only). For each surviving finding (except `static`
    ones — those are tool output), check it against the actual code before
    classifying. You have project access; the hunters that produced these
    findings mostly did not. A finding contradicted by the surrounding code —
@@ -46,7 +46,7 @@ finding assumes, the "missing" handling exists elsewhere — becomes `dismiss`
    with the contradiction recorded as its reason. Do not classify a finding you
    have not verified.
 
-3. **Classify** each finding into exactly one bucket:
+4. **Classify** each finding into exactly one bucket:
    - **decision_needed** -- There is an ambiguous choice that requires human input. The code cannot be correctly patched without knowing the user's intent. Only possible if `{review_mode}` = `"full"`.
    - **patch** -- Code issue that is fixable without human input. The correct fix is unambiguous.
    - **defer** -- Pre-existing issue not caused by the current change. Real but not actionable now.
@@ -56,11 +56,11 @@ have not verified.
 
    If `{auto_mode}` and a finding would otherwise be `decision_needed`: reclassify as `patch` only when the fix is genuinely unambiguous; otherwise reclassify as `defer` with reason "auto-mode: needs human decision" AND record it in the result escalations — severity `CRITICAL` if it concerns correctness or security of the new code, else `PREFERENCE` (see `../automation-mode.md` rule 5).
 
-4. **Drop** all `dismiss` findings. Record the dismiss count for the summary. (`{auto_mode}`: do NOT drop — set each dismissed finding aside, keeping its title, location, and one-line dismissal reason; step-04 writes them to the Review Ledger so later cycles do not re-litigate them.)
+5. **Drop** all `dismiss` findings. Record the dismiss count for the summary. (`{auto_mode}`: do NOT drop — set each dismissed finding aside, keeping its title, location, and one-line dismissal reason; step-04 writes them to the Review Ledger so later cycles do not re-litigate them.)
 
-5. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
+6. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
 
-6. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via `{failed_layers}`.)
+7. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via `{failed_layers}`.)
 
 
 ## NEXT

src/bmm-skills/4-implementation/bmad-code-review/steps/step-04-present.md

@@ -100,8 +100,8 @@ Skip this section if `{spec_file}` is not set.
 
 #### Determine new status based on review outcome
 
-- If all `decision-needed` and `patch` findings were resolved (fixed or dismissed) AND no unresolved HIGH/MEDIUM issues remain: set `{new_status}` = `done`. Update the story file Status section to `done`.
+- If all `decision-needed` and `patch` findings were resolved (fixed or dismissed) AND no unresolved HIGH/MEDIUM issues remain: set `{new_status}` = `done`. Update the spec's YAML frontmatter `status:` field to `done`.
-- If `patch` findings were left as action items, or unresolved issues remain: set `{new_status}` = `in-progress`. Update the story file Status section to `in-progress`.
+- If `patch` findings were left as action items, or unresolved issues remain: set `{new_status}` = `in-progress`. Update the spec's YAML frontmatter `status:` field to `in-progress`.
 
 Save the story file.
 
@@ -141,6 +141,8 @@ Present the user with follow-up options:
 
 ## On Complete
 
+**If `{auto_mode}`:** skip this section entirely — result.json (written after section 6) is the LAST action of the run (see `../automation-mode.md`); the orchestrator owns commit and everything after it.
+
 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.

src/bmm-skills/4-implementation/bmad-quick-dev/automation-mode.md

@@ -82,6 +82,9 @@ These rules override conversational behavior everywhere in this workflow.
      `./step-auto-finalize.md` (status `in-review`; orchestrator reviews).
    - **Never run step-05-present** in either case — the orchestrator commits.
 6. **Never open an editor, never commit, never push, never offer follow-ups.**
+   Skip any `## On Complete` step / `workflow.on_complete` customization — result.json
+   (step-auto-finalize) is the LAST action of the run; the orchestrator owns commit,
+   review, and everything after it.
 
 ## Scope override
 

src/bmm-skills/4-implementation/bmad-quick-dev/step-auto-finalize.md

@@ -67,8 +67,8 @@ ids, verbatim>]` — the orchestrator rejects the result when the list does
 6. State in one line what was implemented and end your turn. Do not ask
    questions, offer next steps, or wait for anything.
 
-## On Complete
+There is no `## On Complete` step here: this step runs only under automation,
-
+where writing result.json (instruction 5) is the LAST action of the run (see
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
+`./automation-mode.md`) and the orchestrator owns everything after it. The
-
+interactive `workflow.on_complete` customization hook lives in
-If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.
+`./step-05-present.md`.