القائمة
Reviews pull requests with scope validation, requirements compliance, and line comments. Use when reviewing GitHub or GitLab PRs.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/athola/claude-night-market --skill pr-reviewيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Turn hunches into accepted results: worthiness score, evidence bar, research-to-rules. Use when vetting ideas. Not for QA; use night-market-validation-and-qa.
Generates and self-executes a diff-derived test plan for a PR. Use when validating PR changes before merge. Do not use for code review; use sanctum:pr-review.
Curate the web-capture index. Use when the capture backlog grows, captures sit unprocessed at seedling/pending, or to surface stored research during work.
عرض SKILL.md
استنادا إلى تصنيف SOC المهني
| name | pr-review |
| description | Reviews pull requests with scope validation, requirements compliance, and line comments. Use when reviewing GitHub or GitLab PRs. |
| alwaysApply | false |
| category | review |
| tags | ["pr","review","scope","github","gitlab","code-quality","knowledge-capture","cross-platform"] |
| tools | [] |
| usage_patterns | ["scope-validation","backlog-triage","requirement-compliance","knowledge-capture"] |
| complexity | intermediate |
| model_hint | standard |
| estimated_tokens | 500 |
| progressive_loading | true |
| modules | ["modules/comment-guidelines.md","modules/educational-insights.md","modules/github-comments.md","modules/knowledge-capture.md","modules/pr-hygiene.md","modules/version-validation.md","modules/pr-hygiene.md","modules/insight-generation.md"] |
| dependencies | ["leyline:git-platform","sanctum:git-workspace-review","sanctum:version-updates","pensive:unified-review","imbue:proof-of-work","imbue:justify","imbue:review-core","imbue:structured-output","memory-palace:review-chamber","scribe:slop-detector","scribe:doc-generator"] |
| role | entrypoint |
Review pull/merge requests with discipline: validate against original requirements, prevent scope creep, and route out-of-scope findings to issues on the detected platform.
Platform detection is automatic via leyline:git-platform. Use gh for GitHub, glab for GitLab. Check session context for git_platform:.
A PR review validates scope compliance, not code perfection.
The goal is to validate the implementation meets its stated requirements without introducing regressions. Improvements beyond the scope belong in future PRs.
Every finding must be classified:
| Category | Definition | Action |
|---|---|---|
| BLOCKING | Bug, security issue, or regression introduced by this change | Must fix before merge |
| IN-SCOPE | Issue directly related to stated requirements | Should address in this PR |
| SUGGESTION | Improvement within changed code, not required | Author decides |
| BACKLOG | Good idea but outside PR scope | Create GitHub issue |
| IGNORE | Nitpick, style preference, or not worth tracking | Skip entirely |
BLOCKING:
IN-SCOPE:
SUGGESTION:
BACKLOG:
IGNORE:
Before looking at ANY code, understand what this PR is supposed to accomplish.
Note: Version validation (Phase 1.5) runs AFTER scope establishment but BEFORE code review. See modules/version-validation.md for details.
Search for scope artifacts in order:
Plan file: Most authoritative (check spec-kit locations first, then root)
# Spec-kit feature plans (preferred - structured implementation blueprints)
find specs -name "plan.md" -type f 2>/dev/null | head -1 | xargs cat 2>/dev/null | head -100
# Legacy/alternative locations
ls docs/plans/ 2>/dev/null
# Root plan.md (may be Claude Plan Mode artifact from v2.0.51+)
cat plan.md 2>/dev/null | head -100
Verification: Run the command with --help flag to verify availability.
Spec file: Requirements definition (check spec-kit locations first)
find specs -name "spec.md" -type f 2>/dev/null | head -1 | xargs cat 2>/dev/null | head -100
cat spec.md 2>/dev/null | head -100
Verification: Run the command with --help flag to verify availability.
Tasks file: Implementation checklist (check spec-kit locations first)
find specs -name "tasks.md" -type f 2>/dev/null | head -1 | xargs cat 2>/dev/null
cat tasks.md 2>/dev/null
Verification: Run the command with --help flag to verify availability.
PR/MR description: Author's intent
# GitHub
gh pr view <number> --json body --jq '.body'
# GitLab
glab mr view <number> --json description --jq '.description'
Verification: Run the command with --help flag to verify availability.
Commit messages: Incremental decisions
# GitHub
gh pr view <number> --json commits --jq '.commits[].messageHeadline'
# GitLab
glab mr view <number> --json commits
Verification: Run the command with --help flag to verify availability.
Output: A clear statement of scope:
"This PR implements [feature X] as specified in plan.md. The requirements are:
- [requirement]
- [requirement]
- [requirement]"
If no scope artifacts exist, flag this as a process issue but continue with PR description as the baseline.
# GitHub
gh pr diff <number> --name-only
gh pr diff <number>
gh pr view <number> --json additions,deletions,changedFiles,commits
# GitLab
glab mr diff <number>
glab mr view <number>
Verification: Run the command with --help flag to verify availability.
Before detailed code review, check scope coverage:
Run version validation checks BEFORE code review.
See modules/version-validation.md for detailed validation procedures.
Quick reference:
--skip-version-check, label, or PR marker)All version mismatches are BLOCKING unless explicitly waived by maintainer.
Before diving into code, run the PR hygiene checks from
modules/pr-hygiene.md:
Atomicity check: Does this PR contain one logical change? Flag mixed commit types (feat, refactor, and fix), formatting commits bundled with logic, or changes spanning unrelated subsystems. Large PRs get 30% defect detection vs 75% for focused ones.
Agent curation check: Does the code show signs of iterative AI generation without a cleanup pass? Look for redundant implementations, premature abstractions, incomplete refactors, and scope drift.
Self-review signals: Are there unsquashed fixup commits, debug statements, or commented-out code that suggest the author did not read their own diff before sending?
Classify findings per modules/pr-hygiene.md severity tables.
Use pensive:unified-review on the changed files. For comment quality assessment, see modules/comment-guidelines.md.
Critical: Evaluate each finding against the scope baseline:
**Verification:** Run the command with `--help` flag to verify availability.
Finding: "Function X lacks input validation"
Scope check: Is input validation mentioned in requirements?
- YES → IN-SCOPE
- NO, but it's a security issue → BLOCKING
- NO, and it's a nice-to-have → BACKLOG
Verification: Run the command with --help flag to verify availability.
Run Skill(imbue:justify) on the PR changes to detect
AI additive bias, test-logic tampering, and unnecessary
complexity.
Key checks:
Classify justify findings using the scope framework:
| Justify Signal | Likely Classification |
|---|---|
| Test logic tampered | BLOCKING |
| High additive bias, no justification | IN-SCOPE |
| Premature abstraction | SUGGESTION |
| Compatibility shim | BACKLOG |
Include the additive bias score and Iron Law status in the Phase 6 report.
Check whether the PR touches existing design invariants. This is a judgment problem that models get wrong far too often: surface conflicts for human review rather than silently accepting or rejecting them.
Quick detection heuristic:
# Check for structural pattern changes
git diff --name-only HEAD...origin/master 2>/dev/null \
| rg "(interface|types|schema|model|base|core|contract)" \
|| git diff --name-only HEAD...origin/master 2>/dev/null \
| grep -E "(interface|types|schema|model|base|core|contract)"
When a conflict is detected:
Do NOT resolve it. Add to the report as a special category:
| Category | Definition | Action |
|---|---|---|
| INVARIANT | Change conflicts with an existing design decision | Escalate to human with 3-option analysis |
For each invariant conflict, present:
Classification: INVARIANT findings are always BLOCKING, not because the code is wrong, but because the judgment call requires human input. Only the human reviewer can decide which of the three options is right.
Why this matters: Bad invariant decisions compound. A few wrong calls and the codebase becomes unsalvageable. This is not a context problem solvable with better documentation: it is a judgment problem that requires human wisdom.
For each BACKLOG item, create an issue on the detected platform:
# GitHub
gh issue create \
--title "[Tech Debt] Brief description" \
--body "## Context
Identified during PR #<number> review.
..." \
--label "tech-debt"
# GitLab
glab issue create \
--title "[Tech Debt] Brief description" \
--description "## Context
Identified during MR !<number> review.
..." \
--label "tech-debt"
Verification: Run the command with --help flag to verify availability.
Ask user before creating: "I found N backlog items. Create issues? [y/n/select]"
Structure the report by classification. Every BLOCKING and
IN-SCOPE finding MUST include educational insights per
modules/educational-insights.md: Why (the principle),
Proof (link to best practice), and a Teachable Moment
(generalized lesson). SUGGESTION findings include Why and
optionally Proof. BACKLOG items need only a brief rationale.
## PR #X: Title
### Scope Compliance
**Requirements:** (from plan/spec)
1. [x] Requirement A - Implemented
2. [x] Requirement B - Implemented
3. [ ] Requirement C - **Missing**
### Blocking (1)
1. [B1] SQL injection via string concatenation
- **Location**: `db/queries.py:89`
- **Anchor**: `cursor.execute("SELECT * FROM t WHERE id = " + uid)`
- **Issue**: User input interpolated directly into SQL
- **Why**: String-interpolated SQL allows attackers to
execute arbitrary queries (CWE-89). This is the #1
web application vulnerability per OWASP Top 10.
- **Proof**: [OWASP SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection)
- **Teachable Moment**: Always use parameterized queries
or an ORM. This applies everywhere user input reaches
a database, cache, or search engine query.
- **Fix**: Use parameterized query:
`cursor.execute("SELECT * FROM t WHERE id = ?", (uid,))`
### In-Scope (1)
1. [S1] Missing validation for edge case
- **Location**: `api.py:45`
- **Anchor**: `def handle_request(payload):`
- **Issue**: Empty input not handled per requirement
- **Why**: Defensive validation at API boundaries
prevents cascading failures in downstream logic.
- **Proof**: [Postel's Law](https://en.wikipedia.org/wiki/Robustness_principle)
- **Teachable Moment**: Validate inputs at system
boundaries (API handlers, CLI args, file parsers)
but trust internal function contracts.
### Suggestions (1)
1. [G1] Consider extracting helper function
- **Why**: The repeated pattern on lines 30-35 and
72-77 violates DRY. Extracting it reduces future
bug surface.
- Author's discretion
### Backlog → GitHub Issues (3)
1. #142 - Refactor authentication module
2. #143 - Add caching layer
3. #144 - Update deprecated dependency
### Recommendation
**APPROVE WITH CHANGES**
Address B1 and S1 before merge.
--local)When --local [path] is passed, write the Phase 6 report to a
local .md file instead of posting via API. Default path:
.pr-review/pr-<number>-review.md. The file includes the
review summary, test plan, and backlog items in a single
document. Issue creation and PR description updates are skipped.
Knowledge capture (Phase 7) still runs.
After generating the report, evaluate findings for knowledge capture into the project's review chamber.
Trigger: Automatically for findings scoring ≥60 on evaluation criteria.
# Capture significant findings to review-chamber
# Uses memory-palace:review-chamber evaluation framework
Verification: Run the command with --help flag to verify availability.
Candidates for capture:
decisions/patterns/standards/lessons/Output: Add to report:
### Knowledge Captured 📚
| Entry ID | Title | Room |
|----------|-------|------|
| abc123 | JWT over sessions | decisions/ |
| def456 | Token refresh pattern | patterns/ |
View: `/review-room list --palace <project>`
Verification: Run the command with --help flag to verify availability.
See modules/knowledge-capture.md for full workflow.
A PR should be approved when:
"While you're here, you should also refactor X, add feature Y, and fix Z in adjacent files."
Do: Create backlog issues, keep PR focused.
"This works but could be 5% more efficient with different approach."
Do: If it meets requirements and has no bugs, it's ready.
"I prefer tabs over spaces."
Do: Use linters for style, reserve review for logic.
"The file you imported from has some issues..."
Do: That's a separate PR. Create an issue if important.
"Here's a test showing the old behavior was wrong."
Do: Write tests that break if your fix is reverted.
Tests should protect against regressions in your code,
not document why the change was needed. See
modules/pr-hygiene.md Principle 4.
"I also reformatted the file and fixed a typo in another module."
Do: One PR = one logical change. Formatting, refactors,
and unrelated fixes belong in separate PRs. See
modules/pr-hygiene.md Principle 2.
"It works and the tests pass."
A PR where the author cannot explain how each changed section works and how it might fail is not ready to merge. This is especially true for AI-assisted code: generation speed creates the illusion of understanding.
Do: Before marking a PR ready, ask the reviewing agent to question you about the changed code: how each part works, what assumptions it makes, and what inputs would break it. Continue until you can answer without hesitation. Only merge code you own front-to-back.
This applies to self-reviews: run the same probe before requesting external review. Do not submit a PR for review that you yourself do not fully understand.
pr-review:findings-verified)Every finding must cite a real location and a verbatim anchor. Write
findings to .review/findings.json and confirm each citation resolves:
python plugins/imbue/scripts/citation_verifier.py \
--findings .review/findings.json --repo-root .
Drop or label UNVERIFIED any finding the verifier fails (exit 1); only
verified findings enter the report. See Skill(imbue:review-core) Step 5
and Skill(imbue:structured-output) for the schema.
/fix-pr: After review identifies issues, use this to address them/pr: To prepare a PR before reviewpensive:unified-review: For the actual code analysispensive:bug-review: For deeper bug hunting if neededscribe:slop-detector: For documentation AND commit message quality analysisscribe:doc-generator: For PR description writing guidelines (slop-free)For all changed .md files, invoke Skill(scribe:slop-detector):
--strict modeScan all PR commit messages for slop markers:
gh pr view <number> --json commits --jq '.commits[].messageBody' | \
grep -iE 'leverage|seamless|comprehensive|delve|robust|utilize|facilitate'
If slop found in commits: Add to SUGGESTION category with remediation guidance.
Apply scribe:slop-detector to PR body:
Location (file:line) and
verbatim Anchor; citation_verifier.py confirmed all citations
(exit 0) or unverified findings are dropped/labeled UNVERIFIEDgh api patterns for inline and summary PR comments