القائمة
Reviews a delivered change against its contracts — the /spec plan, the roadmap phase's boundary, binding ADRs, and test authenticity — and returns a verdict with blocking and advisory findings.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Executes an implementation plan (from /spec) end to end: turns its Steps into a tracked checklist, works through them one at a time — implement, run the Step's Verify, check it off, commit — then runs the plan's overall Verification and delivers a PR. When the plan is one phase of a /phasing roadmap, delivery also writes the phase's carry-over fragment and flips its status in the roadmap. Invoking /implement is itself the go-ahead to execute; there's no separate approval gate. Use when the user wants to execute, build, or ship a plan that already exists, or invokes /implement.
Turns settled PRD/TDD/ADR scope into an ordered set of phases, each sized to be exactly one /spec (one Approach, one Verify surface, one PR), organized as a dependency graph so parallel streams fall out of real technical dependency instead of being guessed upfront. Writes the roadmap to docs/roadmaps/<slug>/roadmap.md; each phase becomes its own /spec afterward. Use when the user wants to break a feature or system into phases, plan a rollout across multiple PRs, or invokes /phasing.
Writes or updates a Product Requirements Document (PRD) — a concise, best-practice description of what a system, feature, or subsystem does for its users, never how it's built. Takes its input from a /brainstorm convergence artifact, a /tdd document, or the user's own description of a feature. Use when the user wants a PRD, product requirements doc, or asks to turn a brainstorm or design into product requirements, or invokes /prd.
Writes or updates an implementation plan — a concise, actionable breakdown of how one change will be made: what recon (and any binding ADRs) found, the chosen approach, an ordered list of steps, and how each step (and the change as a whole) is verified done. Scoped to a single change, not a system (that's a TDD) and not user-facing behavior (that's a PRD) — the plan is the handoff artifact between deciding what to build and building it. Use when the user wants an implementation plan, asks to plan a feature, bugfix, or refactor before coding it, or invokes /spec.
Writes or updates a Technical Design Document (TDD) — a description of how a system, subsystem, or component is put together. Not a proposal: states the design rather than building a case for it, and references the ADRs, PRDs, or brainstorm docs that justify it instead of restating them. Grounds every part in the most reliable source available — code where it's built, anchor docs where it isn't yet — and flags unbuilt pieces inline instead of labeling the whole document. Use when the user asks for a technical design document, architecture document, or system design doc, or wants a system's (or part of a system's) architecture written down with diagrams.
Long-form, user-steered technical brainstorming session for exploring a fuzzy idea (architecture, product, tooling, format, process) down to decision-ready artifacts. Not an option-list generator — one thread at a time, grounded in real context, ending in trade-offs with named prices. Invoke explicitly with /brainstorm.
| name | review |
| description | Reviews a delivered change against its contracts — the /spec plan, the roadmap phase's boundary, binding ADRs, and test authenticity — and returns a verdict with blocking and advisory findings. |
| disable-model-invocation | true |
| license | MIT |
| metadata | {"author":"Marcos Oliveira","version":"1.0.0"} |
A generic reviewer judges a diff against taste; this one judges it against contracts: the plan that promised the change, the roadmap phase that bounds it, and the ADRs that constrain it. Nothing passes because it looks good — it passes because every contract demonstrably holds. Invoke explicitly with /review.
/spec.Read in full: the plan (Goal, Success Criteria, Steps with their Verify lines, Verification, Assumptions in the PR), every ADR the plan references, and — when the plan is a roadmap phase — that phase's contract block (Goal, In/Out, Source) and the carry-over fragment /implement wrote, if any.
Completion criterion: every contract the checks below will judge against is read, not skimmed — plan, ADRs, phase block, fragment.
Read the full diff of the PR or branch, every changed file — plus enough surrounding code to judge each change correct in context, not just plausible in isolation.
Completion criterion: no changed file unread; context opened wherever a change's correctness depends on code outside the diff.
A flat set — apply every check to the whole diff; a skipped check is a review not done.
Completion criterion: all four checks applied to the entire diff; every finding written down with file/line, the contract it breaks, and its severity (blocking or advisory).
The review reports; the fix is a separate /implement pass — judging and patching in the same breath corrupts both. A finding that affects another phase (a fact its /spec needs, a dependency the roadmap missed, an anchor doc the diff disproves) is appended to this phase's carry-over fragment — created at the reserved path if /implement skipped it — never left as a loose comment.
Deliver as a PR review when a PR exists (gh pr review), otherwise in the session: verdict first, then findings grouped by check with file/line and contract, then what was actually run (Verification commands, test suite) and the results.
Completion criterion: verdict stated; every blocking finding actionable without re-deriving the review; cross-phase findings sit in the fragment.
/implement patch.