القائمة
Define behavior and architecture before edits when a change is user-visible, risky, or not yet bounded.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use before saying work is complete, fixed, passing, approved, ready, or safe to hand off.
Compact engineering rules for implementation and review when the repository has no stronger local guidance.
Implement an accepted or clear change with minimal diff, direct verification, and no compatibility wrappers unless required by the contract.
Read-only investigation for unclear requests, bug reports, failures, architecture questions, or project health checks.
Install, repair, package, or verify the SpecPowers plugin and its generated payloads.
Review a diff, commit range, worktree, or implementation plan for correctness, risk, maintainability, and evidence gaps.
| name | define-change |
| description | Define behavior and architecture before edits when a change is user-visible, risky, or not yet bounded. |
Use this mode to turn intent into a behavior contract. Do not split the work into separate ceremony phases. Choose the smallest artifact scale that makes the next edit safe.
Every behavior-changing task needs these facts:
Use for small local work. Keep the contract inline in the conversation.
Use for ordinary features or fixes. Create one concise change note if the repository already keeps change artifacts; otherwise keep it inline.
Use for cross-module, high-risk, or still-unclear work. Create a file-backed brief with the behavior contract, design choices, task slices, and open risks.
When the contract is sufficient, hand off to execute-change with:
