acceptance-criteria-define

Files (1)

• SKILL.md

SKILL.md (first lines)

# Acceptance Criteria: Define

## Step 0: Check for Context

If no request or task description was provided as context (the skill was invoked with no arguments and nothing in the conversation describes a feature, task, or plan to evaluate):

- Output: "This skill needs a request or task description as context. Please describe the feature or task you want acceptance criteria for, or point me to a plan file."
- **STOP — do not continue.**

---

## Step 1: Identify the Plan File (if any)

Check whether the context references an implementation plan file:

- Look for a file path ending in `.md` mentioned in the request or conversation (e.g., `.agents/plans/feature-name.md`)
- Look for any `.agents/plans/*.md` file that matches the feature being discussed

**If a plan file is identified:**
- Read the entire plan file now
- Scan for an existing `## ACCEPTANCE CRITERIA` or `## Acceptance Criteria` section
- If found, extract and note the existing criteria — these are your starting point
- Also scan the `## TESTING STRATEGY`, `## VALIDATION COMMANDS`, and `## Feature Description` sections to understand the full scope

**If no plan file:**
- Proceed with the request description from conversation context only

---

## Step 2: Derive Acceptance Criteria

Based on the context (plan file, feature description, or request in conversation), derive the acceptance criteria.

**Think through each of these dimensions and produce criteria for whichever apply:**

### Functional Correctness
- What must the feature actually do? (the happy paths)
- What inputs/outputs define success?
- What specific behaviors are required vs. optional?

### Error Handling & Edge Cases
- What happens on bad input, missing data, or failures?
- What state should the system be in after an error?

### Integration & End-to-End Flow
- What connected systems must work together for the feature to be considered complete?
- What does "it works" look like from the user's perspective end-to-end?

### Validation & Test Coverage
- Which test levels are required: unit, integration, E2E?
- What automated validation commands should pass before accepting the work?
- Are there manual steps required for final verification?

### Non-Functional Requirements
- Performance: any latency, throughput, or load requirements?
- Security: any auth, data handling, or secret management requirements?
- Observability: logging, error reporting, tracing requirements?

### Not In Scope
- Explicitly list what is NOT expected — this prevents scope creep during review

**Format each criterion as a concrete, testable statement, not a vague goal.**

Good: "The `/mcp/mcp` endpoint returns HTTP 200 with a valid MCP tools list when the server is running"
Bad: "The server should work correctly"

---

## Step 3: Present Criteria to User

Output your derived criteria in a clear, readable list. Use this format:

```
## Proposed Acceptance Criteria

### Functional
- [ ] <criterion>
- [ ] <criterion>

### Error Handling
- [ ] <criterion>

### Integration / E2E
- [ ] <criterion>

### Validation
- [ ] <criterion> — verified by: `<command or test>`

### Out of Scope
- <item> — not required for this task
```

### Auto-approval gate (non-interactive / indirect invocation)

Before asking the user anything, decide whether a user is actually present to confirm. The
AskUserQuestion below only makes sense when this skill was invoked **directly by the user**. When
it was invoked **indirectly** — by another skill, agent, or orchestrator running an automated flow
(e.g. `plan-feature` inside an automated planning/experiment harness, or a planning subagent) —
there is no one waiting to answer, and a blocking question would stall the whole flow.

Treat the invocation as **non-interactive** if ANY of these hold:
- the caller passed an auto-approve signal in context — e.g. `auto_approve: true`,
  `[non-interactive]`, or "auto-approve acceptance criteria"; or
- the context states this skill (or the skill that invoked it) was invoked indirectly / by another
  skill or agent rather than directly by the user.

**If non-interactive:** skip the AskUserQuestion below entirely and proceed with the **proposed
criteria as-is** (identical to option 1). Output one line noting it — "Acceptance criteria
auto-approved (non-interactive invocation)." — then continue to Step 4.

**If interactive (a user invoked this directly):** use **AskUserQuestion** to ask the user:

Question: "Do these acceptance criteria look right, or would you like to define them yourself?"
Options:
1. "Looks good — use these" — proceed with the proposed criteria as-is
2. "I want to add/change something" — user will provide modifications in free text
3. "Let me define them myself" — skip the proposed criteria entirely and wait for the user to write their own

---

From giladresisi/ai-dev-env, MIT.

More from giladresisi/ai-dev-env