القائمة
Synthesize existing Hazma PR review feedback, assess each comment on merit, implement justified in-scope fixes, run the preflight gate, and provide verification-ready responses. Use when reviews already exist; do not use to collect reviews.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
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.
استنادا إلى تصنيف SOC المهني
| name | review-respond |
| description | Synthesize existing Hazma PR review feedback, assess each comment on merit, implement justified in-scope fixes, run the preflight gate, and provide verification-ready responses. Use when reviews already exist; do not use to collect reviews. |
Act as the implementing engineer. Accept neither comments nor rejections on faith: assess each against the current PR head, task scope, ADRs, tests, and measurements. Use the caller-supplied worktree and branch; otherwise resolve the PR/branch and its true merge base.
Read applicable project context and
docs/agents/lessons.md, then classify
each comment as exactly one of:
| Category | Meaning | Action |
|---|---|---|
fix | Valid and in scope | Implement it. |
fix-partial | Valid concern; proposal is wrong | Make the smaller correct fix. |
acknowledge | Valid but out of scope | File or link a follow-up. |
reject | Incorrect or already handled | Explain with command evidence. |
A numerics comment requires a measurement before accepting or rejecting it.
For an acknowledged follow-up, use the lifecycle in
docs/workflow.md, including existing follow-ups
and open-PR deduplication.
Fix the whole class, not only the cited line. Before changing a factual claim,
perform the before/after stale-sibling sweep required by
docs/agents/doc-consistency.md.
Re-measure affected public paths and update durable records and the PR body if
needed. Rebuild after Cython edits and run the preflight gate before staging.
For class-shaped review findings, update the lessons ledger in the same commit
only when a real PR citation is available. In a pipeline or review cycle,
commit and push the approved fixes after the gate; standalone use leaves them
uncommitted for $commit-and-pr.
Return one block per reviewer:
## Response to <Reviewer ID>
### Accepted
| # | Comment Summary | Category | Action Taken |
|---|---|---|---|
### Acknowledged (deferred)
| # | Comment Summary | Reason | Follow-up file |
|---|---|---|---|
### Rejected
| # | Comment Summary | Reason (with evidence) |
|---|---|---|
### Verdict Requested: <ACCEPT | ITERATE>
Then give a combined count, files modified, literal test summary, numerical-impact result, and outstanding questions. Never do drive-by cleanup, silently revert a valid fix, or claim a green run without its summary line.