菜单
Perform a read-only, findings-first review of a Hazma project PLAN before implementation, covering feasibility, numerical correctness, architecture, Python conventions, and testability. Use when a user asks whether a project plan is ready or asks to review projects/<slug>/PLAN.md.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Prepare a guarded, ready-to-paste kickoff prompt for the next eligible phase of a phased project, verifying strict prerequisite closeout first and refusing blocked or ambiguous phase starts.
Safely determine whether a phased Hazma project can begin its next or a requested phase, then produce a guarded Codex kickoff prompt. Use when a user asks which phase is ready, asks to begin a phase, or needs a phase handoff; this skill does not implement the task.
Run Hazma's preflight gate, create or validate a Codex branch, commit intentionally with a valid Conventional Commit header, push, and open or update a pull request. Use when a user asks to commit, ship, or open a PR for current work.
Implement exactly one numbered task from a Hazma project plan, including task-note updates, numerical-impact measurement, documentation consistency, and the preflight gate. Use when a user asks to take a project task or the next project task; stop before committing unless the caller expressly owns the commit.
Orchestrate a bounded, multi-agent Codex review loop for a pushed Hazma pull request: select independent reviewer lenses, collect reviews in parallel, apply and push justified fixes, verify them, post durable round summaries, and stop at convergence, escalation, or the iteration cap.
Review a Hazma pull request against its project task or ad-hoc scope using one focused lens: generalist, completeness, logic, document consistency, or numerics. Use when a user asks for a PR review or when a Codex review cycle assigns a single reviewer lens.
| name | review-plan |
| description | Perform a read-only, findings-first review of a Hazma project PLAN before implementation, covering feasibility, numerical correctness, architecture, Python conventions, and testability. Use when a user asks whether a project plan is ready or asks to review projects/<slug>/PLAN.md. |
Review the plan without editing it. Normalize the supplied slug, project path,
or PLAN.md; require a non-empty projects/<slug>/PLAN.md. An unknown focus
category is an input error. Missing plan-linked context is a finding, not a
reason to fabricate it.
Read PLAN.md, rules.md, phase files, references, ADRs, live task-notes
README, AGENTS.md,
docs/workflow.md,
docs/versioning.md,
docs/PR_GUIDELINES.md, and
docs/agents/lessons.md, plus files the
plan cites. Ignore _template.md.
Verify load-bearing current-state claims with rg, exact file reads, and the
commands the plan asks an implementer to run. Distinguish pre-existing paths
from paths the work will create. A green-but-noop test command is blocking;
record every verified claim with concrete evidence.
Assess every requested category (or all of them) and cite the exact plan location for each finding.
AGENTS.md.Emit only this report. Use [P1] for a blocker, [P2] for needs work, and
[P3] for a suggestion; any P1 means REQUEST MAJOR REVISION.
# Plan Review: <project>
## Findings
<severity-ordered, cited findings and concrete resolutions>
## Summary
| Category | Verdict | Top finding |
|---|---|---|
| ... | Pass / Needs work / Blocker | ... |
## Grounded-facts audit
| Claim (plan location) | Verified? | Evidence |
|---|---|---|
## What the plan does well
<concrete, cited strengths>
## Verdict
<APPROVE | APPROVE WITH CHANGES | REQUEST MAJOR REVISION>