devlyn-cli 1.14.0 → 2.0.0

package/config/skills/devlyn:ideate/references/challenge-rubric.md

@@ -1,122 +0,0 @@
-# CHALLENGE Rubric (single source of truth)
-
-## Contents
-- Context — this is a planning rubric
-- The 5 axes (NO WORKAROUND, NO GUESSWORK, NO OVERENGINEERING, WORLD-CLASS BEST PRACTICE, OPTIMIZED)
-- Hard rule — respect explicit user intent
-- Finding format
-- Examples (good vs bad findings, plus a detour-sequencing example)
-
-The 5-axis rubric applied in Phase 3.5 CHALLENGE of `devlyn:ideate`. Both the solo Claude pass and the Codex critic pass (on `--engine auto`) use this file — there is exactly one definition of the rubric, and `SKILL.md` instructs both passes to read it directly from here.
-
-The rubric exists because plans produced in a single pass, by a single model, in a single conversation almost always fail at least one axis somewhere. The user's historical experience: every time they asked "is this really no-workaround, no-guesswork, no-overengineering, world-class, optimized?", the honest answer was no. This phase makes the answer honestly yes before the user even has to ask.
-
-## Context — this is a PLANNING rubric, not a code rubric
-
-This rubric judges the shape of the roadmap: what items exist, in what order, why. It does NOT judge implementation details, code style, or abstractions in code. "Overengineering" here means overengineering the plan, not overengineering a function. When applying it, keep asking: *is this the most direct, optimized path from the user's stated problem to a working outcome?*
-
-## The 5 axes
-
-### 1. NO WORKAROUND
-
-Does the item solve the actual problem directly, or does it route around a missing capability? If the direct path is "build X" and the item is "work around not having X", it fails.
-
-Canonical failure pattern: the user asks for a feature that papers over a missing foundation. Building the feature adds an item to the plan without solving the real problem, and often makes the real problem harder to fix later.
-
-### 2. NO GUESSWORK
-
-Every requirement must be grounded in something the user explicitly confirmed, or in something verifiable from the problem framing. Silent assumptions, "I think the user probably wants...", and requirements invented to fill gaps all fail.
-
-Canonical failure pattern: vague user input ("improve the dashboard") leads to a fully-specified plan full of invented detail. Correct handling is to mark every assumed fact as [ASSUMED], ask clarifying questions, and keep the plan minimal until the user fills in the gaps.
-
-### 3. NO OVERENGINEERING (planning-stage)
-
-The plan fails this axis when it contains any of:
-
-- **Luxury items** — polish, theming, animations, nice-to-haves that do not serve the stated problem. A polish/theming item in Phase 1 of a tool that does not yet solve its core job.
-- **Filler items** — items added to pad a phase or make the plan feel complete. If an item has no testable requirement a real user would notice if absent, it is filler.
-- **Detour sequencing** — the plan takes the long way around when a direct route exists. Three items building toward X when one item could deliver X. Separate scaffold / store / deploy items when they could be bundled into the actual feature they enable.
-- **Roadmap workarounds masquerading as features** — see axis 1. The same failure can fire on axis 1 (paper-over) and axis 3 (padding the roadmap with the workaround).
-
-The question to ask for every item: *"Is this the most direct, optimized path to the stated goal, or are we decorating / detouring / papering over?"*
-
-### 4. WORLD-CLASS BEST PRACTICE
-
-Would a senior team at a top company structure the roadmap this way for this kind of product today? If a known-good pattern exists for sequencing or decomposing this kind of problem, name it and use it.
-
-Canonical failure pattern: the plan uses a familiar-but-mediocre decomposition when a better-known-good pattern exists for the specific problem type. Example: using manual export/import for cross-device sync when autosave + cloud draft storage is the standard pattern across mainstream editing tools (Notion, Linear, Gmail, Google Docs).
-
-### 5. OPTIMIZED
-
-Does the sequencing minimize wait time, front-load risk, and ship user-visible value at every phase boundary? Dead phases — phases that are pure setup with no visible win for a real user — are a fail.
-
-Canonical failure pattern: Phase 1 is entirely infrastructure (scaffold, models, deploy) and the first user-facing win arrives in Phase 2. Better: Phase 1 ships one thin vertical slice that a real user can use, even if it is small.
-
-## Hard rule — respect explicit user intent
-
-The rubric is a tool to prevent drift from quality, not a tool to override the user. If the user has explicitly and clearly stated a preference ("I want X, not Y"), the rubric does not silently replace X with Y. Instead:
-
-- Run the rubric as normal.
-- If an axis flags X, do not rewrite the plan. Record the finding and surface it to the user as an open question: "The rubric flags X on [axis] because [reason]. You explicitly asked for X — confirm you want to proceed, or consider [alternative]."
-- The user makes the call. The rubric's job is to make the tradeoff visible, not to make the decision.
-
-This rule exists because the 5-axis rubric is an opinionated lens, and opinionated lenses are wrong sometimes. The user's stated intent is ground truth when it is explicit. The rubric is ground truth only for things the user did not explicitly decide.
-
-## Finding format
-
-For every item that fails any axis, produce a finding in this exact format:
-
-```
-Severity: CRITICAL / HIGH / MEDIUM / LOW
-Quote: [copy the specific item title or line you are critiquing — one line]
-Axis: [which of the five]
-Why it fails: [one sentence]
-Fix: [one concrete revision — not "reconsider X", say what to do instead]
-```
-
-For the plan as a whole, give a one-line pass/fail per axis with one-sentence reasoning.
-
-End with a verdict: `PASS / PASS WITH MINOR FIXES / FAIL — REVISION REQUIRED`.
-
-The Quote field is load-bearing. It anchors each finding to a specific line in the plan, which prevents the common failure mode of generic unanchored critiques ("too much in Phase 1", "consider refactoring"). Anchored findings are actionable; unanchored findings are noise.
-
-## Examples
-
-<example>
-BAD finding (too vague, not actionable):
-  Severity: HIGH
-  Axis: NO OVERENGINEERING
-  Why: Phase 1 has too much.
-  Fix: Reduce scope.
-
-GOOD finding (anchored, specific, actionable):
-  Severity: HIGH
-  Quote: "1.3 — Theme customization (light/dark/custom accent colors)"
-  Axis: NO OVERENGINEERING (luxury item)
-  Why it fails: The product does not yet solve its core job of letting users save a session; theming is a decoration item that does not move the primary problem forward.
-  Fix: Move 1.3 to backlog. Phase 1 is shorter by one item. Revisit theming only after the core save flow is shipped and used.
-</example>
-
-<example>
-BAD finding:
-  Severity: HIGH
-  Axis: NO WORKAROUND
-  Why: Item 2.1 is a workaround.
-  Fix: Do it properly.
-
-GOOD finding:
-  Severity: CRITICAL
-  Quote: "2.1 — Export/import session as JSON file so users can move work between devices"
-  Axis: NO WORKAROUND
-  Why it fails: The real problem is cross-device sync. File export is a roadmap workaround that asks the user to do the sync manually; it adds an item to the plan without solving the stated problem, and makes the real problem harder to fix later.
-  Fix: Replace 2.1 with "Cloud-backed session storage" as a direct cross-device solution. If cloud storage is out of scope for the current phase, explicitly defer cross-device sync to a later phase rather than shipping a manual workaround as if it were the feature.
-</example>
-
-<example>
-Detour sequencing finding:
-  Severity: MEDIUM
-  Quote: "Phase 1: 1.1-scaffold, 1.2-data-store, 1.3-log-today, 1.4-streak-display, 1.5-history-view, 1.6-manage-habits, 1.7-deploy"
-  Axis: NO OVERENGINEERING (detour sequencing)
-  Why it fails: Scaffold, data store, streak display, and deploy are not features a user would notice as separate items — they are implementation steps of the three actual user capabilities (log a habit, see streak, see history). Splitting them into standalone roadmap items pads the plan without delivering value at each boundary.
-  Fix: Collapse Phase 1 to 2 items: "1.1 — Log a habit and see streak" (bundles scaffold + store + log + streak), "1.2 — History view". Deploy is part of each item's done criteria, not a standalone item. Result: 7 items → 2 items, same delivered scope.
-</example>

package/config/skills/devlyn:ideate/references/templates/item-spec.md

@@ -1,90 +0,0 @@
-# Item Spec Template (Auto-Resolve-Ready)
-
-Generate one file per roadmap item at `docs/roadmap/phase-N/{id}-{name}.md`. This is the most critical template — each spec becomes the direct input to `/devlyn:auto-resolve`.
-
----
-
-```markdown
----
-id: "[phase.item]"
-title: "[Feature Name]"
-phase: [N]
-status: planned
-priority: [high | medium | low]
-complexity: [low | medium | high]
-depends-on: []
----
-
-# [id] [Feature Name]
-
-## Context
-<!-- 2-3 sentences MAX. Just enough for auto-resolve to understand WHY this exists. -->
-<!-- Extract only the relevant context from the vision — don't make the implementation agent read the full vision document. -->
-[Project] does [what]. This feature [enables/improves/fixes] [specific user capability].
-
-## Customer Frame
-<!-- One sentence. When [situation], [user] wants to [motivation] so they can [outcome]. -->
-<!-- Use this to resolve ambiguous requirements: prefer the behavior that best serves this user outcome, and do not add capabilities outside this frame. -->
-
-## Objective
-<!-- One sentence: what the user can do after this is implemented. -->
-
-## Requirements
-<!-- These become auto-resolve's done-criteria. Quality of these requirements directly determines implementation quality. -->
-- [ ] [Specific, testable requirement]
-- [ ] [Specific, testable requirement]
-- [ ] [Specific, testable requirement]
-- [ ] ...
-
-## Constraints
-<!-- Technical constraints WITH reasoning. Implementation agents respect constraints significantly better when they understand the motivation. -->
-- [Constraint] — Why: [reason]
-- ...
-
-## Out of Scope
-<!-- What this item explicitly does NOT include. This prevents auto-resolve from over-building. -->
-- [Feature/behavior] ([where/when it will be addressed, e.g., "Phase 2, item 2.3"])
-- ...
-
-## Architecture Notes
-<!-- Technical context that helps implementation. Reference decision records when applicable. -->
-<!-- Remove this section if the implementation is straightforward. -->
-
-## Dependencies
-- **Internal**: [Other roadmap items that must exist first, e.g., "1.1 User Auth"]
-- **External**: [APIs, services, credentials, third-party setup needed]
-
-## Verification
-<!-- How to confirm this works. Overlaps with Requirements but focuses on observable user-facing behavior. -->
-- [ ] [Observable verification step]
-- [ ] ...
-```
-
-## Quality Criteria
-
-Before writing a spec, verify each requirement against these criteria:
-
-**Testable**: Can a test assert this, or can a human verify it in under 30 seconds?
-- Bad: "The dashboard loads quickly"
-- Good: "Dashboard initial render completes within 2 seconds on 3G throttled connection"
-
-**Specific**: Is there exactly one interpretation of what "done" means?
-- Bad: "Handles errors gracefully"
-- Good: "Failed API calls display an error banner with the message and a retry button"
-
-**Scoped**: Does this belong to THIS item only?
-- Bad: "The app supports multiple languages" (cross-cutting concern, not a single item)
-- Good: "The settings page displays a language selector with EN and KO options"
-
-**Self-contained**: Can auto-resolve implement this without reading VISION.md or ROADMAP.md?
-- If the Context section references principles without explaining them, it's not self-contained
-- The spec should carry its own context, not point to other documents
-
-## When a Spec Isn't Ready
-
-If you can't write specific requirements for an item, it needs one of:
-1. **More exploration** — go back to Phase 2 for this item
-2. **Splitting** — the item is too large; break it into smaller, specifiable pieces
-3. **A spike** — mark it as a research task whose output is a proper spec
-
-Never generate a spec with vague requirements just to fill the roadmap. A backlog item with "needs exploration" is more honest and more useful than a spec with untestable requirements.

package/config/skills/devlyn:implement-ui/SKILL.md

@@ -1,466 +0,0 @@
-Build or improve UI by assembling a specialized Agent Team. Each teammate brings a different design and engineering perspective — component architecture, interaction design, accessibility, and visual fidelity — to produce production-quality UI that perfectly matches the design system.
-
-Works for both:
-- **New UI**: Build pages/components from scratch using the design system
-- **Improve existing UI**: Audit and upgrade current implementation to match the design system
-
-<context>
-$ARGUMENTS
-</context>
-
-<prerequisites>
-This command expects a design system at `docs/design-system.md`. If it doesn't exist, tell the user:
-```
-No design system found at docs/design-system.md
-Run the pipeline first:
-  1. /devlyn:design-ui → Generate style explorations
-  2. /devlyn:design-system [style-number] → Extract design tokens
-  3. /devlyn:implement-ui → Build/improve UI (this command)
-```
-</prerequisites>
-
-<team_workflow>
-
-## Phase 1: INTAKE (You are the Build Lead — work solo first)
-
-Before spawning any teammates, assess the scope:
-
-1. **Read `docs/design-system.md`** — understand all tokens, component patterns, interactive states
-2. **Detect the project framework** — read package.json, config files, existing components to identify the stack (React, Vue, Svelte, Next.js, vanilla, Flutter, etc.)
-3. **Assess build vs improve mode**:
-
-<mode_detection>
-**Build mode** (new UI):
-- User explicitly asks to build/create pages or components
-- No existing components match the design system
-- Feature spec exists but no implementation yet
-
-**Improve mode** (existing UI):
-- User asks to improve, upgrade, or fix existing UI
-- Existing components exist but don't match the design system
-- UI looks outdated, inconsistent, or has accessibility gaps
-
-**Hybrid mode** (both):
-- Some components exist and need improvement
-- Some new components need to be built
-- Design system has been updated and implementation needs to catch up
-</mode_detection>
-
-4. **Map the work**:
-   - In build mode: read feature specs (`docs/features/`) or product spec (`docs/product-spec.md`) to understand WHAT to build
-   - In improve mode: read existing components, identify gaps between current implementation and design system
-   - List all pages/components that need work
-5. **Select teammates** using the matrix below
-
-<scope_classification>
-**Always spawn** (every build/improve):
-- component-architect
-- ux-engineer
-- accessibility-engineer
-
-**When building for web** (React, Vue, Svelte, Next.js, vanilla HTML/CSS):
-- Add: responsive-engineer
-
-**When improving existing UI** (improve or hybrid mode):
-- Add: visual-qa (to audit current implementation against design system)
-</scope_classification>
-
-Announce to the user:
-```
-[Build/Improve/Hybrid] mode for: [scope summary]
-Framework: [detected framework]
-Design System: docs/design-system.md
-Teammates: [list of roles being spawned and why]
-```
-
-## Phase 2: TEAM ASSEMBLY
-
-Use the Agent Teams infrastructure:
-
-1. **TeamCreate** with name `build-{scope-slug}` (e.g., `build-landing-page`, `build-improve-dashboard`)
-2. **Spawn teammates** using the `Task` tool with `team_name` and `name` parameters. Each teammate is a separate Claude instance.
-3. **TaskCreate** tasks for each teammate — include the design system path, framework info, and their specific mandate.
-4. **Assign tasks** using TaskUpdate with `owner` set to the teammate name.
-
-**IMPORTANT**: Do NOT hardcode a model. All teammates inherit the user's active model automatically.
-
-### Teammate Prompts
-
-When spawning each teammate via the Task tool, use these prompts:
-
-<component_architect_prompt>
-You are the **Component Architect** on an Agent Team building/improving UI.
-
-**Your perspective**: Frontend architect who turns design systems into component trees
-**Your mandate**: Define the component hierarchy, map design tokens to framework primitives, and plan the implementation structure.
-
-**Your process**:
-1. Read `docs/design-system.md` thoroughly — understand every token and component pattern
-2. Read the project's existing components and framework setup
-3. If **build mode**: Design the component tree from scratch
-4. If **improve mode**: Audit existing components against the design system, identify gaps
-
-**Your deliverable**: Send a message to the team lead with:
-
-1. **Token mapping**: How each design token maps to the framework
-   - Colors → CSS variables / theme object / tokens file
-   - Typography → text style utilities or components
-   - Spacing → spacing scale or utilities
-   - Shadows, radii, motion → where they live in code
-
-2. **Component tree**: For each component pattern in the design system:
-   - Component name and file path
-   - Props/API surface
-   - Which design tokens it uses
-   - Variants (if any)
-   - Composition (what it's made of)
-
-3. **Shared patterns**:
-   - Base layout component (container, section wrapper)
-   - Animation utilities (reveal, hover, scroll-triggered)
-   - Theme provider / token distribution strategy
-
-4. **In improve mode, additionally**:
-   - Gap analysis: what exists vs what the design system defines
-   - Files to modify with specific changes needed
-   - Files to create
-
-**Tools available**: Read, Grep, Glob, Bash (read-only)
-
-Read the team config at ~/.claude/teams/{team-name}/config.json to discover teammates. Share your component tree with other teammates so they can provide feedback.
-</component_architect_prompt>
-
-<ux_engineer_prompt>
-You are the **UX Engineer** on an Agent Team building/improving UI.
-
-**Your perspective**: Interaction designer who makes interfaces feel alive and intuitive
-**Your mandate**: Define every interaction pattern, state transition, animation, and micro-interaction based on the design system's motion and interactive state specs.
-
-**Your process**:
-1. Read `docs/design-system.md` — focus on Motion, Interactive States, and Effects sections
-2. Read existing components (if improve mode) to audit current interaction quality
-3. Define interaction specifications for every interactive element
-
-**Your deliverable**: Send a message to the team lead with:
-
-1. **State machine for each interactive component**:
-   ```
-   Button: idle → hover → active → focus → disabled
-   Card: idle → hover (lift + shadow) → active
-   Modal: closed → entering → open → exiting → closed
-   ```
-
-2. **Animation specs** (derived from design system motion tokens):
-   - Page load sequence: which elements appear in what order, with what delays
-   - Scroll-triggered reveals: threshold, animation type, stagger
-   - Hover/focus transitions: property, duration, easing (exact cubic-bezier from design system)
-   - Route transitions (if SPA)
-
-3. **UI state coverage** — for each component/page:
-   - Loading state: skeleton, spinner, or progressive
-   - Empty state: illustration + message + CTA
-   - Error state: inline error, toast, or error page
-   - Success state: confirmation feedback
-
-4. **Micro-interactions**:
-   - Form validation feedback timing
-   - Button click feedback
-   - Toast/notification enter/exit
-   - Scroll indicator behavior
-
-5. **In improve mode, additionally**:
-   - Current interaction gaps (missing states, jarring transitions, no loading states)
-   - Specific files and lines that need interaction improvements
-
-**Tools available**: Read, Grep, Glob
-
-Read the team config at ~/.claude/teams/{team-name}/config.json to discover teammates. Coordinate with the Component Architect on component state management.
-</ux_engineer_prompt>
-
-<accessibility_engineer_prompt>
-You are the **Accessibility Engineer** on an Agent Team building/improving UI.
-
-**Your perspective**: Accessibility specialist ensuring WCAG 2.1 AA compliance
-**Your mandate**: Every component must be usable by everyone — keyboard users, screen reader users, users with low vision, motor impairments, and cognitive differences.
-
-**Your process**:
-1. Read `docs/design-system.md` — check color contrast ratios, font sizes, touch targets
-2. Read existing components (if improve mode) to audit current accessibility
-3. Define accessibility requirements for every component
-
-**Your deliverable**: Send a message to the team lead with:
-
-1. **Color contrast audit** (from design system tokens):
-   - text on background: ratio (PASS/FAIL AA)
-   - text-muted on background: ratio (PASS/FAIL AA)
-   - text on surface: ratio (PASS/FAIL AA)
-   - accent on background: ratio (PASS/FAIL AA for large text)
-   - If any FAIL: recommend adjusted color values that pass while staying close to design intent
-
-2. **Component accessibility requirements**:
-   For each component pattern in the design system:
-   - Semantic HTML element to use
-   - Required ARIA attributes
-   - Keyboard interaction pattern (what keys do what)
-   - Focus management (focus order, focus trapping for modals)
-   - Screen reader announcements (aria-live regions, status updates)
-
-3. **Motion accessibility**:
-   - `prefers-reduced-motion` handling for every animation
-   - Which animations are decorative (can be removed) vs functional (should simplify)
-
-4. **Touch and pointer**:
-   - Minimum touch target sizes (44x44px)
-   - Adequate spacing between interactive elements
-   - Hover-only interactions that need touch alternatives
-
-5. **Content accessibility**:
-   - Image alt text strategy
-   - Heading hierarchy requirements
-   - Link text that makes sense out of context
-   - Form label associations
-
-6. **In improve mode, additionally**:
-   - Current a11y violations with severity and file:line
-   - Quick wins vs structural fixes
-
-**Tools available**: Read, Grep, Glob, Bash (for running any a11y audit tools)
-
-Read the team config at ~/.claude/teams/{team-name}/config.json to discover teammates. Flag accessibility concerns that affect the Component Architect's component design.
-</accessibility_engineer_prompt>
-
-<responsive_engineer_prompt>
-You are the **Responsive Engineer** on an Agent Team building/improving UI for web.
-
-**Your perspective**: Responsive design specialist ensuring the UI works beautifully across all screen sizes
-**Your mandate**: Define the responsive strategy — breakpoints, fluid typography, layout shifts, and touch adaptation.
-
-**Your process**:
-1. Read `docs/design-system.md` — understand spacing, typography, and layout patterns
-2. Read existing components (if improve mode) to audit current responsive behavior
-3. Define responsive specifications
-
-**Your deliverable**: Send a message to the team lead with:
-
-1. **Breakpoint strategy**:
-   - Recommended breakpoints (mobile-first: 640px, 768px, 1024px, 1280px, or project convention)
-   - Which components change at which breakpoints
-
-2. **Layout transformations**:
-   For each page section / component grid:
-   - Desktop layout (columns, gaps)
-   - Tablet layout (columns, gaps, reordering)
-   - Mobile layout (stacking, gaps, padding reduction)
-
-3. **Typography scaling**:
-   - Font size adjustments per breakpoint (use clamp() where supported)
-   - Line-height adjustments for mobile readability
-
-4. **Spacing adjustments**:
-   - Section padding per breakpoint
-   - Card padding per breakpoint
-   - Gap reductions for mobile
-
-5. **Component adaptations**:
-   - Navigation: desktop → hamburger/drawer
-   - Cards: grid → single column
-   - Tables: horizontal scroll or card transformation
-   - Modals: full-screen on mobile vs centered on desktop
-
-6. **Touch targets**:
-   - Minimum 44x44px for all interactive elements on touch devices
-   - Adequate spacing between tappable items
-
-**Tools available**: Read, Grep, Glob
-
-Read the team config at ~/.claude/teams/{team-name}/config.json to discover teammates. Coordinate with the Component Architect on responsive component variants.
-</responsive_engineer_prompt>
-
-<visual_qa_prompt>
-You are the **Visual QA** on an Agent Team improving existing UI.
-
-**Your perspective**: Design system compliance auditor who catches every deviation
-**Your mandate**: Compare the current implementation against the design system and produce a detailed gap report.
-
-**Your process**:
-1. Read `docs/design-system.md` — internalize every token value and component pattern
-2. Read ALL existing component/page files
-3. For each file, compare actual values against design system values
-
-**Your deliverable**: Send a message to the team lead with:
-
-1. **Token compliance audit**:
-   For each design token category (colors, typography, spacing, shadows, radii, motion):
-   - Which tokens are correctly applied
-   - Which tokens are wrong (expected vs actual, file:line)
-   - Which tokens are missing (hardcoded values instead of tokens)
-
-2. **Component pattern compliance**:
-   For each component pattern in the design system:
-   - Does the implementation match the defined pattern?
-   - Missing hover/interactive states
-   - Missing animation/motion
-   - Wrong component structure
-
-3. **Consistency issues**:
-   - Same component styled differently in different places
-   - Hardcoded values that should use tokens
-   - Inconsistent spacing or typography
-
-4. **Priority ranking**:
-   - HIGH: Visible deviations (wrong colors, wrong fonts, missing animations)
-   - MEDIUM: Subtle deviations (slightly wrong spacing, missing hover states)
-   - LOW: Minor inconsistencies (token not used but value is correct)
-
-**Tools available**: Read, Grep, Glob
-
-Read the team config at ~/.claude/teams/{team-name}/config.json to discover teammates. Share your findings with the Component Architect so they can plan structural fixes.
-</visual_qa_prompt>
-
-## Phase 3: PARALLEL ANALYSIS
-
-All teammates work simultaneously. They will:
-- Analyze from their unique perspective
-- Message each other about cross-cutting concerns
-- Send their final specifications/findings to you (Build Lead)
-
-Wait for all teammates to report back. If a teammate goes idle after sending findings, that's normal — they're done with their analysis.
-
-## Phase 4: SYNTHESIS & PLANNING (You, Build Lead)
-
-After receiving all teammate findings:
-
-1. **Read all findings** — component tree, interaction specs, accessibility requirements, responsive strategy, and visual QA gaps (if improve mode)
-2. **Resolve conflicts** — if teammates disagree (e.g., Component Architect's structure conflicts with Accessibility Engineer's semantic requirements), prioritize accessibility
-3. **Create the implementation plan**:
-
-<implementation_plan>
-Organize work into this order:
-
-**Foundation layer** (do first):
-1. Token/theme setup — CSS variables, theme object, or tokens file from design system values
-2. Base utilities — animation helpers, layout primitives, shared styles
-
-**Component layer** (do second):
-3. Atomic components — buttons, badges, labels, icons
-4. Composite components — cards, navigation, section headers, forms
-5. Layout components — page wrapper, section containers, grid systems
-
-**Page layer** (do third):
-6. Page compositions — assemble components into pages
-7. Interaction wiring — state management, transitions, animations
-8. Responsive adjustments — breakpoint-specific overrides
-
-**Polish layer** (do last):
-9. Accessibility pass — ARIA, keyboard nav, focus management, reduced motion
-10. Animation polish — page load sequences, scroll reveals, hover states
-</implementation_plan>
-
-4. **Present the plan to the user** — enter plan mode if the scope is large (5+ components or 3+ pages). For smaller scope, proceed directly.
-
-## Phase 5: IMPLEMENTATION (You, Build Lead)
-
-<implementation_standards>
-Follow these standards for every component:
-
-**Design system fidelity**:
-- Use design tokens from docs/design-system.md — never hardcode values
-- Match component patterns exactly as defined in the design system
-- Apply interactive states with exact values from the design system's Interactive States table
-
-**Accessibility** (non-negotiable):
-- Semantic HTML first (nav, main, section, article, button, etc.)
-- All ARIA attributes from the Accessibility Engineer's spec
-- Keyboard navigation works for all interactive elements
-- `prefers-reduced-motion` media query for all animations
-- Color contrast meets WCAG 2.1 AA (fix if design system tokens fail)
-
-**Interaction quality**:
-- All UI states implemented: loading, empty, error, success
-- Animations use exact easing and duration from design system
-- Page load sequence with staggered reveals
-- Scroll-triggered animations where specified
-- Hover/focus/active states for all interactive elements
-
-**Responsive** (if web):
-- Mobile-first implementation
-- Breakpoints from Responsive Engineer's spec
-- Touch targets minimum 44x44px on touch devices
-
-**Code quality**:
-- Follow existing codebase patterns and conventions
-- Components are composable and reusable
-- No inline styles — use the token system
-- Server components where possible (Next.js)
-- Client components only when interactivity requires it
-</implementation_standards>
-
-Build in the order defined in the implementation plan. After each layer, verify it works before proceeding.
-
-## Phase 6: VALIDATION (You, Build Lead)
-
-After implementation:
-1. Run the test suite (if tests exist)
-2. Verify all design tokens are correctly applied
-3. Verify accessibility requirements are met
-4. Check responsive behavior at key breakpoints
-
-## Phase 7: CLEANUP
-
-After build is complete:
-1. Send `shutdown_request` to all teammates via SendMessage
-2. Wait for shutdown confirmations
-3. Call TeamDelete to clean up the team
-
-</team_workflow>
-
-<output_format>
-Present the result in this format:
-
-<team_build_summary>
-
-### Build Complete
-
-**Mode**: [Build / Improve / Hybrid]
-**Framework**: [detected framework]
-**Design System**: docs/design-system.md
-
-### Team Findings
-- **Component Architect**: [component tree summary — N components mapped]
-- **UX Engineer**: [interaction specs — N states defined, N animations specified]
-- **Accessibility Engineer**: [a11y requirements — contrast PASS/FAIL, N requirements defined]
-- **Responsive Engineer**: [responsive strategy — N breakpoints, key adaptations] (if spawned)
-- **Visual QA**: [N deviations found — N high, N medium, N low] (if spawned)
-
-### Implemented
-**Foundation**:
-- [token/theme file] — [N tokens mapped]
-
-**Components**:
-- [component file:line] — [what it is, key features]
-- ...
-
-**Pages** (if applicable):
-- [page file] — [what it contains]
-
-### Design System Compliance
-- [ ] All color tokens applied (no hardcoded colors)
-- [ ] Typography matches design system specs
-- [ ] Spacing uses design system values
-- [ ] Animations use design system motion tokens
-- [ ] Interactive states match design system table
-- [ ] Component patterns follow design system definitions
-
-### Accessibility
-- [ ] Color contrast WCAG 2.1 AA compliant
-- [ ] Keyboard navigation works for all interactive elements
-- [ ] ARIA attributes applied per spec
-- [ ] `prefers-reduced-motion` handled
-- [ ] Semantic HTML throughout
-
-### Next Steps
-- Run `/devlyn:team-review` to validate code quality
-- Run `/devlyn:team-resolve [feature]` to add features on top of this UI
-
-</team_build_summary>
-</output_format>