devflow-kit 1.8.2 → 2.0.0

package/plugins/devflow-debug/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-debug/commands/debug-teams.md

@@ -1,245 +0,0 @@
----
-description: Debug issues using competing hypothesis investigation with an agent team
----
-
-# Debug Command
-
-Investigate bugs by spawning a team of agents, each pursuing a different hypothesis. Agents actively try to disprove each other's theories, converging on the root cause that survives scrutiny.
-
-## Usage
-
-```
-/debug "description of bug or issue"
-/debug "function returns undefined when called with empty array"
-/debug #42   (investigate bug from GitHub issue)
-```
-
-## Input
-
-`$ARGUMENTS` contains whatever follows `/debug`:
-- Bug description: "login fails after session timeout"
-- GitHub issue: "#42"
-- Empty: use conversation context
-
-## Phases
-
-### Phase 1: Load Project Knowledge
-
-Read `.memory/knowledge/decisions.md` and `.memory/knowledge/pitfalls.md`. Known pitfalls from prior debugging sessions and code reviews can directly inform hypothesis generation — pass their content as context to investigators in Phase 2.
-
-### Phase 2: Context Gathering
-
-If `$ARGUMENTS` starts with `#`, fetch the GitHub issue:
-
-```
-Task(subagent_type="Git"):
-"OPERATION: fetch-issue
-ISSUE: {issue number}
-Return issue title, body, labels, and any linked error logs."
-```
-
-Analyze the bug description (from arguments or issue) and identify 3-5 plausible hypotheses. Each hypothesis must be:
-- **Specific**: Points to a concrete mechanism (not "something is wrong")
-- **Testable**: Can be confirmed or disproved by reading code/logs
-- **Distinct**: Does not overlap significantly with other hypotheses
-
-### Phase 3: Spawn Investigation Team
-
-Create an agent team with one investigator per hypothesis:
-
-```
-Create a team named "debug-{bug-slug}" to investigate: {bug_description}
-
-Spawn investigator teammates with self-contained prompts:
-
-- Name: "investigator-a"
-  Prompt: |
-    You are investigating a bug: {bug_description}
-    Your hypothesis: {hypothesis A description}
-    Focus area: {specific code area, mechanism, or condition}
-
-    Steps:
-    1. Read relevant code files in your focus area
-    2. Trace data flow related to your hypothesis
-    3. Collect evidence FOR your hypothesis (with file:line references)
-    4. Collect evidence AGAINST your hypothesis (with file:line references)
-    5. Document all findings
-    6. Report completion:
-       SendMessage(type: "message", recipient: "team-lead",
-         summary: "Hypothesis A: initial findings ready")
-
-- Name: "investigator-b"
-  Prompt: |
-    You are investigating a bug: {bug_description}
-    Your hypothesis: {hypothesis B description}
-    Focus area: {specific code area, mechanism, or condition}
-
-    Steps:
-    1. Read relevant code files in your focus area
-    2. Trace data flow related to your hypothesis
-    3. Collect evidence FOR your hypothesis (with file:line references)
-    4. Collect evidence AGAINST your hypothesis (with file:line references)
-    5. Document all findings
-    6. Report completion:
-       SendMessage(type: "message", recipient: "team-lead",
-         summary: "Hypothesis B: initial findings ready")
-
-- Name: "investigator-c"
-  Prompt: |
-    You are investigating a bug: {bug_description}
-    Your hypothesis: {hypothesis C description}
-    Focus area: {specific code area, mechanism, or condition}
-
-    Steps:
-    1. Read relevant code files in your focus area
-    2. Trace data flow related to your hypothesis
-    3. Collect evidence FOR your hypothesis (with file:line references)
-    4. Collect evidence AGAINST your hypothesis (with file:line references)
-    5. Document all findings
-    6. Report completion:
-       SendMessage(type: "message", recipient: "team-lead",
-         summary: "Hypothesis C: initial findings ready")
-
-(Add more investigators if bug complexity warrants 4-5 hypotheses — same pattern)
-```
-
-### Phase 4: Investigation
-
-Teammates investigate in parallel:
-- Read relevant source files
-- Trace execution paths
-- Check error handling
-- Look for edge cases and race conditions
-- Build evidence for or against their hypothesis
-
-### Phase 5: Adversarial Debate
-
-Lead initiates debate via broadcast:
-
-```
-SendMessage(type: "broadcast", summary: "Debate: share findings and challenge hypotheses"):
-"Investigation complete. Share your findings:
-1. State your hypothesis
-2. Present evidence FOR (with file:line references)
-3. Present evidence AGAINST
-4. Challenge at least one other investigator's hypothesis
-
-Rules:
-- You must try to DISPROVE other hypotheses, not just support your own
-- Cite specific code when challenging
-- If your hypothesis is disproved, acknowledge it
-- Max 2 exchange rounds before we converge"
-```
-
-Teammates challenge each other directly using SendMessage:
-- `SendMessage(type: "message", recipient: "investigator-b", summary: "Challenge: evidence at auth.ts:42")`
-  "My evidence at `src/auth.ts:42` disproves your hypothesis because..."
-- `SendMessage(type: "message", recipient: "investigator-a", summary: "Counter: Tuesday-only failure")`
-  "Your theory doesn't explain why this only fails on Tuesdays..."
-- `SendMessage(type: "message", recipient: "team-lead", summary: "Updated hypothesis")`
-  "I've updated my hypothesis based on investigator-b's finding at..."
-
-### Phase 6: Convergence
-
-After debate (max 2 rounds), lead collects results:
-
-```
-Lead broadcast:
-"Debate complete. Each investigator: submit final status.
-- CONFIRMED: Your hypothesis survived scrutiny (evidence summary)
-- DISPROVED: Your hypothesis was invalidated (what disproved it)
-- PARTIAL: Some aspects confirmed, others not (details)"
-```
-
-### Phase 7: Cleanup
-
-Shut down all investigator teammates explicitly:
-
-```
-For each teammate in [investigator-a, investigator-b, investigator-c, ...]:
-  SendMessage(type: "shutdown_request", recipient: "{name}", content: "Investigation complete")
-  Wait for shutdown_response (approve: true)
-
-TeamDelete
-Verify TeamDelete succeeded. If failed, retry once after 5s. If retry fails, HALT.
-```
-
-### Phase 8: Report
-
-Lead produces final report:
-
-```markdown
-## Root Cause Analysis: {bug description}
-
-### Root Cause (Consensus)
-{Description of the root cause that survived peer scrutiny}
-{Key evidence with file:line references}
-
-### Investigation Summary
-
-| Hypothesis | Status | Key Evidence |
-|-----------|--------|-------------|
-| A: {description} | CONFIRMED/DISPROVED/PARTIAL | {file:line + summary} |
-| B: {description} | CONFIRMED/DISPROVED/PARTIAL | {file:line + summary} |
-| C: {description} | CONFIRMED/DISPROVED/PARTIAL | {file:line + summary} |
-
-### Key Debate Exchanges
-{2-3 most important exchanges that led to the conclusion}
-
-### Recommended Fix
-{Concrete action items with file references}
-
-### Confidence Level
-{HIGH/MEDIUM/LOW based on consensus strength}
-```
-
-### Phase 9: Record Pitfall (if root cause found)
-
-If root cause was identified with HIGH or MEDIUM confidence:
-1. Read `~/.claude/skills/knowledge-persistence/SKILL.md` and follow its extraction procedure to record pitfalls to `.memory/knowledge/pitfalls.md`
-2. Source field: `/debug {bug description}`
-
-## Architecture
-
-```
-/debug (orchestrator)
-│
-├─ Phase 1: Load Project Knowledge
-│
-├─ Phase 2: Context gathering
-│  └─ Git agent (fetch issue, if #N provided)
-│
-├─ Phase 3: Spawn investigation team
-│  └─ Create team with 3-5 hypothesis investigators
-│
-├─ Phase 4: Parallel investigation
-│  └─ Each teammate investigates independently
-│
-├─ Phase 5: Adversarial debate
-│  └─ Teammates challenge each other directly (max 2 rounds)
-│
-├─ Phase 6: Convergence
-│  └─ Teammates submit final hypothesis status
-│
-├─ Phase 7: Cleanup
-│  └─ Shut down teammates, release resources
-│
-├─ Phase 8: Root cause report with confidence level
-│
-└─ Phase 9: Record Pitfall (inline, if root cause found)
-```
-
-## Principles
-
-1. **Competing hypotheses** - Never investigate a single theory; always have alternatives
-2. **Adversarial debate** - Agents must actively try to disprove each other
-3. **Evidence-based** - Every claim requires file:line references
-4. **Bounded debate** - Max 2 exchange rounds, then converge
-5. **Honest uncertainty** - If no hypothesis survives, report that clearly
-6. **Cleanup always** - Team resources released even on failure
-
-## Error Handling
-
-- If fewer than 3 hypotheses can be generated: proceed with 2, note limited scope
-- If all hypotheses are disproved: report "No root cause identified" with investigation summary
-- If a teammate errors: continue with remaining teammates, note the gap

package/plugins/devflow-debug/commands/debug.md

@@ -1,174 +0,0 @@
----
-description: Debug issues using competing hypothesis investigation with parallel agents
----
-
-# Debug Command
-
-Investigate bugs by spawning parallel agents, each pursuing a different hypothesis. Evidence is aggregated and synthesized to identify the root cause.
-
-## Usage
-
-```
-/debug "description of bug or issue"
-/debug "function returns undefined when called with empty array"
-/debug #42   (investigate bug from GitHub issue)
-```
-
-## Input
-
-`$ARGUMENTS` contains whatever follows `/debug`:
-- Bug description: "login fails after session timeout"
-- GitHub issue: "#42"
-- Empty: use conversation context
-
-## Phases
-
-### Phase 1: Load Project Knowledge
-
-Read `.memory/knowledge/decisions.md` and `.memory/knowledge/pitfalls.md`. Known pitfalls from prior debugging sessions and code reviews can directly inform hypothesis generation — pass their content as context to investigators in Phase 2.
-
-### Phase 2: Context Gathering
-
-If `$ARGUMENTS` starts with `#`, fetch the GitHub issue:
-
-```
-Task(subagent_type="Git"):
-"OPERATION: fetch-issue
-ISSUE: {issue number}
-Return issue title, body, labels, and any linked error logs."
-```
-
-Analyze the bug description (from arguments or issue) and identify 3-5 plausible hypotheses. Each hypothesis must be:
-- **Specific**: Points to a concrete mechanism (not "something is wrong")
-- **Testable**: Can be confirmed or disproved by reading code/logs
-- **Distinct**: Does not overlap significantly with other hypotheses
-
-### Phase 3: Investigate (Parallel)
-
-Spawn one Explore agent per hypothesis in a **single message** (parallel execution):
-
-```
-Task(subagent_type="Explore"):
-"Investigate this bug: {bug_description}
-
-Hypothesis: {hypothesis A description}
-Focus area: {specific code area, mechanism, or condition}
-
-Steps:
-1. Read relevant code files in your focus area
-2. Trace data flow related to this hypothesis
-3. Collect evidence FOR this hypothesis (with file:line references)
-4. Collect evidence AGAINST this hypothesis (with file:line references)
-
-Return a structured report:
-- Hypothesis: {restate}
-- Status: CONFIRMED / DISPROVED / PARTIAL
-- Evidence FOR: [list with file:line refs]
-- Evidence AGAINST: [list with file:line refs]
-- Key finding: {one-sentence summary}"
-
-Task(subagent_type="Explore"):
-"Investigate this bug: {bug_description}
-
-Hypothesis: {hypothesis B description}
-Focus area: {specific code area, mechanism, or condition}
-
-[same steps and return format]"
-
-Task(subagent_type="Explore"):
-"Investigate this bug: {bug_description}
-
-Hypothesis: {hypothesis C description}
-Focus area: {specific code area, mechanism, or condition}
-
-[same steps and return format]"
-
-(Add more investigators if bug complexity warrants 4-5 hypotheses)
-```
-
-### Phase 4: Synthesize
-
-Once all investigators return, spawn a Synthesizer agent to aggregate findings:
-
-```
-Task(subagent_type="Synthesizer"):
-"You are a root cause analyst. Synthesize these investigation reports:
-
-{paste all investigator reports}
-
-Instructions:
-1. Compare evidence across all hypotheses
-2. Identify which hypothesis has the strongest evidence
-3. Note contradictions between investigators
-4. Determine overall root cause (may combine partial findings)
-5. Assess confidence level based on evidence strength"
-```
-
-### Phase 5: Report
-
-Produce the final report:
-
-```markdown
-## Root Cause Analysis: {bug description}
-
-### Root Cause
-{Description of the root cause supported by evidence}
-{Key evidence with file:line references}
-
-### Investigation Summary
-
-| Hypothesis | Status | Key Evidence |
-|-----------|--------|-------------|
-| A: {description} | CONFIRMED/DISPROVED/PARTIAL | {file:line + summary} |
-| B: {description} | CONFIRMED/DISPROVED/PARTIAL | {file:line + summary} |
-| C: {description} | CONFIRMED/DISPROVED/PARTIAL | {file:line + summary} |
-
-### Key Findings
-{2-3 most important discoveries across all investigators}
-
-### Recommended Fix
-{Concrete action items with file references}
-
-### Confidence Level
-{HIGH/MEDIUM/LOW based on evidence strength and investigator agreement}
-```
-
-### Phase 6: Record Pitfall (if root cause found)
-
-If root cause was identified with HIGH or MEDIUM confidence:
-1. Read `~/.claude/skills/knowledge-persistence/SKILL.md` and follow its extraction procedure to record pitfalls to `.memory/knowledge/pitfalls.md`
-2. Source field: `/debug {bug description}`
-
-## Architecture
-
-```
-/debug (orchestrator)
-│
-├─ Phase 1: Load Project Knowledge
-│
-├─ Phase 2: Context gathering
-│  └─ Git agent (fetch issue, if #N provided)
-│
-├─ Phase 3: Parallel investigation
-│  └─ 3-5 Explore agents, one per hypothesis (single message)
-│
-├─ Phase 4: Synthesize
-│  └─ Synthesizer aggregates and compares findings
-│
-├─ Phase 5: Root cause report with confidence level
-│
-└─ Phase 6: Record Pitfall (inline, if root cause found)
-```
-
-## Principles
-
-1. **Competing hypotheses** - Never investigate a single theory; always have alternatives
-2. **Parallel execution** - All investigators run simultaneously for speed
-3. **Evidence-based** - Every claim requires file:line references
-4. **Honest uncertainty** - If no hypothesis survives, report that clearly
-
-## Error Handling
-
-- If fewer than 3 hypotheses can be generated: proceed with 2, note limited scope
-- If all hypotheses are disproved: report "No root cause identified" with investigation summary
-- If an investigator errors: continue with remaining results, note the gap