القائمة
Use after implementation to run independent code review - dispatches reviewer agents based on task level, ensures author-reviewer separation
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use for the L2+ browser-QA gate. Real-browser mode (Playwright Chromium) is opt-in (--browse / SGC_QA_REAL=1); by default runs a stub returning concern (never rubber-stamps). Writes verdict + findings to reviews/{task}/qa/.
Use when starting any conversation - establishes SGC commands, routes tasks to appropriate skills, and enforces system invariants
Use to capture knowledge from solved problems - extracts structured solution documents via 4 specialized agents with dedup enforcement
Use when requirements are unclear, before planning - clarifies goals, constraints, and acceptance criteria through structured questioning
Use when starting any non-trivial task - classifies task level (L0-L3), runs appropriate planning agents, produces intent document and execution plan
Use when ready to release - verifies all evidence, runs ship gate, handles deployment, triggers compound janitor
| name | review |
| description | Use after implementation to run independent code review - dispatches reviewer agents based on task level, ensures author-reviewer separation |
Dispatch reviewer agents (fresh context) against the current task's diff. Reviewers cannot read solutions/ — this is Invariant §1, not a suggestion.
Core principle: the author cannot review their own work. Reviewers must judge without historical-solution bias.
/review after /work is complete/ship (a code review is required for L1+)| Directory | Access |
|---|---|
| decisions | R |
| progress | R |
| solutions | FORBIDDEN (§1) |
| reviews | W |
src/commands/review.ts (runReview)src/dispatcher/agents/reviewer-correctness.ts — runs at every levelsrc/dispatcher/agents/reviewer-specialists.ts — reviewer.{security,migration,performance,infra} spawn in parallel when the diff matches their trigger keywords. Heuristic keyword matchers, not LLM-backed. Aggregate verdict = worst-of (pass < concern < fail)contracts/sgc-capabilities.yaml. What each one actually is: correctness is the only LLM-backed reviewer and runs at every level; tests + maintainability are always-on at L2+; security/migration/performance/infra are diff-conditional at L2+ — all six are heuristic keyword matchers. adversarial and spec are status: slot-only: manifested but NEVER dispatched, so do not route work to them expecting a result.spawn.ts emits scope_tokens: + FORBIDDEN from: read:solutions in every reviewer prompt (holistically verified by tests/eval/reviewer-isolation.test.ts)When this skill is invoked, dispatch to the sgc CLI:
bun src/sgc.ts review $ARGUMENTS
Re-running review for the same task throws AppendOnly — reviews are an audit trail, not a retry loop. To ship despite a fail verdict, supply --override "<≥40-char reason>" at sgc ship.
For broader static analysis beyond sgc's reviewer cluster:
gs:/review — pre-landing PR review with SQL safety, LLM trust boundary, and structural checksAt L2+ the dispatcher scans the diff and spawns matching specialists alongside reviewer.correctness and the always-on tests + maintainability pair. (Phase 2c / v1.27.0 lowered this gate from L3-only; this doc said L3 for four releases after that stopped being true.)
| Specialist | Trigger keywords (loose match, identifier-friendly) | Severity on hit |
|---|---|---|
reviewer.security | auth · jwt · token · session · crypto · password · secret · signature · encrypt/decrypt | medium |
reviewer.migration | migration · ALTER/DROP/CREATE TABLE · ALTER/RENAME COLUMN · backfill | high |
reviewer.performance | perf · cache · memoize · index · benchmark · n+1 · O(n) · p95/p99 | medium |
reviewer.infra | Dockerfile · FROM · kubectl · k8s · terraform · helm · fly.toml · vercel.json · render.yaml · github/workflows | high |
Patterns are deliberately loose (no word boundaries) so camelCase / snake_case identifiers like signJwt or auth_token still match — false positives are acceptable for a keyword stub; precision is the LLM path's job.