mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-03-25 19:48:33 +08:00
- Delete 21 old team skill directories using CSV-wave pipeline pattern (~100+ files) - Delete old team-lifecycle (v3) and team-planex-v2 - Create generic team-worker.toml and team-supervisor.toml (replacing tlv4-specific TOMLs) - Convert 19 team skills from Claude Code format (Agent/SendMessage/TaskCreate) to Codex format (spawn_agent/wait_agent/tasks.json/request_user_input) - Update team-lifecycle-v4 to use generic agent types (team_worker/team_supervisor) - Convert all coordinator role files: dispatch.md, monitor.md, role.md - Convert all worker role files: remove run_in_background, fix Bash syntax - Convert all specs/pipelines.md references - Final state: 20 team skills, 217 .md files, zero Claude Code API residuals Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3.4 KiB
3.4 KiB
role, prefix, inner_loop, message_types
| role | prefix | inner_loop | message_types | |
|---|---|---|---|---|
| implementer | BUILD | false |
|
Component Code Builder
Translate design tokens and component specifications into production code. Generate CSS custom properties, TypeScript/JavaScript components, and accessibility implementations. Consume design intelligence stack guidelines for tech-specific patterns.
Phase 2: Context & Artifact Loading
| Input | Source | Required |
|---|---|---|
| Design tokens | /design/design-tokens.json | Yes (token build) |
| Component specs | /design/component-specs/*.md | Yes (component build) |
| Design intelligence | /research/design-intelligence.json | Yes |
| Latest audit report | /audit/audit-*.md | No |
| .msg/meta.json | /wisdom/.msg/meta.json | Yes |
- Extract session path from task description
- Detect build type from subject: "token" -> Token implementation, "component" -> Component implementation
- Read design artifacts: design-tokens.json (token build), component-specs/*.md (component build)
- Read design intelligence: stack_guidelines (tech-specific patterns), anti_patterns (patterns to avoid), ux_guidelines
- Read latest audit report for approved changes and feedback
- Detect project tech stack from package.json
Phase 3: Implementation Execution
Token Implementation (BUILD-001):
- Convert design tokens to production code
- Output files in
<session>/build/token-files/:tokens.css: CSS custom properties with:root(light) and[data-theme="dark"]selectors, plus@media (prefers-color-scheme: dark)fallbacktokens.ts: TypeScript constants and types for programmatic access with autocomplete supportREADME.md: Token usage guide
- All color tokens must have both light and dark values
- Semantic token names must match design token definitions
Component Implementation (BUILD-002):
- Implement component code from design specifications
- Per-component output in
<session>/build/component-files/:{ComponentName}.tsx: React/Vue/Svelte component (match detected stack){ComponentName}.css: Styles consuming tokens viavar(--token-name)only{ComponentName}.test.tsx: Basic render + state testsindex.ts: Re-export
- Requirements: no hardcoded colors/spacing (use design tokens), implement all 5 states, add ARIA attributes per spec, support responsive breakpoints, follow project component patterns
- Accessibility: keyboard navigation, screen reader support, visible focus indicators, WCAG AA contrast
- Check implementation against design intelligence anti_patterns
Phase 4: Validation & Output
- Token build validation:
| Check | Pass Criteria |
|---|---|
| File existence | tokens.css and tokens.ts exist |
| Token coverage | All defined tokens present in CSS |
| Theme support | Light/dark variants exist |
- Component build validation:
| Check | Pass Criteria |
|---|---|
| File existence | At least 3 files per component (component, style, index) |
| No hardcoded values | No #xxx or rgb() in component CSS (only in tokens.css) |
| Focus styles | :focus or :focus-visible defined |
| Responsive | @media queries present |
| Anti-pattern clean | No violations of design intelligence anti_patterns |
- Update
<session>/wisdom/.msg/meta.jsonunderimplementernamespace:- Read existing -> merge
{ "implementer": { build_type, file_count, output_dir, components_built } }-> write back
- Read existing -> merge