Update project structure and configurations
This commit is contained in:
@@ -3,4 +3,88 @@ 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.
|
||||
# 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.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths (e.g. `checklist.md`) resolve from the skill root.
|
||||
- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
|
||||
- `{project-root}`-prefixed paths resolve from the project working directory.
|
||||
- `{skill-name}` resolves to the skill directory's basename.
|
||||
|
||||
## On Activation
|
||||
|
||||
### Step 1: Resolve the Workflow Block
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
|
||||
|
||||
**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
|
||||
|
||||
1. `{skill-root}/customize.toml` — defaults
|
||||
2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
|
||||
3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
|
||||
|
||||
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
|
||||
|
||||
### Step 2: Execute Prepend Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
|
||||
|
||||
### Step 3: Load Persistent Facts
|
||||
|
||||
Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
|
||||
|
||||
### Step 4: Load Config
|
||||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` 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}`
|
||||
|
||||
### Step 5: Greet the User
|
||||
|
||||
Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
### Step 6: Execute Append Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. Begin the workflow below.
|
||||
|
||||
## 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
|
||||
|
||||
## FIRST STEP
|
||||
|
||||
Read fully and follow: `./steps/step-01-gather-context.md`
|
||||
|
||||
41
.opencode/skills/bmad-code-review/customize.toml
Normal file
41
.opencode/skills/bmad-code-review/customize.toml
Normal file
@@ -0,0 +1,41 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-code-review. Mirrors the
|
||||
# agent customization shape under the [workflow] namespace.
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
|
||||
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Overrides append. Use for pre-flight loads, compliance checks, etc.
|
||||
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before the workflow begins.
|
||||
# Overrides append. Use for context-heavy setup that should happen
|
||||
# once the user has been acknowledged.
|
||||
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the workflow keeps in mind for the whole run
|
||||
# (standards, compliance constraints, stylistic guardrails).
|
||||
# Distinct from the runtime memory sidecar — these are static context
|
||||
# loaded on activation. Overrides append.
|
||||
#
|
||||
# Each entry is either:
|
||||
# - a literal sentence, e.g. "All stories must include testable acceptance criteria."
|
||||
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
|
||||
# (glob patterns are supported; the file's contents are loaded and treated as facts).
|
||||
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# Scalar: executed when the workflow reaches its final step,
|
||||
# after review findings are presented and sprint status is synced. Override wins.
|
||||
# Leave empty for no custom post-completion behavior.
|
||||
|
||||
on_complete = ""
|
||||
@@ -15,18 +15,37 @@ story_key: '' # set at runtime when discovered from sprint status
|
||||
|
||||
## 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.
|
||||
1. **Find the review target.** The conversation context before this skill was triggered IS your starting point — not a blank slate. Check in this order — stop as soon as the review target is identified:
|
||||
|
||||
**Tier 1 — Explicit argument.**
|
||||
Did the user pass a PR, commit SHA, branch, spec file, or diff source this message?
|
||||
- PR reference → resolve to branch/commit via `gh pr view`. If resolution fails, ask for a SHA or branch.
|
||||
- Commit or branch → use directly.
|
||||
- Spec file → set `{spec_file}` to the provided path. Check its frontmatter for `baseline_commit`. If found, use as diff baseline. If not found, continue the cascade (a spec alone does not identify a diff source).
|
||||
- Also scan the argument for diff-mode keywords that narrow the scope:
|
||||
- "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" / "<from-sha>..<to-sha>" → Specific commit range
|
||||
- "this diff" / "provided diff" / "paste" → User-provided diff (do not match bare "diff" — it appears in other modes)
|
||||
- When multiple keywords match, prefer the most specific (e.g., "branch diff" over bare "diff").
|
||||
|
||||
**Tier 2 — Recent conversation.**
|
||||
Do the last few messages reveal what the user wants to be reviewed? Look for spec paths, commit refs, branches, PRs, or descriptions of a change. Apply the same diff-mode keyword scan and routing as Tier 1.
|
||||
|
||||
**Tier 3 — Sprint tracking.**
|
||||
Look for a sprint status file (`*sprint-status*`) in `{implementation_artifacts}` or `{planning_artifacts}`. If found, scan for stories with status `review`:
|
||||
- **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.
|
||||
- **Multiple `review` stories:** Present them as numbered options alongside a manual choice option. Wait for user selection. If a story is selected, set `{story_key}` and use its context to determine the diff source. If manual choice is selected, clear `{story_key}` and fall through.
|
||||
- **None:** Fall through.
|
||||
|
||||
**Tier 4 — Current git state.**
|
||||
If version control is unavailable, skip to Tier 5. Otherwise, check the current branch and HEAD. If the branch is not `main` (or the default branch), confirm: "I see HEAD is `<short-sha>` on `<branch>` — do you want to review this branch's changes?" If confirmed, treat as a branch diff against `main`. If declined, fall through.
|
||||
|
||||
**Tier 5 — Ask.**
|
||||
Fall through to instruction 2.
|
||||
|
||||
Never ask extra questions beyond what the cascade prescribes. If a tier above already identified the target, skip the remaining tiers and proceed to instruction 3 (construct diff).
|
||||
|
||||
2. HALT. Ask the user: **What do you want to review?** Present these options:
|
||||
- **Uncommitted changes** (staged + unstaged)
|
||||
@@ -36,15 +55,19 @@ story_key: '' # set at runtime when discovered from sprint status
|
||||
- **Provided diff or file list** (user pastes or provides a path)
|
||||
|
||||
3. Construct `{diff_output}` from the chosen source.
|
||||
- For **staged changes only**: run `git diff --cached`.
|
||||
- For **uncommitted changes** (staged + unstaged): run `git diff HEAD`.
|
||||
- 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"`.
|
||||
4. **Set the spec context.**
|
||||
- If `{spec_file}` is already set (from Tier 1 or Tier 2): verify the file exists and is readable, then set `{review_mode}` = `"full"`.
|
||||
- Otherwise, 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.
|
||||
|
||||
|
||||
@@ -10,6 +10,7 @@ failed_layers: '' # set at runtime: comma-separated list of layers that failed o
|
||||
- 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.
|
||||
- All review subagents must run at the same model capability as the current session.
|
||||
|
||||
## INSTRUCTIONS
|
||||
|
||||
|
||||
@@ -46,35 +46,32 @@ If `decision_needed` findings exist, present each one with its detail and the op
|
||||
|
||||
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.
|
||||
**HALT** — I am waiting for your numbered choice. Reply with only the number. 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):
|
||||
If `{spec_file}` is set, present all three options:
|
||||
|
||||
> **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
|
||||
> **How would you like to handle the `<P>` `patch` findings?**
|
||||
> 1. **Apply every patch** — fix all of them now, no per-finding confirmation. Defer and decision-needed items are not touched.
|
||||
> 2. **Leave as action items** — they are already in the story file
|
||||
> 3. **Walk through each** — let me show details before deciding
|
||||
> 3. **Walk through each patch** — show details for each 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:
|
||||
If `{spec_file}` is **not** set, present only options 1 and 2 (omit "Leave as action items" — findings were not written to a file):
|
||||
|
||||
> **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
|
||||
> **How would you like to handle the `<P>` `patch` findings?**
|
||||
> 1. **Apply every patch** — fix all of them now, no per-finding confirmation. Defer and decision-needed items are not touched.
|
||||
> 2. **Walk through each patch** — show details for each 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.
|
||||
**HALT** — I am waiting for your numbered choice. Reply with only the number. 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.
|
||||
- **Apply every patch**: Apply every patch finding without per-finding confirmation. Do not modify defer or decision-needed items. After all patches are applied, present a summary of changes made. If `{spec_file}` is set, check off the patch items in the story file (leave defer items as-is).
|
||||
- **Leave as action items** (only when `{spec_file}` is set): Done — findings are already written to the story.
|
||||
- **Walk through each patch**: 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.
|
||||
**HALT** — I am waiting for your numbered choice. Do not proceed until you select an option.
|
||||
|
||||
**✅ Code review actions complete**
|
||||
|
||||
@@ -127,3 +124,9 @@ Present the user with follow-up options:
|
||||
> 3. **Done** — end the workflow
|
||||
|
||||
**HALT** — I am waiting for your choice. Do not proceed until the user selects an option.
|
||||
|
||||
## On Complete
|
||||
|
||||
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.
|
||||
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user