メニュー
This skill should be used when the user asks to "define acceptance criteria", "what are the success criteria", "set quality gates", "establish acceptance tests", "define what success looks like", or needs to specify pre-declared success criteria before code execution begins.
This skill should be used when the user asks to "show audit trail", "why did we make this decision", "what happened after this", "trace this decision", "show decision history", "search audit log", or needs to understand the decision history and rationale behind code changes verified through coherence check.
This skill should be used when the user asks to "check this code", "validate this", "verify this implementation", "is this correct", "review this code", "check for errors", "multi-agent verification", or mentions production-critical code, financial calculations, security implementations, or high-stakes operations. Provides comprehensive multi-agent verification workflow with specialized critic agents.
This skill should be used when the user asks to "review the plan", "check the execution plan", "validate this plan", "is this plan good", or automatically after the planner agent creates an execution plan. Validates plans for completeness, clarity, measurability, and proper acceptance criteria before execution begins.
This skill should be used when the user asks to "verify critic independence", "check for overlapping failures", "validate swiss cheese model", "are the critics independent", "measure orthogonality", or needs to verify that multiple critic layers have misaligned failure modes as required by the swiss cheese model.
This skill should be used when the user asks to "use backward design", "create curriculum using UbD", "design learning outcomes first", "start with desired results", "plan assessments before activities", "design assessments first", "create outcomes-based curriculum", or references Understanding by Design framework. Also applies when user mentions aligning outcomes with assessments or avoiding activity-first planning. Provides comprehensive guidance on applying backward design methodology to create effective curricula for 1-2 day intensive workshops.
This skill should be used when the user asks to "write learning objectives", "create measurable learning outcomes", "select action verbs for objectives", "what cognitive levels should I target", "how to scaffold learning", "write course objectives", "make objectives more specific", or references Bloom's taxonomy. Also relevant when users say "my objectives aren't measurable", "how do I assess what students learned", or "progression from basic to advanced skills". Provides comprehensive guidance on applying Bloom's taxonomy to create measurable, appropriately-leveled learning objectives for intensive workshops.
| name | Acceptance Criteria |
| description | This skill should be used when the user asks to "define acceptance criteria", "what are the success criteria", "set quality gates", "establish acceptance tests", "define what success looks like", or needs to specify pre-declared success criteria before code execution begins. |
Define specific, measurable acceptance criteria before any code execution, following test-driven development principles. Criteria serve as quality gates that critics evaluate with veto authority.
Must be:
/acceptance-criteria define for authentication refactoring:
- All existing tests must pass
- No OWASP Top 10 vulnerabilities
- Token storage uses httpOnly cookies
- Coverage maintains above 85%
Parsed automatically into structured format.
criteria:
- name: Test Pass Rate
description: All existing auth tests pass
validator: code-critic
threshold: 100%
- name: Security Compliance
description: No OWASP Top 10 vulnerabilities introduced
validator: security-critic
checklist: OWASP-2021
- name: Code Coverage
description: Maintain test coverage
validator: code-critic
threshold: ">= 85%"
/acceptance-criteria use template financial
Loads pre-built criteria set for financial calculations.
---
domain: financial
criteria:
- Decimal precision maintained (no float arithmetic)
- Banker's rounding applied (IEEE 754)
- All operations logged to audit trail
- Results formatted to 2 decimal places
- Currency conversion explicit (no implicit conversions)
validators:
- domain-critic (financial specialization)
- code-critic (logic verification)
---
---
domain: security
criteria:
- No SQL injection vectors (parameterized queries only)
- No XSS vulnerabilities (output escaping verified)
- Authentication bypass prevented (auth required on protected routes)
- HTTPS enforced (no plaintext transmission)
- Secrets not in code (environment variables used)
- Password hashing with bcrypt/argon2
validators:
- security-critic
- code-critic (implementation check)
---
---
domain: performance
criteria:
- API latency < 200ms (95th percentile)
- Database queries < 10ms
- No N+1 query patterns
- Memory usage < 512MB
- Caching implemented for expensive operations
validators:
- code-critic (performance checks)
- domain-critic (SLA validation)
---
Each criterion evaluated by assigned critic:
Code Critic checks:
Security Critic checks:
Domain Critic checks:
Update criteria based on lessons learned:
/acceptance-criteria add to financial template:
- Handle leap year calculations correctly
- Timezone conversions must be explicit
Criteria library grows with project experience.
templates/financial.yaml - Financial calculation standardstemplates/security.yaml - OWASP checklist and auth patternstemplates/performance.yaml - Latency SLAs and optimizationreferences/criteria-library.md - All available criteria sets