القائمة
Transform vague acceptance criteria into concrete, machine-verifiable checks. Required for the planner agent when writing task ACs.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | actionable-acceptance-criteria |
| description | Transform vague acceptance criteria into concrete, machine-verifiable checks. Required for the planner agent when writing task ACs. |
Turn each acceptance criterion into something a reviewer can verify without reading the implementation or asking the author "did you do it?".
Every AC must be one of these forms:
| Form | Example |
|---|---|
| Command that exits 0 | cargo test --test e2e -- test_auth_flow passes |
| Command whose output contains X | curl -s localhost:8080/health returns {"status":"ok"} |
| File exists with content | src/models/user.rs exports a User struct with fields id: Uuid, email: String |
| Grep assertion | grep -r 'pub fn create_user' src/ matches exactly one file |
| Behavioral assertion | Clicking "Submit" with empty email shows "Email is required" inline (not an alert) |
| Negative assertion | cargo clippy -- -D warnings produces no output |
These are NOT actionable acceptance criteria:
For each AC the planner writes, run it through this checklist:
Each task should have 2-5 ACs. If you have more than 5, the task is too big; split it. If you have exactly 1, it's probably too vague; decompose it.
Bad:
acceptance_criteria:
- Authentication works
- Tests pass
Good:
acceptance_criteria:
- POST /api/auth/login with valid credentials returns 200 and a JSON body containing `token` (string) and `expires_at` (ISO 8601)
- POST /api/auth/login with invalid credentials returns 401 and `{"error":"invalid_credentials"}`
- cargo test --test auth -- test_login_valid exits 0
- cargo test --test auth -- test_login_invalid exits 0
Use when validating TUI or CLI behavior end-to-end via tmux. Provides the canonical pattern for spawning any terminal application inside tmux, sending keystrokes or shell commands, capturing pane output as plain text, and asserting on screen state. Works for full TUI apps (ratatui, bubbletea, etc.), interactive CLIs (REPLs, prompts), and non-interactive CLIs whose output needs visual inspection beyond what stdout parsing gives you.
Use when the orchestrator needs to resolve any mode-sensitive decision for the current TPM task — which reviewer dispatch pattern to invoke, how to aggregate verdicts, whether to run merge-resolver and QA, what to name Step 6b cleanup sessions. Encapsulates ALL fast / standard / prod tier policy so the orchestrator stays lean and `skills/dispatch-session/` stays mechanism-only. Required for the orchestrator agent at every tier-variant branch point.
Use when spawning a new agent session via Agent of Empires (AoE). Provides the canonical command patterns for spawning planner, implementer, reviewer, and merge-resolver sessions with the correct system prompts, worktrees, groups, and per-session event monitors. Required for the orchestrator agent.
Structured ideation skill for the planner agent. Explores alternative architectures, surfaces tradeoffs, and identifies constraints before committing to a decomposition. Invoked in standard/prod tiers; skipped in fast tier.
Use to discover a target repo's engineering philosophy from its on-disk conventions (CLAUDE.md + .claude/skills/**/SKILL.md). Required for the Principal Engineer agent in prod tier; invoked at the start of its review so findings can be grounded in the repo's own rules rather than reviewer opinion.
Use when reviewing code changes adversarially. Three-layer review with information asymmetry — Blind Hunter (diff only), Edge Case Hunter (diff + code access), Acceptance Auditor (diff + spec). Required for the Blind Hunter / Edge Case Hunter / Acceptance Auditor agents and invoked transitively by the orchestrator when dispatching reviewers.