一键在 Manus 中运行任何 Skill

validation-contracts

星标8

分支0

更新时间2026年6月14日 07:53

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 页面并帮你完成安装。

在 Manus 中运行

来源

cysecor

cysecor/exexutor

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Validation contracts

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.

Assertion format

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 falsifiable
AS-015: The MessageService class has a sendMessage method. — implementation, not behaviour
AS-032: Users will be happy with the unread count. — not observable
AS-067: The system should be secure. — too broad to assign or verify

Quality rules

Testable in one sentence. If you can't imagine the test, the assertion is too vague.
Behaviour, not structure. Never mention class names, function names, or file paths.
Independently failable. Each assertion can fail on its own without taking three others down with it.
Negative cases explicit. For every positive assertion, ask: what's the matching negative? users CAN do X deserves a sibling users CANNOT do Y.
No compound assertions. Split anything containing "and" into separate IDs.

Coverage

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.

Updates after approval

Once missions/<id>/APPROVED exists, the contract is locked. Real life will surface gaps anyway. When that happens:

NEVER modify or delete an existing assertion ID.
MAY append new assertion IDs with new numbers (skip gaps freely — never renumber).
MUST create new features to cover the new assertions and add them to 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.

同仓库更多 Skills

同仓库

model-selection

cysecor/exexutor

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.

2026-06-148

connection-setup

cysecor/exexutor

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.

2026-06-148

discovery-questions

cysecor/exexutor

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.

2026-06-148

mission-planning

cysecor/exexutor

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.

2026-06-148

structured-handoffs

cysecor/exexutor

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.

2026-06-148

task-clarification

cysecor/exexutor

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.

2026-06-148

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.

Validation contracts

Assertion format

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 falsifiable
AS-015: The MessageService class has a sendMessage method. — implementation, not behaviour
AS-032: Users will be happy with the unread count. — not observable
AS-067: The system should be secure. — too broad to assign or verify

Quality rules

Testable in one sentence. If you can't imagine the test, the assertion is too vague.
Behaviour, not structure. Never mention class names, function names, or file paths.
Independently failable. Each assertion can fail on its own without taking three others down with it.
Negative cases explicit. For every positive assertion, ask: what's the matching negative? users CAN do X deserves a sibling users CANNOT do Y.
No compound assertions. Split anything containing "and" into separate IDs.

Coverage

Updates after approval

Once missions/<id>/APPROVED exists, the contract is locked. Real life will surface gaps anyway. When that happens:

NEVER modify or delete an existing assertion ID.
MAY append new assertion IDs with new numbers (skip gaps freely — never renumber).
MUST create new features to cover the new assertions and add them to 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.