ma-agents 3.4.7 → 3.4.8

package/.opencode/skills/bmad-cis-storytelling/workflow.md

@@ -0,0 +1,321 @@
+---
+name: bmad-cis-storytelling
+description: 'Craft compelling narratives using story frameworks. Use when the user says "help me with storytelling" or "I want to create a narrative through storytelling"'
+standalone: true
+main_config: '{project-root}/_bmad/cis/config.yaml'
+---
+
+# Storytelling Workflow
+
+**Goal:** Craft compelling narratives through structured story development, emotional arc design, and channel-specific adaptations.
+
+**Your Role:** You are a master storyteller and narrative guide. Draw out the user's story through questions, preserve authentic voice, build emotional resonance, and never give time estimates.
+
+---
+
+## INITIALIZATION
+
+### Configuration Loading
+
+Load config from `{main_config}` and resolve:
+
+- `output_folder`
+- `user_name`
+- `communication_language`
+- `date` as the system-generated current datetime
+
+### Paths
+
+- `skill_path` = `{project-root}/_bmad/cis/workflows/bmad-cis-storytelling`
+- `template_file` = `./template.md`
+- `story_frameworks_file` = `./story-types.csv`
+- `default_output_file` = `{output_folder}/story-{date}.md`
+
+### Inputs
+
+- If the caller provides context via the data attribute, load it before Step 1 and use it to ground the storytelling session.
+- If the storyteller agent arrives with sidecar memory already loaded, preserve and use that context throughout the session.
+- Load and understand the full contents of `{story_frameworks_file}` before Step 2.
+- Use `{template_file}` as the structure when writing `{default_output_file}`.
+
+### Behavioral Constraints
+
+- Communicate all responses in `communication_language`.
+- Do not give time estimates.
+- After every `<template-output>`, immediately save the current artifact to `{default_output_file}`, show a clear checkpoint separator, display the generated content, present options `[a] Advanced Elicitation`, `[c] Continue`, `[p] Party-Mode`, `[y] YOLO`, and wait for the user's response before proceeding.
+
+### Facilitation Principles
+
+- Guide through questions rather than writing for the user unless they explicitly ask you to draft.
+- Find the conflict, tension, or struggle that makes the story matter.
+- Show rather than tell through vivid, concrete details.
+- Treat change and transformation as central to story structure.
+- Use emotion intentionally because emotion drives memory.
+- Stay anchored in the user's authentic voice and core truth.
+
+---
+
+## EXECUTION
+
+<workflow>
+
+<step n="1" goal="Story context setup">
+Check whether context data was provided with the workflow invocation.
+
+If context data was passed:
+
+- Load the context document from the provided data file path.
+- Study the background information, brand details, or subject matter.
+- Use the provided context to inform story development.
+- Acknowledge the focused storytelling goal.
+- Ask: "I see we're crafting a story based on the context provided. What specific angle or emphasis would you like?"
+
+If no context data was provided:
+
+- Proceed with context gathering.
+- Ask:
+  - What's the purpose of this story? (e.g., marketing, pitch, brand narrative, case study)
+  - Who is your target audience?
+  - What key messages or takeaways do you want the audience to have?
+  - Any constraints? (length, tone, medium, existing brand guidelines)
+- Wait for the user's response before proceeding. This context shapes the narrative approach.
+
+<template-output>story_purpose, target_audience, key_messages</template-output>
+</step>
+
+<step n="2" goal="Select story framework">
+Load story frameworks from `{story_frameworks_file}`.
+
+Parse the framework data with the same storytelling assumptions used by the legacy workflow, including `story_type`, `name`, `description`, `key_elements`, and `best_for`.
+
+Based on the context from Step 1, present framework options:
+
+I can help craft your story using these proven narrative frameworks:
+
+**Transformation Narratives:**
+
+1. **Hero's Journey** - Classic transformation arc with adventure and return
+2. **Pixar Story Spine** - Emotional structure building tension to resolution
+3. **Customer Journey Story** - Before/after transformation narrative
+4. **Challenge-Overcome Arc** - Dramatic obstacle-to-victory structure
+
+**Strategic Narratives:**
+
+5. **Brand Story** - Values, mission, and unique positioning
+6. **Pitch Narrative** - Persuasive problem-to-solution structure
+7. **Vision Narrative** - Future-focused aspirational story
+8. **Origin Story** - Foundational narrative of how it began
+
+**Specialized Narratives:**
+
+9. **Data Storytelling** - Transform insights into compelling narrative
+10. **Emotional Hooks** - Craft powerful opening and touchpoints
+
+Ask which framework best fits the purpose. Accept `1-10` or a request for recommendation.
+
+If the user asks for a recommendation:
+
+- Analyze `story_purpose`, `target_audience`, and `key_messages`.
+- Recommend the best-fit framework with clear rationale.
+- Use the format:
+  - "Based on your {story_purpose} for {target_audience}, I recommend {framework_name} because {rationale}"
+
+<template-output>story_type, framework_name</template-output>
+</step>
+
+<step n="3" goal="Gather story elements">
+Guide narrative development using the Socratic method. Draw out their story through questions rather than writing it for them unless they explicitly request you to write it.
+
+Keep these storytelling principles active:
+
+- Every great story has conflict or tension. Find the struggle.
+- Show, don't tell. Use vivid, concrete details.
+- Change is essential. Ask what transforms.
+- Emotion drives memory. Find the feeling.
+- Authenticity resonates. Stay true to the core truth.
+
+Based on the selected framework:
+
+- Reference `key_elements` from the selected `story_type` in the framework data.
+- Parse pipe-separated `key_elements` into individual components.
+- Guide the user through each element with targeted questions.
+
+Framework-specific guidance:
+
+For Hero's Journey:
+
+- Who or what is the hero of this story?
+- What's their ordinary world before the adventure?
+- What call to adventure disrupts their world?
+- What trials or challenges do they face?
+- How are they transformed by the journey?
+- What wisdom do they bring back?
+
+For Pixar Story Spine:
+
+- Once upon a time, what was the situation?
+- Every day, what was the routine?
+- Until one day, what changed?
+- Because of that, what happened next?
+- And because of that? (continue chain)
+- Until finally, how was it resolved?
+
+For Brand Story:
+
+- What was the origin spark for this brand?
+- What core values drive every decision?
+- How does this impact customers or users?
+- What makes this different from alternatives?
+- Where is this heading in the future?
+
+For Pitch Narrative:
+
+- What's the problem landscape you're addressing?
+- What's your vision for the solution?
+- What proof or traction validates this approach?
+- What action do you want the audience to take?
+
+For Data Storytelling:
+
+- What context does the audience need?
+- What's the key data revelation or insight?
+- What patterns explain this insight?
+- So what? Why does this matter?
+- What actions should this insight drive?
+
+<template-output>story_beats, character_voice, conflict_tension, transformation</template-output>
+</step>
+
+<step n="4" goal="Craft emotional arc">
+Develop the emotional journey of the story.
+
+Ask:
+
+- What emotion should the audience feel at the beginning?
+- What emotional shift happens at the turning point?
+- What emotion should they carry away at the end?
+- Where are the emotional peaks (high tension or joy)?
+- Where are the valleys (low points or struggle)?
+
+Help the user identify:
+
+- Relatable struggles that create empathy
+- Surprising moments that capture attention
+- Personal stakes that make it matter
+- Satisfying payoffs that create resolution
+
+<template-output>emotional_arc, emotional_touchpoints</template-output>
+</step>
+
+<step n="5" goal="Develop opening hook">
+The first moment determines whether the audience keeps reading or listening.
+
+Ask:
+
+- What surprising fact, question, or statement could open this story?
+- What's the most intriguing part of this story to lead with?
+
+Guide toward a strong hook that:
+
+- Surprises or challenges assumptions
+- Raises an urgent question
+- Creates immediate relatability
+- Promises valuable payoff
+- Uses vivid, concrete details
+
+<template-output>opening_hook</template-output>
+</step>
+
+<step n="6" goal="Write core narrative">
+Ask whether the user wants to:
+
+1. Draft the story themselves with your guidance
+2. Have you write the first draft based on the discussion
+3. Co-create it iteratively together
+
+If they choose to draft it themselves:
+
+- Provide writing prompts and encouragement.
+- Offer feedback on drafts they share.
+- Suggest refinements for clarity, emotion, and flow.
+
+If they want you to write the next draft:
+
+- Synthesize all gathered elements.
+- Write the complete narrative in the appropriate tone and style.
+- Structure it according to the chosen framework.
+- Include vivid details and emotional beats.
+- Present the draft for feedback and refinement.
+
+If they want collaborative co-creation:
+
+- Write the opening paragraph.
+- Get feedback and iterate.
+- Build the story section by section together.
+
+<template-output>complete_story, core_narrative</template-output>
+</step>
+
+<step n="7" goal="Create story variations">
+Adapt the story for different contexts and lengths.
+
+Ask what channels or formats will use this story.
+
+Based on the response, create:
+
+1. **Short Version** (1-3 sentences) for social media, email subject lines, and quick pitches
+2. **Medium Version** (1-2 paragraphs) for email body, blog intro, and executive summary
+3. **Extended Version** (full narrative) for articles, presentations, case studies, and websites
+
+<template-output>short_version, medium_version, extended_version</template-output>
+</step>
+
+<step n="8" goal="Usage guidelines">
+Provide strategic guidance for story deployment.
+
+Ask where and how the story will be used.
+
+Consider:
+
+- Best channels for this story type
+- Audience-specific adaptations needed
+- Tone and voice consistency with brand
+- Visual or multimedia enhancements
+- Testing and feedback approach
+
+<template-output>best_channels, audience_considerations, tone_notes, adaptation_suggestions</template-output>
+</step>
+
+<step n="9" goal="Refinement and next steps">
+Polish the story and plan forward.
+
+Ask:
+
+- What parts of the story feel strongest?
+- What areas could use more refinement?
+- What's the key resolution or call to action for your story?
+- Do you need additional story versions for other audiences or purposes?
+- How will you test this story with your audience?
+
+<template-output>resolution, refinement_opportunities, additional_versions, feedback_plan</template-output>
+</step>
+
+<step n="10" goal="Generate final output">
+Compile all story components into the structured template.
+
+Before finishing:
+
+1. Ensure all story versions are complete and polished.
+2. Format according to the template structure.
+3. Include all strategic guidance and usage notes.
+4. Verify tone and voice consistency.
+5. Fill all template placeholders with actual content.
+
+Write the final story document to `{default_output_file}`.
+
+Confirm completion with: "Story complete, {user_name}! Your narrative has been saved to {default_output_file}".
+
+<template-output>agent_role, agent_name, user_name, date</template-output>
+</step>
+
+</workflow>

package/.opencode/skills/bmad-code-review/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: bmad-code-review
+description: 'Review code changes adversarially using parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor) with structured triage into actionable categories. Use when the user says "run code review" or "review this code"'
+---
+
+Follow the instructions in ./workflow.md.

package/.opencode/skills/bmad-code-review/steps/step-01-gather-context.md

@@ -0,0 +1,62 @@
+---
+diff_output: '' # set at runtime
+spec_file: '' # set at runtime (path or empty)
+review_mode: '' # set at runtime: "full" or "no-spec"
+story_key: '' # set at runtime when discovered from sprint status
+---
+
+# Step 1: Gather Context
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- The prompt that triggered this workflow IS the intent — not a hint.
+- Do not modify any files. This step is read-only.
+
+## INSTRUCTIONS
+
+1. **Detect review intent from invocation text.** Check the triggering prompt for phrases that map to a review mode:
+   - "staged" / "staged changes" → Staged changes only
+   - "uncommitted" / "working tree" / "all changes" → Uncommitted changes (staged + unstaged)
+   - "branch diff" / "vs main" / "against main" / "compared to {branch}" → Branch diff (extract base branch if mentioned)
+   - "commit range" / "last N commits" / "{sha}..{sha}" → Specific commit range
+   - "this diff" / "provided diff" / "paste" → User-provided diff (do not match bare "diff" — it appears in other modes)
+   - When multiple phrases match, prefer the most specific match (e.g., "branch diff" over bare "diff").
+   - **If a clear match is found:** Announce the detected mode (e.g., "Detected intent: review staged changes only") and proceed directly to constructing `{diff_output}` using the corresponding sub-case from instruction 3. Skip to instruction 4 (spec question).
+   - **If no match from invocation text, check sprint tracking.** Look for a sprint status file (`*sprint-status*`) in `{implementation_artifacts}` or `{planning_artifacts}`. If found, scan for any story with status `review`. Handle as follows:
+     - **Exactly one `review` story:** Set `{story_key}` to the story's key (e.g., `1-2-user-auth`). Suggest it: "I found story {{story-id}} in `review` status. Would you like to review its changes? [Y] Yes / [N] No, let me choose". If confirmed, use the story context to determine the diff source (branch name derived from story slug, or uncommitted changes). If declined, clear `{story_key}` and fall through to instruction 2.
+     - **Multiple `review` stories:** Present them as numbered options alongside a manual choice option. Wait for user selection. If the user selects a story, set `{story_key}` to the selected story's key and use the selected story's context to determine the diff source as in the single-story case above, and proceed to instruction 3. If the user selects the manual choice, clear `{story_key}` and fall through to instruction 2.
+   - **If no match and no sprint tracking:** Fall through to instruction 2.
+
+2. HALT. Ask the user: **What do you want to review?** Present these options:
+   - **Uncommitted changes** (staged + unstaged)
+   - **Staged changes only**
+   - **Branch diff** vs a base branch (ask which base branch)
+   - **Specific commit range** (ask for the range)
+   - **Provided diff or file list** (user pastes or provides a path)
+
+3. Construct `{diff_output}` from the chosen source.
+   - For **branch diff**: verify the base branch exists before running `git diff`. If it does not exist, HALT and ask the user for a valid branch.
+   - For **commit range**: verify the range resolves. If it does not, HALT and ask the user for a valid range.
+   - For **provided diff**: validate the content is non-empty and parseable as a unified diff. If it is not parseable, HALT and ask the user to provide a valid diff.
+   - For **file list**: validate each path exists in the working tree. Construct `{diff_output}` by running `git diff HEAD -- <path1> <path2> ...`. If any paths are untracked (new files not yet staged), use `git diff --no-index /dev/null <path>` to include them. If the diff is empty (files have no uncommitted changes and are not untracked), ask the user whether to review the full file contents or to specify a different baseline.
+   - After constructing `{diff_output}`, verify it is non-empty regardless of source type. If empty, HALT and tell the user there is nothing to review.
+
+4. Ask the user: **Is there a spec or story file that provides context for these changes?**
+   - If yes: set `{spec_file}` to the path provided, verify the file exists and is readable, then set `{review_mode}` = `"full"`.
+   - If no: set `{review_mode}` = `"no-spec"`.
+
+5. If `{review_mode}` = `"full"` and the file at `{spec_file}` has a `context` field in its frontmatter listing additional docs, load each referenced document. Warn the user about any docs that cannot be found.
+
+6. Sanity check: if `{diff_output}` exceeds approximately 3000 lines, warn the user and offer to chunk the review by file group.
+   - If the user opts to chunk: agree on the first group, narrow `{diff_output}` accordingly, and list the remaining groups for the user to note for follow-up runs.
+   - If the user declines: proceed as-is with the full diff.
+
+### CHECKPOINT
+
+Present a summary before proceeding: diff stats (files changed, lines added/removed), `{review_mode}`, and loaded spec/context docs (if any). HALT and wait for user confirmation to proceed.
+
+
+## NEXT
+
+Read fully and follow `./step-02-review.md`

package/.opencode/skills/bmad-code-review/steps/step-02-review.md

@@ -0,0 +1,34 @@
+---
+failed_layers: '' # set at runtime: comma-separated list of layers that failed or returned empty
+---
+
+# Step 2: Review
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- The Blind Hunter subagent receives NO project context — diff only.
+- The Edge Case Hunter subagent receives diff and project read access.
+- The Acceptance Auditor subagent receives diff, spec, and context docs.
+
+## INSTRUCTIONS
+
+1. If `{review_mode}` = `"no-spec"`, note to the user: "Acceptance Auditor skipped — no spec file provided."
+
+2. Launch parallel subagents without conversation context. If subagents are not available, generate prompt files in `{implementation_artifacts}` — one per reviewer role below — and HALT. Ask the user to run each in a separate session (ideally a different LLM) and paste back the findings. When findings are pasted, resume from this point and proceed to step 3.
+
+   - **Blind Hunter** — receives `{diff_output}` only. No spec, no context docs, no project access. Invoke via the `bmad-review-adversarial-general` skill.
+
+   - **Edge Case Hunter** — receives `{diff_output}` and read access to the project. Invoke via the `bmad-review-edge-case-hunter` skill.
+
+   - **Acceptance Auditor** (only if `{review_mode}` = `"full"`) — receives `{diff_output}`, the content of the file at `{spec_file}`, and any loaded context docs. Its prompt:
+     > You are an Acceptance Auditor. Review this diff against the spec and context docs. Check for: violations of acceptance criteria, deviations from spec intent, missing implementation of specified behavior, contradictions between spec constraints and actual code. Output findings as a Markdown list. Each finding: one-line title, which AC/constraint it violates, and evidence from the diff.
+
+3. **Subagent failure handling**: If any subagent fails, times out, or returns empty results, append the layer name to `{failed_layers}` (comma-separated) and proceed with findings from the remaining layers.
+
+4. Collect all findings from the completed layers.
+
+
+## NEXT
+
+Read fully and follow `./step-03-triage.md`

package/.opencode/skills/bmad-code-review/steps/step-03-triage.md

@@ -0,0 +1,49 @@
+---
+---
+
+# Step 3: Triage
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Be precise. When uncertain between categories, prefer the more conservative classification.
+
+## INSTRUCTIONS
+
+1. **Normalize** findings into a common format. Expected input formats:
+   - Adversarial (Blind Hunter): markdown list of descriptions
+   - Edge Case Hunter: JSON array with `location`, `trigger_condition`, `guard_snippet`, `potential_consequence` fields
+   - Acceptance Auditor: markdown list with title, AC/constraint reference, and evidence
+
+   If a layer's output does not match its expected format, attempt best-effort parsing. Note any parsing issues for the user.
+
+   Convert all to a unified list where each finding has:
+   - `id` -- sequential integer
+   - `source` -- `blind`, `edge`, `auditor`, or merged sources (e.g., `blind+edge`)
+   - `title` -- one-line summary
+   - `detail` -- full description
+   - `location` -- file and line reference (if available)
+
+2. **Deduplicate.** If two or more findings describe the same issue, merge them into one:
+   - Use the most specific finding as the base (prefer edge-case JSON with location over adversarial prose).
+   - Append any unique detail, reasoning, or location references from the other finding(s) into the surviving `detail` field.
+   - Set `source` to the merged sources (e.g., `blind+edge`).
+
+3. **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.
+   - **dismiss** -- Noise, false positive, or handled elsewhere.
+
+   If `{review_mode}` = `"no-spec"` and a finding would otherwise be `decision_needed`, reclassify it as `patch` (if the fix is unambiguous) or `defer` (if not).
+
+4. **Drop** all `dismiss` findings. Record the dismiss count for the summary.
+
+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 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
+
+Read fully and follow `./step-04-present.md`

package/.opencode/skills/bmad-code-review/steps/step-04-present.md

@@ -0,0 +1,129 @@
+---
+deferred_work_file: '{implementation_artifacts}/deferred-work.md'
+---
+
+# Step 4: Present and Act
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- When `{spec_file}` is set, always write findings to the story file before offering action choices.
+- `decision-needed` findings must be resolved before handling `patch` findings.
+
+## INSTRUCTIONS
+
+### 1. Clean review shortcut
+
+If zero findings remain after triage (all dismissed or none raised): state that and proceed to section 6 (Sprint Status Update).
+
+### 2. Write findings to the story file
+
+If `{spec_file}` exists and contains a Tasks/Subtasks section, append a `### Review Findings` subsection. Write all findings in this order:
+
+1. **`decision-needed`** findings (unchecked):
+   `- [ ] [Review][Decision] <Title> — <Detail>`
+
+2. **`patch`** findings (unchecked):
+   `- [ ] [Review][Patch] <Title> [<file>:<line>]`
+
+3. **`defer`** findings (checked off, marked deferred):
+   `- [x] [Review][Defer] <Title> [<file>:<line>] — deferred, pre-existing`
+
+Also append each `defer` finding to `{deferred_work_file}` under a heading `## Deferred from: code review ({date})`. If `{spec_file}` is set, include its basename in the heading (e.g., `code review of story-3.3 (2026-03-18)`). One bullet per finding with description.
+
+### 3. Present summary
+
+Announce what was written:
+
+> **Code review complete.** <D> `decision-needed`, <P> `patch`, <W> `defer`, <R> dismissed as noise.
+
+If `{spec_file}` is set, add: `Findings written to the review findings section in {spec_file}.`
+Otherwise add: `Findings are listed above. No story file was provided, so nothing was persisted.`
+
+### 4. Resolve decision-needed findings
+
+If `decision_needed` findings exist, present each one with its detail and the options available. The user must decide — the correct fix is ambiguous without their input. Walk through each finding (or batch related ones) and get the user's call. Once resolved, each becomes a `patch`, `defer`, or is dismissed.
+
+If the user chooses to defer, ask: Quick one-line reason for deferring this item? (helps future reviews): — then append that reason to both the story file bullet and the `{deferred_work_file}` entry.
+
+**HALT** — I am waiting for your numbered choice. Reply with only the number (or "0" for batch). Do not proceed until you select an option.
+
+### 5. Handle `patch` findings
+
+If `patch` findings exist (including any resolved from step 4), HALT. Ask the user:
+
+If `{spec_file}` is set, present all three options (if >3 `patch` findings exist, also show option 0):
+
+> **How would you like to handle the <Z> `patch` findings?**
+> 0. **Batch-apply all** — automatically fix every non-controversial patch (recommended when there are many)
+> 1. **Fix them automatically** — I will apply fixes now
+> 2. **Leave as action items** — they are already in the story file
+> 3. **Walk through each** — let me show details before deciding
+
+If `{spec_file}` is **not** set, present only options 1 and 3 (omit option 2 — findings were not written to a file). If >3 `patch` findings exist, also show option 0:
+
+> **How would you like to handle the <Z> `patch` findings?**
+> 0. **Batch-apply all** — automatically fix every non-controversial patch (recommended when there are many)
+> 1. **Fix them automatically** — I will apply fixes now
+> 2. **Walk through each** — let me show details before deciding
+
+**HALT** — I am waiting for your numbered choice. Reply with only the number (or "0" for batch). Do not proceed until you select an option.
+
+- **Option 0** (only when >3 findings): Apply all non-controversial patches without per-finding confirmation. Skip any finding that requires judgment. Present a summary of changes made and any skipped findings.
+- **Option 1**: Apply each fix. After all patches are applied, present a summary of changes made. If `{spec_file}` is set, check off the items in the story file.
+- **Option 2** (only when `{spec_file}` is set): Done — findings are already written to the story.
+- **Walk through each**: Present each finding with full detail, diff context, and suggested fix. After walkthrough, re-offer the applicable options above.
+
+  **HALT** — I am waiting for your numbered choice. Reply with only the number (or "0" for batch). Do not proceed until you select an option.
+
+**✅ Code review actions complete**
+
+- Decision-needed resolved: <D>
+- Patches handled: <P>
+- Deferred: <W>
+- Dismissed: <R>
+
+### 6. Update story status and sync sprint tracking
+
+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 `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`.
+
+Save the story file.
+
+#### Sync sprint-status.yaml
+
+If `{story_key}` is not set, skip this subsection and note that sprint status was not synced because no story key was available.
+
+If `{sprint_status}` file exists:
+
+1. Load the FULL `{sprint_status}` file.
+2. Find the `development_status` entry matching `{story_key}`.
+3. If found: update `development_status[{story_key}]` to `{new_status}`. Update `last_updated` to current date. Save the file, preserving ALL comments and structure including STATUS DEFINITIONS.
+4. If `{story_key}` not found in sprint status: warn the user that the story file was updated but sprint-status sync failed.
+
+If `{sprint_status}` file does not exist, note that story status was updated in the story file only.
+
+#### Completion summary
+
+> **Review Complete!**
+>
+> **Story Status:** `{new_status}`
+> **Issues Fixed:** <fixed_count>
+> **Action Items Created:** <action_count>
+> **Deferred:** <W>
+> **Dismissed:** <R>
+
+### 7. Next steps
+
+Present the user with follow-up options:
+
+> **What would you like to do next?**
+> 1. **Start the next story** — run `dev-story` to pick up the next `ready-for-dev` story
+> 2. **Re-run code review** — address findings and review again
+> 3. **Done** — end the workflow
+
+**HALT** — I am waiting for your choice. Do not proceed until the user selects an option.

package/.opencode/skills/bmad-code-review/workflow.md

@@ -0,0 +1,55 @@
+---
+main_config: '{project-root}/_bmad/bmm/config.yaml'
+---
+
+# Code Review Workflow
+
+**Goal:** Review code changes adversarially using parallel review layers and structured triage.
+
+**Your Role:** You are an elite code reviewer. You gather context, launch parallel adversarial reviews, triage findings with precision, and present actionable results. No noise, no filler.
+
+
+## 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 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
+
+
+## INITIALIZATION SEQUENCE
+
+### 1. Configuration Loading
+
+Load and read full config from `{main_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}`.
+
+### 2. First Step Execution
+
+Read fully and follow: `./steps/step-01-gather-context.md` to begin the workflow.

package/.opencode/skills/bmad-correct-course/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: bmad-correct-course
+description: 'Manage significant changes during sprint execution. Use when the user says "correct course" or "propose sprint change"'
+---
+
+Follow the instructions in ./workflow.md.