| name | review-code |
| description | Mobile-specific code review with two-stage review gates, platform conventions, and priority-ranked findings |
| source_type | command |
| source_file | commands/review-code.md |
review-code
Migrated from commands/review-code.md.
Codex packaging notes
- Claude/Telar source files remain the source of truth; this file is the generated Codex adapter.
- Skill-local support files from the original Telar skill, such as
references/... or workflow/..., are packaged beside this SKILL.md.
- Repo-root references from the original Telar file, such as
agents/..., commands/..., scripts/..., resources/..., rules/..., hooks/..., or templates/..., are packaged at this plugin root.
- The original Telar orchestration source (
skills/orchestration/...) is packaged under source/skills/orchestration/... for exact-reference lookups; all other Telar skills exist here only as the generated adapters under the plugin-root skills/ directory.
- Resolve plugin-root paths from this generated skill directory via
../.. when reading support files or running packaged scripts.
- In Codex, this skill is the replacement for the Claude slash command
/tl-telar:review-code; invoke it as $review-code or through @tl-telar.
- Do not require Claude slash-command dispatch or Claude-only environment setup before following the workflow.
- When the original command says to load
skills/orchestration/<name>, load the generated Codex skill at ../orchestration-<name>/SKILL.md first. The original source copy also exists under ../../source/skills/orchestration/<name>/SKILL.md for exact Telar-source references.
Code Review
Comprehensive mobile-specific code review with two-stage review gates.
Phase 0: Specification Compliance (0-15%)
Load Skills
skills:
- review-gates
rules:
- platform-conventions
Stage 1: Spec Compliance
If PLAN.md exists:
- Check each task's acceptance criteria against implementation
- Flag unmet criteria
- Verify PROGRESS.md is up to date
If no PLAN.md:
- Skip this phase, proceed to architecture review
Verification Evidence
Before concluding any phase, require fresh verification:
skills:
- verification-before-completion
- All "pass" verdicts must reference fresh test runs or simulator verification
- Do not accept stale evidence from before the latest changes
Output
- Spec compliance status (pass/fail per criterion)
Phase 1: Architecture Review (15-35%)
Load Agents
agents:
- react-native-expert OR flutter-expert
- mobile-navigation-architect
Review Areas
-
Project structure
- Feature organization
- Module boundaries
- Import structure
-
Component architecture
- Component responsibilities
- Prop drilling depth
- State colocation
-
Navigation structure
- Route organization
- Deep linking coverage
- Navigation state management
Checklist
- [ ] Clear separation of concerns
- [ ] Consistent folder structure
- [ ] Appropriate module boundaries
- [ ] No circular dependencies
Output
- Architecture issues list
- Recommendations
Phase 2: Pattern Analysis (20-40%)
Load Agents
agents:
- mobile-state-management
Review Areas
-
State management
- Appropriate state location
- Server vs client state
- State update patterns
-
Data fetching
- Loading states
- Error handling
- Caching strategy
-
Component patterns
- Presentational vs container
- Hooks usage
- Render optimization
Anti-Patterns to Flag
const [globalData, setGlobalData] = useState()
const data = await fetch(url)
<A><B><C><D prop={value} /></C></B></A>
Output
- Pattern issues list
- Refactoring suggestions
Phase 3: Performance Review (40-60%)
Load Agents
agents:
- mobile-performance-optimizer
Review Areas
-
Render performance
- Unnecessary re-renders
- Missing memoization
- Large component trees
-
List performance
- FlatList/ListView optimization
- Key extraction
- Item memoization
-
Bundle size
- Large imports
- Unused dependencies
- Code splitting opportunities
Performance Flags
<Item style={{ margin: 10 }} />
<FlatList data={items} />
import _ from 'lodash'
Output
- Performance issues list
- Optimization opportunities
Phase 4: Security Review (60-80%)
Load Agents
agents:
- mobile-security-specialist
Review Areas
-
Data storage
- Sensitive data in secure storage
- No secrets in code
- Proper encryption
-
Network security
- HTTPS only
- Certificate pinning
- Auth token handling
-
Input validation
- User input sanitization
- API response validation
Security Flags
await AsyncStorage.setItem('token', authToken)
const API_KEY = 'sk-xxx'
const data = await response.json()
Output
- Security issues list
- Severity ratings
- Remediation steps
Phase 5: Accessibility Review (80-100%)
Load Agents
agents:
- mobile-accessibility-expert
Review Areas
-
Screen reader support
- Accessibility labels
- Semantic elements
- Focus order
-
Touch targets
- Minimum 44x44 points
- Adequate spacing
-
Visual accessibility
- Color contrast
- Text scaling
- Motion sensitivity
Accessibility Flags
<TouchableOpacity onPress={onPress}>
<Icon name="settings" />
</TouchableOpacity>
<Pressable style={{ padding: 4 }} />
Output
- Accessibility issues list
- WCAG compliance status
- Fixes required
Final Report
Summary
| Category | Issues | Critical | High | Medium | Low |
|----------|--------|----------|------|--------|-----|
| Architecture | 3 | 0 | 1 | 2 | 0 |
| Patterns | 5 | 0 | 2 | 2 | 1 |
| Performance | 4 | 1 | 1 | 2 | 0 |
| Security | 2 | 1 | 1 | 0 | 0 |
| Accessibility | 6 | 0 | 2 | 3 | 1 |
Stage 2: Code Quality Summary
- [ ] Follows project patterns (codebase-first)
- [ ] Platform conventions respected (HIG/Material)
- [ ] Touch targets >= 44x44 (iOS) / 48x48 (Android)
- [ ] Deep link handling correct
- [ ] Error states handled
- [ ] Tests included
- [ ] No duplication (textual or semantic — same job, different code) whose sites change together for the same reason; existing shared units reused, not re-implemented
- [ ] No bloat / speculative abstraction (simplicity-first); design patterns applied only where they earn complexity
- [ ] NOT flagged: coincidental similarity with different responsibilities (wrong abstraction), dogmatic tiny-function/length gates
Apply the full rule catalog from resources/rubrics/orchestration/maintainability-design-adversarial-rubric.md (D-DUP / D-REUSE / D-BLOAT / D-SMELL / D-SOLID / D-PATTERN / D-CLEAN). Genuine duplication/bloat → P1 (blocks merge); reuse/refactor suggestions → P3 (advisory). Honor the Metz "change together for the same reason" guardrail.
Action Items
- P1 — Fix immediately (blocks merge)
- P2 — Fix before merge (quality issues)
- P3 — Track for later (improvements)
References
rules/platform-conventions.md for HIG/Material compliance
skills/review-gates.md for two-stage review process
resources/rubrics/orchestration/maintainability-design-adversarial-rubric.md for the senior maintainability/design rule catalog (duplication, reuse, bloat, smells, SOLID)
skills/clean-code.md for the implementer-side authoring contract