القائمة
Use after implementation to run a full generic code review, validate findings, and write a prioritized implementation plan for confirmed fixes.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use after review-and-plan to verify the full pipeline ran, implementation aligns with the spec, final gates pass, and human plus agent journey coverage exists.
Use after tasks.yaml and thin task contracts exist to implement the dependency-ordered task graph and mark tasks done only after verification passes.
Use after an approved spec to create a dependency-ordered software delivery plan and tasks.yaml skeleton before task contracts or implementation.
Use when turning a raw software feature idea into an approved specification before planning, tasks, implementation, review, or finalization.
Use after a delivery plan exists to write thin per-task implementation contracts and complete tasks.yaml for execution.
Use after pipeline-review-and-plan reviewer reports exist to eliminate false positives and write a prioritized implementation plan from confirmed findings.
| name | pipeline-review-and-plan |
| description | Use after implementation to run a full generic code review, validate findings, and write a prioritized implementation plan for confirmed fixes. |
Stage 5: implementation -> review -> validated fix plan.
Run a full review pipeline and validate findings before reporting or fixing them. Raw reviewer findings are not final; only validated findings reach the user or downstream tasks.
Arguments: [target-ref] [base-ref] [plan-path]
target-ref: branch, tag, or commit to review. Default: HEAD.base-ref: comparison base. Default: main.plan-path: optional path to spec.md, plan.md, or a feature directory.Create .pipeline/review/<review-id>/ with:
setup.logstat.txtdiff.patchlog.txtcriteria-snapshot.mdrisk-profile.mdplan-snapshot.md when a plan path is providedUse git merge-base target base when possible. If merge-base fails, fall back
to target~1..target and record the fallback in setup.log.
Risk profile:
low: docs, comments, examples, formatting-only, or isolated cleanup.standard: ordinary implementation changes with bounded runtime effect.high: public API, generated contract, auth, secrets, persistence,
migrations, storage, destructive operations, concurrency, UI request chains,
SDK/CLI/tool surfaces, or broad compatibility risk.Use these prompt files as authoritative criteria:
| Reviewer | Prompt file | Output |
|---|---|---|
| Security | review-security/review-security.md | security.md |
| Maintainability | review-maintainability/review-maintainability.md | maintainability.md |
| Clean code and SOLID | review-clean-code/review-clean-code.md | clean-code.md |
| Tests | review-tests/review-tests.md | tests.md |
| Developer and agent experience | review-developer-experience/review-developer-experience.md | developer-experience.md |
| Bugs and performance | review-bugs/review-bugs.md | bugs.md |
| Frontend | review-frontend/review-frontend.md | frontend.md when frontend files changed |
| Public contracts | review-contracts/review-contracts.md | contracts.md when public contracts changed |
Run reviewers in parallel when the active tool supports it. Otherwise run them one at a time with the same shared packet.
Reviewers must:
criteria-snapshot.md and risk-profile.md.After reviewer files exist, write .pipeline/review/<review-id>/summary.md
with critical, major, minor, clean, and full report sections.
Immediately invoke pipeline-validate-reviews with the review id. This stage is
not complete until both files exist:
.pipeline/review/<review-id>/validation.md.pipeline/review/<review-id>/implementation-plan.mdReport review id, review directory, summary path, validation path, implementation-plan path, risk level, and counts of confirmed findings, blocking investigations, verification checks, and eliminated findings.