Menu
MUST BE USED when user asks to: review code, review PR, check my code, look at my changes, review changes. Reviews pull requests and code changes, evaluating quality and providing actionable feedback.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
MUST BE LOADED for any coding task: implementing features, fixing bugs, writing code, refactoring, or making changes. This skill provides the mandatory step-by-step SDLC (Software Development Lifecycle) workflow for orchestrating development using specialized skills and sub-agents. Load this skill when the user asks to 'add', 'create', 'build', 'fix', 'update', 'change', 'implement', or 'refactor' anything.
MUST BE LOADED BEFORE modifying docs/tasks.md, docs/changes/, or task lists. Also load when user mentions tasks.md, changes/, 'the task file', specs, or discusses tasks/tracking. Triggers include: 'add a task', 'update tasks', 'mark as done', 'mark complete', 'track this', 'next task', 'what's next', 'work on next', create tickets/issues, 'add a feature', 'improve X to allow Y', plan features, break down tasks, or ANY project/task management discussion. This skill handles all task tracking through docs/tasks.md, docs/changes/ task lists, or external tools (GitHub Issues, Jira).
Spawn a coordinated sub-agent team to implement a spec or multi-task feature in parallel. Use when user says '/team', 'use a team', 'parallel implementation', 'work on multiple tasks', or provides a spec/issue that requires coordinated multi-PR work. The main session acts as coordinator — no code, no commits, only delegation and quality control.
Write, update, and maintain living specification documents and propose change documents. Use when user says 'write a spec', 'create a spec', 'spec out', 'update spec', 'spec this', 'design a feature', 'write a feature spec', or needs to create/modify specs in docs/specs/ or propose changes in docs/changes/. Handles the complete spec lifecycle: creation, updates, gap analysis, and change proposals.
MUST BE USED when user asks to: implement a feature, fix a bug, write code, add functionality, build something, code this, make changes. Implements code changes — when used within the SDLC workflow, PR creation is handled separately by pr-preparer.
Run OpenAI Codex's AI code review LOCALLY via the `codex` CLI BEFORE opening a PR (part of pre-PR self-review). Runs one-shot, reviewing the current branch against main, prints findings to stdout, and you resolve them before the PR is opened. Use during pre-PR self-review, alongside fx-dev:coderabbit-review.
| name | pr-reviewer |
| description | MUST BE USED when user asks to: review code, review PR, check my code, look at my changes, review changes. Reviews pull requests and code changes, evaluating quality and providing actionable feedback. |
BEFORE reviewing any code, you MUST:
Read the project instruction files:
# Project conventions (canonical)
cat AGENTS.md 2>/dev/null || echo "No AGENTS.md found"
# Review conventions (canonical) — highest priority for review decisions
cat REVIEW.md 2>/dev/null || echo "No REVIEW.md found"
# Claude-only additions, if any beyond the @AGENTS.md import
cat CLAUDE.md 2>/dev/null || echo "No CLAUDE.md found"
AGENTS.md is how the code should be written; REVIEW.md is how it should be reviewed. When they conflict on a review decision, REVIEW.md wins.
Legacy repos may still keep conventions in CLAUDE.md or the obsolete .github/copilot-instructions.md. Read those only if the canonical files are missing, and suggest running fx-dev:upgrade to migrate.
Apply project rules as BLOCKING issues. These files define project-specific requirements that override general best practices. Violations are BLOCKING, not suggestions.
For projects with vendor submodules (e.g., vendor/ directory):
Check every new file against vendor for duplicates:
# For each new file in src/lib/, check vendor
find vendor -name "filename.ts" -type f
Flag as BLOCKING if:
Space-Lua is AVAILABLE - If vendor code uses LuaEnv, luaQuery, evalExpression, etc., check if project already has Space-Lua aliases. If yes, the code should be imported, NOT ported.
Ask these questions for every port:
bun run build to prove import fails?fx-dev:resolve-pr-feedback skill to handle all automated feedback**Decision**: APPROVE/REQUEST CHANGES
**Size**: X lines [OK/EXCEEDS]
**Automated Reviews**: NONE/DETECTED (Copilot/CodeRabbit)
**Ready**: YES/NO
### Blocking
- [Critical issues only]
### Suggestions
- [Nice improvements]
### Next
- [Clear actions]
Remember: Enable autonomous workflow with clear feedback.