القائمة
Code review with auto-fix — plan-vs-implementation comparison or structured git-diff review. Automatically fixes issues found during review.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/ReinaMacCredy/loveNovel --skill reviewيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | review |
| description | Code review with auto-fix — plan-vs-implementation comparison or structured git-diff review. Automatically fixes issues found during review. |
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion |
| disable-model-invocation | true |
Perform a rigorous, structured comparison of the plan against the actual implementation. Every acceptance criterion gets a verdict. Scope compliance is checked. Issues found during review are automatically fixed when possible; complex issues are logged as TODOs.
Discover all plans from both active and archive directories:
Glob(".maestro/plans/*.md")
Glob(".maestro/archive/*.md")
AskUserQuestion and ask which plan to review. Include filenames, modification dates, and location context — mark plans from .maestro/plans/ as (active) and plans from .maestro/archive/ as (archived). Load the selected plan.Read the chosen plan file in full.
Extract these sections from the plan:
**In**:)**Out**:)- [ ] Task N: Title or - [x] Task N: Title)<!-- commit: {SHA} --> annotation on the checkbox line, if present)**File**: \path``)**Description**:)**Acceptance criteria**:)**Agent**:)If any section is missing, note it as [SECTION NOT FOUND] and continue.
For each task in the plan, check every acceptance criterion individually:
<!-- commit: {SHA} --> annotation, use git show {SHA} --stat to identify exactly which files were changed in that commit, and git show {SHA} to inspect the diff. This scopes your verification to the actual changes made for this task rather than searching the entire codebase.**File**: exist? (Glob)git show {SHA} for evidenceDo NOT just check file existence — verify the content matches each criterion.
For each item listed under **Out**: in the Scope section:
This catches scope creep — work that was explicitly excluded but got done anyway.
For each item listed under **In**: in the Scope section:
This catches scope gaps — work that was promised but not delivered.
Execute each verification command from the plan's ## Verification section:
If a verification command references tools or packages that aren't installed, mark as SKIP with explanation.
Look for and run the project's standard validation checks:
package.json for test, build, lint, typecheck scripts — run them if they existMakefile — run relevant targets if present.github/workflows/, .gitlab-ci.yml) — note what CI would runscripts/validate-*.sh) — run themRecord each result as PASS, FAIL, or SKIP (with reason).
Check if /work created a wisdom file for this execution:
Glob(".maestro/wisdom/*.md")
Generate the final report in this exact format:
## Review: {Plan Name}
**Plan**: `{plan file path}`
**Reviewed**: {current date}
---
### Objective
{State the objective from the plan}
**Met**: YES / PARTIAL / NO
---
### Task Completion
#### Task {N}: {Title}
**File**: `{path}`
**Commit**: `{SHA or "none"}`
**Status**: COMPLETE / PARTIAL / MISSING
| # | Criterion | Verdict | Evidence |
|---|-----------|---------|----------|
| 1 | {criterion text} | PASS/FAIL | {file:line or reason} |
| 2 | {criterion text} | PASS/FAIL | {file:line or reason} |
{Repeat for each task}
---
### Scope Compliance
**In-Scope Coverage:**
| Item | Status | Evidence |
|------|--------|----------|
| {in-scope item} | COVERED/UNCOVERED | {where implemented} |
**Out-of-Scope Violations:**
| Item | Status | Evidence |
|------|--------|----------|
| {out-scope item} | CLEAN/VIOLATION | {what was found} |
---
### Verification Results
| # | Check | Result | Output |
|---|-------|--------|--------|
| 1 | {verification command} | PASS/FAIL/SKIP | {summary} |
---
### Regression Check
| Check | Result | Output |
|-------|--------|--------|
| {check name} | PASS/FAIL/SKIP | {summary} |
---
### Wisdom Extraction
**Status**: PASS / FAIL
**File**: `{path or "none found"}`
---
### Remediation
{Only include this section if there are FAILs}
For each failure, provide a specific fix suggestion:
- **Task {N}, Criterion {M}**: {What needs to be done to fix it}
- **Scope violation — {item}**: {What to revert or how to address}
- **Verification — {check}**: {How to fix the failing check}
---
### Auto-Fix Results
{Populated by Step 9.5 — see below}
---
### Verdict: COMPLETE / NEEDS WORK / FAILED
**Summary**: {1-2 sentence summary}
- **COMPLETE**: All criteria PASS, scope is clean, verifications pass, wisdom extracted
- **NEEDS WORK**: Most criteria pass but some failures need attention
- **FAILED**: Majority of criteria fail or critical tasks are missing
{If NEEDS WORK or FAILED, list the specific items that need attention}
Populate every section. Do not skip sections — use "N/A" if a section has no applicable items. Be precise with evidence: include file paths and line numbers, not vague descriptions.
After generating the report, automatically fix issues that can be resolved with mechanical edits.
Review every FAIL finding from the report (Task Completion criteria, Scope violations, Verification failures). Classify each as:
For each fixable finding:
Edit(file_path, old_string, new_string) — use the smallest possible edit{file}:{line} — {description of fix}For each complex finding:
TODO: {Task N, Criterion M} — {what needs to be done}After all fixes are applied, re-run the verification commands from Step 6 and the regression checks from Step 7:
# Re-run plan verification commands
Bash("{each verification command from the plan}")
# Re-run project validation
Bash("{test/build/lint commands from Step 7}")
Record updated results.
Populate the Auto-Fix Results section in the report (the placeholder added in Step 9):
### Auto-Fix Results
**Fixed ({N} of {total FAIL count}):**
| # | Finding | File | Fix Applied |
|---|---------|------|-------------|
| 1 | {Task N, Criterion M or finding description} | `{file}:{line}` | {what was changed} |
**Unfixed — TODO ({M} remaining):**
| # | Finding | Reason |
|---|---------|--------|
| 1 | {Task N, Criterion M or finding description} | {why it couldn't be fixed inline} |
**Re-Verification:**
| # | Check | Before Fix | After Fix |
|---|-------|------------|-----------|
| 1 | {command or check name} | FAIL | PASS/FAIL |
If no FAILs were found in the report, populate the section with: No issues to fix.
After fixes, update the verdict based on remaining unfixed issues only:
Update the Verdict section at the bottom of the report to reflect post-fix state. Append a note:
Auto-fix applied: {N} issues fixed, {M} remaining as TODO.
If re-verification still shows FAIL results after auto-fix:
Exit conditions:
Update the final verdict and append: Auto-fix escalation: {N} additional issues fixed in {M} cycles, {R} remaining as TODO.
If the verdict is COMPLETE and the plan was loaded from .maestro/plans/ (not already in .maestro/archive/):
mkdir -p .maestro/archive/
mv .maestro/plans/{name}.md .maestro/archive/{name}.md
.maestro/archive/{name}.md"If the plan is already in .maestro/archive/, or the verdict is not COMPLETE, do nothing.
Trigger: Review found >= 2 FAIL findings (skip for clean reviews).
Auto-extract review insights as learned skills:
.claude/skills/learned/{slug}.md with triggers matching the pattern keywordsThis ensures recurring review failures get codified as skills that future agents will see, breaking the cycle of repeated mistakes.
When no plan is found, perform a structured code review based on git changes.
Identify what changes to review by checking the git state:
Check if on a feature branch (not main or master):
Bash("git rev-parse --abbrev-ref HEAD")
main or master)
Bash("git diff main...HEAD --name-only")
main/master: diff the most recent commit(s) with uncommitted changes
Bash("git diff HEAD --name-only")
Bash("git diff HEAD~1 --name-only")
If no changes are found at all: Report "No changes detected. Nothing to review." and stop.
Collect the full diff for the determined scope:
Bash("git diff main...HEAD") # or the appropriate diff command from above
List changed files with their change type (added/modified/deleted):
Bash("git diff main...HEAD --name-status")
Record the diff scope (branch name, commit range, or "uncommitted") for the report header.
For each changed file (skip deleted files), read the file and the relevant diff hunks. Check for:
For each file, read it:
Read("{file_path}")
Record findings as a list of {file, line, dimension, severity, description} tuples. Severity levels:
Spawn the security-reviewer agent for deep security analysis on the diff:
Task(
description: "Security review for code review",
subagent_type: "security-reviewer",
model: "sonnet",
prompt: |
Analyze the following diff for security vulnerabilities:
{diff from Step P1}
Check: auth/authz, input validation, secrets exposure, injection risks (SQL, XSS, command), dependency security, sensitive data logging, error message leaking.
Run ecosystem audit if applicable (bun audit / pip-audit / govulncheck).
Report each finding with: severity (Critical/High/Medium/Low), file:line, description, recommendation.
)
Map security-reviewer findings to review dimensions:
All findings go into the review's "Findings by File" table with Dimension = "Security".
For each changed file that contains implementation code (not test files, configs, or docs):
Identify the expected test file — Based on project conventions, determine where tests should live:
Glob("**/*test*{file_basename}*")
Glob("**/*{file_basename}*test*")
Glob("**/__tests__/{file_basename}*")
Glob("**/test_*{file_basename_no_ext}*")
Check test existence — Does a corresponding test file exist?
Check for test changes in the diff — Were test files modified as part of this change?
Record findings:
Run the project's standard validation checks (same as plan-based Step 7):
package.json for test, build, lint, typecheck scripts — run them if they existMakefile — run relevant targets if present.github/workflows/, .gitlab-ci.yml) — note what CI would runscripts/validate-*.sh) — run themRecord each result as PASS, FAIL, or SKIP (with reason).
If reviewing a branch with multiple commits, examine commit quality:
Bash("git log main..HEAD --oneline")
Check for:
console.log, debugger, print(), TODO/FIXME that appear to be temporary:
Grep("(console\\.log|debugger|print\\(|TODO|FIXME|HACK|XXX)", changed_files)
.env, credentials, or config files that might contain secretsRecord findings:
Generate the report in this exact format:
## Code Review: {branch name or "uncommitted changes"}
**Scope**: `{diff description, e.g., "feature-branch vs. main (12 commits, 8 files)"}`
**Reviewed**: {current date}
---
### Changed Files
| # | File | Status | Findings |
|---|------|--------|----------|
| 1 | `{path}` | Added/Modified/Deleted | {count} FAIL, {count} WARN, {count} INFO |
---
### Findings by File
#### `{file_path}`
| # | Line | Dimension | Severity | Finding |
|---|------|-----------|----------|---------|
| 1 | {line} | Quality/Security/Tests/Hygiene | FAIL/WARN/INFO | {description} |
{Repeat for each file with findings}
---
### Regression Check
| Check | Result | Output |
|-------|--------|--------|
| {check name} | PASS/FAIL/SKIP | {summary} |
---
### Summary
| Dimension | FAIL | WARN | INFO |
|-----------|------|------|------|
| Code Quality | {n} | {n} | {n} |
| Security | {n} | {n} | {n} |
| Test Coverage | {n} | {n} | {n} |
| Commit Hygiene | {n} | {n} | {n} |
| **Total** | **{n}** | **{n}** | **{n}** |
---
### Auto-Fix Results
{Populated by Step P7.5 — see below}
---
### Verdict: CLEAN / NEEDS WORK / FAILED
**Summary**: {1-2 sentence summary}
- **CLEAN**: No FAILs, few or no WARNs, regressions pass
- **NEEDS WORK**: No FAILs but multiple WARNs that should be addressed
- **FAILED**: One or more FAILs that must be fixed before merging
{If NEEDS WORK or FAILED, list the specific items that need attention}
Populate every section. If a file has no findings, omit it from "Findings by File" but keep it in the "Changed Files" table with "0 findings". Be precise with line numbers.
After generating the report, automatically fix issues that can be resolved with mechanical edits.
Review every FAIL finding from the report (Code Quality, Security, Test Coverage, Commit Hygiene dimensions). Classify each as:
console.log, debugger, print()), trivial naming fixes, missing type annotations with obvious types. The fix is unambiguous and localized to a few lines.Also review WARN findings — apply the same classification. Fix WARNs that are mechanical (e.g., removing a console.log), skip WARNs that require judgment.
For each fixable finding:
Edit(file_path, old_string, new_string) — use the smallest possible edit{file}:{line} — {description of fix}For each complex finding:
TODO: {Dimension, file:line} — {what needs to be done}After all fixes are applied, re-run the regression checks from Step P5:
# Re-run project validation
Bash("{test/build/lint commands from Step P5}")
If a regression check that previously passed now fails after a fix:
Edit to restore the original codeReverted — caused regression in {check name}Record updated results.
Populate the Auto-Fix Results section in the report (the placeholder added in Step P7):
### Auto-Fix Results
**Fixed ({N} of {total FAIL+WARN count}):**
| # | Finding | File | Fix Applied |
|---|---------|------|-------------|
| 1 | {Dimension: description} | `{file}:{line}` | {what was changed} |
**Unfixed — TODO ({M} remaining):**
| # | Finding | Reason |
|---|---------|--------|
| 1 | {Dimension: description} | {why it couldn't be fixed inline} |
**Re-Verification:**
| # | Check | Before Fix | After Fix |
|---|-------|------------|-----------|
| 1 | {check name} | PASS/FAIL | PASS/FAIL |
If no FAILs or fixable WARNs were found in the report, populate the section with: No issues to fix.
After fixes, update the verdict based on remaining unfixed issues only:
Update the Verdict section at the bottom of the report to reflect post-fix state. Append a note:
Auto-fix applied: {N} issues fixed, {M} remaining as TODO.
If re-verification still shows FAIL results after auto-fix:
Exit conditions:
Update the final verdict and append: Auto-fix escalation: {N} additional issues fixed in {M} cycles, {R} remaining as TODO.
Trigger: Review found >= 2 FAIL findings (skip for clean reviews).
Auto-extract review insights as learned skills:
.claude/skills/learned/{slug}.md with triggers matching the pattern keywordsThis ensures recurring review failures get codified as skills that future agents will see, breaking the cycle of repeated mistakes.