acceptance-pipeline-feature-design

Acceptance Pipeline 機能設計

Uncle Bob の Acceptance Pipeline 仕様を拡張する新機能の設計をエージェントに案内します。仕様として十分な品質を備えた成果物を作成します。言語や実装に依存せず、正確な動作要件を定め、原仕様のスタイルと厳密さに合わせます。

これは複数のスキルを組み合わせるスキルです。既存機能の一覧を作成するものではありません（その役割は acceptance-pipeline-catalog が担います）。代わりに、次に何を作るかを設計するための、体系的なワークフローを提供します。

適用するタイミング

• mutator に新しい変更戦略、値型、フィルターメカニズムを設計する場合
• パーサーに新しい Gherkin 構文（データテーブル、タグ、Rules キーワード）のサポートを追加する場合
• JSON IR に新しいフィールドやオブジェクトを追加する場合
• 新しいレポート形式（HTML、JUnit XML）や出力チャネルを作成する場合
• 新しいパイプラインステージや動作モード（並列実行、カバレッジフィルタリング）を追加する場合
• 複数のパイプラインコンポーネントに影響する仕様レベルの変更（横断的な変更）を行う場合

前提条件

このスキルを使用する前に、acceptance-pipeline-catalog を利用できることを確認してください。このスキルでは、9 つの必須コンポーネント、JSON IR スキーマ、適合性チェックリスト（21 項目）、エージェント設定チェックリスト（15 ステップ）の基本となるリファレンスを提供します。このスキルはその基盤の上に構築されています。

ワークフローの概要

ワークフローには、順番に実行する 5 つのフェーズがあります。各フェーズは前のフェーズの成果物を基に進めます。フェーズを省略すると、不完全または一貫性のない設計になります。

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

この順序が重要な理由：

• フェーズ 1 では、既存機能を再発明することを防ぎ、設計で確立済みのパターンを確実に使用します。
• フェーズ 2 では、記述を始める前に分類を行います。パーサーの拡張とレポーターの拡張では、制約が異なります。
• フェーズ 3 では、フェーズ 2 での分類を踏まえて、実際の仕様文を作成します。
• フェーズ 4 では、実装の外部から機能をテストできることを確認します。適合性項目を書けない場合、仕様が曖昧すぎます。
• フェーズ 5 を最後に行うのは、影響を正確に評価するには、仕様と適合性項目がすべて揃っている必要があるためです。

使用方法

1. まず acceptance-pipeline-catalog スキルを読んで、現在の仕様を理解します
2. 現在のワークフローステップに対応するフェーズのリファレンスを読みます：

フェーズ	リファレンス	読むタイミング
1	既存仕様の調査	常に — どの機能設計でも最初のステップです
2	拡張ポイントの特定	調査後 — 機能をどこに組み込むか分類します
3	機能仕様の草案作成	分類後 — 仕様のセクションを記述します
4	適合性設計	草案作成後 — テスト可能な適合性項目を追加します
5	影響分析	適合性設計後 — 互換性を評価します

3. 必要に応じて補足リファレンスを参照します：

リファレンス	読むタイミング
スタイルガイド	フェーズ 3 中 — Uncle Bob の仕様記述パターンを確認します
拡張カタログ	フェーズ 2 中 — 将来の拡張に関するアイデアや複雑さについての注記を確認します

拡張ポイントのクイックリファレンス

機能は、次の9つのコンポーネントの1つ以上に追加されます。JSON IRは、すべてのコンポーネントがこれを使用するため、最も影響の大きい拡張ポイントです。

拡張ポイント	変更内容	影響レベル
パーサー	新しいGherkin構文を受け入れます	中 — IRとその下流に影響します
IR	JSONインターチェンジに新しいフィールドまたはオブジェクトを追加します	高 — すべてのコンシューマーに影響します
ジェネレーター	新しい出力形式または生成方法を追加します	低 — 生成処理に限定されます
ランタイム	新しい実行モード、フック、ディスパッチを追加します	中 — ハンドラーの契約に影響します
ハンドラー	新しいマッチング方法または契約を追加します	低〜中 — ステップのマッチングに限定されます
ミューテーター	新しいミューテーション方法またはフィルターを追加します	低 — ミューテーションモードに限定されます
レポーター	新しいレポート形式または出力チャネルを追加します	低 — レポート処理に限定されます
パイプライン	新しいステージまたは動作モードを追加します	高 — 構造が変わります
横断的	複数のコンポーネントにまたがります	最高 — 慎重な分析が必要です

出力

ワークフローでは、次の成果物を作成します。

1. フィーチャー仕様セクション — Acceptance Pipeline Specificationにそのまま追加できます。目的の段落、動作要件、データ形式、例を含む、Uncle Bobのスタイルで記述します。
2. 適合性項目 — 既存の21項目のチェックリストを拡張する、番号付きのテスト可能な項目です。
3. 影響分析テーブル — コンポーネントごとに、変更の種類、IRへの影響、破壊的変更、新しい適合性項目を評価します。

関連スキル

• acceptance-pipeline-catalog — 仕様全体の基本リファレンス（前提条件）
• clean-code — Uncle Bobのコーディング原則（スタイルを合わせる際に役立つ背景情報）

注意点

使用中に見つかった問題点については、gotchas.mdを参照してください。