Feature Forge
Turn fuzzy feature ideas into numbered Given-When-Then acceptance criteria so your agent and you share the same testable scope before coding.
Overview
feature-forge is an agent skill most often used in Validate (also Build and Ship) that produces Given-When-Then acceptance criteria for features.
Install
npx skills add https://github.com/jeffallan/claude-skills --skill feature-forgeWhat is this skill?
- Given-When-Then template with AC-### numbering for traceability
- Worked examples for happy path, error cases, and edge cases (login, cart, session expiry)
- Explicit Then/And outcomes so agents can map criteria to tests or tickets
- Scenario naming convention for readable specs and review threads
- Given-When-Then AC template with AC-### numbering
- Example sets cover happy path, error cases, and edge cases
Adoption & trust: 2.4k installs on skills.sh; 9.7k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know what feature you want but lack concrete, testable behaviors for happy paths, errors, and edge cases.
Who is it for?
Solo founders scoping MVPs, agent-driven implementers who need a spec fence, and indie teams aligning UX errors before merge.
Skip if: Fully specced tickets with existing Gherkin suites or pure visual design explorations with no behavioral contract.
When should I use this skill?
A feature needs testable acceptance criteria in Given-When-Then form before implementation or QA.
What do I get? / Deliverables
You get numbered AC-### scenarios in Given-When-Then format ready for implementation plans, manual QA, or automated test stubs.
- Numbered Given-When-Then acceptance criteria document
- Scenario groups for happy, error, and edge paths
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Acceptance criteria lock what “done” means during Validate scope, but the same ACs feed Build implementation and Ship testing. Given-When-Then scenarios define boundaries and edge cases before full build investment.
Where it fits
Forge ACs for checkout including empty-cart and session-expiry before you estimate the sprint.
Split a dashboard feature into AC-001..N so the agent implements redirects and toasts exactly as specified.
Walk manual QA down error-case ACs like invalid login without rewriting the spec.
How it compares
Structured acceptance-criteria authoring—not a Playwright runner or Figma handoff skill.
Common Questions / FAQ
Who is feature-forge for?
Solo and indie builders who want coding agents to implement against clear behavioral specs written as Given-When-Then criteria.
When should I use feature-forge?
During Validate scope when defining an MVP slice, in Build pm when breaking a feature into stories, and in Ship testing when turning behaviors into checklists.
Is feature-forge safe to install?
It is prose templates only; review the Security Audits panel on this page like any third-party skill before enabling in production repos.
SKILL.md
READMESKILL.md - Feature Forge
# Acceptance Criteria ## Given-When-Then Format ```markdown ### AC-001: [Scenario Name] Given [context/precondition] When [action taken] Then [expected result] ``` ## Examples by Type ### Happy Path ```markdown ### AC-001: Successful Login Given a registered user with valid credentials When they submit the login form Then they are redirected to the dashboard And a success message is displayed And their session is created ### AC-002: Add Item to Cart Given a logged-in user viewing a product When they click "Add to Cart" Then the item appears in their cart And the cart badge updates with the count And a confirmation toast is shown ``` ### Error Cases ```markdown ### AC-003: Invalid Login Given a user with incorrect password When they submit the login form Then an error message "Invalid credentials" is displayed And the password field is cleared And they remain on the login page ### AC-004: Duplicate Email Registration Given an email already exists in the system When a new user tries to register with that email Then an error message "Email already registered" is displayed And the form is not submitted ``` ### Edge Cases ```markdown ### AC-005: Empty Cart Checkout Given a user with an empty cart When they navigate to checkout Then they see "Your cart is empty" message And a "Continue Shopping" button is displayed ### AC-006: Session Expiry Given a user whose session has expired When they try to perform any authenticated action Then they are redirected to login And a message "Session expired, please log in again" is shown And their intended action is preserved for after login ``` ### Authorization ```markdown ### AC-007: Admin-Only Access Given a regular user (non-admin) When they try to access /admin/users Then they receive a 403 Forbidden response And are redirected to the home page And an "Access denied" message is shown ### AC-008: Own Resource Only Given a user viewing another user's profile When they try to edit the profile Then the edit button is not visible And direct URL access returns 403 ``` ## INVEST Criteria Good acceptance criteria follow INVEST: | Criterion | Description | Check | |-----------|-------------|-------| | **I**ndependent | Can be tested alone | No dependencies on other ACs | | **N**egotiable | Details can be discussed | Not over-specified | | **V**aluable | Delivers user value | Ties to requirement | | **E**stimable | Effort can be estimated | Clear scope | | **S**mall | Testable in one session | Not too broad | | **T**estable | Pass/fail is clear | Objective criteria | ## Quick Reference | Scenario Type | Given | When | Then | |---------------|-------|------|------| | Happy path | Valid state | Valid action | Success result | | Error | Invalid state/input | Action | Error message | | Edge case | Boundary condition | Action | Graceful handling | | Authorization | User role | Protected action | Appropriate access | | Concurrency | Multiple actors | Simultaneous action | Consistent state | # EARS Syntax ## EARS Format Easy Approach to Requirements Syntax for clear, unambiguous requirements. ### Basic Pattern ``` While <precondition>, when <trigger>, the system shall <response>. ``` ### Pattern Types **Ubiquitous (Always True)** ``` The system shall [action]. ``` Example: The system shall encrypt all passwords using bcrypt. **Event-Driven** ``` When [trigger], the system shall [action]. ``` Example: When the user clicks "Submit", the system shall save the form data. **State-Driven** ``` While [state], the system shall [action]. ``` Example: While the user is logged in, the system shall display the dashboard. **Conditional (Most Common)** ``` While [state], when [trigger], the system shall [action]. ``` Example: While the cart contains items, when the user clicks "Checkout", the system shall navigate to the payment page. **Optional** ``` Where [feature enabled], the system shall [action]. ``` Example: Where two-factor authentication is enabled, the system shall require a verif