القائمة
Format and quality rules for the validation contract — the flat, numbered, falsifiable assertion list every feature must satisfy. Activate when planning a mission or when validating one.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | validation-contracts |
| description | Format and quality rules for the validation contract — the flat, numbered, falsifiable assertion list every feature must satisfy. Activate when planning a mission or when validating one. |
The validation contract is a flat, numbered list of assertions about the system's behaviour. It is the source of truth for "is the mission done." It is written before any code and is immutable once approved.
Each assertion is one line:
AS-NNN: <single observable behaviour, present tense, no implementation detail>
Good examples:
AS-014: A user can send a message to a channel they have joined.AS-015: A user cannot send a message to a channel they have not joined; the API returns 403.AS-032: The unread count for a channel resets to 0 when the user opens that channel.AS-067: A new user's email is verified before they can send messages; unverified users see a banner prompting verification.Reject and rewrite examples:
AS-014: Auth works correctly. — not falsifiableAS-015: The MessageService class has a sendMessage method. — implementation, not behaviourAS-032: Users will be happy with the unread count. — not observableAS-067: The system should be secure. — too broad to assign or verifyusers CAN do X deserves a sibling users CANNOT do Y.Every assertion in the contract is assigned to at least one feature in
plan.md. The union of feature assignments equals the full contract. A
mission is done only when every assertion is GREEN across both the
scrutiny validator and (where behavioural) the UX validator.
Once missions/<id>/APPROVED exists, the contract is locked. Real life will
surface gaps anyway. When that happens:
plan.md in the appropriate milestone.This rule exists because a worker or validator may be referencing an old assertion ID in a half-written test or report. Renumbering breaks them silently.
Guidance for picking the right model per role ("droid whispering"). Activate when configuring agents, starting a new mission, or diagnosing why a role is misbehaving. Model strings age fast — verify current names via search per P-2 before relying on the defaults below.
How to set up every external service the project needs WITHOUT asking the user to run commands or follow long tutorials. The orchestrator handles all installation, configuration, MCP setup, and verification. The user provides only the data the orchestrator cannot obtain itself (credentials, choices). MCP servers are preferred over raw API integration where available.
How to run the two-round multiple-choice discovery questionnaire. Defines the 30 default round-1 questions across 6 categories, how to adapt them per project type, and how to generate the 15 round-2 follow-ups from gaps and contradictions.
How to produce the validation contract, draft plan, and tech-decisions from the description and discovery answers. Web-searches for current versions before committing to anything. Targets fine-grained feature decomposition (more features = better). Features here are DRAFTS — the /mission-tasks phase enriches them. Activate during /mission-plan.
Mandatory handoff template every worker fills out before exiting. The pre-worker-exit hook validates this file and blocks the worker if anything is missing. Activate inside any worker subagent.
Per-feature 20-question interrogation that turns a draft feature spec into a fully-specified one. Three rounds — 10 task questions, 5 follow-ups, 5 "definition of done" questions. Each question has 4 options with one ★ recommended based on context. Activate during /mission-tasks.