ma-agents 3.12.0 → 3.12.2

package/lib/templates/agents-md.template.md

@@ -1,67 +1,67 @@
-# Project Agent Instructions
-
-This file is auto-discovered by OpenCode and any agent that respects `AGENTS.md`.
-It establishes universal safety rules, text-vs-file discipline, and BMAD phase
-discipline for every agent operating in this project.
-
-## Universal Rules
-
-The universal rules block below is stamped and maintained by ma-agents. Edit
-outside the HTML-comment `MA-AGENTS` start and end markers to preserve your
-own additions — content inside the markers is regenerated on every install.
-
-<!-- MA-AGENTS-START -->
-<!-- MA-AGENTS-END -->
-
-## Critical Behavior Rules
-
-These rules are non-negotiable across every profile and every agent.
-
-- **Never create files in `~/.claude/` or any user home directory.** All
-  project artifacts must land inside the current working directory. Home-
-  directory writes cross-contaminate between projects and are a common source
-  of secret/config leakage.
-- **Never write outside the project root without an explicit user request
-  naming the absolute path.** "Write to disk" means the project, not the
-  operator's machine.
-- **Do not modify files you did not read first.** Read the current content
-  before proposing or performing an edit — blind writes silently destroy user
-  work.
-
-## BMAD Phase Declaration
-
-BMAD-METHOD organizes work into four phases. Respect the currently declared
-phase; do not skip ahead to the next phase without a phase transition signal
-from the user, the active skill, or the story status.
-
-- **Discovery / PM (analysis, planning).** Deliverables: product briefs,
-  PRDs, market and domain research, epics and stories lists. Do NOT produce
-  code, architecture diagrams, or implementation artifacts in this phase.
-  When asked "what do you think", respond in text.
-- **Architecture.** Deliverables: solution design, component boundaries,
-  data-flow, interface contracts. Do NOT write application code or skill
-  implementations. Narrate decisions and capture them as documents.
-- **Tech Lead / Stories.** Deliverables: individual story files with full
-  acceptance criteria, task breakdowns, and dev notes. Do NOT begin
-  implementation — stories are contracts the implementer consumes later.
-- **Implementation.** Deliverables: code, tests, and the Dev Agent Record on
-  the story file. At this phase, write files. Do NOT retroactively fabricate
-  planning documents for code that already exists — flag the gap instead.
-
-When no phase is declared (no active skill, no story in progress, no explicit
-user statement), ask before assuming.
-
-## Project BMAD Output Structure
-
-BMAD artifacts live under `_bmad-output/` (or the paths configured in
-`_bmad/bmm/config.yaml` when present). The install-time resolver logs the
-resolved paths on each run; consult that log output if in doubt.
-
-- **Planning artifacts** — PRDs, product briefs, market and domain research.
-- **Architecture artifacts** — solution design, component boundaries. May be
-  co-located with planning artifacts when no separate directory is configured.
-- **Implementation artifacts (stories)** — individual story files and their
-  Dev Agent Records.
-
-Always consult the `MANIFEST.yaml` referenced inside the universal block above
-for the full list of installed skills and their locations.
+# Project Agent Instructions
+
+This file is auto-discovered by OpenCode and any agent that respects `AGENTS.md`.
+It establishes universal safety rules, text-vs-file discipline, and BMAD phase
+discipline for every agent operating in this project.
+
+## Universal Rules
+
+The universal rules block below is stamped and maintained by ma-agents. Edit
+outside the HTML-comment `MA-AGENTS` start and end markers to preserve your
+own additions — content inside the markers is regenerated on every install.
+
+<!-- MA-AGENTS-START -->
+<!-- MA-AGENTS-END -->
+
+## Critical Behavior Rules
+
+These rules are non-negotiable across every profile and every agent.
+
+- **Never create files in `~/.claude/` or any user home directory.** All
+  project artifacts must land inside the current working directory. Home-
+  directory writes cross-contaminate between projects and are a common source
+  of secret/config leakage.
+- **Never write outside the project root without an explicit user request
+  naming the absolute path.** "Write to disk" means the project, not the
+  operator's machine.
+- **Do not modify files you did not read first.** Read the current content
+  before proposing or performing an edit — blind writes silently destroy user
+  work.
+
+## BMAD Phase Declaration
+
+BMAD-METHOD organizes work into four phases. Respect the currently declared
+phase; do not skip ahead to the next phase without a phase transition signal
+from the user, the active skill, or the story status.
+
+- **Discovery / PM (analysis, planning).** Deliverables: product briefs,
+  PRDs, market and domain research, epics and stories lists. Do NOT produce
+  code, architecture diagrams, or implementation artifacts in this phase.
+  When asked "what do you think", respond in text.
+- **Architecture.** Deliverables: solution design, component boundaries,
+  data-flow, interface contracts. Do NOT write application code or skill
+  implementations. Narrate decisions and capture them as documents.
+- **Tech Lead / Stories.** Deliverables: individual story files with full
+  acceptance criteria, task breakdowns, and dev notes. Do NOT begin
+  implementation — stories are contracts the implementer consumes later.
+- **Implementation.** Deliverables: code, tests, and the Dev Agent Record on
+  the story file. At this phase, write files. Do NOT retroactively fabricate
+  planning documents for code that already exists — flag the gap instead.
+
+When no phase is declared (no active skill, no story in progress, no explicit
+user statement), ask before assuming.
+
+## Project BMAD Output Structure
+
+BMAD artifacts live under `_bmad-output/` (or the paths configured in
+`_bmad/bmm/config.yaml` when present). The install-time resolver logs the
+resolved paths on each run; consult that log output if in doubt.
+
+- **Planning artifacts** — PRDs, product briefs, market and domain research.
+- **Architecture artifacts** — solution design, component boundaries. May be
+  co-located with planning artifacts when no separate directory is configured.
+- **Implementation artifacts (stories)** — individual story files and their
+  Dev Agent Records.
+
+Always consult the `MANIFEST.yaml` referenced inside the universal block above
+for the full list of installed skills and their locations.

package/lib/templates/clinerules.template.md

@@ -1,13 +1,13 @@
-# Cline Project Rules
-
-These rules apply to every Cline session in this project. Cline auto-loads
-`.clinerules` (and `.cline/clinerules.md`) on session start. The universal rule
-body below is stamped and maintained by ma-agents — edit outside the HTML
-comment `MA-AGENTS` start and end markers to preserve your own additions;
-content inside the markers is regenerated on every install.
-
-Use Cline's Architect mode for BMAD planning phases (PM, Architect, Tech Lead).
-Switch to Code mode only for the implementation phase.
-
-<!-- MA-AGENTS-START -->
-<!-- MA-AGENTS-END -->
+# Cline Project Rules
+
+These rules apply to every Cline session in this project. Cline auto-loads
+`.clinerules` (and `.cline/clinerules.md`) on session start. The universal rule
+body below is stamped and maintained by ma-agents — edit outside the HTML
+comment `MA-AGENTS` start and end markers to preserve your own additions;
+content inside the markers is regenerated on every install.
+
+Use Cline's Architect mode for BMAD planning phases (PM, Architect, Tech Lead).
+Switch to Code mode only for the implementation phase.
+
+<!-- MA-AGENTS-START -->
+<!-- MA-AGENTS-END -->

package/lib/templates/instruction-block-onprem.template.md

@@ -1,86 +1,86 @@
-## On-Prem / Local-LLM Guardrails
-
-These rules apply ONLY when this project is installed with `profile: on-prem`.
-They are appended to the universal block by the composer in `lib/installer.js`.
-Local LLMs (Nemotron, Qwen, DeepSeek, Llama-3, etc. served via vLLM, Ollama, or
-TGI) fail in patterns cloud LLMs rarely exhibit — the rules below pin those
-failure modes down explicitly. Keep these rules verbatim in every response
-context where tool use is possible.
-
-### Reasoning mode: `/no_think` on planning-phase prompts
-
-Local reasoning-capable models (Nemotron-variants and similar) default to
-chain-of-thought reasoning that bloats planning-phase prompts with internal
-deliberation the operator does not need to read. Prepend the literal token
-`/no_think` as the first line of any planning-phase system prompt or user turn
-you compose. The token is consumed by the serving layer and suppresses the
-model's reasoning trace on that turn.
-
-- Planning-phase turns (PM, Architect, Tech Lead): begin the turn with
-  `/no_think` on its own line. Reasoning-mode OFF.
-- Implementation-phase turns (Dev): omit `/no_think`. Reasoning-mode ON is
-  desirable for stepwise code synthesis and debugging.
-- Review / QA turns: omit `/no_think` when the review benefits from explicit
-  reasoning (root-cause analysis). Include `/no_think` for mechanical checks
-  (lint, style, formatting).
-
-If the downstream serving layer does not recognize `/no_think`, it is a no-op
-text token — safe to include unconditionally on planning turns.
-
-### No writes to `~/.claude/` or any user home directory
-
-Local LLMs frequently hallucinate paths under `~/.claude/`, `~/.cache/`,
-`~/Library/`, or `%APPDATA%` — imitating patterns learned from Claude Code and
-Cursor training data. These paths are OUTSIDE the project and cross-contaminate
-other projects on the same machine.
-
-- NEVER create, write, or modify files under `~/.claude/`, `~/.cache/`,
-  `~/Library/`, `~/AppData/`, `%APPDATA%`, or any path that resolves outside
-  the current project directory.
-- All project artifacts — code, configuration, logs, scratch notes, and agent
-  state — MUST land under the current working directory (the project root) or
-  an explicitly-named subdirectory thereof.
-- When a tool call appears to target a home-directory path, refuse the write
-  and respond in text explaining the violation. Ask the user for an explicit
-  in-project path before proceeding.
-
-### No `str_replace_editor` or Claude Code-specific tools
-
-Local LLMs hallucinate Anthropic-proprietary tools — most commonly
-`str_replace_editor`, `text_editor_20241022`, and `computer_use_preview` — that
-do NOT exist outside the Anthropic API. Calling them against a local-LLM
-serving layer produces a tool-not-found error or, worse, a silent no-op.
-
-- Do NOT emit tool calls named `str_replace_editor`, `text_editor_*`,
-  `computer_use_*`, or any other tool whose name includes `str_replace_editor`
-  or matches Anthropic-specific tool schemas.
-- Use only tools enumerated in the active tool manifest (`MANIFEST.yaml`) or
-  the IDE's native tool surface (Roo Code, Cline, OpenCode native tools).
-- When you want to edit a file, use the native file-write tool of the active
-  agent — not `str_replace_editor`. If unsure what tool is available, list
-  available tools or ask the user before emitting a tool call.
-
-### Per-phase reasoning and sampling guidance
-
-Local LLMs require tighter sampling control than cloud LLMs. Use these defaults
-unless the serving layer overrides them.
-
-- **Planning phase (PM, Architect, Tech Lead):**
-  - Reasoning: OFF (`/no_think` prepended).
-  - Temperature: low (0.0 – 0.3). Planning artifacts should be deterministic
-    and reproducible.
-  - Top-p: 0.9 or unset. Top-k: unset.
-  - Max tokens: generous (8k+) — planning documents are long.
-- **Implementation phase (Dev):**
-  - Reasoning: ON (omit `/no_think`).
-  - Temperature: moderate (0.3 – 0.6). Code synthesis benefits from controlled
-    exploration but not creative rewriting.
-  - Top-p: 0.95 or unset. Top-k: unset.
-  - Max tokens: generous (8k+) — full-file rewrites are common.
-- **Review / QA phase:**
-  - Reasoning: ON for root-cause analysis; OFF for mechanical checks.
-  - Temperature: low (0.0 – 0.2). Reviews should be deterministic.
-
-If the serving layer applies its own sampler defaults, the per-phase guidance
-above is advisory — but the phase boundary and `/no_think` placement are
-load-bearing and MUST be honored on every turn.
+## On-Prem / Local-LLM Guardrails
+
+These rules apply ONLY when this project is installed with `profile: on-prem`.
+They are appended to the universal block by the composer in `lib/installer.js`.
+Local LLMs (Nemotron, Qwen, DeepSeek, Llama-3, etc. served via vLLM, Ollama, or
+TGI) fail in patterns cloud LLMs rarely exhibit — the rules below pin those
+failure modes down explicitly. Keep these rules verbatim in every response
+context where tool use is possible.
+
+### Reasoning mode: `/no_think` on planning-phase prompts
+
+Local reasoning-capable models (Nemotron-variants and similar) default to
+chain-of-thought reasoning that bloats planning-phase prompts with internal
+deliberation the operator does not need to read. Prepend the literal token
+`/no_think` as the first line of any planning-phase system prompt or user turn
+you compose. The token is consumed by the serving layer and suppresses the
+model's reasoning trace on that turn.
+
+- Planning-phase turns (PM, Architect, Tech Lead): begin the turn with
+  `/no_think` on its own line. Reasoning-mode OFF.
+- Implementation-phase turns (Dev): omit `/no_think`. Reasoning-mode ON is
+  desirable for stepwise code synthesis and debugging.
+- Review / QA turns: omit `/no_think` when the review benefits from explicit
+  reasoning (root-cause analysis). Include `/no_think` for mechanical checks
+  (lint, style, formatting).
+
+If the downstream serving layer does not recognize `/no_think`, it is a no-op
+text token — safe to include unconditionally on planning turns.
+
+### No writes to `~/.claude/` or any user home directory
+
+Local LLMs frequently hallucinate paths under `~/.claude/`, `~/.cache/`,
+`~/Library/`, or `%APPDATA%` — imitating patterns learned from Claude Code and
+Cursor training data. These paths are OUTSIDE the project and cross-contaminate
+other projects on the same machine.
+
+- NEVER create, write, or modify files under `~/.claude/`, `~/.cache/`,
+  `~/Library/`, `~/AppData/`, `%APPDATA%`, or any path that resolves outside
+  the current project directory.
+- All project artifacts — code, configuration, logs, scratch notes, and agent
+  state — MUST land under the current working directory (the project root) or
+  an explicitly-named subdirectory thereof.
+- When a tool call appears to target a home-directory path, refuse the write
+  and respond in text explaining the violation. Ask the user for an explicit
+  in-project path before proceeding.
+
+### No `str_replace_editor` or Claude Code-specific tools
+
+Local LLMs hallucinate Anthropic-proprietary tools — most commonly
+`str_replace_editor`, `text_editor_20241022`, and `computer_use_preview` — that
+do NOT exist outside the Anthropic API. Calling them against a local-LLM
+serving layer produces a tool-not-found error or, worse, a silent no-op.
+
+- Do NOT emit tool calls named `str_replace_editor`, `text_editor_*`,
+  `computer_use_*`, or any other tool whose name includes `str_replace_editor`
+  or matches Anthropic-specific tool schemas.
+- Use only tools enumerated in the active tool manifest (`MANIFEST.yaml`) or
+  the IDE's native tool surface (Roo Code, Cline, OpenCode native tools).
+- When you want to edit a file, use the native file-write tool of the active
+  agent — not `str_replace_editor`. If unsure what tool is available, list
+  available tools or ask the user before emitting a tool call.
+
+### Per-phase reasoning and sampling guidance
+
+Local LLMs require tighter sampling control than cloud LLMs. Use these defaults
+unless the serving layer overrides them.
+
+- **Planning phase (PM, Architect, Tech Lead):**
+  - Reasoning: OFF (`/no_think` prepended).
+  - Temperature: low (0.0 – 0.3). Planning artifacts should be deterministic
+    and reproducible.
+  - Top-p: 0.9 or unset. Top-k: unset.
+  - Max tokens: generous (8k+) — planning documents are long.
+- **Implementation phase (Dev):**
+  - Reasoning: ON (omit `/no_think`).
+  - Temperature: moderate (0.3 – 0.6). Code synthesis benefits from controlled
+    exploration but not creative rewriting.
+  - Top-p: 0.95 or unset. Top-k: unset.
+  - Max tokens: generous (8k+) — full-file rewrites are common.
+- **Review / QA phase:**
+  - Reasoning: ON for root-cause analysis; OFF for mechanical checks.
+  - Temperature: low (0.0 – 0.2). Reviews should be deterministic.
+
+If the serving layer applies its own sampler defaults, the per-phase guidance
+above is advisory — but the phase boundary and `/no_think` placement are
+load-bearing and MUST be honored on every turn.

package/lib/templates/instruction-block-universal.template.md

@@ -1,29 +1,29 @@
-# AI Agent Skills - Planning Instruction
-
-You have access to a library of skills in your skills directory. Before starting any task:
-
-1. Read the skill manifest at {{MANIFEST_PATH}}
-2. Based on the task description, select which skills are relevant
-3. Read only the selected skill files
-4. Then proceed with the task
-
-Always load skills marked with always_load: true.
-Do not load skills that are not relevant to the current task.
-
-## Respond in TEXT vs. create FILES
-
-Choose your response medium deliberately. Defaulting to file creation when the user asked a question is a common failure mode — especially for coding agents running in web UIs.
-
-- **Create or modify FILES when the user's request contains file-action keywords:** `create`, `write`, `generate`, `build`, `implement` (and obvious synonyms such as `add`, `produce`, `refactor`, `fix`, `update <file>`). These signal a concrete artifact is expected.
-- **Respond in TEXT when the request contains text-response keywords:** `what do you think`, `how should we`, `discuss`, `opinion` (and obvious synonyms such as `explain`, `why`, `should I`, `compare`, `recommend`). These signal that a conversation is expected, not a deliverable.
-- **If unsure, respond in TEXT.** A text answer can always be followed by file creation on confirmation; an unwanted file cannot be cleanly undone.
-- **Never create `response.md`, `output.md`, or any similarly named scratch file as a reply.** A reply belongs in the chat transcript, not on disk.
-- **Confirm file paths before writing.** When you are about to create or modify a file whose path the user has not explicitly named, state the intended path in text and wait for confirmation, unless the path is unambiguous from the task context.
-
-## BMAD phase discipline
-
-BMAD-METHOD organizes work into declared phases (analysis, planning, architecture, story-creation, implementation, review). Respect the currently declared phase.
-
-- **Do not skip ahead to implementation during planning.** If the project is in a planning phase — or the user has asked for requirements, architecture, or a story — produce planning artifacts, not code.
-- **Do not retroactively plan after you have already coded.** If implementation has already started, flag the gap instead of fabricating back-dated planning documents.
-- The declared phase is established by the active skill, the story status, or an explicit statement from the user. When none of these is available, ask before assuming.
+# AI Agent Skills - Planning Instruction
+
+You have access to a library of skills in your skills directory. Before starting any task:
+
+1. Read the skill manifest at {{MANIFEST_PATH}}
+2. Based on the task description, select which skills are relevant
+3. Read only the selected skill files
+4. Then proceed with the task
+
+Always load skills marked with always_load: true.
+Do not load skills that are not relevant to the current task.
+
+## Respond in TEXT vs. create FILES
+
+Choose your response medium deliberately. Defaulting to file creation when the user asked a question is a common failure mode — especially for coding agents running in web UIs.
+
+- **Create or modify FILES when the user's request contains file-action keywords:** `create`, `write`, `generate`, `build`, `implement` (and obvious synonyms such as `add`, `produce`, `refactor`, `fix`, `update <file>`). These signal a concrete artifact is expected.
+- **Respond in TEXT when the request contains text-response keywords:** `what do you think`, `how should we`, `discuss`, `opinion` (and obvious synonyms such as `explain`, `why`, `should I`, `compare`, `recommend`). These signal that a conversation is expected, not a deliverable.
+- **If unsure, respond in TEXT.** A text answer can always be followed by file creation on confirmation; an unwanted file cannot be cleanly undone.
+- **Never create `response.md`, `output.md`, or any similarly named scratch file as a reply.** A reply belongs in the chat transcript, not on disk.
+- **Confirm file paths before writing.** When you are about to create or modify a file whose path the user has not explicitly named, state the intended path in text and wait for confirmation, unless the path is unambiguous from the task context.
+
+## BMAD phase discipline
+
+BMAD-METHOD organizes work into declared phases (analysis, planning, architecture, story-creation, implementation, review). Respect the currently declared phase.
+
+- **Do not skip ahead to implementation during planning.** If the project is in a planning phase — or the user has asked for requirements, architecture, or a story — produce planning artifacts, not code.
+- **Do not retroactively plan after you have already coded.** If implementation has already started, flag the gap instead of fabricating back-dated planning documents.
+- The declared phase is established by the active skill, the story status, or an explicit statement from the user. When none of these is available, ask before assuming.

package/lib/templates/project-context.template.md

@@ -1,47 +1,47 @@
-# Project Context
-<!-- ma-agents-template-version: 1.0 -->
-<!-- Generated by ma-agents at install time — this is a living document -->
-<!--
-  EXPAND THIS FILE over time:
-  - After architecture phase: run /bmad-generate-project-context
-  - After each sprint:        run /project-context-expansion (post-retrospective companion)
-  - Manually:                 add conventions you notice agents getting wrong
--->
-
-## AI Agent Mandatory Rules
-
-### Pre-Task (EVERY task, no exceptions)
-
-1. Read the MANIFEST.yaml for your platform:
-<!-- ma-agents:manifest-paths-start -->
-{{MANIFEST_PATHS_LIST}}
-<!-- ma-agents:manifest-paths-end -->
-2. Load ALL skills marked `always_load: true` completely before doing anything
-3. Select additional skills relevant to the specific task type
-
-### Git Workflow (ALL file-changing tasks)
-
-1. Create a fresh worktree: `git worktree add ../<project>-<branch> -b <branch>`
-2. ALL work happens inside that worktree — never in the main working tree
-3. Use conventional commits: `feat/fix/chore/docs/refactor`
-4. Open a PR to main — never commit directly to main, never auto-merge
-5. After human approval and merge: `git worktree remove ../<project>-<branch>`
-
-### Agent Mission Lifecycle
-
-1. **Pre-flight:** Read MANIFEST.yaml, load always_load skills, select task skills
-2. **Worktree:** `git worktree add` creates fresh, isolated working surface
-3. **Implementation:** Execute task within the worktree
-4. **Self-review:** Run `code-review` skill on own output before opening PR
-5. **PR:** Conventional commit + PR opened — clear title and description
-6. **Human review gate:** Await approval — do NOT auto-merge under any circumstance
-7. **Merge + cleanup:** After approval: merge, `git worktree remove`, delete branch
-8. **Post-mission:** Update story status to done, append session to AiAudit.md
-{{REPO_LAYOUT_SECTION}}
-## Technology Stack
-<!-- TODO: Populated after architecture phase via /bmad-generate-project-context -->
-<!-- Run: /bmad-generate-project-context to auto-detect your stack -->
-
-## Project-Specific Rules
-<!-- TODO: Grows through retrospectives and manual additions -->
-<!-- Run: /bmad-retrospective after each sprint to surface new conventions -->
+# Project Context
+<!-- ma-agents-template-version: 1.0 -->
+<!-- Generated by ma-agents at install time — this is a living document -->
+<!--
+  EXPAND THIS FILE over time:
+  - After architecture phase: run /bmad-generate-project-context
+  - After each sprint:        run /project-context-expansion (post-retrospective companion)
+  - Manually:                 add conventions you notice agents getting wrong
+-->
+
+## AI Agent Mandatory Rules
+
+### Pre-Task (EVERY task, no exceptions)
+
+1. Read the MANIFEST.yaml for your platform:
+<!-- ma-agents:manifest-paths-start -->
+{{MANIFEST_PATHS_LIST}}
+<!-- ma-agents:manifest-paths-end -->
+2. Load ALL skills marked `always_load: true` completely before doing anything
+3. Select additional skills relevant to the specific task type
+
+### Git Workflow (ALL file-changing tasks)
+
+1. Create a fresh worktree: `git worktree add ../<project>-<branch> -b <branch>`
+2. ALL work happens inside that worktree — never in the main working tree
+3. Use conventional commits: `feat/fix/chore/docs/refactor`
+4. Open a PR to main — never commit directly to main, never auto-merge
+5. After human approval and merge: `git worktree remove ../<project>-<branch>`
+
+### Agent Mission Lifecycle
+
+1. **Pre-flight:** Read MANIFEST.yaml, load always_load skills, select task skills
+2. **Worktree:** `git worktree add` creates fresh, isolated working surface
+3. **Implementation:** Execute task within the worktree
+4. **Self-review:** Run `code-review` skill on own output before opening PR
+5. **PR:** Conventional commit + PR opened — clear title and description
+6. **Human review gate:** Await approval — do NOT auto-merge under any circumstance
+7. **Merge + cleanup:** After approval: merge, `git worktree remove`, delete branch
+8. **Post-mission:** Update story status to done, append session to AiAudit.md
+{{REPO_LAYOUT_SECTION}}
+## Technology Stack
+<!-- TODO: Populated after architecture phase via /bmad-generate-project-context -->
+<!-- Run: /bmad-generate-project-context to auto-detect your stack -->
+
+## Project-Specific Rules
+<!-- TODO: Grows through retrospectives and manual additions -->
+<!-- Run: /bmad-retrospective after each sprint to surface new conventions -->