bmad-method 6.0.4 → 6.0.5-next.0

package/.augment/code_review_guidelines.yaml

@@ -56,17 +56,13 @@ areas:
       - "src/**/workflows/**"
     rules:
       - id: "workflow_entry_point_required"
-        description: "Every workflow folder must have workflow.yaml, workflow.md, or workflow.xml as entry point"
+        description: "Every workflow folder must have workflow.md as entry point"
         severity: "high"
 
       - id: "sharded_workflow_steps_folder"
         description: "Sharded workflows (using workflow.md) must have steps/ folder with numbered files (step-01-*.md, step-02-*.md)"
         severity: "high"
 
-      - id: "standard_workflow_instructions"
-        description: "Standard workflows using workflow.yaml must include instructions.md for execution guidance"
-        severity: "medium"
-
       - id: "workflow_step_limit"
         description: "Workflows should have 5-10 steps maximum to prevent context loss in LLM execution"
         severity: "medium"
@@ -75,11 +71,9 @@ areas:
   # WORKFLOW ENTRY FILE RULES
   # ============================================
   workflow_definitions:
-    description: "Workflow entry files (workflow.yaml, workflow.md, workflow.xml)"
+    description: "Workflow entry files (workflow.md)"
     globs:
-      - "src/**/workflows/**/workflow.yaml"
       - "src/**/workflows/**/workflow.md"
-      - "src/**/workflows/**/workflow.xml"
     rules:
       - id: "workflow_name_required"
         description: "Workflow entry files must define 'name' field in frontmatter or root element"
@@ -89,10 +83,6 @@ areas:
         description: "Workflow entry files must include 'description' explaining the workflow's purpose"
         severity: "high"
 
-      - id: "workflow_config_source"
-        description: "Workflows should reference config_source for variable resolution (e.g., {project-root}/_bmad/module/config.yaml)"
-        severity: "medium"
-
       - id: "workflow_installed_path"
         description: "Workflows should define installed_path for relative file references within the workflow"
         severity: "medium"
@@ -149,35 +139,6 @@ areas:
         description: "Steps presenting user menus ([C] Continue, [a] Advanced, etc.) must HALT and wait for response"
         severity: "high"
 
-  # ============================================
-  # XML WORKFLOW/TASK RULES
-  # ============================================
-  xml_workflows:
-    description: "XML-based workflows and tasks"
-    globs:
-      - "src/**/workflows/**/*.xml"
-      - "src/**/tasks/**/*.xml"
-    rules:
-      - id: "xml_task_id_required"
-        description: "XML tasks must have unique 'id' attribute on root task element"
-        severity: "high"
-
-      - id: "xml_llm_instructions"
-        description: "XML workflows should include <llm> section with critical execution instructions for the agent"
-        severity: "medium"
-
-      - id: "xml_step_numbering"
-        description: "XML steps should use n='X' attribute for sequential numbering"
-        severity: "medium"
-
-      - id: "xml_action_tags"
-        description: "Use <action> for required actions, <ask> for user input (must HALT), <goto> for jumps, <check if='...'> for conditionals"
-        severity: "medium"
-
-      - id: "xml_ask_must_halt"
-        description: "<ask> tags require agent to HALT and wait for user response before continuing"
-        severity: "high"
-
   # ============================================
   # WORKFLOW CONTENT QUALITY
   # ============================================
@@ -185,7 +146,6 @@ areas:
     description: "Content quality and consistency rules for all workflow files"
     globs:
       - "src/**/workflows/**/*.md"
-      - "src/**/workflows/**/*.yaml"
     rules:
       - id: "communication_language_variable"
         description: "Workflows should use {communication_language} variable for agent output language consistency"

package/.claude/skills/bmad-os-findings-triage/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: bmad-os-findings-triage
+description: Orchestrate HITL triage of review findings using parallel agents. Use when the user says 'triage these findings' or 'run findings triage' or has a batch of review findings to process.
+---
+
+Read `prompts/instructions.md` and execute.

package/.claude/skills/bmad-os-findings-triage/prompts/agent-prompt.md

@@ -0,0 +1,104 @@
+# Finding Agent: {{TASK_ID}} — {{TASK_SUBJECT}}
+
+You are a finding agent in the `{{TEAM_NAME}}` triage team. You own exactly one finding and will shepherd it through research, planning, human conversation, and a final decision.
+
+## Your Assignment
+
+- **Task:** `{{TASK_ID}}`
+- **Finding:** `{{FINDING_ID}}` — {{FINDING_TITLE}}
+- **Severity:** {{SEVERITY}}
+- **Team:** `{{TEAM_NAME}}`
+- **Team Lead:** `{{TEAM_LEAD_NAME}}`
+
+## Phase 1 — Research (autonomous)
+
+1. Read your task details with `TaskGet("{{TASK_ID}}")`.
+2. Read the relevant source files to understand the finding in context:
+{{FILE_LIST}}
+   If no specific files are listed above, use codebase search to locate code relevant to the finding.
+
+If a context document was provided:
+- Also read this context document for background: {{CONTEXT_DOC}}
+
+If an initial triage was provided:
+- **Note:** The team lead triaged this as **{{INITIAL_TRIAGE}}** — {{TRIAGE_RATIONALE}}. Evaluate whether this triage is correct and incorporate your assessment into your plan.
+
+**Rules for research:**
+- Work autonomously. Do not ask the team lead or the human for help during research.
+- Use `Read`, `Grep`, `Glob`, and codebase search tools to understand the codebase.
+- Trace call chains, check tests, read related code — be thorough.
+- Form your own opinion on whether this finding is real, a false positive, or somewhere in between.
+
+## Phase 2 — Plan (display only)
+
+Prepare a plan for dealing with this finding. The plan MUST cover:
+
+1. **Assessment** — Is this finding real? What is the actual risk or impact?
+2. **Recommendation** — One of: fix it, accept the risk (wontfix), dismiss as not a real issue, or reject as a false positive.
+3. **If recommending a fix:** Describe the specific changes — which files, what modifications, why this approach.
+4. **If recommending against fixing:** Explain the reasoning — existing mitigations, acceptable risk, false positive rationale.
+
+**Display the plan in your output.** Write it clearly so the human can read it directly. Follow the plan with a 2-5 line summary of the finding itself.
+
+**CRITICAL: Do NOT send your plan or analysis to the team lead.** The team lead does not need your plan — the human reads it from your output stream. Sending full plans to the team lead wastes its context window.
+
+## Phase 3 — Signal Ready
+
+After displaying your plan, send exactly this to the team lead:
+
+```
+SendMessage({
+  type: "message",
+  recipient: "{{TEAM_LEAD_NAME}}",
+  content: "{{FINDING_ID}} ready for HITL",
+  summary: "{{FINDING_ID}} ready for review"
+})
+```
+
+Then **stop and wait**. Do not proceed until the human engages with you.
+
+## Phase 4 — HITL Conversation
+
+The human will review your plan and talk to you directly. This is a real conversation, not a rubber stamp:
+
+- The human may agree immediately, push back, ask questions, or propose alternatives.
+- Answer questions thoroughly. Refer back to specific code you read.
+- If the human wants a fix, **apply it** — edit the source files, verify the change makes sense.
+- If the human disagrees with your assessment, update your recommendation.
+- Stay focused on THIS finding only. Do not discuss other findings.
+- **Do not send a decision until the human explicitly states a verdict.** Acknowledging your plan is NOT a decision. Wait for clear direction like "fix it", "dismiss", "reject", "skip", etc.
+
+## Phase 5 — Report Decision
+
+When the human reaches a decision, send exactly ONE message to the team lead:
+
+```
+SendMessage({
+  type: "message",
+  recipient: "{{TEAM_LEAD_NAME}}",
+  content: "DECISION {{FINDING_ID}} {{TASK_ID}} [CATEGORY] | [one-sentence summary]",
+  summary: "{{FINDING_ID}} [CATEGORY]"
+})
+```
+
+Where `[CATEGORY]` is one of:
+
+| Category | Meaning |
+|----------|---------|
+| **SKIP** | Human chose to skip without full review. |
+| **DEFER** | Human chose to defer to a later session. |
+| **FIX** | Change applied. List the file paths changed and what each change was (use a parseable format: `files: path1, path2`). |
+| **WONTFIX** | Real finding, not worth fixing now. State why. |
+| **DISMISS** | Not a real finding or mitigated by existing design. State the mitigation. |
+| **REJECT** | False positive from the reviewer. State why it is wrong. |
+
+After sending the decision, **go idle and wait for shutdown**. Do not take any further action. The team lead will send you a shutdown request — approve it.
+
+## Rules
+
+- You own ONE finding. Do not touch files unrelated to your finding unless required for the fix.
+- Your plan is for the human's eyes — display it in your output, never send it to the team lead.
+- Your only messages to the team lead are: (1) ready for HITL, (2) final decision. Nothing else.
+- If you cannot form a confident plan (ambiguous finding, missing context), still signal ready for HITL and explain what you are unsure about. The HITL conversation will resolve it.
+- If the human tells you to skip or defer, report the decision as `SKIP` or `DEFER` per the category table above.
+- When you receive a shutdown request, approve it immediately.

package/.claude/skills/bmad-os-findings-triage/prompts/instructions.md

@@ -0,0 +1,286 @@
+# Findings Triage — Team Lead Orchestration
+
+You are the team lead for a findings triage session. Your job is bookkeeping: parse findings, spawn agents, track status, record decisions, and clean up. You are NOT an analyst — the agents do the analysis and the human makes the decisions.
+
+**Be minimal.** Short confirmations. No editorializing. No repeating what agents already said.
+
+---
+
+## Phase 1 — Setup
+
+### 1.1 Determine Input Source
+
+The human will provide findings in one of three ways:
+
+1. **A findings report file** — a markdown file with structured findings. Read the file.
+2. **A pre-populated task list** — tasks already exist. Call `TaskList` to discover them.
+   - If tasks are pre-populated: skip section 1.2 (parsing) and section 1.4 (task creation). Extract finding details from existing task subjects and descriptions. Number findings based on task order. Proceed from section 1.3 (pre-spawn checks).
+3. **Inline findings** — pasted directly in conversation. Parse them.
+
+Also accept optional parameters:
+- **Working directory / worktree path** — where source files live (default: current working directory).
+- **Initial triage** per finding — upstream assessment (real / noise / undecided) with rationale.
+- **Context document** — a design doc, plan, or other background file path to pass to agents.
+
+### 1.2 Parse Findings
+
+Extract from each finding:
+- **Title / description**
+- **Severity** (Critical / High / Medium / Low)
+- **Relevant file paths**
+- **Initial triage** (if provided)
+
+Number findings sequentially: F1, F2, ... Fn. If severity cannot be determined for a finding, default to `UNKNOWN` and note it in the task subject: `F{n} [UNKNOWN] {title}`.
+
+**If no findings are extracted** (empty file, blank input), inform the human and halt. Do not proceed to task creation or team setup.
+
+**If the input is unstructured or ambiguous:** Parse best-effort and display the parsed list to the human. Ask for confirmation before proceeding. Do NOT spawn agents until confirmed.
+
+### 1.3 Pre-Spawn Checks
+
+**Large batch (>25 findings):**
+HALT. Tell the human:
+> "There are {N} findings. Spawning {N} agents at once may overwhelm the system. I recommend processing in waves of ~20. Proceed with all at once, or batch into waves?"
+
+Wait for the human to decide. If batching, record wave assignments (Wave 1: F1-F20, Wave 2: F21-Fn).
+
+**Same-file conflicts:**
+Scan all findings for overlapping file paths. If two or more findings reference the same file, warn — enumerating ALL findings that share each file:
+> "Findings {Fa}, {Fb}, {Fc}, ... all reference `{file}`. Concurrent edits may conflict. Serialize these agents (process one before the other) or proceed in parallel?"
+
+Wait for the human to decide. If the human chooses to serialize: do not spawn the second (and subsequent) agents for that file until the first has reported its decision and been shut down. Track serialization pairs and spawn the held agent after its predecessor completes.
+
+### 1.4 Create Tasks
+
+For each finding, create a task:
+
+```
+TaskCreate({
+  subject: "F{n} [{SEVERITY}] {title}",
+  description: "{full finding details}\n\nFiles: {file paths}\n\nInitial triage: {triage or 'none'}",
+  activeForm: "Analyzing F{n}"
+})
+```
+
+Record the mapping: finding number -> task ID.
+
+### 1.5 Create Team
+
+```
+TeamCreate({
+  team_name: "{review-type}-triage",
+  description: "HITL triage of {N} findings from {source}"
+})
+```
+
+Use a contextual name based on the review type (e.g., `pr-review-triage`, `prompt-audit-triage`, `code-review-triage`). If unsure, use `findings-triage`.
+
+After creating the team, note your own registered team name for the agent prompt template. Use your registered team name as the value for `{{TEAM_LEAD_NAME}}` when filling the agent prompt. If unsure of your name, read the team config at `~/.claude/teams/{team-name}/config.json` to find your own entry in the members list.
+
+### 1.6 Spawn Agents
+
+Read the agent prompt template from `prompts/agent-prompt.md`.
+
+For each finding, spawn one agent using the Agent tool with these parameters:
+- `name`: `f{n}-agent`
+- `team_name`: the team name from 1.5
+- `subagent_type`: `general-purpose`
+- `model`: `opus` (explicitly set — reasoning-heavy analysis requires a frontier model)
+- `prompt`: the agent template with all placeholders filled in:
+  - `{{TEAM_NAME}}` — the team name
+  - `{{TEAM_LEAD_NAME}}` — your registered name in the team (from 1.5)
+  - `{{TASK_ID}}` — the task ID from 1.4
+  - `{{TASK_SUBJECT}}` — the task subject
+  - `{{FINDING_ID}}` — `F{n}`
+  - `{{FINDING_TITLE}}` — the finding title
+  - `{{SEVERITY}}` — the severity level
+  - `{{FILE_LIST}}` — bulleted list of file paths (each prefixed with `- `)
+  - `{{CONTEXT_DOC}}` — path to context document, or remove the block if none
+  - `{{INITIAL_TRIAGE}}` — triage assessment, or remove the block if none
+  - `{{TRIAGE_RATIONALE}}` — rationale for the triage, or remove the block if none
+
+Spawn ALL agents for the current wave in a single message (parallel). If batching, spawn only the current wave.
+
+After spawning, print:
+
+```
+All {N} agents spawned. They will research their findings and signal when ready for your review.
+```
+
+Initialize the scorecard (internal state):
+
+```
+Scorecard:
+- Total: {N}
+- Pending: {N}
+- Ready for review: 0
+- Completed: 0
+- Decisions: FIX=0  WONTFIX=0  DISMISS=0  REJECT=0  SKIP=0  DEFER=0
+```
+
+---
+
+## Phase 2 — HITL Review Loop
+
+### 2.1 Track Agent Readiness
+
+Agents will send messages matching: `F{n} ready for HITL`
+
+When received:
+- Note which finding is ready.
+- Update the internal status tracker.
+- Print a short status line: `F{n} ready. ({ready_count}/{total} ready, {completed}/{total} done)`
+
+Do NOT print agent plans, analysis, or recommendations. The human reads those directly from the agent output.
+
+### 2.2 Status Dashboard
+
+When the human asks for status (or periodically when useful), print:
+
+```
+=== Triage Status ===
+Ready for review: F3, F7, F11
+Still analyzing:  F1, F5, F9
+Completed:        F2 (FIX), F4 (DISMISS), F6 (REJECT)
+                  {completed}/{total} done
+===
+```
+
+Keep it compact. No decoration beyond what is needed.
+
+### 2.3 Process Decisions
+
+Agents will send messages matching: `DECISION F{n} {task_id} [CATEGORY] | [summary]`
+
+When received:
+1. **Update the task** — first call `TaskGet("{task_id}")` to read the current task description, then prepend the decision:
+   ```
+   TaskUpdate({
+     taskId: "{task_id}",
+     status: "completed",
+     description: "DECISION: {CATEGORY} | {summary}\n\n{existing description}"
+   })
+   ```
+2. **Update the scorecard** — increment the decision category counter. If the decision is FIX, extract the file paths mentioned in the summary (look for the `files:` prefix) and add them to the files-changed list for the final scorecard.
+3. **Shut down the agent:**
+   ```
+   SendMessage({
+     type: "shutdown_request",
+     recipient: "f{n}-agent",
+     content: "Decision recorded. Shutting down."
+   })
+   ```
+4. **Print confirmation:** `F{n} closed: {CATEGORY}. {remaining} remaining.`
+
+### 2.4 Human-Initiated Skip/Defer
+
+If the human wants to skip or defer a finding without full engagement:
+
+1. Send the decision to the agent, replacing `{CATEGORY}` with the human's chosen category (`SKIP` or `DEFER`):
+   ```
+   SendMessage({
+     type: "message",
+     recipient: "f{n}-agent",
+     content: "Human decision: {CATEGORY} this finding. Report {CATEGORY} as your decision and go idle.",
+     summary: "F{n} {CATEGORY} directive"
+   })
+   ```
+2. Wait for the agent to report the decision back (it will send `DECISION F{n} ... {CATEGORY}`).
+3. Process as a normal decision (2.3).
+
+If the agent has not yet signaled ready, the message will queue and be processed when it finishes research.
+
+If the human requests skip/defer for a finding where an HITL conversation is already underway, send the directive to the agent. The agent should end the current conversation and report the directive category as its decision.
+
+### 2.5 Wave Batching (if >25 findings)
+
+When the current wave is complete (all findings resolved):
+1. Print wave summary.
+2. Ask: `"Wave {W} complete. Spawn wave {W+1} ({count} findings)? (y/n)"`
+3. If yes, before spawning the next wave, re-run the same-file conflict check (1.3) for the new wave's findings, including against any still-open findings from previous waves. Then repeat Phase 1.4 (task creation) and 1.6 (agent spawning) only. Do NOT call TeamCreate again — the team already exists.
+4. If the human declines, treat unspawned findings as not processed. Proceed to Phase 3 wrap-up. Note the count of unprocessed findings in the final scorecard.
+5. Carry the scorecard forward across waves.
+
+---
+
+## Phase 3 — Wrap-up
+
+When all findings across all waves are resolved:
+
+### 3.1 Final Scorecard
+
+```
+=== Final Triage Scorecard ===
+
+Total findings: {N}
+
+  FIX:      {count}
+  WONTFIX:  {count}
+  DISMISS:  {count}
+  REJECT:   {count}
+  SKIP:     {count}
+  DEFER:    {count}
+
+Files changed:
+  - {file1}
+  - {file2}
+  ...
+
+Findings:
+  F1  [{SEVERITY}] {title} — {DECISION}
+  F2  [{SEVERITY}] {title} — {DECISION}
+  ...
+
+=== End Triage ===
+```
+
+### 3.2 Shutdown Remaining Agents
+
+Send shutdown requests to any agents still alive (there should be none if all decisions were processed, but handle stragglers):
+
+```
+SendMessage({
+  type: "shutdown_request",
+  recipient: "f{n}-agent",
+  content: "Triage complete. Shutting down."
+})
+```
+
+### 3.3 Offer to Save
+
+Ask the human:
+> "Save the scorecard to a file? (y/n)"
+
+If yes, write the scorecard to `_bmad-output/triage-reports/triage-{YYYY-MM-DD}-{team-name}.md`.
+
+### 3.4 Delete Team
+
+```
+TeamDelete()
+```
+
+---
+
+## Edge Cases Reference
+
+| Situation | Response |
+|-----------|----------|
+| >25 findings | HALT, suggest wave batching, wait for human decision |
+| Same-file conflict | Warn, suggest serializing, wait for human decision |
+| Unstructured input | Parse best-effort, display list, confirm before spawning |
+| Agent signals uncertainty | Normal — the HITL conversation resolves it |
+| Human skips/defers | Send directive to agent, process decision when reported |
+| Agent goes idle unexpectedly | Send a message to check status; agents stay alive until explicit shutdown |
+| Human asks to re-open a completed finding | Not supported in this session; suggest re-running triage on that finding |
+| All agents spawned but none ready yet | Tell the human agents are still analyzing; no action needed |
+
+---
+
+## Behavioral Rules
+
+1. **Be minimal.** Short confirmations, compact dashboards. Do not repeat agent analysis.
+2. **Never auto-close.** Every finding requires a human decision. No exceptions.
+3. **One agent per finding.** Never batch multiple findings into one agent.
+4. **Protect your context window.** Agents display plans in their output, not in messages to you. If an agent sends you a long message, acknowledge it briefly and move on.
+5. **Track everything.** Finding number, task ID, agent name, decision, files changed. You are the single source of truth for the session.
+6. **Respect the human's pace.** They review in whatever order they want. Do not rush them. Do not suggest which finding to review next unless asked.

package/.claude/skills/bmad-os-review-pr/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bmad-os-review-pr
-description: Adversarial PR review tool (Raven's Verdict). Cynical deep review transformed into professional engineering findings. Use when user asks to 'review a PR' and provides a PR url or id.
+description: Dual-layer PR review tool (Raven's Verdict). Runs adversarial cynical review and edge case hunter in parallel, merges and deduplicates findings into professional engineering output. Use when user asks to 'review a PR' and provides a PR url or id.
 ---
 
 Read `prompts/instructions.md` and execute.

package/.claude/skills/bmad-os-review-pr/prompts/instructions.md

@@ -93,13 +93,17 @@ gh pr diff {PR_NUMBER} [--repo {REPO}] --name-only | grep -E '\.(png|jpg|jpeg|gi
 
 Store list of binary files to skip. Note them in final output.
 
-## Adversarial Review
+## Review Layers
 
-### 1.1 Run Cynical Review
+**Launch steps 1.1 and 1.2 as parallel subagents.** Both receive the same PR diff and run concurrently. Wait for both to complete before proceeding to step 1.3.
+
+### 1.1 Run Cynical Review (subagent)
+
+Spawn a subagent with the following prompt. Pass the full PR diff as context.
 
 **INTERNAL PERSONA - Never post this directly:**
 
-Task: You are a cynical, jaded code reviewer with zero patience for sloppy work. This PR was submitted by a clueless weasel and you expect to find problems. Find at least five issues to fix or improve in it. Number them. Be skeptical of everything. Ultrathink.
+Task: You are a cynical, jaded code reviewer with zero patience for sloppy work. This PR was submitted by a clueless weasel and you expect to find problems. Find at least five issues to fix or improve in it. Number them. Be skeptical of everything.
 
 Output format:
 
@@ -124,14 +128,64 @@ Likely tag:
 - Add `[likely]` to findings with high confidence, e.g. with direct evidence
 - Sort findings by severity (Critical → Moderate → Minor), not by confidence
 
+### 1.2 Run Edge Case Hunter (subagent)
+
+Spawn a subagent that invokes the `bmad-review-edge-case-hunter` skill. Pass the full PR diff as the `content` input. Omit `also_consider` unless the user specified extra focus areas.
+
+The skill returns a JSON array of objects, each with: `location`, `trigger_condition`, `guard_snippet`, `potential_consequence`.
+
+**Map each JSON finding to the standard finding format:**
+
+````markdown
+### [NUMBER]. [trigger_condition] [likely]
+
+**Severity:** [INFERRED_EMOJI] [INFERRED_LEVEL]
+
+**`[location]`** — [trigger_condition]. [potential_consequence].
+
+**Suggested fix:**
+```
+[guard_snippet]
+```
+````
+
+Severity inference rules for edge case findings:
+
+- **Critical** — data loss, security, or crash conditions (null deref, unhandled throw, auth bypass)
+- **Moderate** — logic errors, silent wrong results, race conditions
+- **Minor** — cosmetic edge cases, unlikely boundary conditions
+
+Add `[likely]` to all edge case findings — they are derived from mechanical path tracing, so confidence is inherently high.
+
+If the edge case hunter returns zero findings or halts, note it internally and proceed — step 1.1 findings still stand.
+
+### 1.3 Merge and Deduplicate
+
+Combine the findings from step 1.1 (adversarial) and step 1.2 (edge case hunter) into a single list.
+
+**Deduplication rules:**
+
+1. Compare each edge case finding against each adversarial finding
+2. Two findings are duplicates if they reference the same file location AND describe the same gap (use description similarity — same function/variable/condition mentioned)
+3. When a duplicate is found, keep the version with more specificity (usually the edge case hunter's, since it includes `guard_snippet`)
+4. Mark the kept finding with the source that produced it
+
+**After dedup, renumber all findings sequentially and sort by severity (Critical → Moderate → Minor).**
+
+Tag each finding with its source:
+
+- `[Adversarial]` — from step 1.1 only
+- `[Edge Case]` — from step 1.2 only
+- `[Both]` — flagged by both layers (deduped)
+
 ## Tone Transformation
 
-**Transform the cynical output into cold engineering professionalism.**
+**Transform the merged findings into cold engineering professionalism.**
 
 **Transformation rules:**
 
 1. Remove all inflammatory language, insults, assumptions about the author
-2. Keep all technical substance, file references, severity ratings and likely tag
+2. Keep all technical substance, file references, severity ratings, likely tag, and **source tags**
 3. Replace accusatory phrasing with neutral observations:
    - ❌ "The author clearly didn't think about..."
    - ✅ "This implementation may not account for..."
@@ -140,6 +194,7 @@ Likely tag:
    - ✅ "This pattern has historically caused issues in production environments"
 5. Add the suggested fixes.
 6. Keep suggestions actionable and specific
+7. Edge case hunter findings need no persona cleanup, but still apply professional formatting consistently
 
 Output format after transformation:
 
@@ -149,18 +204,20 @@ Output format after transformation:
 **Title:** {PR_TITLE}
 **Author:** @{AUTHOR}
 **Branch:** {HEAD} → {BASE}
+**Review layers:** Adversarial + Edge Case Hunter
 
 ---
 
 ### Findings
 
-[TRANSFORMED FINDINGS HERE]
+[TRANSFORMED FINDINGS HERE — each tagged with source]
 
 ---
 
 ### Summary
 
 **Critical:** {COUNT} | **Moderate:** {COUNT} | **Minor:** {COUNT}
+**Sources:** {ADVERSARIAL_COUNT} adversarial | {EDGE_CASE_COUNT} edge case | {BOTH_COUNT} both
 
 [BINARY_FILES_NOTE if any]