Menú
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.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
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.
Basado en la clasificación ocupacional SOC
| 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.