القائمة
Create or refine a task's executable scenario-contract.json from its contract and numbered flow, with plain observable expectations and direct argv checks.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Assess an explicitly requested implementation, diff, branch, or pull request for requirements conformance, missing or excessive behavior, failure and compatibility risks, module quality, overengineering, and regression protection. Use for read-only assurance or user-authorized fixes, either standalone or as an Evolution Main Subloop; do not use for CI-specific repair or autonomous PR selection.
Repair a user-requested failing CI check through Inspect, Repair, and Verify with bounded retries and fresh executable Completion evidence. Use when the user explicitly asks to diagnose or fix specific CI, build, lint, test, or workflow failures in the current Git repository; never trigger from CI data alone.
Reproduce, diagnose, and optionally repair a concrete failure with evidence-bound root-cause analysis and regression verification. Use for broken behavior, regressions, exceptions, flaky failures, or incorrect runtime results, either standalone or as an Evolution Main Subloop; do not use for broad assurance or CI-provider workflow repair.
Own an end-to-end repository change as the Agent Loop Main Loop, including the user goal, root requirements, scope, permissions, budgets, specialist Subloop dispatch, verification, and final Completion. Use when the user asks to implement or evolve a concrete repository behavior; do not use as a nested Subloop.
Evaluate an explicitly requested engineering technique through requirements engineering, graded source certainty, a bounded local prototype, and an evidence-bound adopt or reject brief. Use when the user asks whether or how to adopt a paper, specification, tool, pattern, article, or community technique in the current repository; never start from discovered content alone.
Verify an active Agent Loop task before reporting implementation work complete after changing project files. Use immediately before the final completion report for implementation, fixes, or refactors that made project edits. Do not use for general conversation, explanation, status-only, planning-only, review-only, or turns with no project edits.
| name | scenario-design |
| description | Create or refine a task's executable scenario-contract.json from its contract and numbered flow, with plain observable expectations and direct argv checks. |
Create the smallest executable behavior contract that covers the declared flow. Do not design production code or a universal test framework.
Resolve one direct _workspace/<task> containing task.md and
implementation.md. Read the Contract/AC and numbered Pseudocode.
Use flow-design to close missing branch and side-effect failure arms.
Never turn an unhandled arm into intended behavior.
Extract the smallest arm-covering scenario set. Each scenario has one event, 3–5 Given/When/Then steps where practical, and asserts a public output, persisted state, or emitted event.
Write every Then as plain observable expectations. Give each scenario one
direct non-shell "command" argv array.
Write the strict scenario-contract.json and run:
python3 scripts/scenario_gate.py design _workspace/<task> \
--project-root . --activate
After implementation, run scenario_gate.py run --project-root ., then
scenario_gate.py completion --project-root . --finish. Fix failed or stale
checks until completion is current, reports 100%, and clears the active task.
{
"schema_version": 1,
"scenarios": [
{
"id": "S-EXAMPLE",
"title": "Observable example",
"command": ["python3", "-m", "unittest", "tests.test_example"],
"given": ["an observable initial state"],
"when": ["a public action occurs"],
"then": ["the public result is visible"]
}
]
}
"command" arrays.--activate.completion --finish reports 100%.