القائمة
Use when completing a feature, a design step, or before merging — runs a ≥2-peer consensus review and reconciles the findings, instead of a single rubber-stamp pass.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when bringing the harness method to a NEW or non-sentropic repo — maps the repo's conventions into a harness profile so the same scope/branch/verify kernel applies anywhere.
Use before any creative/design work (a feature, a package, an evolution) — explores intent and design via the spec-ladder with multi-peer adversarial review BEFORE implementation.
Use on any bug, test failure, or unexpected behaviour BEFORE proposing a fix — runs the generic evidence-first root-cause loop.
Use when you have a spec/decisions and need an executable plan — writes a lot-based BRANCH.md from the template and completes with track for realization state.
Use when adding or evolving tests for a feature/bugfix — applies the sentropic test-pyramid, scoped-test loop, environment isolation, and AI-flaky policy.
Load FIRST in any sentropic repo — establishes the harness method (branch/scope/test/debug/review/brainstorm/plan) and supersedes superpowers for those acts.
| name | review |
| description | Use when completing a feature, a design step, or before merging — runs a ≥2-peer consensus review and reconciles the findings, instead of a single rubber-stamp pass. |
Native sentropic code/design review. Stronger than a single review: ≥2 independent peers, distinct
lenses, reconciled. Open it with harness review "<target>" --consensus [--peers <n>] (records a
WorkEvent).
Before implementing a suggestion, verify it. If feedback is unclear or technically questionable, push back with evidence rather than complying blindly. Apply what's correct; refute what's wrong; ask when genuinely ambiguous.
Findings that gate a lot escalate to a VerificationRun (harness verify --category static). Narrative
findings stay a WorkEvent. Blocking findings must be resolved before merge; non-blocking are logged in
BRANCH.md ## Feedback Loop with owner + status.
