Acceptance Pipeline Feature Design
Guides agents through designing new features that extend Uncle Bob's Acceptance Pipeline Specification. Produces spec-quality output — language-neutral, implementation-agnostic, with precise behavioral requirements — that matches the style and rigor of the original spec.
This is a composition skill. It does not catalog what exists (that is acceptance-pipeline-catalog's job). Instead, it provides a structured workflow for designing what comes next.
When to Apply
- Designing a new mutation strategy, value type, or filter mechanism for the mutator
- Adding new Gherkin syntax support (data tables, tags, Rules keyword) to the parser
- Extending the JSON IR with new fields or objects
- Creating new report formats (HTML, JUnit XML) or output channels
- Adding new pipeline stages or operating modes (parallel runs, coverage filtering)
- Any spec-level change that affects multiple pipeline components (cross-cutting)
Prerequisite
Before using this skill, ensure acceptance-pipeline-catalog is available. That skill provides the baseline reference for the 9 required components, JSON IR schema, conformance checklist (21 items), and agent setup checklist (15 steps). This skill builds on top of that foundation.
Workflow Overview
The workflow has five phases, executed in order. Each phase builds on the output of the previous one — skipping phases produces incomplete or inconsistent designs.
Phase 1: Survey Existing Spec → Know what exists before proposing changes
Phase 2: Identify Extension Point → Classify where the feature attaches
Phase 3: Draft Feature Spec → Write the spec section in Uncle Bob's style
Phase 4: Conformance Design → Add testable conformance items
Phase 5: Impact Analysis → Assess backward compatibility and migration
Why this order matters:
- Phase 1 prevents reinventing existing capabilities and ensures the design uses established patterns.
- Phase 2 forces classification before writing — a parser extension has different constraints than a reporter extension.
- Phase 3 produces the actual spec text, informed by the classification from Phase 2.
- Phase 4 ensures the feature is testable from outside the implementation — if you cannot write conformance items, the spec is too vague.
- Phase 5 comes last because you need the complete spec and conformance items to assess impact accurately.
How to Use
- Start by reading the
acceptance-pipeline-catalog skill to understand the current spec
- Read the phase reference that matches your current workflow step:
| Phase |
Reference |
When to Read |
| 1 |
Survey Existing Spec |
Always — first step for any feature design |
| 2 |
Identify Extension Point |
After survey — classify where the feature attaches |
| 3 |
Draft Feature Spec |
After classification — write the spec section |
| 4 |
Conformance Design |
After drafting — add testable conformance items |
| 5 |
Impact Analysis |
After conformance — assess compatibility |
- Consult supporting references as needed:
| Reference |
When to Read |
| Style Guide |
During Phase 3 — Uncle Bob's spec writing patterns |
| Extension Catalog |
During Phase 2 — ideas and complexity notes for future extensions |
Extension Point Quick Reference
Features attach to one or more of these 9 components. The JSON IR is the highest-impact extension point because all components consume it.
| Extension Point |
What Changes |
Impact Level |
| Parser |
New Gherkin syntax accepted |
Medium — affects IR and downstream |
| IR |
New fields or objects in JSON interchange |
High — all consumers affected |
| Generator |
New output formats or generation strategies |
Low — isolated to generation |
| Runtime |
New execution modes, hooks, dispatch |
Medium — affects handler contracts |
| Handlers |
New matching strategies or contracts |
Low-Medium — isolated to step matching |
| Mutator |
New mutation strategies or filters |
Low — isolated to mutation mode |
| Reporter |
New report formats or output channels |
Low — isolated to reporting |
| Pipeline |
New stages or operating modes |
High — structural change |
| Cross-cutting |
Spans multiple components |
Highest — requires careful analysis |
Output
The workflow produces these artifacts:
- Feature spec section — Ready to insert into the Acceptance Pipeline Specification. Written in Uncle Bob's style with purpose paragraph, behavioral requirements, data formats, and examples.
- Conformance items — Numbered, testable items extending the existing 21-item checklist.
- Impact analysis table — Component-by-component assessment of change type, IR effects, breaking changes, and new conformance items.
Related Skills
acceptance-pipeline-catalog — Baseline reference for the complete spec (prerequisite)clean-code — Uncle Bob's coding principles (useful context for style alignment)
Gotchas
See gotchas.md for failure points discovered during use.
1---2name: acceptance-pipeline-feature-design3description: Designs new features, extensions, or modifications to Uncle Bob's Acceptance Pipeline Specification — new mutation strategies, Gherkin syntax support, report formats, pipeline stages, IR fields, or handler patterns. Trigger when someone asks "how would I add X to the acceptance pipeline" or discusses spec-level changes to the parser, generator, runtime, mutator, or reporter components — even if they don't explicitly say "feature design." Works in tandem with the acceptance-pipeline-catalog skill, which provides the baseline spec reference.4---5# Acceptance Pipeline Feature Design
6
7Guides agents through designing new features that extend Uncle Bob's Acceptance Pipeline Specification. Produces spec-quality output — language-neutral, implementation-agnostic, with precise behavioral requirements — that matches the style and rigor of the original spec.
8
9This is a composition skill. It does not catalog what exists (that is `acceptance-pipeline-catalog`'s job). Instead, it provides a structured workflow for designing what comes next.
10
11## When to Apply
12
13- Designing a new mutation strategy, value type, or filter mechanism for the mutator
14- Adding new Gherkin syntax support (data tables, tags, Rules keyword) to the parser
15- Extending the JSON IR with new fields or objects
16- Creating new report formats (HTML, JUnit XML) or output channels
17- Adding new pipeline stages or operating modes (parallel runs, coverage filtering)
18- Any spec-level change that affects multiple pipeline components (cross-cutting)
19
20## Prerequisite
21
22Before using this skill, ensure `acceptance-pipeline-catalog` is available. That skill provides the baseline reference for the 9 required components, JSON IR schema, conformance checklist (21 items), and agent setup checklist (15 steps). This skill builds on top of that foundation.
23
24## Workflow Overview
25
26The workflow has five phases, executed in order. Each phase builds on the output of the previous one — skipping phases produces incomplete or inconsistent designs.
27
28```
29Phase 1: Survey Existing Spec → Know what exists before proposing changes
30Phase 2: Identify Extension Point → Classify where the feature attaches
31Phase 3: Draft Feature Spec → Write the spec section in Uncle Bob's style
32Phase 4: Conformance Design → Add testable conformance items
33Phase 5: Impact Analysis → Assess backward compatibility and migration
34```
35
36**Why this order matters:**
37- Phase 1 prevents reinventing existing capabilities and ensures the design uses established patterns.
38- Phase 2 forces classification before writing — a parser extension has different constraints than a reporter extension.
39- Phase 3 produces the actual spec text, informed by the classification from Phase 2.
40- Phase 4 ensures the feature is testable from outside the implementation — if you cannot write conformance items, the spec is too vague.
41- Phase 5 comes last because you need the complete spec and conformance items to assess impact accurately.
42
43## How to Use
44
451. Start by reading the `acceptance-pipeline-catalog` skill to understand the current spec
462. Read the phase reference that matches your current workflow step:
47
48| Phase | Reference | When to Read |
49|-------|-----------|-------------|
50| 1 | [Survey Existing Spec](references/phase-1-survey.md) | Always — first step for any feature design |
51| 2 | [Identify Extension Point](references/phase-2-extension-point.md) | After survey — classify where the feature attaches |
52| 3 | [Draft Feature Spec](references/phase-3-draft-spec.md) | After classification — write the spec section |
53| 4 | [Conformance Design](references/phase-4-conformance.md) | After drafting — add testable conformance items |
54| 5 | [Impact Analysis](references/phase-5-impact-analysis.md) | After conformance — assess compatibility |
55
563. Consult supporting references as needed:
57
58| Reference | When to Read |
59|-----------|-------------|
60| [Style Guide](references/style-guide.md) | During Phase 3 — Uncle Bob's spec writing patterns |
61| [Extension Catalog](references/extension-catalog.md) | During Phase 2 — ideas and complexity notes for future extensions |
62
63## Extension Point Quick Reference
64
65Features attach to one or more of these 9 components. The JSON IR is the highest-impact extension point because all components consume it.
66
67| Extension Point | What Changes | Impact Level |
68|----------------|-------------|-------------|
69| Parser | New Gherkin syntax accepted | Medium — affects IR and downstream |
70| IR | New fields or objects in JSON interchange | **High** — all consumers affected |
71| Generator | New output formats or generation strategies | Low — isolated to generation |
72| Runtime | New execution modes, hooks, dispatch | Medium — affects handler contracts |
73| Handlers | New matching strategies or contracts | Low-Medium — isolated to step matching |
74| Mutator | New mutation strategies or filters | Low — isolated to mutation mode |
75| Reporter | New report formats or output channels | Low — isolated to reporting |
76| Pipeline | New stages or operating modes | **High** — structural change |
77| Cross-cutting | Spans multiple components | **Highest** — requires careful analysis |
78
79## Output
80
81The workflow produces these artifacts:
82
831. **Feature spec section** — Ready to insert into the Acceptance Pipeline Specification. Written in Uncle Bob's style with purpose paragraph, behavioral requirements, data formats, and examples.
842. **Conformance items** — Numbered, testable items extending the existing 21-item checklist.
853. **Impact analysis table** — Component-by-component assessment of change type, IR effects, breaking changes, and new conformance items.
86
87## Related Skills
88
89- `acceptance-pipeline-catalog` — Baseline reference for the complete spec (prerequisite)
90- `clean-code` — Uncle Bob's coding principles (useful context for style alignment)
91
92## Gotchas
93
94See [gotchas.md](gotchas.md) for failure points discovered during use.
pproenca