- name
- review-implementation
- description
- Use after implementing a feature to verify structural completeness and code quality. Auto-detects what changed and runs appropriate checks.
# Review Implementation
Structured review checklist for verifying implementation completeness.
## Invocation
- `/review-implementation` — auto-detect from git diff
- `/review-implementation <path>` — review specific files
## Step 1: Detect What Changed
```bash
git diff --name-only main # or appropriate base branch
```
Categorize changes:
- New files added → component/module review
- Transformation/mapping files → rule review
- Modified existing files → change review
## Step 2: Structural Checks
Run checks appropriate to the project. Read CLAUDE.md for project-specific conventions.
### Universal Checks (all projects)
| # | Check | How |
|---|-------|-----|
| 1 | Source file exists at expected location | Glob |
| 2 | Tests exist for new code | Glob for test files |
| 3 | Module registered/exported | Grep in registry files |
| 4 | No orphaned imports | Grep for unused imports |
| 5 | Naming follows project convention | Compare with existing files |
### Project-Specific Checks
Read CLAUDE.md for additional checks. Common patterns:
- Trait/interface implementations complete
- Serialization support (if required)
- CLI/dispatch registration
- Documentation entries
- Example programs registered
Build the checklist dynamically from CLAUDE.md conventions + reference implementations.
## Step 3: Build Checks
Run project build and test commands (from CLAUDE.md):
```bash
# Examples — actual commands from CLAUDE.md
make test
make lint
# or: pytest, cargo test, npm test, etc.
```
Report pass/fail. If tests fail, identify which and suggest fixes.
## Step 4: Semantic Review
Read implementation files and assess:
1. **Correctness** — Does the logic match the plan/spec? Edge cases handled?
2. **DRY** — Duplicated logic that should be extracted? Copy-pasted blocks?
3. **KISS** — Unnecessary complexity? Over-engineering? Premature abstraction?
4. **Explainability** — Can every non-trivial change be explained in one sentence?
## Output Format
```
## Review: [Type] [Name]
### Structural Completeness
| # | Check | Status |
|---|-------|--------|
| 1 | Source file exists | PASS |
| 2 | Tests exist | PASS |
| ... | ... | ... |
### Build Status
- tests: PASS / FAIL
- lint: PASS / FAIL
### Semantic Review
- Correctness: OK / [issues]
- DRY: OK / [duplicated logic in ...]
- KISS: OK / [unnecessary complexity in ...]
### Summary
- X/Y checks passed
- [action items for failures]
```
## Integration
Called automatically at the end of:
- `workflow:add-model` (Step 5)
- `workflow:add-rule` (Step 6)
- `workflow:workflow` (Step 4)
Also invocable standalone via `/review-implementation`.
在 GitHub 查看