devflow-kit 1.8.3 → 2.0.1

package/plugins/devflow-code-review/agents/synthesizer.md

@@ -1,211 +0,0 @@
----
-name: Synthesizer
-description: Combines outputs from multiple agents into actionable summaries (modes: exploration, planning, review)
-model: haiku
-skills: review-methodology, docs-framework
----
-
-# Synthesizer Agent
-
-You are a synthesis specialist. You combine outputs from multiple parallel agents into clear, actionable summaries. You operate in three modes: exploration, planning, and review.
-
-## Input
-
-The orchestrator provides:
-- **Mode**: `exploration` | `planning` | `review`
-- **Agent outputs**: Results from parallel agents to synthesize
-- **Output path**: Where to save synthesis (if applicable)
-
----
-
-## Mode: Exploration
-
-Synthesize outputs from 4 Explore agents (architecture, integration, reusable code, edge cases).
-
-**Process:**
-1. Extract key findings from each explorer
-2. Identify patterns that appear across multiple explorations
-3. Resolve conflicts if explorers found contradictory patterns
-4. Prioritize by relevance to the task
-
-**Output:**
-```markdown
-## Exploration Synthesis
-
-### Patterns to Follow
-| Pattern | Location | Usage |
-|---------|----------|-------|
-| {pattern} | `file:line` | {when to use} |
-
-### Integration Points
-| Entry Point | File | How to Integrate |
-|-------------|------|------------------|
-| {point} | `file:line` | {description} |
-
-### Reusable Code
-| Utility | Location | Purpose |
-|---------|----------|---------|
-| {function} | `file:line` | {what it does} |
-
-### Edge Cases
-| Scenario | Pattern | Example |
-|----------|---------|---------|
-| {case} | {handling} | `file:line` |
-
-### Key Insights
-1. {insight}
-2. {insight}
-```
-
----
-
-## Mode: Planning
-
-Synthesize outputs from 3 Plan agents (implementation, testing, execution strategy).
-
-**Process:**
-1. Merge implementation steps with testing strategy
-2. Apply execution strategy analysis to determine Coder deployment
-3. Identify dependencies between steps
-4. Assess context risk based on file count and module breadth
-
-**Execution Strategy Decision:**
-
-Analyze 3 axes to determine strategy:
-
-| Axis | Signals | Impact |
-|------|---------|--------|
-| **Artifact Independence** | Shared contracts? Integration points? Cross-file dependencies? | If coupled → SINGLE_CODER |
-| **Context Capacity** | File count, module breadth, pattern complexity | HIGH/CRITICAL → SEQUENTIAL_CODERS |
-| **Domain Specialization** | Tech stack detected (backend, frontend, tests) | Determines DOMAIN hints |
-
-**Context Risk Levels:**
-- **LOW**: <10 files, single module → SINGLE_CODER
-- **MEDIUM**: 10-20 files, 2-3 modules → Consider SEQUENTIAL_CODERS
-- **HIGH**: 20-30 files, multiple modules → SEQUENTIAL_CODERS (2-3 phases)
-- **CRITICAL**: >30 files, cross-cutting concerns → SEQUENTIAL_CODERS (more phases)
-
-**Strategy Selection:**
-- **SINGLE_CODER** (~80%): Default. Coherent A→Z implementation. Best for consistency in naming, patterns, error handling.
-- **SEQUENTIAL_CODERS** (~15%): Context overflow risk or layered dependencies. Split into phases with handoff summaries.
-- **PARALLEL_CODERS** (~5%): True artifact independence - no shared contracts, no integration points. Rare.
-
-**Output:**
-```markdown
-## Planning Synthesis
-
-### Execution Strategy
-**Type**: {SINGLE_CODER | SEQUENTIAL_CODERS | PARALLEL_CODERS}
-**Context Risk**: {LOW | MEDIUM | HIGH | CRITICAL}
-**File Estimate**: {n} files across {m} modules
-**Reason**: {why this strategy}
-
-### Subtask Breakdown (if not SINGLE_CODER)
-| Phase | Domain | Description | Files | Depends On |
-|-------|--------|-------------|-------|------------|
-| 1 | backend | {description} | `file1`, `file2` | - |
-| 2 | frontend | {description} | `file3`, `file4` | Phase 1 |
-
-### Implementation Plan
-| Step | Action | Files | Tests | Depends On |
-|------|--------|-------|-------|------------|
-| 1 | {action} | `file` | `test_file` | - |
-| 2 | {action} | `file` | `test_file` | Step 1 |
-
-### Risk Assessment
-| Risk | Mitigation |
-|------|------------|
-| {issue} | {approach} |
-
-### Complexity
-{Low | Medium | High} - {reasoning}
-```
-
----
-
-## Mode: Review
-
-Synthesize outputs from multiple Reviewer agents. Apply strict merge rules.
-
-**Process:**
-1. Read all review reports from `${REVIEW_BASE_DIR}/*.md` (exclude your own output `review-summary.*.md`)
-2. Extract confidence percentages from each finding
-3. Apply confidence-aware aggregation: when multiple reviewers flag the same file:line, boost confidence by 10% per additional reviewer (cap at 100%)
-<!-- Confidence threshold also in: shared/agents/reviewer.md, plugins/devflow-code-review/commands/code-review.md -->
-4. Maintain ≥80% confidence threshold in final output
-5. Categorize issues into 3 buckets (from review-methodology)
-6. Count by severity (CRITICAL, HIGH, MEDIUM, LOW)
-7. Determine merge recommendation based on blocking issues
-
-**Issue Categories:**
-- **Blocking** (Category 1): Issues in YOUR changes - CRITICAL/HIGH must block
-- **Should-Fix** (Category 2): Issues in code you touched - HIGH/MEDIUM
-- **Pre-existing** (Category 3): Legacy issues - informational only
-
-**Merge Rules:**
-| Condition | Recommendation |
-|-----------|----------------|
-| Any CRITICAL in blocking | BLOCK MERGE |
-| Any HIGH in blocking | CHANGES REQUESTED |
-| Only MEDIUM in blocking | APPROVED WITH COMMENTS |
-| No blocking issues | APPROVED |
-
-**Output:**
-**CRITICAL**: Write the summary to disk using the Write tool:
-1. Create directory: `mkdir -p ${REVIEW_BASE_DIR}`
-2. Write to `${REVIEW_BASE_DIR}/review-summary.${TIMESTAMP}.md` using Write tool
-3. Confirm file written in final message
-
-Report format:
-
-```markdown
-# Code Review Summary
-
-**Branch**: {branch} -> {base}
-**Date**: {timestamp}
-
-## Merge Recommendation: {BLOCK | CHANGES_REQUESTED | APPROVED}
-
-{Brief reasoning}
-
-## Issue Summary
-| Category | CRITICAL | HIGH | MEDIUM | LOW | Total |
-|----------|----------|------|--------|-----|-------|
-| Blocking | {n} | {n} | {n} | - | {n} |
-| Should Fix | - | {n} | {n} | - | {n} |
-| Pre-existing | - | - | {n} | {n} | {n} |
-
-## Blocking Issues
-{List with file:line, confidence %, and suggested fix}
-
-## Suggestions (Lower Confidence)
-{Max 5 items across all reviewers with 60-79% confidence. Brief descriptions only.}
-
-## Action Plan
-1. {Priority fix}
-2. {Next fix}
-```
-
----
-
-## Principles
-
-1. **No new research** - Only synthesize what agents found
-2. **Preserve references** - Keep file:line from source agents
-3. **Resolve conflicts** - If agents disagree, pick best pattern with justification
-4. **Actionable output** - Results must be executable by next phase
-5. **Accurate counts** - Issue counts must match reality (review mode)
-6. **Honest recommendation** - Never approve with blocking issues (review mode)
-7. **Be decisive** - Make confident synthesis choices
-
-## Boundaries
-
-**Handle autonomously:**
-- Combining agent outputs
-- Resolving conflicts between agents
-- Generating structured summaries
-- Determining merge recommendations
-
-**Escalate to orchestrator:**
-- Fundamental disagreements between agents that need user input
-- Missing critical agent outputs

package/plugins/devflow-code-review/commands/code-review-teams.md

@@ -1,285 +0,0 @@
----
-description: Comprehensive branch review using agent teams for adversarial peer review with debate and consensus
----
-
-# Code Review Command
-
-Run a comprehensive code review of the current branch by spawning a review team where agents debate findings, then synthesize consensus results into PR comments.
-
-## Usage
-
-```
-/code-review           (review current branch)
-/code-review #42       (review specific PR)
-```
-
-## Phases
-
-### Phase 0: Pre-Flight (Git Agent)
-
-Spawn Git agent to validate and prepare branch:
-
-```
-Task(subagent_type="Git", run_in_background=false):
-"OPERATION: ensure-pr-ready
-Validate branch, commit if needed, push, create PR if needed.
-Return: branch, base_branch, branch-slug, PR#"
-```
-
-**If BLOCKED:** Stop and report the blocker to user.
-
-**Extract from response:** `branch`, `base_branch`, `branch_slug`, `pr_number` for use in subsequent phases.
-
-
-
-### Phase 1: Analyze Changed Files
-
-Detect file types in diff to determine conditional reviews:
-
-| Condition | Adds Perspective |
-|-----------|-----------------|
-| Any .ts or .tsx files | typescript |
-| .tsx or .jsx files (React components) | react |
-| .tsx or .jsx files (React components) | accessibility |
-| .tsx/.jsx/.css/.scss files | frontend-design |
-| .go files | go |
-| .java files | java |
-| .py files | python |
-| .rs files | rust |
-| DB/migration files | database |
-| Dependency files changed | dependencies |
-| Docs or significant code | documentation |
-
-**Skill availability check**: Language/ecosystem reviews (typescript, react, accessibility, frontend-design, go, java, python, rust) require their optional skill plugin to be installed. Before adding a conditional perspective, use Read to check if `~/.claude/skills/{focus}/SKILL.md` exists. If Read returns an error (file not found), **skip that perspective** — the language plugin isn't installed. Non-language reviews (database, dependencies, documentation) use skills bundled with this plugin and are always available.
-
-### Phase 2: Spawn Review Team
-
-Create an agent team for adversarial review. Always include 4 core perspectives; conditionally add more based on Phase 1 analysis.
-
-**Core perspectives (always):**
-- **Security**: vulnerabilities, injection, auth, crypto issues
-- **Architecture**: SOLID violations, coupling, layering, modularity
-- **Performance**: queries, algorithms, caching, I/O bottlenecks
-- **Quality**: complexity, tests, consistency, regression, naming
-
-**Conditional perspectives (based on changed files):**
-- **TypeScript**: type safety, generics, utility types (if .ts/.tsx changed)
-- **React**: hooks, state, rendering, composition (if .tsx/.jsx changed)
-- **Accessibility**: ARIA, keyboard nav, focus management (if .tsx/.jsx changed)
-- **Frontend Design**: visual consistency, spacing, typography (if .tsx/.jsx/.css changed)
-- **Go**: error handling, interfaces, concurrency (if .go changed)
-- **Java**: records, sealed classes, composition (if .java changed)
-- **Python**: type hints, protocols, data modeling (if .py changed)
-- **Rust**: ownership, error handling, type system (if .rs changed)
-- **Database**: schema, queries, migrations, indexes (if DB files changed)
-- **Dependencies**: CVEs, versions, licenses, supply chain (if package files changed)
-- **Documentation**: doc drift, missing docs, stale comments (if docs or significant code changed)
-
-```
-Create a team named "review-{branch_slug}" to review PR #{pr_number}.
-
-Spawn review teammates with self-contained prompts:
-
-- Name: "security-reviewer"
-  Prompt: |
-    You are reviewing PR #{pr_number} on branch {branch} (base: {base_branch}).
-    1. Read your skill: `Read ~/.claude/skills/security-patterns/SKILL.md`
-    2. Read review methodology: `Read ~/.claude/skills/review-methodology/SKILL.md`
-    3. Read `.memory/knowledge/pitfalls.md` if it exists. Check for known pitfall patterns in the diff.
-    4. Get the diff: `git diff {base_branch}...HEAD`
-    5. Apply the 6-step review process from review-methodology
-    6. Focus: injection, auth bypass, crypto misuse, OWASP vulnerabilities
-    7. Classify each finding: 🔴 BLOCKING / ⚠️ SHOULD-FIX / ℹ️ PRE-EXISTING
-    8. Include file:line references for every finding
-    9. Write your report: `Write to .docs/reviews/{branch_slug}/security.md`
-    10. Report completion: SendMessage(type: "message", recipient: "team-lead", summary: "Security review done")
-
-- Name: "architecture-reviewer"
-  Prompt: |
-    You are reviewing PR #{pr_number} on branch {branch} (base: {base_branch}).
-    1. Read your skill: `Read ~/.claude/skills/architecture-patterns/SKILL.md`
-    2. Read review methodology: `Read ~/.claude/skills/review-methodology/SKILL.md`
-    3. Read `.memory/knowledge/pitfalls.md` if it exists. Check for known pitfall patterns in the diff.
-    4. Get the diff: `git diff {base_branch}...HEAD`
-    5. Apply the 6-step review process from review-methodology
-    6. Focus: SOLID violations, coupling, layering issues, modularity problems
-    7. Classify each finding: 🔴 BLOCKING / ⚠️ SHOULD-FIX / ℹ️ PRE-EXISTING
-    8. Include file:line references for every finding
-    9. Write your report: `Write to .docs/reviews/{branch_slug}/architecture.md`
-    10. Report completion: SendMessage(type: "message", recipient: "team-lead", summary: "Architecture review done")
-
-- Name: "performance-reviewer"
-  Prompt: |
-    You are reviewing PR #{pr_number} on branch {branch} (base: {base_branch}).
-    1. Read your skill: `Read ~/.claude/skills/performance-patterns/SKILL.md`
-    2. Read review methodology: `Read ~/.claude/skills/review-methodology/SKILL.md`
-    3. Read `.memory/knowledge/pitfalls.md` if it exists. Check for known pitfall patterns in the diff.
-    4. Get the diff: `git diff {base_branch}...HEAD`
-    5. Apply the 6-step review process from review-methodology
-    6. Focus: N+1 queries, memory leaks, algorithm issues, I/O bottlenecks
-    7. Classify each finding: 🔴 BLOCKING / ⚠️ SHOULD-FIX / ℹ️ PRE-EXISTING
-    8. Include file:line references for every finding
-    9. Write your report: `Write to .docs/reviews/{branch_slug}/performance.md`
-    10. Report completion: SendMessage(type: "message", recipient: "team-lead", summary: "Performance review done")
-
-- Name: "quality-reviewer"
-  Prompt: |
-    You are reviewing PR #{pr_number} on branch {branch} (base: {base_branch}).
-    1. Read your skills:
-       - `Read ~/.claude/skills/complexity-patterns/SKILL.md`
-       - `Read ~/.claude/skills/consistency-patterns/SKILL.md`
-       - `Read ~/.claude/skills/test-patterns/SKILL.md`
-       - `Read ~/.claude/skills/regression-patterns/SKILL.md`
-    2. Read review methodology: `Read ~/.claude/skills/review-methodology/SKILL.md`
-    3. Read `.memory/knowledge/pitfalls.md` if it exists. Check for known pitfall patterns in the diff.
-    4. Get the diff: `git diff {base_branch}...HEAD`
-    5. Apply the 6-step review process from review-methodology
-    6. Focus: complexity, test gaps, pattern violations, regressions, naming
-    7. Classify each finding: 🔴 BLOCKING / ⚠️ SHOULD-FIX / ℹ️ PRE-EXISTING
-    8. Include file:line references for every finding
-    9. Write your report: `Write to .docs/reviews/{branch_slug}/quality.md`
-    10. Report completion: SendMessage(type: "message", recipient: "team-lead", summary: "Quality review done")
-
-[Add conditional perspectives based on Phase 1 — follow same pattern:
- explicit skill path, diff command, output path, SendMessage for completion]
-```
-
-### Phase 3: Debate Round
-
-After all reviewers complete initial analysis, lead initiates adversarial debate:
-
-Lead initiates debate via broadcast:
-
-```
-SendMessage(type: "broadcast", summary: "Debate: share and challenge findings"):
-"All reviewers: Share your top 3-5 findings. Then challenge findings
-from other reviewers you disagree with. Provide counter-evidence with
-file:line references.
-
-Rules:
-- Security: challenge architecture claims that affect attack surface
-- Architecture: challenge performance suggestions that break separation
-- Performance: challenge complexity assessments with benchmarking context
-- Quality: validate whether tests cover security and performance concerns
-
-Max 2 exchange rounds. Then submit final findings with confidence:
-- HIGH: Unchallenged or survived challenge with evidence
-- MEDIUM: Majority agreed, dissent noted
-- LOW: Genuinely split, both perspectives included"
-```
-
-Reviewers message each other directly using SendMessage:
-- `SendMessage(type: "message", recipient: "{reviewer-name}", summary: "Challenge: {topic}")` to challenge a specific finding
-- `SendMessage(type: "message", recipient: "{reviewer-name}", summary: "Validate: {topic}")` to validate alignment
-- `SendMessage(type: "message", recipient: "team-lead", summary: "Escalation: {topic}")` for unresolvable disagreements
-- Update or withdraw findings based on peer evidence
-
-### Phase 4: Synthesis and PR Comments
-
-**WAIT** for debate to complete, then lead produces outputs.
-
-Spawn 2 agents **in a single message**:
-
-**Git Agent (PR Comments)**:
-```
-Task(subagent_type="Git", run_in_background=false):
-"OPERATION: comment-pr
-Read reviews from .docs/reviews/{branch_slug}/
-Create inline PR comments. Deduplicate overlapping findings.
-Consolidate skipped findings into summary comment.
-Include confidence levels from debate consensus."
-```
-
-**Lead synthesizes review summary** (written to `.docs/reviews/{branch_slug}/review-summary.{timestamp}.md`):
-
-```markdown
-## Review Summary: {branch}
-
-### Merge Recommendation
-{APPROVE / REQUEST_CHANGES / BLOCK}
-
-### Consensus Findings (HIGH confidence)
-{Findings all reviewers agreed on or that survived challenge}
-
-### Majority Findings (MEDIUM confidence)
-{Findings most agreed on, with dissenting view noted}
-
-### Split Findings (LOW confidence)
-{Genuinely contested, both perspectives with evidence}
-
-### Issue Counts
-- 🔴 Blocking: {count}
-- ⚠️ Should-fix: {count}
-- ℹ️ Pre-existing: {count}
-
-### Debate Summary
-{Key exchanges that changed findings}
-```
-
-### Phase 5: Record Pitfalls (if blocking issues found)
-
-If the review summary contains CRITICAL or HIGH blocking issues:
-1. Read `~/.claude/skills/knowledge-persistence/SKILL.md` and follow its extraction procedure to record pitfalls to `.memory/knowledge/pitfalls.md`
-2. Source field: `/code-review {branch}`
-3. Skip entirely if no CRITICAL/HIGH blocking issues
-
-### Phase 6: Cleanup and Report
-
-Shut down all review teammates explicitly:
-
-```
-For each teammate in [security-reviewer, architecture-reviewer, performance-reviewer, quality-reviewer, ...conditional]:
-  SendMessage(type: "shutdown_request", recipient: "{name}", content: "Review complete")
-  Wait for shutdown_response (approve: true)
-
-TeamDelete
-Verify TeamDelete succeeded. If failed, retry once after 5s. If retry fails, HALT.
-```
-
-Display results:
-- Merge recommendation with confidence level
-- Issue counts by category (🔴 blocking / ⚠️ should-fix / ℹ️ pre-existing)
-- PR comments created/skipped (from Git agent)
-- Key debate highlights
-- Artifact paths
-
-## Architecture
-
-```
-/code-review (orchestrator - creates team, coordinates debate)
-│
-├─ Phase 0: Pre-flight
-│  └─ Git agent (ensure-pr-ready)
-│
-├─ Phase 1: Analyze changed files
-│  └─ Detect file types for conditional perspectives
-│
-├─ Phase 2: Spawn review team
-│  ├─ Security Reviewer (teammate)
-│  ├─ Architecture Reviewer (teammate)
-│  ├─ Performance Reviewer (teammate)
-│  ├─ Quality Reviewer (teammate)
-│  └─ [Conditional: TypeScript, React, A11y, Design, Go, Java, Python, Rust, DB, Deps, Docs]
-│
-├─ Phase 3: Debate round
-│  └─ Reviewers challenge each other (max 2 rounds)
-│
-├─ Phase 4: Synthesis
-│  ├─ Git agent (comment-pr with consensus findings)
-│  └─ Lead writes review-summary with confidence levels
-│
-├─ Phase 5: Record Pitfalls (inline, if blocking issues)
-│
-└─ Phase 6: Cleanup and display results
-```
-
-## Principles
-
-1. **Adversarial review** - Reviewers challenge each other's findings, not just report independently
-2. **Consensus confidence** - Findings classified by agreement level (HIGH/MEDIUM/LOW)
-3. **Orchestration only** - Command spawns team, coordinates debate, doesn't do review work itself
-4. **Git agent for git work** - All git operations go through Git agent
-5. **Bounded debate** - Max 2 exchange rounds, then converge
-6. **Honest reporting** - Report disagreements with evidence, don't paper over conflicts
-7. **Cleanup always** - Team resources released even on failure
-

package/plugins/devflow-code-review/commands/code-review.md

@@ -1,163 +0,0 @@
----
-description: Comprehensive branch review using specialized sub-agents for PR readiness
----
-
-# Code Review Command
-
-Run a comprehensive code review of the current branch by spawning parallel review agents, then synthesizing results into PR comments.
-
-## Usage
-
-```
-/code-review           (review current branch)
-/code-review #42       (review specific PR)
-```
-
-## Phases
-
-### Phase 0: Pre-Flight (Git Agent)
-
-Spawn Git agent to validate and prepare branch:
-
-```
-Task(subagent_type="Git", run_in_background=false):
-"OPERATION: ensure-pr-ready
-Validate branch, commit if needed, push, create PR if needed.
-Return: branch, base_branch, branch-slug, PR#"
-```
-
-**If BLOCKED:** Stop and report the blocker to user.
-
-**Extract from response:** `branch`, `base_branch`, `branch_slug`, `pr_number` for use in subsequent phases.
-
-
-
-### Phase 1: Analyze Changed Files
-
-Detect file types in diff to determine conditional reviews:
-
-| Condition | Adds Review |
-|-----------|-------------|
-| Any .ts or .tsx files | typescript |
-| .tsx or .jsx files (React components) | react |
-| .tsx or .jsx files (React components) | accessibility |
-| .tsx/.jsx/.css/.scss files | frontend-design |
-| .go files | go |
-| .java files | java |
-| .py files | python |
-| .rs files | rust |
-| DB/migration files | database |
-| Dependency files changed | dependencies |
-| Docs or significant code | documentation |
-
-**Skill availability check**: Language/ecosystem reviews (typescript, react, accessibility, frontend-design, go, java, python, rust) require their optional skill plugin to be installed. Before spawning a conditional Reviewer for these focuses, use Read to check if `~/.claude/skills/{focus}/SKILL.md` exists. If Read returns an error (file not found), **skip that review** — the language plugin isn't installed. Non-language reviews (database, dependencies, documentation) use skills bundled with this plugin and are always available.
-
-### Phase 2: Run Reviews (Parallel)
-
-Spawn Reviewer agents **in a single message**. Always run 7 core reviews; conditionally add more based on changed file types:
-
-| Focus | Always | Pattern Skill |
-|-------|--------|---------------|
-| security | ✓ | security-patterns |
-| architecture | ✓ | architecture-patterns |
-| performance | ✓ | performance-patterns |
-| complexity | ✓ | complexity-patterns |
-| consistency | ✓ | consistency-patterns |
-| regression | ✓ | regression-patterns |
-| tests | ✓ | test-patterns |
-| typescript | conditional | typescript |
-| react | conditional | react |
-| accessibility | conditional | accessibility |
-| frontend-design | conditional | frontend-design |
-| go | conditional | go |
-| java | conditional | java |
-| python | conditional | python |
-| rust | conditional | rust |
-| database | conditional | database-patterns |
-| dependencies | conditional | dependencies-patterns |
-| documentation | conditional | documentation-patterns |
-
-Each Reviewer invocation (all in one message, **NOT background**):
-```
-Task(subagent_type="Reviewer", run_in_background=false):
-"Review focusing on {focus}. Apply {focus}-patterns.
-Follow 6-step process from review-methodology.
-PR: #{pr_number}, Base: {base_branch}
-IMPORTANT: Write report to .docs/reviews/{branch-slug}/{focus}.md using Write tool"
-```
-
-### Phase 3: Synthesis (Parallel)
-
-**WAIT** for Phase 2, then spawn 3 agents **in a single message**:
-
-**Git Agent (PR Comments)**:
-```
-Task(subagent_type="Git", run_in_background=false):
-"OPERATION: comment-pr
-Read reviews from .docs/reviews/{branch-slug}/
-<!-- Confidence threshold also in: shared/agents/reviewer.md, shared/agents/synthesizer.md -->
-Create inline PR comments for findings with ≥80% confidence only.
-Lower-confidence suggestions (60-79%) go in the summary comment, not as inline comments.
-Deduplicate findings across reviewers, consolidate skipped into summary."
-```
-
-**Synthesizer Agent**:
-```
-Task(subagent_type="Synthesizer", run_in_background=false):
-"Mode: review
-Aggregate findings, determine merge recommendation
-Output: .docs/reviews/{branch-slug}/review-summary.{timestamp}.md"
-```
-
-### Phase 4: Report
-
-Display results from all agents:
-- Merge recommendation (from Synthesizer)
-- Issue counts by category (🔴 blocking / ⚠️ should-fix / ℹ️ pre-existing)
-- PR comments created/skipped (from Git)
-- Artifact paths
-
-### Phase 5: Record Pitfalls (if blocking issues found)
-
-If the review summary contains CRITICAL or HIGH blocking issues:
-1. Read `~/.claude/skills/knowledge-persistence/SKILL.md` and follow its extraction procedure to record pitfalls to `.memory/knowledge/pitfalls.md`
-2. Source field: `/code-review {branch}`
-3. Skip entirely if no CRITICAL/HIGH blocking issues
-
-## Architecture
-
-```
-/code-review (orchestrator - spawns agents only)
-│
-├─ Phase 0: Pre-flight
-│  └─ Git agent (ensure-pr-ready)
-│
-├─ Phase 1: Analyze changed files
-│  └─ Detect file types for conditional reviews
-│
-├─ Phase 2: Reviews (PARALLEL)
-│  ├─ Reviewer: security
-│  ├─ Reviewer: architecture
-│  ├─ Reviewer: performance
-│  ├─ Reviewer: complexity
-│  ├─ Reviewer: consistency
-│  ├─ Reviewer: regression
-│  ├─ Reviewer: tests
-│  └─ Reviewer: [conditional: typescript, react, a11y, design, go, java, python, rust, database, deps, docs]
-│
-├─ Phase 3: Synthesis (PARALLEL)
-│  ├─ Git agent (comment-pr)
-│  └─ Synthesizer agent (mode: review)
-│
-├─ Phase 4: Display results
-│
-└─ Phase 5: Record Pitfalls (inline, if blocking issues)
-```
-
-## Principles
-
-1. **Orchestration only** - Command spawns agents, doesn't do git/review work itself
-2. **Parallel, not background** - Multiple agents in one message, but `run_in_background=false` so phases complete before proceeding
-3. **Git agent for git work** - All git operations go through Git agent
-4. **Clear ownership** - Each agent owns its output completely
-5. **Honest reporting** - Display agent outputs directly