Skip to content
Back to skills

Acceptance Criteria Gen

ASecurity

Generate acceptance criteria tied to observable outcomes.

  • 8 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 2, 2026
ai-agentsgorails

Security analysis

A100/100

Pro scans all 7 files and shows the line behind each finding

Scanned September 20, 2026

npx -y skills add Eliyce/paqad-ai --skill acceptance-criteria-gen --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Acceptance Criteria Gen?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Acceptance Criteria Gen
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/eliyce-acceptance-criteria-gen/badge)](https://www.skillsdirectory.com/skills/eliyce-acceptance-criteria-gen)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: acceptance-criteria-gen
description: Generate acceptance criteria tied to observable outcomes.
model_tier: reasoning
triggers:
  - process_depth:
      - graduated lane
      - full lane
cacheable: false
cache_key_inputs: []
output_format: markdown
input_schema:
  request_text:
    type: string
    required: true
    description: Scoped request or story to convert into acceptance criteria.
  constraints_path:
    type: path
    required: false
    description: Optional canonical constraints document.
---

## What It Does

Turns a scoped request into testable acceptance criteria that describe observable behavior, guardrails, and failure handling without relying on implied implementation details.

## Use This When

Use this when a request is entering planning or solutioning and the current brief has goals but not enough precise behavior to verify. It is especially important before stories, test mapping, or handoff artifacts are written.

## Inputs

- Read the active request, tracker entry, or plan summary first.
- Read the canonical module docs or feature spec that defines the current behavior.
- Read `references/criteria-template.md` before drafting criteria so wording stays consistent.

## Procedure

1. Run `scripts/extract-ac-ids.sh <spec-file>` to get the set of AC ids already taken; never reuse a removed id.
2. For each new criterion, run `scripts/next-ac-id.sh <spec-file>` to allocate the next free flat id.
3. List the user-visible outcomes and constraints; convert each into one observable Given/When/Then line using `assets/output.template.md` as the shape, ending each line with an explicit `(proof: automated|manual|visual)` tag.
4. Surface negative and edge paths with the shared rubric instead of relying on the happy path alone: run `edge-case-detection` (`runtime/base/skills/edge-case-detection/SKILL.md`) over the same request as a sub-step. It is reused as-is — do not clone it — and its category set (empty, stale, loading, retry, permission, concurrency, rollback, integration, overflow, state-skip) already covers the paths acceptance criteria must guard. Follow each returned case's `Apply To:` routing: fold a case that changes an error, empty, or permission path the request actually touches into a flat `AC-n` negative-path criterion here (Given the failing/empty/unauthorized condition, when …, then the observable guard holds); record a case that is a deliberate exclusion — an edge behaviour the change will not handle — under the spec's `## Non-goals` section (parsed into `FeatureSpec.non_goals`) rather than as a criterion. Drop cases that are not credible for this request, and drop criteria that describe implementation choices instead of behavior.
5. Validate the draft with `scripts/lint-ac-output.sh <draft-file>` — exit 0 means the structural contract is met; non-zero means fix and re-lint before returning.

## Output Contract

- Match `assets/output.template.md`: a `## Acceptance criteria` heading, then one flat `- AC-N: Given …, when …, then … (proof: automated|manual|visual).` bullet per criterion, ending with a `## Coverage Notes` block.
- Use FLAT `AC-N` identifiers only. Dotted two-level `AC-N.N` ids are forbidden — the freeze parser reads flat ids and would renumber or drop a dotted one (issue #512, C4), so a block passing this skill can never fail the freeze on shape.
- Every criterion line carries an explicit `(proof: …)` tag so the frozen criterion has a proof type.
- Identifiers must be stable across spec revisions — removed criteria do not have their identifier reused.
- The output must pass `scripts/lint-ac-output.sh` with exit 0 before returning.

## Escalate / Stop Conditions

- Ask for clarification when the request does not define the actor, trigger, or expected result.
- Warn when canonical docs conflict with the requested behavior and note the drift explicitly.
- Stop short of inventing hidden business rules; record the gap instead.

## Resources

- `references/criteria-template.md`
- `scripts/extract-ac-ids.sh`
- `scripts/next-ac-id.sh`
- `scripts/lint-ac-output.sh`
- `assets/output.template.md`
- `runtime/base/skills/edge-case-detection/SKILL.md`
- `runtime/capabilities/coding/checklists/edge-cases-coding.md`
- `agents/openai.yaml`

Files in this skill

  • SKILL.md3 KB
  • agents/openai.yaml130 B
  • assets/output.template.md368 B
  • references/criteria-template.md293 B
  • scripts/extract-ac-ids.sh663 B
  • scripts/lint-ac-output.sh2 KB
  • scripts/next-ac-id.sh1.1 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.