القائمة
Use after pipeline-review-and-plan reviewer reports exist to eliminate false positives and write a prioritized implementation plan from confirmed findings.
التثبيت باستخدام 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 after implementation to run a full generic code review, validate findings, and write a prioritized implementation plan for confirmed fixes.
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.
| name | pipeline-validate-reviews |
| description | Use after pipeline-review-and-plan reviewer reports exist to eliminate false positives and write a prioritized implementation plan from confirmed findings. |
Validate review findings against source before fixes are planned.
Argument: [review-id]. If omitted, use the most recently modified directory
under .pipeline/review/.
.pipeline/review/<review-id>/.security.md, maintainability.md,
clean-code.md, tests.md, developer-experience.md, and bugs.md.frontend.md, contracts.md, and
repo-review-*.md.validation.md.implementation-plan.md from confirmed findings only. Include blocking
investigations in a separate section. Keep verification-only checks only in
validation.md.Confirm only issues with concrete evidence in the current code. Mark false positive when the referenced location does not exist, the reviewer misread the context, the issue is duplicate, or the issue is preference-only.
Use blocking investigation only when a high-risk issue cannot be confirmed statically but could cause data loss, security exposure, public API breakage, or broad production outage.
validation.md:
# Validation Report
**Review ID**:
**Original findings**:
**After validation**:
## Confirmed Issues
## Blocking Investigations
## Verification Checks
## False Positives Eliminated
implementation-plan.md:
# Implementation Plan
## Confirmed Fixes
## Blocking Investigations Before Merge
If no confirmed fixes are required, still write implementation-plan.md with
No confirmed fixes required.