From autonomous-sdlc
Generates structured Given/When/Then acceptance criteria in markdown. Produces Gherkin-ready BDD specs with edge cases for pre-implementation requirements.
npx claudepluginhub joshuaoliphant/claude-plugins --plugin autonomous-sdlcThis skill uses the workspace's default tool permissions.
Co-author acceptance criteria with the user before code exists. Produce structured Given/When/Then specs that define *what* "done" means — the source of truth that feeds the SDLC pipeline (architect plans, builder TDD targets, validator reports, bdd-generate scaffolding).
Generates structured Given/When/Then acceptance criteria for user stories or features, covering happy path, edge cases, error states, and non-functional requirements for engineering/QA handoff.
Generates Gherkin (Given/When/Then) acceptance criteria from user stories or requirements. Covers happy paths, alternatives, negative scenarios, edge cases, and errors for automated tests.
Writes clear, testable acceptance criteria in Given-When-Then format following INVEST principles and BDD best practices. Useful for user story planning, design, and ensuring testable requirements.
Share bugs, ideas, or general feedback.
Co-author acceptance criteria with the user before code exists. Produce structured Given/When/Then specs that define what "done" means — the source of truth that feeds the SDLC pipeline (architect plans, builder TDD targets, validator reports, bdd-generate scaffolding).
Stance: assume the user is learning BDD. Guide, don't lecture. Ask questions, don't assert assumptions.
bdd-generate (Gherkin scaffolding). The handoff to bdd-generate is optional.## Acceptance Criteria: {Feature Name}
### AC-1: {Descriptive title}
**Given** {precondition — state before the action}
**When** {single action the user or system takes}
**Then** {verifiable, measurable outcome}
and {additional outcome on indented line}
**Edge cases:**
- {What should happen when...?}
**Notes:** {Open questions, V2 considerations, or scope decisions}
Design rules:
bdd-generateuser_id" is.### AC-N: Input validation (parameterized)
**Given** a user on the registration form
**When** the user submits with `<input>`
**Then** the system displays `<error_message>`
| input | error_message |
|-------|---------------|
| empty email | "Email is required" |
| "not-an-email" | "Invalid email format" |
| Anti-Pattern | Example | Fix |
|---|---|---|
| Implementation-as-criteria | "Then the system stores a bcrypt hash" | "Then the password is stored securely" |
| God criterion | AC covers login + session + redirect + audit | Split into AC-1, AC-2, AC-3, AC-4 |
| Missing the Given | "When the user clicks delete Then removed" | "Given a user viewing their own item When..." |
| Non-verifiable Then | "Then handles the error gracefully" | "Then displays 'Unable to process' and logs correlation ID" |
For structured probing questions organized by domain (input validation, auth, state integrity, concurrency, boundaries, errors, external deps, UX states), consult:
→ references/edge-case-checklist.md
For BDD terminology definitions, consult:
→ references/bdd-glossary.md
python ${CLAUDE_PLUGIN_ROOT}/scripts/feedback_manager.py autonomous-sdlc show-feedback
Apply relevant feedback: spec_writing, bdd_workflow, general.
Redirect implementation language to behavior language. "I need JWT authentication" → "Users need to log in and stay authenticated across requests."
Ask:
Red flag: if the user describes how instead of what, gently redirect.
Coach the Given/When/Then for the primary success scenario:
Write it. Read it back. Ask: "Does this capture what you mean?"
Consult references/edge-case-checklist.md for structured probing questions.
Present edge cases as questions, not assertions. Let the user decide what matters for V1:
For each confirmed edge case, write a full AC block or add to an existing AC's edge case list.
When 3+ edge cases follow the same behavioral pattern, consolidate into a parameterized table. Signs: "It should reject empty, too-long, and malformed input" or "Different roles have different permissions."
Read back all acceptance criteria, then:
Mark deferred items with "V2:" prefix in a Notes section.
Wait for user confirmation before considering the spec complete.
Structured acceptance criteria in markdown, ready to:
## Acceptance Criteria section of an architect plan documentbdd-generate for Gherkin scaffoldingAC-N numbers provide traceability across the entire SDLC pipeline.