Implementation Coordination Skill
Coordinate implementation phase by breaking down work, delegating to engineers, and maintaining quality standards.
When to Use
- Starting implementation phase (after Plan completes)
- Running in parallel with Test and Package phases
- Need to delegate implementation tasks
- Managing multiple engineering tasks simultaneously
Quick Reference
# Review GitHub issue for implementation tasks
gh issue view <number> --json body --jq '.body'
# Verify code quality
pixi run mojo test -I . tests/
pixi run mojo build -I . <module>
just pre-commit-all
# Check for warnings (zero-warnings policy)
# Any output = fix before committing
Workflow
- Review plan specifications - Understand deliverables and success criteria
- Break into tasks - Create granular implementation work items
- Delegate by complexity:
- Senior Engineer: Complex algorithms, SIMD, memory management
- Engineer: Standard implementations, business logic
- Junior Engineer: Boilerplate, simple helpers, type definitions
- Monitor progress - Check completion status, unblock issues
- Code review - Verify quality, standards, tests, documentation
- Final checks - Format, lint, test coverage, no warnings
Delegation Matrix
| Complexity |
Task |
Engineer |
| High |
Complex algorithms, SIMD optimizations |
Senior |
| High |
Memory management, ownership patterns |
Senior |
| Medium |
Standard functions, business logic |
Standard |
| Medium |
Data structures, operations |
Standard |
| Low |
Boilerplate, type aliases |
Junior |
| Low |
Simple helpers, constants |
Junior |
Mojo Implementation Standards
Function definitions:
# High-performance critical
fn simd_add[dtype: DType](a: Tensor[dtype], b: Tensor[dtype]) -> Tensor[dtype]:
"""SIMD-optimized addition."""
pass
# Flexible/Python interop
def load_model(path: String) -> PythonObject:
pass
Memory management:
# Transfer ownership
fn process(owned data: Tensor) -> Tensor:
return data^
# Read-only access
fn analyze(borrowed data: Tensor):
pass
# Mutable access (Mojo v0.26.1+)
fn modify(mut data: Tensor):
pass
Quality Checklist
Before code review approval:
Phase Dependencies
- Input from: Plan phase (specifications and deliverables)
- Parallel with: Test phase (TDD) and Package phase
- Precedes: Cleanup phase (after parallel phases complete)
Output Location
- Implementation:
/shared/<module>/, /examples/, /tooling/
- Documentation: GitHub issue comments
- Issue updates: Track progress, blockers, learnings via
gh issue comment
Error Handling
| Blocker |
Resolution |
| Unclear requirements |
Escalate to Design for clarification |
| Performance issues |
Consult Performance Specialist |
| Test failures |
Debug with Test Specialist |
| Missing dependencies |
Update Plan, communicate status |
| Compiler warnings |
Fix immediately (zero-warnings policy) |
References
CLAUDE.md - "Mojo Syntax Standards" (current v0.26.1+ patterns)
CLAUDE.md - "Critical Pre-Flight Checklist" (before committing)
CLAUDE.md - "Common Mistakes to Avoid" (64+ test failure learnings)
notes/review/mojo-test-failure-learnings.md - Real implementation patterns
Key Principle: Implement to make tests pass, not the other way around.
1---2name: phase-implement3description: Coordinate implementation phase by delegating tasks and ensuring code quality. Use during implementation phase to manage engineer tasks.4---5
6# Implementation Coordination Skill
7
8Coordinate implementation phase by breaking down work, delegating to engineers, and maintaining quality standards.
9
10## When to Use
11
12- Starting implementation phase (after Plan completes)
13- Running in parallel with Test and Package phases
14- Need to delegate implementation tasks
15- Managing multiple engineering tasks simultaneously
16
17## Quick Reference
18
19```bash
20# Review GitHub issue for implementation tasks
21gh issue view <number> --json body --jq '.body'
22
23# Verify code quality
24pixi run mojo test -I . tests/
25pixi run mojo build -I . <module>
26just pre-commit-all
27
28# Check for warnings (zero-warnings policy)
29# Any output = fix before committing
30```
31
32## Workflow
33
341. **Review plan specifications** - Understand deliverables and success criteria
352. **Break into tasks** - Create granular implementation work items
363. **Delegate by complexity**:
37 - **Senior Engineer**: Complex algorithms, SIMD, memory management
38 - **Engineer**: Standard implementations, business logic
39 - **Junior Engineer**: Boilerplate, simple helpers, type definitions
404. **Monitor progress** - Check completion status, unblock issues
415. **Code review** - Verify quality, standards, tests, documentation
426. **Final checks** - Format, lint, test coverage, no warnings
43
44## Delegation Matrix
45
46| Complexity | Task | Engineer |
47|------------|------|----------|
48| High | Complex algorithms, SIMD optimizations | Senior |
49| High | Memory management, ownership patterns | Senior |
50| Medium | Standard functions, business logic | Standard |
51| Medium | Data structures, operations | Standard |
52| Low | Boilerplate, type aliases | Junior |
53| Low | Simple helpers, constants | Junior |
54
55## Mojo Implementation Standards
56
57**Function definitions**:
58
59```mojo
60# High-performance critical
61fn simd_add[dtype: DType](a: Tensor[dtype], b: Tensor[dtype]) -> Tensor[dtype]:
62 """SIMD-optimized addition."""
63 pass
64
65# Flexible/Python interop
66def load_model(path: String) -> PythonObject:
67 pass
68```
69
70**Memory management**:
71
72```mojo
73# Transfer ownership
74fn process(owned data: Tensor) -> Tensor:
75 return data^
76
77# Read-only access
78fn analyze(borrowed data: Tensor):
79 pass
80
81# Mutable access (Mojo v0.26.1+)
82fn modify(mut data: Tensor):
83 pass
84```
85
86## Quality Checklist
87
88Before code review approval:
89
90- [ ] All tests passing
91- [ ] 80% test coverage minimum
92- [ ] No compiler warnings (zero-warnings policy)
93- [ ] `pixi run mojo format` applied
94- [ ] Docstrings complete
95- [ ] No TODOs/FIXMEs (or documented)
96- [ ] Performance meets requirements
97- [ ] Follows Mojo syntax standards (Mojo v0.26.1+)
98
99## Phase Dependencies
100
101- **Input from**: Plan phase (specifications and deliverables)
102- **Parallel with**: Test phase (TDD) and Package phase
103- **Precedes**: Cleanup phase (after parallel phases complete)
104
105## Output Location
106
107- **Implementation**: `/shared/<module>/`, `/examples/`, `/tooling/`
108- **Documentation**: GitHub issue comments
109- **Issue updates**: Track progress, blockers, learnings via `gh issue comment`
110
111## Error Handling
112
113| Blocker | Resolution |
114|---------|-----------|
115| Unclear requirements | Escalate to Design for clarification |
116| Performance issues | Consult Performance Specialist |
117| Test failures | Debug with Test Specialist |
118| Missing dependencies | Update Plan, communicate status |
119| Compiler warnings | Fix immediately (zero-warnings policy) |
120
121## References
122
123- `CLAUDE.md` - "Mojo Syntax Standards" (current v0.26.1+ patterns)
124- `CLAUDE.md` - "Critical Pre-Flight Checklist" (before committing)
125- `CLAUDE.md` - "Common Mistakes to Avoid" (64+ test failure learnings)
126- `notes/review/mojo-test-failure-learnings.md` - Real implementation patterns
127
128---
129
130**Key Principle**: Implement to make tests pass, not the other way around.