devflow-kit 0.9.0 → 1.0.0

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

@@ -0,0 +1,122 @@
+# 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-implement/skills/agent-teams/references/team-patterns.md

@@ -0,0 +1,217 @@
+# 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 |

package/plugins/devflow-implement/skills/frontend-design/SKILL.md

@@ -0,0 +1,254 @@
+---
+name: frontend-design
+description: This skill should be used when the user asks to "design a component", "pick colors", "improve typography", "fix spacing", "choose a layout", or discusses visual design, CSS, styling decisions, or responsive interfaces. Provides patterns for typography scales, color systems, spacing, and production-grade UI design.
+user-invocable: false
+allowed-tools: Read, Grep, Glob
+activation:
+  file-patterns:
+    - "**/*.tsx"
+    - "**/*.jsx"
+    - "**/*.css"
+    - "**/*.scss"
+    - "**/tailwind.config.*"
+  exclude:
+    - "node_modules/**"
+    - "**/*.test.*"
+    - "**/*.spec.*"
+---
+
+# Frontend Design Patterns
+
+Reference for intentional visual design, following Anthropic's 4 Dimensions framework. Focus on deliberate aesthetic choices over default slop.
+
+## Iron Law
+
+> **AESTHETICS MUST HAVE INTENT**
+>
+> Every visual choice must be justified. Default styles, copied gradients, and
+> "looks modern" are not justifications. If you cannot explain why a specific
+> font, color, or animation exists, it's design debt. Good design is invisible
+> because it serves purpose, not because it copies trends.
+
+## When This Skill Activates
+
+- Creating or styling UI components
+- Reviewing CSS, Tailwind, or styled-components
+- Discussing typography, color schemes, or layouts
+- Building design systems or component libraries
+- Evaluating visual consistency
+
+---
+
+## 1. Typography Intent
+
+### Font Personality Must Match Product
+
+```css
+/* CORRECT: Deliberate choice with rationale */
+/* Product: Developer documentation - needs readability */
+font-family: 'IBM Plex Mono', 'JetBrains Mono', monospace;
+
+/* VIOLATION: Inter because "everyone uses it" */
+font-family: 'Inter', sans-serif; /* Why? What does it communicate? */
+```
+
+### Clear Hierarchy
+
+```css
+/* CORRECT: Distinct visual hierarchy */
+.heading-1 { font-size: 2.5rem; font-weight: 700; letter-spacing: -0.02em; }
+.heading-2 { font-size: 1.75rem; font-weight: 600; letter-spacing: -0.01em; }
+.body { font-size: 1rem; font-weight: 400; line-height: 1.6; }
+.caption { font-size: 0.875rem; font-weight: 400; color: var(--text-muted); }
+
+/* VIOLATION: No hierarchy - everything similar */
+.text { font-size: 1rem; }
+.text-big { font-size: 1.1rem; }
+```
+
+### Line Height Tuning
+
+```css
+/* CORRECT: Context-appropriate line height */
+.heading { line-height: 1.2; }  /* Tight for short headings */
+.body { line-height: 1.6; }     /* Comfortable for reading */
+.code { line-height: 1.4; }     /* Balanced for code */
+
+/* VIOLATION: Universal line height */
+* { line-height: 1.5; }
+```
+
+---
+
+## 2. Color and Theme
+
+### Deliberate Palette
+
+```css
+/* CORRECT: Semantic color system with clear purpose */
+:root {
+  --color-primary: #0066cc;     /* Actions, links - trust/stability */
+  --color-success: #0a6640;     /* Positive outcomes */
+  --color-warning: #b35900;     /* Attention needed */
+  --color-error: #c41e3a;       /* Errors, destructive */
+  --color-neutral-900: #1a1a1a; /* Primary text */
+  --color-neutral-500: #6b7280; /* Secondary text */
+  --color-neutral-100: #f5f5f5; /* Backgrounds */
+}
+
+/* VIOLATION: Random hex values without system */
+.button { background: #4f46e5; }
+.link { color: #3b82f6; }
+.alert { background: #ef4444; }
+```
+
+### Light/Dark as First-Class
+
+```css
+/* CORRECT: Design for both modes intentionally */
+:root {
+  --bg-primary: #ffffff;
+  --text-primary: #1a1a1a;
+}
+
+@media (prefers-color-scheme: dark) {
+  :root {
+    --bg-primary: #0f0f0f;
+    --text-primary: #f5f5f5;
+  }
+}
+
+/* VIOLATION: Dark mode as afterthought */
+.dark-mode { filter: invert(1); }
+```
+
+---
+
+## 3. Motion and Animation
+
+### State Communication
+
+```css
+/* CORRECT: Animation communicates state change */
+.button {
+  transition: transform 0.1s ease-out, background 0.15s ease;
+}
+.button:active {
+  transform: scale(0.98); /* Feedback: "I received your click" */
+}
+
+/* VIOLATION: Animation for decoration */
+.button {
+  animation: pulse 2s infinite; /* Why is it pulsing? */
+}
+```
+
+### Consistent Timing
+
+```css
+/* CORRECT: Timing scale for consistency */
+:root {
+  --duration-fast: 100ms;   /* Micro-interactions */
+  --duration-normal: 200ms; /* Standard transitions */
+  --duration-slow: 300ms;   /* Complex animations */
+  --easing-default: cubic-bezier(0.4, 0, 0.2, 1);
+}
+
+/* VIOLATION: Random durations */
+.modal { transition: 0.35s; }
+.dropdown { transition: 0.2s; }
+.tooltip { transition: 0.15s; }
+```
+
+### Appropriate Duration
+
+| Element | Duration | Rationale |
+|---------|----------|-----------|
+| Hover states | 100-150ms | Immediate feedback |
+| Dropdowns | 150-200ms | Quick but perceptible |
+| Modals | 200-300ms | Significant context change |
+| Page transitions | 300-500ms | Major navigation |
+
+---
+
+## 4. Spatial Composition
+
+### Consistent Spacing Scale
+
+```css
+/* CORRECT: Mathematical spacing system */
+:root {
+  --space-1: 0.25rem;  /* 4px */
+  --space-2: 0.5rem;   /* 8px */
+  --space-3: 0.75rem;  /* 12px */
+  --space-4: 1rem;     /* 16px */
+  --space-6: 1.5rem;   /* 24px */
+  --space-8: 2rem;     /* 32px */
+  --space-12: 3rem;    /* 48px */
+}
+
+/* VIOLATION: Magic numbers */
+.card { padding: 18px 22px; margin-bottom: 13px; }
+```
+
+### Whitespace With Purpose
+
+```css
+/* CORRECT: Whitespace creates visual grouping */
+.section { margin-bottom: var(--space-12); }
+.section-header { margin-bottom: var(--space-6); }
+.paragraph { margin-bottom: var(--space-4); }
+
+/* VIOLATION: Uniform spacing (no hierarchy) */
+* + * { margin-top: 1rem; }
+```
+
+---
+
+## AI Slop Detection
+
+Flag these patterns - they indicate thoughtless defaults:
+
+| Pattern | Problem |
+|---------|---------|
+| Purple-to-pink gradient | Copied from templates without brand justification |
+| `font-family: Inter` without rationale | Default choice, not intentional |
+| Everything centered | No visual hierarchy or flow |
+| `rounded-xl` on everything | Border radius should vary by context |
+| Shadows on everything | Elevation should be meaningful |
+| Generic "hero section" with gradient | Template copy, not designed |
+| `animate-pulse` on buttons | Meaningless attention grab |
+| Glassmorphism everywhere | Trend following, not purpose |
+
+---
+
+## Extended References
+
+For additional patterns and examples:
+- `references/violations.md` - Extended design anti-patterns
+- `references/patterns.md` - Extended correct patterns
+- `references/detection.md` - Grep patterns for finding issues
+
+---
+
+## Severity Guidelines
+
+| Severity | Criteria |
+|----------|----------|
+| CRITICAL | No design system (random values everywhere) |
+| HIGH | Inconsistent spacing/typography, broken dark mode |
+| MEDIUM | Missing hover states, poor visual hierarchy |
+| LOW | Could improve animation timing, minor inconsistencies |
+
+---
+
+## Checklist
+
+- [ ] Typography choices have documented rationale
+- [ ] Color palette is semantic (not arbitrary hex)
+- [ ] Dark/light modes both intentionally designed
+- [ ] Spacing follows consistent scale
+- [ ] Animations communicate state (not decoration)
+- [ ] No "AI slop" patterns present
+- [ ] Visual hierarchy is clear
+- [ ] Responsive behavior is intentional