Menu
Phase quality review against the project quality bar. Use when reviewing implementation quality, scoring a phase, or gating merge readiness.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Explore the codebase and write a discovery brief. Use when discovering scope, surveying a codebase, or starting a feature.
QA passed — merge branch to main, move ticket to Done, delete branch. Use after QA sign-off on a completed feature.
Run one fully-autonomous development iteration. Picks a ticket (from --focus or backlog via ideator), then runs the `orchestrator autopilot <slug>` workflow subcommand. This skill should be used when the user says 'autopilot', 'autonomous', 'self-improve'.
Create commits in logical groups. This skill should be used when the user says 'commit-group', 'group commits', 'organize commits', or when there are multiple unstaged changes that should be organized into atomic commits.
Complete feature — verify, signoff, archive. Runs only the complete phase of the orchestrate workflow. This skill should be used when the user says 'complete feature', 'finish feature', 'merge to main'.
Fetch curated, agent-optimized library documentation via Context Hub (chub). Use when implementing features that use external libraries, when Context7 returns noisy/incomplete docs, when you need language-specific or version-specific API docs, or when the user says "chub", "context hub", "get docs for X". Prefer this over Context7 for libraries in chub's registry — curated docs have less noise and better code examples.
| name | review |
| description | Phase quality review against the project quality bar. Use when reviewing implementation quality, scoring a phase, or gating merge readiness. |
| user-invocable | true |
| extends | git+git@github.com:ugudlado/prompt-packs.git@302b87dcc7c8b6a83d249194f3e47e98d3214794#reviewer |
Intent: Run phase quality checks and decide pass/retry.
task_execution_resultdesign.md (optional, at spec/changes/<slug>/design.md)tasks.yaml (optional, at spec/changes/<slug>/tasks.yaml)phase_review_reportphase-review.md written to $WORKTREE_ARTIFACT_DIR/$CHANGE_ID/phase-review.md..orchestrator/config/):
pytest -q,
package.json scripts, etc.). Execute every discovered command. Any
non-zero exit is a critical correctness finding — cannot pass this round.
If no verify command is discoverable at all: this is itself a critical
finding in spec_compliance (missing quality gate) — cannot pass this
round. Write phase-review.md noting what was searched and what the repo
should document, and return COMPLETION with status: failed per step 9
below.spec/changes/archive/*/state.yaml.schema: field.metrics.review_score_avg across those entries (skip entries missing this field).quarantine_events (may be absent or empty).T-<N> (reason: <category>, attempts: <K>): <last_detail>status: pending, OR
b. Is explicitly accepted by the user (state.yaml contains
quarantine_accepted: ["T-<N>", ...]); for autopilot schema,
quarantined tasks are treated as accepted automatically — no human gate.design.md is absent, read acceptance criteria from
$WORKTREE_ARTIFACT_DIR/$CHANGE_ID/ticket-context.md
(spec/changes/<slug>/ticket-context.md) instead.
The ticket AC section is the contract — verify each checkbox item with evidence.COMPLETION:
status: completed
outputs:
phase_review_report: {verdict: pass}
review_score:
overall: <N>
dimensions: {spec_compliance: <N>, correctness: <N>, security: <N>, simplicity: <N>, code_quality: <N>}
artifacts: [phase-review.md]
status: pending.status: failed — the engine routes back via the
workflow's on_failure edge. Do NOT implement retry counting here; the
engine enforces max_retries on the node.COMPLETION:
status: failed
outputs:
phase_review_report: {verdict: needs_work}
review_score:
overall: <N>
dimensions: {spec_compliance: <N>, correctness: <N>, security: <N>, simplicity: <N>, code_quality: <N>}
artifacts: [phase-review.md]
status: pending. If any pending tasks exist and are not explicitly quarantined in state.yaml, write phase-review.md with verdict incomplete_phase listing the pending task IDs — return COMPLETION with status: failed and outputs.phase_review_report: {verdict: incomplete_phase}, and do NOT include review_score. status: failed is required so the on_failure edge fires back to implement — without it the dispatcher treats the step as completed and silently advances past the implement phase with tasks still pending. This guards against dispatcher bugs or manual advances that reach review before all tasks are complete. evidence.verified entry from a completed implement step in step_history and re-run its check command. A mismatch with the recorded result is a critical correctness finding (fabricated evidence) — this is the only enforcement on self-reported evidence, so treat a mismatch as severe.