메뉴
Review coding changes against the approved plan, identify concrete bugs, regressions, and plan-adherence gaps, run approved isolated fix passes, then close the loop with optional planning-doc cleanup and PR/MR creation.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Plan coding work as a compact implementation-step bundle with a conservative research decision, high-level overview first, and planning artifacts written only under .project_planning/YYYY-MM-DD_FEATURE_NAME/. This skill plans only — it never writes, edits, or refactors implementation code, and never skips ahead to building. If only the skill name is given, ask for a high-level description first before writing planning files.
Execute an approved coding plan as serial-first implementation steps with tight scope control, planner-defined verification strategy, and mandatory sub-agent/worktree execution.
Execute an approved coding plan in staged steps with tight scope control, planner-defined verification strategy, deferred automated verification by default, and mandatory isolated sub-agent dispatch when the runtime supports safe worktree execution.
Close out a completed coding loop by validating final chain readiness, checking for leftover repository state, and optionally preparing and creating a PR or MR when the remote provider is supported.
Plan coding work in stages with a mandatory research-decision checkpoint, a high-level overview first, and planning artifacts written only under .project_planning/YYYY-MM-DD_FEATURE_NAME/. If only the skill name is given, ask for a high-level description first before writing any planning files.
Review coding changes against the approved plan, identify concrete bugs, regressions, and plan-adherence gaps, and, when approved, run a batched sequential review-fix loop using isolated sub-agents before finalization.
| name | das-review |
| description | Review coding changes against the approved plan, identify concrete bugs, regressions, and plan-adherence gaps, run approved isolated fix passes, then close the loop with optional planning-doc cleanup and PR/MR creation. |
Use this skill after execution. Validate the implemented work against overview.md, plan.yaml, execution.md, and the actual repository state. If needed, run a bounded review-fix loop. When the review passes, own closeout: optional planning-doc cleanup and optional PR/MR creation.
The reviewer is the final gate for the loop.
overview.md, plan.yaml, and execution.md.cl/YYYY-MM-DD_FEATURE_NAME..project_planning/ is gitignored by running git check-ignore -q .project_planning/. If exit code is 0, planning artifacts are local-only — do not stage or commit them at any point during this workflow. If exit code is non-zero, planning artifacts are version-controlled — commit them as described below.Follow this sequence:
Stop and report blockers instead of widening scope.
review.md is optional.
Do not create review.md by default. Create it only when the user chooses to keep planning docs or declines planning-doc deletion during closeout.
When created, review.md is a compact final-state file under the planning folder. It should record:
fail, pass_with_notes, or passDo not maintain a verbose review history unless needed to preserve finding resolution.
Compare these inputs:
overview.md for original intent, boundaries, and verification strategyplan.yaml for the approved implementation contractexecution.md for completed steps, deviations, and verificationFocus on:
approach and the Key Decisions cited in its decisions listReview touched files and directly adjacent regression-risk areas: call sites, interfaces, tests, config, data paths, and package boundaries touched by or directly depending on the change. Do not broadly re-review unrelated code.
For inspection, use native tools directly — Read to examine files, grep and glob to locate code and call sites, Write for review.md. Do not route through Bash when a dedicated tool exists.
Prefer evidence over speculation. Findings should reference concrete code, artifacts, missing checks, or reproducible reasoning.
Classify findings as:
blocking: must be fixed before closeoutnon_blocking: record but does not block closeoutinformational: useful note onlyMap final status as:
fail if blocking findings remainpass_with_notes if no blocking findings remain but non-blocking findings remainpass if only informational findings or no findings remainOnly fixable blocking findings enter the fix plan by default. Include non-blocking fixes only when directly adjacent and negligible in scope.
Do not edit code before a review pass has produced concrete findings and the user has approved the fix plan.
Each review pass may produce one consolidated fix plan. The plan must map fixes to blocking finding ids and state which verification will be rerun.
The reviewer prefers the highest available delegation tier for fix passes:
Prefer isolated delegation. Fall back through tiers in order. Do not skip direct delegation and jump to inline fixes just because worktrees failed.
The reviewer owns provisioning, merge, verification, cleanup, and any review.md updates.
After git worktree add, verify the worktree before dispatching:
ls -d <worktree-path> — confirm the directory was created.git -C <worktree-path> branch --show-current — confirm it is on the expected temporary branch.If either check fails, prune the entry with git worktree remove <worktree-path> and fall back to direct delegation.
The review-fix sub-agent must:
Review-fix work is sequential. Do not parallelize it.
Use the cheapest capable sub-agent or delegation profile available in the current runtime.
The reviewer must provide a tight, self-contained task with known context, relevant files, approved decisions, constraints, expected output, non-goals, and the pre-commit checklist below.
Include the appropriate checklist verbatim in every delegated task that commits. The sub-agent must run all checks before git commit.
Isolated delegation mode:
git branch --show-current — must equal the temporary branch name given in the task. If it shows the feature branch, STOP and report without committing.git rev-parse --show-toplevel — must equal the worktree path given in the task. If it shows a different path, STOP and report without committing.git status — must show only files within the declared scope as modified. If unexpected files appear, STOP and report.Direct delegation mode:
git branch --show-current — must equal the feature branch name given in the task. If it shows a different branch, STOP and report without committing.git status — must show only files within the declared scope as modified. If unexpected files appear, STOP and report.If any check fails, the sub-agent must not commit. It must report the mismatch and let the executor recover.
Before running linters, clean any linter cache that stores results by absolute path. Stale entries from deleted worktrees cause false positives (e.g. golangci-lint cache clean for Go projects).
Reuse the verification strategy in overview.md by default. Rerun the narrowest checks that cover the fixes and any affected acceptance criteria.
If verification fails, either run another approved review-fix pass or report a blocker. Do not silently downgrade failures.
Closeout starts only when final review status is pass or pass_with_notes, blocking findings are resolved, and the feature branch is clean.
Offer the user these closeout actions:
Do not delete planning artifacts, push, or create a PR/MR without explicit user confirmation.
Planning docs are disposable after successful review unless the user wants to keep them.
If the user chooses cleanup:
.project_planning/YYYY-MM-DD_FEATURE_NAME/If the user declines cleanup, create or update review.md with the final review and closeout state.
Use commit messages for PR/MR summaries. Do not broad-diff the branch against origin/main by default.
Build the PR/MR body from:
Use loop artifacts only as fallback if they still exist and commit messages are missing, vague, contradictory, or clearly insufficient.
Inspect targeted diffs only if commit messages and available artifacts are insufficient.
Detect the remote provider from the current branch tracking remote or origin.
Choose the target branch in this order:
origin/mainorigin/masterUse only known provider flows:
gh pr create --title <title> --body <body> --base <target> --head <branch>git push -o merge_request.create -o merge_request.target=<target> <remote> <branch>az repos pr create --title <title> --description <body> --source-branch <branch> --target-branch <target>Ask for confirmation before pushing or creating a PR/MR. Do not dump the full PR/MR body unless the user asks.
The loop is complete when review has passed and the user has either accepted, declined, or completed closeout actions. Unsupported PR/MR creation does not invalidate the reviewed work; it only prevents automatic PR/MR creation.