devflow-kit 1.8.3 → 2.0.1

package/plugins/devflow-code-review/skills/agent-teams/SKILL.md

@@ -1,124 +0,0 @@
----
-name: agent-teams
-description: This skill should be used when the user asks to "create an agent team", "spawn teammates", "set up debate protocol", "coordinate agents", or discusses peer-to-peer agent collaboration, consensus formation, or team-based workflows. Provides patterns for team spawning, message passing, adversarial debate, and quality gates driven by multi-agent consensus.
-user-invocable: false
-allowed-tools: Read, Grep, Glob
----
-
-# Agent Teams Patterns
-
-Patterns for collaborative multi-agent workflows using Claude Code's Agent Teams feature. Teams enable peer-to-peer communication between agents, replacing one-way subagent reporting with adversarial debate and consensus.
-
-## Iron Law
-
-> **TEAMMATES CHALLENGE EACH OTHER**
->
-> Every finding must survive peer scrutiny. No unchallenged claims reach the final
-> report. A single agent's opinion is a hypothesis; consensus from debate is a finding.
-
----
-
-## When This Activates
-
-- Creating agent teams for review, implementation, or debugging
-- Spawning teammates with distinct perspectives
-- Coordinating multi-agent debate rounds
-- Forming consensus from conflicting findings
-
-## Core Patterns
-
-### Team Spawning
-
-Size team to task complexity. Assign distinct, non-overlapping perspectives.
-
-| Task Complexity | Team Size | Rationale |
-|----------------|-----------|-----------|
-| Simple review | 2-3 | Security + architecture sufficient |
-| Full review | 4-5 | Core perspectives covered |
-| Debug investigation | 3-5 | One per hypothesis |
-| Implementation | 2-4 | Domain-separated work units |
-| Specification | 3-4 | Debate requirements before user gates |
-| Resolution | 2-4 | Cross-validate fixes across batches |
-
-**Model guidance**: Explorers/Reviewers inherit parent model. Validators use `model: haiku`.
-
-### Detection and Fallback
-
-Attempt `TeamCreate`. If it fails or the tool is unavailable, fall back to parallel subagents:
-
-```
-try TeamCreate → success → proceed with team workflow
-                → failure → fall back to parallel Task() calls
-```
-
-Always document which mode was used in the final report.
-
-### Task List Coordination
-
-Use `TaskCreate` to give each teammate a trackable work unit. Lead checks `TaskList` for structured progress visibility beyond ad-hoc messages:
-
-```
-1. Lead creates tasks for each teammate's work unit
-2. Teammates claim tasks via TaskUpdate (owner: self)
-3. Teammates mark tasks completed when done
-4. Lead checks TaskList before proceeding to next phase
-```
-
-### Challenge Protocol
-
-1. **Initial work**: Each teammate completes independent analysis
-2. **Exchange**: Lead broadcasts "Share findings and challenge others"
-3. **Direct debate**: Teammates message each other with evidence
-4. **Resolution**: Contradictions resolved through 1-2 exchanges
-5. **Escalation**: Unresolved after 2 exchanges → report disagreement to lead
-
-### Consensus Formation
-
-| Agreement Level | Confidence | Report As |
-|----------------|------------|-----------|
-| Unanimous | HIGH | Confirmed finding |
-| Majority (>50%) | MEDIUM | Finding with noted dissent |
-| Split (50/50) | LOW | Disagreement with both perspectives |
-
-### Team Cleanup
-
-Lead MUST always handle cleanup:
-1. Ensure all teammates have completed or been shut down
-2. Call `TeamDelete` to release resources
-3. Verify no orphaned sessions remain
-4. **CRITICAL**: Confirm cleanup completed before creating next team
-
----
-
-## Limitations
-
-| Limitation | Impact | Guidance |
-|-----------|--------|----------|
-| One team per session | Cannot run two teams concurrently | Shut down and verify cleanup before creating next team |
-| No nested teams | Teammates cannot spawn sub-teams | Keep hierarchy flat; only lead creates teams |
-| No session resumption | Teammate state lost if interrupted | Start fresh; don't rely on teammate state persistence |
-| Shutdown can be slow | Cleanup may take several seconds | Wait for confirmation; don't race to create next team |
-| Task status may lag | Task list updates aren't instant | Use direct messages for time-sensitive coordination |
-| Permissions inherited | Teammates get lead's permissions at spawn | Cannot escalate permissions mid-session |
-
----
-
-## Anti-Patterns
-
-| Anti-Pattern | Correct Approach |
-|-------------|-----------------|
-| Overlapping perspectives | Assign distinct, non-overlapping focus areas |
-| Skipping debate round | Always require peer challenge before synthesis |
-| Unlimited debate | Cap at 2 exchanges per topic, then escalate |
-| Lead does analysis work | Lead coordinates only; teammates do analysis |
-| Ignoring minority opinion | Report dissent with evidence in final output |
-| Creating team before prior cleanup | Wait for TeamDelete confirmation, then create |
-| Messaging-only coordination | Use task list for structured progress tracking |
-
----
-
-## Extended References
-
-- `references/team-patterns.md` - Team structures for review, implement, debug, specify, resolve workflows
-- `references/communication.md` - Message protocols, broadcast patterns, debate formats
-- `references/cleanup.md` - Session management, orphan detection, resource cleanup

package/plugins/devflow-code-review/skills/agent-teams/references/cleanup.md

@@ -1,104 +0,0 @@
-# Session Management and Cleanup
-
-## Team Lifecycle
-
-```
-1. Lead creates team
-2. Lead spawns teammates
-3. Teammates work independently
-4. Debate rounds (teammates message directly)
-5. Lead collects consensus
-6. Lead shuts down teammates
-7. Lead calls cleanup
-8. Lead verifies no orphans
-```
-
----
-
-## Cleanup Rules
-
-### Lead Responsibilities
-
-1. **Always call cleanup** - Even if team work was interrupted or errored
-2. **Shut down teammates first** - Before calling cleanup
-3. **Verify completion** - Check that no orphaned sessions remain
-
-### Error Handling
-
-If a teammate errors or hangs:
-1. Send shutdown message to the teammate
-2. Wait briefly for graceful shutdown
-3. Proceed with cleanup for remaining team
-4. Report the failed teammate in final output
-
-### Orphan Detection
-
-After cleanup, verify:
-- No tmux sessions from the team remain (split-pane mode)
-- No background processes from teammates
-- Team config at `~/.claude/teams/{team-name}/` is cleaned up
-
----
-
-## Known Limitations
-
-| Limitation | Mitigation |
-|-----------|------------|
-| No session resumption for teammates | Start fresh; don't rely on teammate state persistence |
-| One team per session | Queue team work sequentially if needed |
-| Task status may lag | Use direct messages for time-sensitive coordination |
-| No nested teams | Teammates cannot spawn sub-teams; keep hierarchy flat |
-| Split-pane requires tmux/iTerm2 | Fall back to in-process mode if unavailable |
-
----
-
-## Cost Management
-
-### Token Optimization
-
-| Strategy | Savings |
-|----------|---------|
-| Use haiku for validation teammates | ~70% per validation agent |
-| Limit debate to 2 rounds | Prevents runaway token usage |
-| Size teams to task (don't over-spawn) | Fewer agents = fewer tokens |
-| Shut down teammates promptly | No idle token consumption |
-
-### When NOT to Use Teams
-
-- Simple, single-focus tasks (use regular subagent)
-- Tasks requiring sequential dependency (no parallelism benefit)
-- Cost-sensitive operations where subagent is sufficient
-- Tasks where debate adds no value (e.g., formatting, simple fixes)
-
----
-
-## Sequential Team Transition Protocol
-
-Commands that create multiple teams (e.g., `/implement`, `/specify`) MUST follow this 4-step protocol between teams. Skipping steps causes silent failures due to the one-team-per-session constraint.
-
-```
-Step 1: SHUTDOWN — Send shutdown_request to each teammate by name
-  SendMessage(type: "shutdown_request", recipient: "{name}", content: "Phase complete")
-  Wait for each shutdown_response (approve: true)
-
-Step 2: DELETE — Remove team resources
-  TeamDelete
-
-Step 3: VERIFY — Confirm cleanup succeeded
-  If TeamDelete returned success → proceed
-  If TeamDelete failed → retry once after 5s
-  If retry fails → HALT and report to user:
-    "Team cleanup failed for {team-name}. Cannot create next team."
-
-Step 4: CREATE — Only now create the next team
-  TeamCreate(team_name: "{next-team-name}")
-```
-
-### Failure Modes
-
-| Failure | Action |
-|---------|--------|
-| Teammate ignores shutdown_request | Wait 30s, then proceed to TeamDelete (force cleanup) |
-| TeamDelete fails | Retry once after 5s delay |
-| TeamDelete retry fails | HALT execution, report to user |
-| TeamCreate fails after successful delete | Retry once; if fails, fall back to parallel Task() subagents |

package/plugins/devflow-code-review/skills/agent-teams/references/communication.md

@@ -1,122 +0,0 @@
-# Communication Protocols
-
-## Message Types
-
-### Direct Message (one-to-one)
-
-Use when challenging a specific teammate's finding:
-
-```
-To [Security Reviewer]:
-"Your finding about SQL injection at api/users.ts:42 - I disagree.
-The parameterized query at line 45 handles this. Check the query builder
-pattern used throughout this codebase."
-```
-
-### Broadcast (one-to-all)
-
-Use when sharing findings that affect all teammates:
-
-```
-Broadcast:
-"I found that the auth middleware is bypassed for /api/internal/* routes.
-This affects security, architecture, and testing perspectives."
-```
-
----
-
-## Debate Protocol
-
-### Round Structure
-
-```
-Round 1: Initial findings (each teammate shares top findings)
-Round 2: Challenge round (teammates dispute or validate)
-Round 3: Resolution (update, withdraw, or escalate)
-```
-
-**Cap: 2 challenge exchanges per topic.** If unresolved, escalate to lead.
-
-### Challenge Format
-
-When challenging another teammate:
-
-```
-CHALLENGE to [Teammate]:
-- Finding: [what they claimed]
-- Evidence against: [your counter-evidence with file:line references]
-- Suggested resolution: [what you think is correct]
-```
-
-### Concession Format
-
-When accepting a challenge:
-
-```
-UPDATED based on [Teammate]'s challenge:
-- Original: [what I originally claimed]
-- Revised: [updated finding incorporating their evidence]
-```
-
-### Escalation Format
-
-When debate is unresolved after 2 exchanges:
-
-```
-ESCALATION to Lead:
-- Topic: [what we disagree about]
-- Position A: [first perspective with evidence]
-- Position B: [second perspective with evidence]
-- Recommendation: [which has stronger evidence, or "genuinely split"]
-```
-
----
-
-## Lead Coordination Messages
-
-### Initiating Debate
-
-```
-Lead broadcast:
-"All teammates: Share your top 3-5 findings. After sharing, challenge
-any finding you disagree with. Provide evidence (file:line references).
-You have 2 exchange rounds to resolve disagreements."
-```
-
-### Ending Debate
-
-```
-Lead broadcast:
-"Debate round complete. Submit final findings with confidence levels:
-- HIGH: Unanimous or unchallenged with evidence
-- MEDIUM: Majority agreed, dissent noted
-- LOW: Split opinion, both perspectives included"
-```
-
-### Requesting Clarification
-
-```
-Lead to [Teammate]:
-"Your finding about X contradicts [Other Teammate]'s finding about Y.
-Can you address their evidence at [file:line]?"
-```
-
----
-
-## Output Aggregation
-
-### Consensus Report Structure
-
-```markdown
-## Confirmed Findings (HIGH confidence)
-[Findings all teammates agreed on or that survived challenge]
-
-## Majority Findings (MEDIUM confidence)
-[Findings most agreed on, with dissenting view noted]
-
-## Split Findings (LOW confidence)
-[Genuinely contested findings with both perspectives and evidence]
-
-## Withdrawn Findings
-[Findings that were disproved during debate]
-```

package/plugins/devflow-code-review/skills/agent-teams/references/team-patterns.md

@@ -1,217 +0,0 @@
-# Team Patterns by Workflow
-
-## Task-Based Coordination
-
-All team workflows should use the shared task list for structured progress tracking:
-
-```
-1. Lead creates team
-2. Lead creates tasks (TaskCreate) for each teammate's work unit
-3. Lead spawns teammates, assigning tasks via TaskUpdate(owner)
-4. Teammates work, mark tasks completed via TaskUpdate(status: completed)
-5. Lead checks TaskList before proceeding to next phase
-6. Lead shuts down teammates, calls TeamDelete
-```
-
-**Example task creation for a review team:**
-
-```
-TaskCreate: "Security review of auth module" → assigned to Security Reviewer
-TaskCreate: "Architecture review of auth module" → assigned to Architecture Reviewer
-TaskCreate: "Performance review of auth module" → assigned to Performance Reviewer
-```
-
----
-
-## Review Team
-
-### Standard Review (4 perspectives)
-
-```
-Lead spawns:
-├── Security reviewer    → vulnerabilities, injection, auth, crypto
-├── Architecture reviewer → SOLID, coupling, layering, modularity
-├── Performance reviewer  → queries, algorithms, caching, I/O
-└── Quality reviewer      → complexity, tests, consistency, naming
-```
-
-### Extended Review (add conditionally)
-
-```
-Additional teammates based on changed files:
-├── TypeScript reviewer  → type safety, generics (if .ts/.tsx changed)
-├── React reviewer       → hooks, state, rendering (if .tsx/.jsx changed)
-├── Database reviewer    → schema, queries, migrations (if DB files changed)
-└── Dependencies reviewer → CVEs, versions, licenses (if package files changed)
-```
-
-### Review Debate Flow
-
-```
-1. Each reviewer analyzes independently
-2. Lead broadcasts: "Share top 3 findings and challenge others"
-3. Security challenges architecture: "This coupling creates attack surface"
-4. Architecture challenges performance: "Your caching suggestion breaks separation"
-5. Quality validates: "Tests don't cover the security concern raised"
-6. Lead collects consensus after max 2 exchange rounds
-```
-
----
-
-## Implementation Team
-
-### Exploration Team (4 perspectives)
-
-```
-Lead spawns:
-├── Architecture explorer  → existing patterns, module structure
-├── Integration explorer   → entry points, services, config
-├── Reusable code explorer → utilities, helpers, shared logic
-└── Edge case explorer     → error conditions, boundaries, race conditions
-```
-
-### Planning Team (3 perspectives)
-
-```
-Lead spawns:
-├── Implementation planner → step-by-step coding approach
-├── Testing planner        → test strategy and coverage plan
-└── Risk planner           → potential issues, rollback strategy
-```
-
-### Implementation Debate
-
-```
-1. Explorers share findings
-2. Architecture challenges edge cases: "This boundary isn't handled"
-3. Integration challenges reusable code: "That helper doesn't cover our case"
-4. Lead synthesizes consensus exploration
-
-5. Planners propose approaches
-6. Testing challenges implementation: "This approach is untestable"
-7. Risk challenges both: "Rollback is impossible with this migration"
-8. Lead synthesizes consensus plan
-```
-
----
-
-## Specification Team
-
-### Requirements Exploration Team (4 perspectives)
-
-```
-Lead spawns:
-├── User Perspective Explorer  → target users, goals, pain points, user journeys
-├── Similar Features Explorer  → comparable features, scope patterns, precedents
-├── Constraints Explorer       → dependencies, business rules, security, performance
-└── Failure Mode Explorer      → error states, edge cases, validation needs
-```
-
-### Requirements Debate Flow
-
-```
-1. Each explorer shares findings from their perspective
-2. Constraints challenges user perspective: "This requirement conflicts with X constraint"
-3. Failure modes challenges similar features: "That pattern failed in Y scenario"
-4. Similar features validates user perspective: "This UX pattern works well in Z"
-5. Lead collects consensus after max 2 exchange rounds
-```
-
-### Scope Planning Team (3 perspectives)
-
-```
-Lead spawns:
-├── User Stories Planner       → actors, actions, outcomes ("As X, I want Y, so that Z")
-├── Scope Boundaries Planner   → v1 MVP, v2 deferred, out of scope, dependencies
-└── Acceptance Criteria Planner → success/failure/edge case criteria (testable)
-```
-
-### Scope Debate Flow
-
-```
-1. Each planner presents their analysis
-2. Scope challenges user stories: "This story is too broad for v1"
-3. Acceptance challenges scope: "These boundaries leave this edge case uncovered"
-4. User stories challenges acceptance: "This criterion is untestable"
-5. Lead collects consensus after max 2 exchange rounds
-```
-
-**Note**: Specification teams complement (not replace) the 3 mandatory clarification gates. User still drives all decisions via Gate 0, Gate 1, and Gate 2.
-
----
-
-## Resolution Team
-
-### Cross-Validation Resolution Team
-
-```
-Lead spawns resolvers based on batches:
-├── Resolver A → Batch 1 issues (file-a cluster)
-├── Resolver B → Batch 2 issues (file-b cluster)
-└── Resolver C → Batch 3 issues (file-c cluster)
-```
-
-### Resolution Debate Flow
-
-```
-1. Each resolver independently validates + fixes their batch
-2. Lead broadcasts: "Review each other's fixes for cross-batch conflicts"
-3. Resolver A: "My fix in file-a.ts changes the interface that Resolver B depends on"
-4. Resolver B: "Confirmed — my fix in file-b.ts imports from that interface"
-5. Resolvers coordinate the fix or escalate conflict to lead
-6. Lead collects consensus after max 2 exchange rounds
-```
-
-### When Cross-Validation Adds Value
-
-- Fixes touch shared interfaces or types
-- Resolvers modify files that import from each other
-- Batch fixes could introduce conflicting patterns
-- Large resolution sets (>5 issues across multiple files)
-
-### When to Skip Cross-Validation
-
-- All fixes are in completely independent files
-- Only 1-2 batches with no shared dependencies
-- Fixes are trivial (typos, formatting, naming)
-
----
-
-## Debug Team
-
-### Hypothesis Investigation (3-5 hypotheses)
-
-```
-Lead spawns (one per hypothesis):
-├── Hypothesis A investigator → state management / race condition
-├── Hypothesis B investigator → configuration / environment
-├── Hypothesis C investigator → edge case / input validation
-└── Hypothesis D investigator → dependency / version issue
-```
-
-### Debug Debate Flow
-
-```
-1. Each investigator gathers evidence for their hypothesis
-2. Lead broadcasts: "Present evidence. Disprove each other."
-3. Investigator A: "Found race condition at file:line"
-4. Investigator B: "My config theory is disproved by A's evidence"
-5. Investigator C: "A's race condition doesn't explain the timing"
-6. Converge on surviving hypothesis with strongest evidence
-```
-
----
-
-## Team Size Guidelines
-
-| Scenario | Min | Max | Rationale |
-|----------|-----|-----|-----------|
-| Quick review | 2 | 3 | Focused, low cost |
-| Full review | 4 | 5 | Core perspectives |
-| Exploration | 3 | 4 | Diminishing returns beyond 4 |
-| Planning | 2 | 3 | Too many cooks |
-| Specification (explore) | 3 | 4 | Requirements need diverse perspectives |
-| Specification (scope) | 2 | 3 | Scope planning benefits from focus |
-| Resolution | 2 | 4 | One per independent batch |
-| Debugging | 3 | 5 | One per viable hypothesis |
-| Parallel coding | 2 | 3 | Merge complexity grows fast |