القائمة
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.
التثبيت باستخدام 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.
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.
| name | review-pr |
| description | 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. |
Review one PR and return one structured verdict. Do not implement fixes or
orchestrate other reviewers; use $review-cycle for the bounded multi-agent
loop and $review-plan for a pre-implementation plan.
Normalize a PR number, URL, or pushed branch. Fetch its metadata and fresh head ref; do not judge the ambient checkout:
git fetch origin pull/<N>/head:refs/remotes/origin/pr/<N>
Verify that SHA against gh pr view <N>. Treat a truncated gh pr diff as
incomplete; read changed files from the fetched ref. Parse project branches as
<agent>/<slug>/<task> for both agent prefixes. For project work, read
lessons.md, the PLAN's numerical-impact section, optional rules, target
phase, task note, relevant ADRs, and upstream learnings. For ad-hoc work,
review against AGENTS.md, the PR guidelines, and the change itself.
Read every changed non-trivial file in full context. Check common diff omissions: public exports, sibling dispatch tables, Cython rebuild evidence, stale Sphinx references, package data registration, and ignored tests.
Read the assigned section of
docs/agents/review-lenses.md and
apply its baseline duties before the lens rubric. Reproduce PR-body claims,
check a real pytest collection/result, run changed examples or observable
claims, and require a rebuild after Cython edits.
default: public API, units/docstrings, layering, broadcasting, debug
residue, task completion, and PR conventions.completeness: explicit Exit-Criterion-to-pinning-test map and scope.logic: adversarial mutation, boundary/error cases, and test validity.doc-consistency: execute every applicable check in
docs/agents/doc-consistency.md
with line-numbered evidence.numerics: measure public before/after values, dimensional analysis,
limiting cases, stability, integration/interpolation bounds, tolerance, and
hot-path performance.Use REQUEST CHANGES for any blocking finding and APPROVE otherwise.
COMMENT is only for a standalone advisory review. On a verification pass,
classify every prior comment as RESOLVED, PARTIALLY RESOLVED, or
UNRESOLVED.
## Verdict
<APPROVE | REQUEST CHANGES | COMMENT>
## Issues (<lens> Focus)
### Blocking
<numbered, file-and-line-specific findings or None>
### Non-blocking
<numbered findings or None>
## Cross-cutting
<only clearly blocking issues outside the lens>
## Lens-Specific Observations
<required evidence for the selected lens>
If a required command or dependency cannot run, report the verification gap; never invent a result or turn environment noise into a code defect.