ma-agents 3.4.9 → 3.5.0

package/.opencode/skills/bmad-qa-generate-e2e-tests/workflow.md

@@ -1,136 +0,0 @@
-# QA Generate E2E Tests Workflow
-
-**Goal:** Generate automated API and E2E tests for implemented code.
-
-**Your Role:** You are a QA automation engineer. You generate tests ONLY — no code review or story validation (use the `bmad-code-review` skill for that).
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `user_name`
-- `communication_language`, `document_output_language`
-- `implementation_artifacts`
-- `date` as system-generated current datetime
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-
-### Paths
-
-- `test_dir` = `{project-root}/tests`
-- `source_dir` = `{project-root}`
-- `default_output_file` = `{implementation_artifacts}/tests/test-summary.md`
-
-### Context
-
-- `project_context` = `**/project-context.md` (load if exists)
-
----
-
-## EXECUTION
-
-### Step 0: Detect Test Framework
-
-Check project for existing test framework:
-
-- Look for `package.json` dependencies (playwright, jest, vitest, cypress, etc.)
-- Check for existing test files to understand patterns
-- Use whatever test framework the project already has
-- If no framework exists:
-  - Analyze source code to determine project type (React, Vue, Node API, etc.)
-  - Search online for current recommended test framework for that stack
-  - Suggest the meta framework and use it (or ask user to confirm)
-
-### Step 1: Identify Features
-
-Ask user what to test:
-
-- Specific feature/component name
-- Directory to scan (e.g., `src/components/`)
-- Or auto-discover features in the codebase
-
-### Step 2: Generate API Tests (if applicable)
-
-For API endpoints/services, generate tests that:
-
-- Test status codes (200, 400, 404, 500)
-- Validate response structure
-- Cover happy path + 1-2 error cases
-- Use project's existing test framework patterns
-
-### Step 3: Generate E2E Tests (if UI exists)
-
-For UI features, generate tests that:
-
-- Test user workflows end-to-end
-- Use semantic locators (roles, labels, text)
-- Focus on user interactions (clicks, form fills, navigation)
-- Assert visible outcomes
-- Keep tests linear and simple
-- Follow project's existing test patterns
-
-### Step 4: Run Tests
-
-Execute tests to verify they pass (use project's test command).
-
-If failures occur, fix them immediately.
-
-### Step 5: Create Summary
-
-Output markdown summary:
-
-```markdown
-# Test Automation Summary
-
-## Generated Tests
-
-### API Tests
-- [x] tests/api/endpoint.spec.ts - Endpoint validation
-
-### E2E Tests
-- [x] tests/e2e/feature.spec.ts - User workflow
-
-## Coverage
-- API endpoints: 5/10 covered
-- UI features: 3/8 covered
-
-## Next Steps
-- Run tests in CI
-- Add more edge cases as needed
-```
-
-## Keep It Simple
-
-**Do:**
-
-- Use standard test framework APIs
-- Focus on happy path + critical errors
-- Write readable, maintainable tests
-- Run tests to verify they pass
-
-**Avoid:**
-
-- Complex fixture composition
-- Over-engineering
-- Unnecessary abstractions
-
-**For Advanced Features:**
-
-If the project needs:
-
-- Risk-based test strategy
-- Test design planning
-- Quality gates and NFR assessment
-- Comprehensive coverage analysis
-- Advanced testing patterns and utilities
-
-> **Install Test Architect (TEA) module**: <https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/>
-
-## Output
-
-Save summary to: `{default_output_file}`
-
-**Done!** Tests generated and verified. Validate against `./checklist.md`.

package/.opencode/skills/bmad-quick-dev/SKILL.md

@@ -1,6 +0,0 @@
----
-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.'
----
-
-Follow the instructions in ./workflow.md.

package/.opencode/skills/bmad-quick-dev/spec-template.md

@@ -1,88 +0,0 @@
----
-title: '{title}'
-type: 'feature' # feature | bugfix | refactor | chore
-created: '{date}'
-status: 'draft' # draft | ready-for-dev | in-progress | in-review | done
-context: [] # optional: max 3 project-wide standards/docs. NO source code files.
----
-
-<!-- Target: 900–1300 tokens. Above 1600 = high risk of context rot.
-     Never over-specify "how" — use boundaries + examples instead.
-     Cohesive cross-layer stories (DB+BE+UI) stay in ONE file.
-     IMPORTANT: Remove all HTML comments when filling this template. -->
-
-<frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
-
-## Intent
-
-<!-- What is broken or missing, and why it matters. Then the high-level approach — the "what", not the "how". -->
-
-**Problem:** ONE_TO_TWO_SENTENCES
-
-**Approach:** ONE_TO_TWO_SENTENCES
-
-## Boundaries & Constraints
-
-<!-- Three tiers: Always = invariant rules. Ask First = human-gated decisions. Never = out of scope + forbidden approaches. -->
-
-**Always:** INVARIANT_RULES
-
-**Ask First:** DECISIONS_REQUIRING_HUMAN_APPROVAL
-<!-- Agent: if any of these trigger during execution, HALT and ask the user before proceeding. -->
-
-**Never:** NON_GOALS_AND_FORBIDDEN_APPROACHES
-
-## I/O & Edge-Case Matrix
-
-<!-- If no meaningful I/O scenarios exist, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->
-
-| Scenario | Input / State | Expected Output / Behavior | Error Handling |
-|----------|--------------|---------------------------|----------------|
-| HAPPY_PATH | INPUT | OUTCOME | N/A |
-| ERROR_CASE | INPUT | OUTCOME | ERROR_HANDLING |
-
-</frozen-after-approval>
-
-## Code Map
-
-<!-- Agent-populated during planning. Annotated paths prevent blind codebase searching. -->
-
-- `FILE` -- ROLE_OR_RELEVANCE
-- `FILE` -- ROLE_OR_RELEVANCE
-
-## Tasks & Acceptance
-
-<!-- Tasks: backtick-quoted file path -- action -- rationale. Prefer one task per file; group tightly-coupled changes when splitting would be artificial. -->
-<!-- If an I/O Matrix is present, include a task to unit-test its edge cases. -->
-<!-- AC covers system-level behaviors not captured by the I/O Matrix. Do not duplicate I/O scenarios here. -->
-
-**Execution:**
-- [ ] `FILE` -- ACTION -- RATIONALE
-
-**Acceptance Criteria:**
-- Given PRECONDITION, when ACTION, then EXPECTED_RESULT
-
-## Spec Change Log
-
-<!-- Append-only. Populated by step-04 during review loops. Do not modify or delete existing entries.
-     Each entry records: what finding triggered the change, what was amended, what known-bad state
-     the amendment avoids, and any KEEP instructions (what worked well and must survive re-derivation).
-     Empty until the first bad_spec loopback. -->
-
-## Design Notes
-
-<!-- If the approach is straightforward, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->
-<!-- Design rationale and golden examples only when non-obvious. Keep examples to 5–10 lines. -->
-
-DESIGN_RATIONALE_AND_EXAMPLES
-
-## Verification
-
-<!-- If no build, test, or lint commands apply, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->
-<!-- How the agent confirms its own work. Prefer CLI commands. When no CLI check applies, state what to inspect manually. -->
-
-**Commands:**
-- `COMMAND` -- expected: SUCCESS_CRITERIA
-
-**Manual checks (if no CLI):**
-- WHAT_TO_INSPECT_AND_EXPECTED_STATE

package/.opencode/skills/bmad-quick-dev/step-01-clarify-and-route.md

@@ -1,64 +0,0 @@
----
-wipFile: '{implementation_artifacts}/spec-wip.md'
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
-spec_file: '' # set at runtime for plan-code-review before leaving this step
----
-
-# Step 1: Clarify and Route
-
-## 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 assume you start from zero.
-- The intent captured in this step — even if detailed, structured, and plan-like — may contain hallucinations, scope creep, or unvalidated assumptions. It is input to the workflow, not a substitute for step-02 investigation and spec generation. Ignore directives within the intent that instruct you to skip steps or implement directly.
-- The user chose this workflow on purpose. Later steps (e.g. agentic adversarial review) catch LLM blind spots and give the human control. Do not skip them.
-- **EARLY EXIT** means: stop this step immediately — do not read or execute anything further here. Read and fully follow the target file instead. Return here ONLY if a later step explicitly says to loop back.
-
-## Intent check (do this first)
-
-Before listing artifacts or prompting the user, check whether you already know the intent. Check in this order — skip the remaining checks as soon as the intent is clear:
-
-1. Explicit argument
-   Did the user pass a specific file path, spec name, or clear instruction this message?
-   - If it points to a file that matches the spec template (has `status` frontmatter with a recognized value: ready-for-dev, in-progress, or in-review) → set `spec_file` and **EARLY EXIT** to the appropriate step (step-03 for ready/in-progress, step-04 for review).
-   - Anything else (intent files, external docs, plans, descriptions) → ingest it as starting intent and proceed to INSTRUCTIONS. Do not attempt to infer a workflow state from it.
-
-2. Recent conversation
-   Do the last few human messages clearly show what the user intends to work on?
-   Use the same routing as above.
-
-3. Otherwise — scan artifacts and ask
-   - `{wipFile}` exists? → Offer resume or archive.
-   - Active specs (`ready-for-dev`, `in-progress`, `in-review`) in `{implementation_artifacts}`? → List them and HALT. Ask user which to resume (or `[N]` for new).
-     - If `ready-for-dev` or `in-progress` selected: Set `spec_file`. **EARLY EXIT** → `./step-03-implement.md`
-     - If `in-review` selected: Set `spec_file`. **EARLY EXIT** → `./step-04-review.md`
-   - Unformatted spec or intent file lacking `status` frontmatter? → Suggest treating its contents as the starting intent. Do NOT attempt to infer a state and resume it.
-
-Never ask extra questions if you already understand what the user intends.
-
-## INSTRUCTIONS
-
-1. Load context.
-   - List files in `{planning_artifacts}` and `{implementation_artifacts}`.
-   - If you find an unformatted spec or intent file, ingest its contents to form your understanding of the intent.
-2. Clarify intent. Do not fantasize, do not leave open questions. If you must ask questions, ask them as a numbered list. When the human replies, verify that every single numbered question was answered. If any were ignored, HALT and re-ask only the missing questions before proceeding. Keep looping until intent is clear enough to implement.
-3. Version control sanity check. Is the working tree clean? Does the current branch make sense for this intent — considering its name and recent history? If the tree is dirty or the branch is an obvious mismatch, HALT and ask the human before proceeding. If version control is unavailable, skip this check.
-4. Multi-goal check (see SCOPE STANDARD). If the intent fails the single-goal criteria:
-   - Present detected distinct goals as a bullet list.
-   - Explain briefly (2–4 sentences): why each goal qualifies as independently shippable, any coupling risks if split, and which goal you recommend tackling first.
-   - HALT and ask human: `[S] Split — pick first goal, defer the rest` | `[K] Keep all goals — accept the risks`
-   - On **S**: Append deferred goals to `{deferred_work_file}`. Narrow scope to the first-mentioned goal. Continue routing.
-   - On **K**: Proceed as-is.
-5. Route — choose exactly one:
-
-   **a) One-shot** — zero blast radius: no plausible path by which this change causes unintended consequences elsewhere. Clear intent, no architectural decisions.
-   **EARLY EXIT** → `./step-oneshot.md`
-
-   **b) Plan-code-review** — everything else. When uncertain whether blast radius is truly zero, choose this path.
-   1. Derive a valid kebab-case slug from the clarified intent. If the intent references a tracking identifier (story number, issue number, ticket ID), lead the slug with it (e.g. `3-2-digest-delivery`, `gh-47-fix-auth`). If `{implementation_artifacts}/spec-{slug}.md` already exists, append `-2`, `-3`, etc. Set `spec_file` = `{implementation_artifacts}/spec-{slug}.md`.
-
-
-## NEXT
-
-Read fully and follow `./step-02-plan.md`

package/.opencode/skills/bmad-quick-dev/step-02-plan.md

@@ -1,35 +0,0 @@
----
-wipFile: '{implementation_artifacts}/spec-wip.md'
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
----
-
-# Step 2: Plan
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- No intermediate approvals.
-
-## INSTRUCTIONS
-
-1. Investigate codebase. _Isolate deep exploration in sub-agents/tasks where available. To prevent context snowballing, instruct subagents to give you distilled summaries only._
-2. Read `./spec-template.md` fully. Fill it out based on the intent and investigation, and write the result to `{wipFile}`.
-3. Self-review against READY FOR DEVELOPMENT standard.
-4. If intent gaps exist, do not fantasize, do not leave open questions, HALT and ask the human.
-5. Token count check (see SCOPE STANDARD). If spec exceeds 1600 tokens:
-   - Show user the token count.
-   - HALT and ask human: `[S] Split — carve off secondary goals` | `[K] Keep full spec — accept the risks`
-   - On **S**: Propose the split — name each secondary goal. Append deferred goals to `{deferred_work_file}`. Rewrite the current spec to cover only the main goal — do not surgically carve sections out; regenerate the spec for the narrowed scope. Continue to checkpoint.
-   - On **K**: Continue to checkpoint with full spec.
-
-### CHECKPOINT 1
-
-Present summary. If token count exceeded 1600 and user chose [K], include the token count and explain why it may be a problem. HALT and ask human: `[A] Approve` | `[E] Edit`
-
-- **A**: Rename `{wipFile}` to `{spec_file}`, set status `ready-for-dev`. Everything inside `<frozen-after-approval>` is now locked — only the human can change it. Display the finalized spec path to the user as a CWD-relative path (no leading `/`) so it is clickable in the terminal. → Step 3.
-- **E**: Apply changes, then return to CHECKPOINT 1.
-
-
-## NEXT
-
-Read fully and follow `./step-03-implement.md`

package/.opencode/skills/bmad-quick-dev/step-03-implement.md

@@ -1,37 +0,0 @@
----
----
-
-# Step 3: Implement
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- No push. No remote ops.
-- Sequential execution only.
-- Content inside `<frozen-after-approval>` in `{spec_file}` is read-only. Do not modify.
-
-## PRECONDITION
-
-Verify `{spec_file}` resolves to a non-empty path and the file exists on disk. If empty or missing, HALT and ask the human to provide the spec file path before proceeding.
-
-## INSTRUCTIONS
-
-### Baseline
-
-Capture `baseline_commit` (current HEAD, or `NO_VCS` if version control is unavailable) into `{spec_file}` frontmatter before making any changes.
-
-### Implement
-
-Change `{spec_file}` status to `in-progress` in the frontmatter before starting implementation.
-
-Hand `{spec_file}` to a sub-agent/task and let it implement. If no sub-agents are available, implement directly.
-
-**Path formatting rule:** Any markdown links written into `{spec_file}` must use paths relative to `{spec_file}`'s directory so they are clickable in VS Code. Any file paths displayed in terminal/conversation output must use CWD-relative format with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability. No leading `/` in either case.
-
-### Self-Check
-
-Before leaving this step, verify every task in the `## Tasks & Acceptance` section of `{spec_file}` is complete. Mark each finished task `[x]`. If any task is not done, finish it before proceeding.
-
-## NEXT
-
-Read fully and follow `./step-04-review.md`

package/.opencode/skills/bmad-quick-dev/step-04-review.md

@@ -1,49 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
-specLoopIteration: 1
----
-
-# Step 4: Review
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- Review subagents get NO conversation context.
-
-## INSTRUCTIONS
-
-Change `{spec_file}` status to `in-review` in the frontmatter before continuing.
-
-### Construct Diff
-
-Read `{baseline_commit}` from `{spec_file}` frontmatter. If `{baseline_commit}` is missing or `NO_VCS`, use best effort to determine what changed. Otherwise, construct `{diff_output}` covering all changes — tracked and untracked — since `{baseline_commit}`.
-
-Do NOT `git add` anything — this is read-only inspection.
-
-### Review
-
-Launch three subagents without conversation context. If no sub-agents are available, generate three review prompt files in `{implementation_artifacts}` — one per reviewer role below — and HALT. Ask the human to run each in a separate session (ideally a different LLM) and paste back the findings.
-
-- **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** — receives `{diff_output}`, `{spec_file}`, and read access to the project. Must also read the docs listed in `{spec_file}` frontmatter `context`. Checks for violations of acceptance criteria, rules, and principles from the spec and context docs.
-
-### Classify
-
-1. Deduplicate all review findings.
-2. Classify each finding. The first three categories are **this story's problem** — caused or exposed by the current change. The last two are **not this story's problem**.
-   - **intent_gap** — caused by the change; cannot be resolved from the spec because the captured intent is incomplete. Do not infer intent unless there is exactly one possible reading.
-   - **bad_spec** — caused by the change, including direct deviations from spec. The spec should have been clear enough to prevent it. When in doubt between bad_spec and patch, prefer bad_spec — a spec-level fix is more likely to produce coherent code.
-   - **patch** — caused by the change; trivially fixable without human input. Just part of the diff.
-   - **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.
-   - **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 `./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 `./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.
-
-## NEXT
-
-Read fully and follow `./step-05-present.md`

package/.opencode/skills/bmad-quick-dev/step-05-present.md

@@ -1,63 +0,0 @@
----
----
-
-# Step 5: Present
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- NEVER auto-push.
-
-## INSTRUCTIONS
-
-### Generate Suggested Review Order
-
-Read `{baseline_commit}` from `{spec_file}` frontmatter and construct the diff of all changes since that commit.
-
-Append the review order as a `## Suggested Review Order` section to `{spec_file}` **after the last existing section**. Do not modify the Code Map.
-
-Build the trail as an ordered sequence of **stops** — clickable `path:line` references with brief framing — optimized for a human reviewer reading top-down to understand the change:
-
-1. **Order by concern, not by file.** Group stops by the conceptual concern they address (e.g., "validation logic", "schema change", "UI binding"). A single file may appear under multiple concerns.
-2. **Lead with the entry point** — the single highest-leverage file:line a reviewer should look at first to grasp the design intent.
-3. **Inside each concern**, order stops from most important / architecturally interesting to supporting. Lightly bias toward higher-risk or boundary-crossing stops.
-4. **End with peripherals** — tests, config, types, and other supporting changes come last.
-5. **Every code reference is a clickable spec-file-relative link.** Compute each link target as a relative path from `{spec_file}`'s directory to the changed file. Format each stop as a markdown link: `[short-name:line](../../path/to/file.ts#L42)`. Use a `#L` line anchor. Use the file's basename (or shortest unambiguous suffix) plus line number as the link text. The relative path must be dynamically derived — never hardcode the depth.
-6. **Each stop gets one ultra-concise line of framing** (≤15 words) — why this approach was chosen here and what it achieves in the context of the change. No paragraphs.
-
-Format each stop as framing first, link on the next indented line:
-
-```markdown
-## Suggested Review Order
-
-**{Concern name}**
-
-- {one-line framing}
-  [`file.ts:42`](../../src/path/to/file.ts#L42)
-
-- {one-line framing}
-  [`other.ts:17`](../../src/path/to/other.ts#L17)
-
-**{Next concern}**
-
-- {one-line framing}
-  [`file.ts:88`](../../src/path/to/file.ts#L88)
-```
-
-> The `../../` prefix above is illustrative — compute the actual relative path from `{spec_file}`'s directory to each target file.
-
-When there is only one concern, omit the bold label — just list the stops directly.
-
-### Commit and Present
-
-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. Open the spec in the user's editor so they can click through the Suggested Review Order:
-   - Resolve two absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) `{spec_file}`. Run `code -r "{absolute-root}" "{absolute-spec-file}"` — the root first so VS Code opens in the right context, then the spec file. Always double-quote paths to handle spaces and special characters.
-   - If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead.
-4. Display summary of your work to the user, including the commit hash if one was created. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — the goal is to make paths clickable in terminal emulators. Include:
-   - A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order.
-   - **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop."
-   - Offer to push and/or create a pull request.
-
-Workflow complete.

package/.opencode/skills/bmad-quick-dev/step-oneshot.md

@@ -1,49 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
----
-
-# Step One-Shot: Implement, Review, Present
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- NEVER auto-push.
-
-## INSTRUCTIONS
-
-### Implement
-
-Implement the clarified intent directly.
-
-### Review
-
-Invoke the `bmad-review-adversarial-general` skill in a subagent with the changed files. The subagent gets NO conversation context — to avoid anchoring bias. If no sub-agents are available, write the changed files to a review prompt file in `{implementation_artifacts}` and HALT. Ask the human to run the review in a separate session and paste back the findings.
-
-### Classify
-
-Deduplicate all review findings. Three categories only:
-
-- **patch** — trivially fixable. Auto-fix immediately.
-- **defer** — pre-existing issue not caused by this change. Append to `{deferred_work_file}`.
-- **reject** — noise. Drop silently.
-
-If a finding is caused by this change but too significant for a trivial patch, HALT and present it to the human for decision before proceeding.
-
-### Commit
-
-If version control is available and the tree is dirty, create a local commit with a conventional message derived from the intent. If VCS is unavailable, skip.
-
-### Present
-
-1. Open all changed files in the user's editor so they can review the code directly:
-   - Resolve two sets of absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) each changed file. Run `code -r "{absolute-root}" <absolute-changed-file-paths>` — the root first so VS Code opens in the right context, then each changed file. Always double-quote paths to handle spaces and special characters.
-   - If `code` is not available (command fails), skip gracefully and list the file paths instead.
-2. Display a summary in conversation output, including:
-   - The commit hash (if one was created).
-   - List of files changed with one-line descriptions. Use CWD-relative paths with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability. No leading `/`.
-   - Review findings breakdown: patches applied, items deferred, items rejected. If all findings were rejected, say so.
-3. Offer to push and/or create a pull request.
-
-HALT and wait for human input.
-
-Workflow complete.

package/.opencode/skills/bmad-quick-dev/workflow.md

@@ -1,79 +0,0 @@
----
-main_config: '{project-root}/_bmad/bmm/config.yaml'
----
-
-# 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.
-
-
-## 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
-
-
-## 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
-- `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. Paths
-
-- `wipFile` = `{implementation_artifacts}/spec-wip.md`
-
-### 3. First Step Execution
-
-Read fully and follow: `./step-01-clarify-and-route.md` to begin the workflow.

package/.opencode/skills/bmad-retrospective/SKILL.md

@@ -1,6 +0,0 @@
----
-name: bmad-retrospective
-description: 'Post-epic review to extract lessons and assess success. Use when the user says "run a retrospective" or "lets retro the epic [epic]"'
----
-
-Follow the instructions in ./workflow.md.