القائمة
Use when changing production behavior, tests, policy gates, validators, docs, or exceptions where correctness, hidden debt, magic constants, stale contracts, or silent failures could ship.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when a request needs product/design exploration, unclear requirements, multiple viable approaches, UI/UX choices, or new behavior whose intent is not yet bounded.
Use when 2+ independent tasks, failures, research lanes, exploration lanes, or path-scoped investigations can run without shared state, shared files, or sequential dependency.
Use when executing a written implementation plan inline in the current session with checkpoints and verification.
Use when adding or changing a capability surface such as a public function, API, command, prompt, workflow, schema/helper, policy, or reusable instruction.
Use when implementation is complete, verification passes, and the remaining decision is how to integrate, merge, PR, clean up, or finish the branch.
Use when creating or revising docs, plans, records, PR text, handoffs, or other prose that should be sparse, direct, and low-context.
| name | quality-contracts |
| description | Use when changing production behavior, tests, policy gates, validators, docs, or exceptions where correctness, hidden debt, magic constants, stale contracts, or silent failures could ship. |
Quality rules are contracts with consequences and falsifiers, not style preferences. Invoke them only when they change proof or risk.
Redteam forwarder: For contracts with contested scope or high-stakes outcomes (auth, billing, security-relevant paths, policy changes), run /redteam:review to verify the contract holds against adversarial inputs before declaring it complete. The contract's falsifier field should itself be testable — use /redteam:verify to confirm.
Purpose: prevent changes from hiding defects behind prose, exemptions, or weak tests. Consumer: agents implementing, reviewing, validating, or documenting behavior. Failure consequence: gates pass while behavior remains unproved; future agents trust stale docs or exemptions; failures disappear from evidence. Falsifier: the change is cosmetic and cannot affect behavior, proof, observability, policy scope, or a public contract.
When any rule applies, state:
failure consequence: <what breaks>. falsifier: <what would prove this rule wrong>.
Core contracts:
If a rule applies but the consumer, consequence, or falsifier is unclear, stop with:
BLOCKED: purpose unclear - <missing field>.
