This skill repeatedly uses a task planner, code architect, and code reviewer, and after stabilization, runs tests to improve the code to a production-ready level.
When to Use
Use this skill in the following situations:
- When quality verification is needed after implementing a new feature
- When side effect verification is needed after fixing a complex bug
- When code quality verification is needed after refactoring
- When final verification is needed before production deployment
Workflow
Phase 1: Initial Analysis
- Identify target files/branches
- Determine current state (git status, git diff)
- Detect test environment (pytest, npm test, cargo test, go test, make test, etc.)
- Create Todo list
Phase 2: Iterative Improvement Loop
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────────┐ │
│ │ Task Planner │────▶│ Code Architect │────▶│ Code Reviewer │ │
│ │ (분석 & 계획) │ │ (수정) │ │ (검토) │ │
│ └─────────────────┘ └─────────────────┘ └──────────┬──────────┘ │
│ ▲ │ │
│ │ ▼ │
│ │ ┌─────────────────────┐ │
│ │ │ Critical Issues? │ │
│ │ └──────────┬──────────┘ │
│ │ │ │
│ │ Yes │ No │
│ └──────────────────────────────────────────────────┤ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Stable? (3 loops │ │
│ │ or Production Ready)│ │
│ └──────────┬──────────┘ │
│ │ │
│ No │ Yes │
│ ┌──────────────────────────────────────────────┤ │
│ │ ▼ │
│ │ ┌─────────────────────┐ │
│ │ │ Run Tests │◀────────┐ │
│ │ │ (pytest, npm, etc) │ │ │
│ │ └──────────┬──────────┘ │ │
│ │ │ │ │
│ │ Pass │ Fail │ │
│ │ ┌──────────┴──────────┐ │ │
│ │ ▼ ▼ │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ │ │
│ │ │ Complete! │ │ Debugger │──┘ │
│ │ └─────────────────┘ │ (분석 & 수정) │ │
│ │ └────────┬────────┘ │
│ │ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
Phase 3: Run Tests (After Stabilization)
- Automatically detect test framework
- Run relevant tests
- On failure, analyze with debugger agent
- Test again after fixes
Phase 4: Completion
- Commit all changes
- Push branch
- Report final status
Agent Invocation Instructions
1. Invoke task-planner-analyzer agent (at the start of each iteration)
At the start of each iteration cycle, invoke with the Task tool:
Task tool 사용:
- subagent_type: "task-planner-analyzer"
- prompt:
- 이전 code-reviewer의 피드백 (있는 경우)
- 수정해야 할 이슈들의 목록
- 코드베이스 구조 분석 및 제약 조건 파악 요청
- 구체적인 수정 계획과 todo list 생성 요청
2. Invoke modular-code-architect agent
When modifications are needed according to the task-planner-analyzer's plan, invoke with the Task tool:
Task tool 사용:
- subagent_type: "modular-code-architect"
- prompt:
- task-planner-analyzer가 생성한 계획 포함
- 수정해야 할 이슈들의 상세 설명
- 파일 경로, 라인 번호, 구체적인 수정 방향 포함
3. Invoke code-reviewer agent
When reviewing after modifications, invoke with the Task tool:
Task tool 사용:
- subagent_type: "code-reviewer"
- prompt:
- main 브랜치와 비교 또는 특정 커밋과 비교
- ultrathink 수준의 심층 분석 요청
- Critical, Warning, Suggestion 구분하여 보고 요청
4. Invoke debugger agent (on test failure)
When test failure analysis is needed, invoke with the Task tool:
Task tool 사용:
- subagent_type: "debugger"
- prompt:
- 실패한 테스트 출력 전체 포함
- 관련 파일 경로 명시
- 에러 메시지와 스택 트레이스 포함
- 수정 방향 제안 요청
Test Framework Detection
Automatically detect the test environment in the following order:
Python Project
# 탐지 방법
- pytest.ini, pyproject.toml, setup.cfg 확인
- tests/ 또는 test/ 디렉토리 존재 확인
# 실행 명령
pytest -v --tb=short
# 또는 특정 파일만
pytest -v path/to/test_file.py
JavaScript/TypeScript Project
# 탐지 방법
- package.json의 scripts.test 확인
- jest.config.js, vitest.config.ts 확인
# 실행 명령
npm test
# 또는
yarn test
Rust Project
# 탐지 방법
- Cargo.toml 확인
# 실행 명령
cargo test
Go Project
# 탐지 방법
- go.mod 확인
- *_test.go 파일 존재 확인
# 실행 명령
go test ./...
Makefile-based
# 탐지 방법
- Makefile에 test 타겟 확인
# 실행 명령
make test
Stabilization Criteria
If any of the following conditions is met, determine it as "stabilized" and run tests:
- Production Ready Determination: code-reviewer determines "production ready" or "no critical issues"
- 3 Consecutive Rounds with No Changes: Completed 3 review cycles without critical issues
- Only Warnings Remain: When all critical issues are resolved and only warnings/suggestions remain
Iteration Termination Conditions
The iteration terminates when all of the following conditions are met:
- No Critical Issues: code-reviewer does not report critical issues
- Tests Pass: All relevant tests pass
- Gradient Flow Normal: (For ML code) gradients flow correctly
- Edge Case Handling Complete: All edge cases are handled
Maximum iterations
To prevent infinite loops:
- Code review loop: up to 10 times
- Test fix loop: up to 5 times
- If exceeded, report the current status to the user and request manual intervention
Usage examples
Example 1: New feature verification
사용자: "이 브랜치의 코드를 iterative-code-review로 검증해줘"
Claude:
1. git diff main...HEAD로 변경사항 확인
2. 테스트 환경 탐지 (pytest 발견)
3. [반복 시작] task-planner-analyzer로 이슈 분석 및 수정 계획 수립
4. modular-code-architect로 계획에 따라 수정
5. code-reviewer로 검토
6. Critical 이슈 발견 시 → task-planner-analyzer로 돌아가서 반복 (3회)
7. Production-ready 판정 → 테스트 실행
8. pytest 실패 → debugger로 분석 → 수정
9. pytest 통과 → 완료!
Example 2: ML model modification verification
사용자: "/iterative-code-review models/trm_titans.py"
Claude:
1. 해당 파일 분석
2. [반복 1] task-planner-analyzer로 개선 계획 수립
3. modular-code-architect로 개선점 구현
4. code-reviewer로 검증 (gradient flow 특별 주의)
5. [반복 2-4] Critical 이슈에 대해 계획→수정→검토 반복
6. 4회 반복 후 안정화 → 테스트 실행
7. 완료 보고
Example 3: Handling test failures
코드 리뷰 완료 후:
1. pytest -v 실행
2. test_memory_update FAILED 발견
3. debugger 에이전트 호출:
- 에러: "AssertionError: gradient is None"
- 분석: create_graph=False로 인한 문제
4. task-planner-analyzer로 수정 계획 수립
5. modular-code-architect로 수정
6. pytest 재실행 → 통과
7. 완료!
Best Practices
- Using a Todo list: Track progress with the TodoWrite tool
- Separate commits: Create a meaningful commit for each fix cycle
- Incremental improvement: Proceed step by step rather than fixing everything at once
- Documentation: Record the reasons for fixes and decisions in the commit message
- Test first: If possible, first check the failing test before fixing
Precautions
- Do not merge directly into the main branch (unless otherwise instructed)
- Do not use destructive git commands (force push, hard reset, etc.)
- When running tests, it is recommended to run only the relevant tests instead of the full test suite (to save time)
- For projects without tests, completion is possible based on the code-reviewer's judgment alone
- ML training tests can take a long time, so a short smoke test is recommended