mcpField
A
acceptance-pipeline-catalog

acceptance-pipeline-catalog

github.com/pproencaTesting & quality218132 installsUpdated 11w ago
Repository

About acceptance-pipeline-catalog

acceptance-pipeline-catalog is a language-neutral specification skill for building a pipeline from Gherkin features through JSON IR and generated acceptance tests to mutation testing. It supports developers implementing or validating parsers, generators, runtimes, runners, and mutators.

Key features

  1. 01Rules across 14 pipeline categories
  2. 02Gherkin parser and JSON IR requirements
  3. 03Acceptance test generation and runtime guidance
  4. 04Mutation rules and result classification
  5. 05Execution, reporting, and conformance guidance

Use cases

  1. 01Designing a Gherkin-to-test pipeline
  2. 02Implementing mutation testing for example values
  3. 03Diagnosing parser, generator, or runner failures
  4. 04Checking a pipeline against conformance requirements

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/pproenca/dot-skills --skill acceptance-pipeline-catalog

After installing, type/acceptance-pipeline-catalogin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

gotchas.md
metadata.json
references/
_sections.md
conform-checklist.md
exec-parallelism.md
exec-timeout.md
exec-work-directory.md
exec-workflow.md
gen-command-interface.md
gen-requirements.md
handler-matching.md
handler-unsupported.md
handler-value-handling.md
handler-world-state.md
ir-example-object.md
ir-feature-object.md
ir-scenario-object.md
ir-step-object.md
layout-commands.md
layout-required-paths.md
layout-scripts.md
mut-command-interface.md
mut-deep-copy.md
mut-identity.md
mut-scope.md
parser-background.md
parser-command-interface.md
parser-examples-tables.md
parser-feature-declaration.md
parser-general-rules.md

Details

From the project README

Robert C. Martin Acceptance Pipeline Best Practices

Language-neutral specification for a portable acceptance-test pipeline: Gherkin feature files to JSON IR to generated acceptance tests to mutation testing. Based on Robert C. Martin's Acceptance Pipeline Specification. Contains ~50 rules across 14 categories, prioritized by impact.

When to Apply

Reference these rules when:

  • Building a Gherkin parser that outputs JSON IR
  • Implementing an acceptance test generator from JSON IR
  • Writing an acceptance runtime that expands scenarios and dispatches steps
  • Implementing mutation testing for acceptance test example values
  • Setting up the full pipeline (parser, generator, runner, mutator) in a new project
  • Debugging pipeline failures (parse errors, generation issues, mutation classification)

Pipeline Overview

The pipeline has two modes:

Normal acceptance run:

feature file -> gherkin parser -> JSON IR -> acceptance generator -> generated tests -> test runner

Mutation run:

feature file -> gherkin parser -> base JSON IR -> mutator (one changed IR per mutation)
  -> generator (tests per mutation) -> test runner (evaluate each) -> mutation report

The normal run proves the project satisfies the feature. The mutation run probes whether tests are strong enough to fail when example data changes.

Rule Categories by Priority

PriorityCategoryImpactPrefixRules
1ParserCRITICALparser-9
2JSON IRCRITICALir-4
3GeneratorCRITICALgen-2
4RuntimeHIGHrt-3
5Step HandlersHIGHhandler-4
6Test RunnerHIGHrunner-2
7Mutator CoreHIGHmut-4
8Value Mutation RulesHIGHval-10
9Result ClassificationHIGHresult-2
10ConformanceHIGHconform-1
11Agent SetupHIGHsetup-1
12Mutation ExecutionMEDIUMexec-4
13ReportsMEDIUMreport-3
14Project LayoutMEDIUMlayout-3

Quick Reference

1. Parser (CRITICAL)
2. JSON IR (CRITICAL)
3. Generator (CRITICAL)
4. Runtime (HIGH)
5. Step Handlers (HIGH)
6. Test Runner (HIGH)
7. Mutator Core (HIGH)
8. Value Mutation Rules (HIGH)
9. Result Classification (HIGH)
10. Conformance (HIGH)
11. Agent Setup (HIGH)
12. Mutation Execution (MEDIUM)
13. Reports (MEDIUM)
14. Project Layout (MEDIUM)

How to Use

Read individual reference files for detailed spec requirements and rationale:

  • Start with the category relevant to the component you are building
  • Each rule file is self-contained with WHY explanations, spec requirements, and examples
  • For a new project setup, read setup-checklist first
  • For validation, use conform-checklist
  • Check gotchas.md for known failure points

Reference Files

FileDescription
metadata.jsonVersion and reference information
gotchas.mdKnown failure points (append-only)
references/All rule files organized by prefix

Comments

Markdown supported