القائمة
Code review process and quality framework. Use when reviewing PRs, auditing code quality, or evaluating AI-generated code. Pair with language-specific code-review skill.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | code-review |
| description | Code review process and quality framework. Use when reviewing PRs, auditing code quality, or evaluating AI-generated code. Pair with language-specific code-review skill. |
Systematic review across five axes. Work through each in order. Report findings per category.
Every comment MUST have a severity prefix:
| Prefix | Meaning | Author Action |
|---|---|---|
| Critical: | Blocks merge. Security, data loss, crash. | Must fix |
| Important: | Bug risk, missing error handling, design issue | Should fix |
| Suggestion: | Style, minor optimization, readability | Nice to have |
| Nit: | Trivial, optional | May ignore |
| FYI | Informational only | No action needed |
| Lines Changed | Assessment |
|---|---|
| ~100 | Good — easy to review thoroughly |
| ~300 | Acceptable if single logical change |
| ~1000+ | Too large — must split before review |
| Strategy | When |
|---|---|
| Stack | Sequential dependencies — submit small change, next one builds on it |
| By file group | Different reviewers needed for different parts |
| Horizontal | Shared code/stubs first, then consumers |
| Vertical | Smaller full-stack slices of the feature |
## Review: [package or file]
**Verdict**: [APPROVE / REQUEST CHANGES / COMMENT]
### Critical
- [file:line] Description. Fix: [specific fix]
### Important
- [file:line] Description. Fix: [specific fix]
### Suggestions
- [file:line] Description
### Positive
- [Brief note on what was done well]
### Summary
[1-2 sentences: overall assessment + what was verified]
| Shortcut | Reality |
|---|---|
| "LGTM, looks fine" | Rubber-stamping is not reviewing. Check each axis systematically. |
| "It works, so it's correct" | Working code can still have races, leaks, and security holes. |
| "AI-generated code is probably fine" | AI code needs more scrutiny. It's confident and plausible, even when wrong. |
| "It's too big to review properly" | Then it's too big to merge. Split it first. |
Spec-driven development workflow. Main Claude acts as the lead — spawns critic/scout/architect/builder/tester/reviewer as subagents, enforces human-in-the-loop gates at every phase boundary via AskUserQuestion, records every decision in docs/specs/<slug>/group-log.md. Load this skill whenever the user invokes /define, /orchestrate, /plan, /build, or /ship; whenever a task spans multiple files, packages, or concerns; whenever design decisions need review before implementation; whenever an in-progress spec under docs/specs/<slug>/ needs to resume; or whenever you're about to coordinate critic/scout/architect/builder/tester/reviewer in a sequence. This is the correct skill for any multi-step engineering task that benefits from gated, auditable execution — do not try to coordinate specialists ad-hoc.
Artifact contract for docs/specs/<slug>/ — spec.md template, frontmatter schema (task/status/current_group/total_groups/created/updated), spec directory layout, contracts-trigger rules, and parallelization markers ([P]). Load this skill whenever you're creating a new docs/specs/<slug>/ directory, authoring or editing spec.md, checking whether an existing spec matches the template (e.g., during review, resumption, or session-start scan), validating frontmatter values, or deciding whether a task needs contracts.md. Pair with core/orchestration, which owns the workflow that populates these artifacts.
Author and maintain a project constitution at docs/constitution.md — the list of invariants that reviewer and critic enforce on every spec and every diff. Load this skill whenever you're creating a new constitution from scratch or from EXAMPLE_CONSTITUTION.md, proposing candidate invariants via /constitution-propose, adding or editing an invariant, sunsetting an obsolete rule, or promoting a recurring "don't do X" review comment into an enforced invariant. Also use when a post-incident review surfaces a rule that should have been caught mechanically. Reviewer and critic consume the registered invariants automatically via the project_constitution session-start field — you do not need this skill for enforcement, only for authoring.
Ground a task in the existing codebase before specification — grep for prior art, read similar features, surface inherited gotchas, write discovery.md. Load this skill whenever you're running scout during /define or /orchestrate, whenever a task touches an area of the codebase you have not read in this session, whenever the task mentions a feature name that might already exist, or whenever recent_learnings flags a gotcha or pattern near the task. Prevents specs built on phantom assumptions.
Decision tree for routing any task to the right agent and skill set. Loaded on session start and consulted whenever you're unsure which specialist applies, which skill combination to load for a given task, or when main Claude (running core/orchestration) needs to decide which subagent to spawn for a Phase 3 subtask. Also surfaces available CLI tools, MCP servers, and user-installed skills/agents/plugins so you can prefer what's actually on the machine.
Output compression for human-facing responses. Use when responding to users in a terminal, writing end-of-turn summaries, explaining diffs, producing status updates, or any non-artifact output addressed to a human reader. Specifies what to compress (articles, filler, pleasantries, hedging) and what to leave full-fidelity (SPEC files, agent-to-agent reports, commands, code blocks, paths, acceptance criteria, inline docstrings). Triggered automatically by the /compact slash command and loaded by all agents by default.