界面已本地化;技能介绍与说明文档按所选语言由 AI 自动翻译,代码、命令、路径和专业术语保留原文,以原作者文档为准。
探索技能
开发与工程 · SKILL.md

acceptance-pipeline-catalog

acceptance-pipeline-catalog

【开发与工程】Use when implementing, reviewing, or debugging a Gherkin acceptance-test pipeline with mutation testing. Covers parser, JSON IR, generator, runtime, step handlers, test runner, mutator, value mutation rules, execution, result classification, reporting, project layout, conformance, and agent setup. Based on Uncle Bob's Acceptance Pipeline Specificatio…

独立 GitHub 快照 · 自动分类 · 以原作者文档为准

技能说明

GitHub

name: acceptance-pipeline-catalog description: Use when implementing, reviewing, or debugging a Gherkin acceptance-test pipeline with mutation testing. Covers parser, JSON IR, generator, runtime, step handlers, test runner, mutator, value mutation rules, execution, result classification, reporting, project layout, conformance, and agent setup. Based on Uncle Bob's Acceptance Pipeline Specification. Trigger even when the user mentions Gherkin parsing, acceptance test generation, mutation testing for acceptance tests, or building a portable test pipeline.

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
我的收藏