بنقرة واحدة
code-review-protocol
Use when reviewing or requesting code review. Two-stage protocol with fresh-reviewer enforcement.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Use when reviewing or requesting code review. Two-stage protocol with fresh-reviewer enforcement.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | code-review-protocol |
| description | Use when reviewing or requesting code review. Two-stage protocol with fresh-reviewer enforcement. |
∀ code reviews (spec compliance ∨ code quality).
Stage 1 (spec compliance) MUST pass before Stage 2 (code quality) runs.
| Stage | Role | Checks | Verdict |
|---|---|---|---|
| 1: Spec | spec reviewer | ∀ criteria implemented? Extra work? Correct interpretation? | PASS ∨ FAIL |
| 2: Quality | code quality reviewer | Correctness, tests (edge cases), patterns, YAGNI, readability | APPROVE ∨ REQUEST_CHANGES |
Before requesting review, verify:
| Level | Meaning | Blocks? |
|---|---|---|
| Critical | Bug, security, data loss | Yes |
| Important | Pattern violation, missing tests, unclear logic | Yes |
| Minor | Style, naming, comment | No |
Core Principle: Only flag issues that cause real problems. Not theoretical concerns, not style preferences.
| Question | If Yes | If No |
|---|---|---|
| Bug ∈ prod? | Critical | Continue |
| Confuses next dev? | Important | Continue |
| ¬noticed ∈ 1000-line diff? | Skip | Continue |
| Blocks merge? | Flag | Skip |
| Just cosmetic? | Skip | Skip |
Anti-Pattern: Nitpicking wastes time and erodes trust. Prefer clear, blocking issues over style commentary.
¬agent reviews code it wrote. Verify reviewer hasn't authored the code under review.
Use when making git commits. Conventional commit format and rules.
Use when running security review on a diff/PR/file. Research-vs-Reporting discipline, three-tier confidence gate, attacker-controllable taxonomy.
Use when invoking plannotator for approval review of generated .tff-cc milestone artifacts (plan, verification, spec).
Use when starting design or discovery work. MUST use before any creative work.
Use when the user wants to report a bug, file an issue, or send feedback about tff-cc. Triggers on phrases like 'report issue', 'file a bug', 'tff-cc broke', 'something is wrong with tff-cc', 'open an issue', '/report-issue'.
Use when creating, refining, or composing skills. Evidence-driven pattern analysis.