improve-pipeline

パイプラインの改善

実際の利用でパイプライン自体の弱点が明らかになったときに、このスキルを使用します。きっかけとなるインシデントは別のリポジトリで発生する場合もありますが、改善対象は常に chrislacey89/skills です。対象となるのは、今後のエージェント型開発の指針となるスキル、ドキュメント、チェックリスト、ワークフローのガイダンスです。

これは自動的な自己変更ではありません。デフォルトの出力は chrislacey89/skills の GitHub issue です。issue では、何が起きたのか、なぜ単なるプロジェクトの問題ではなくパイプラインの問題なのか、どのような変更が推奨されるのか、その変更がリポジトリ全体にどのような影響を及ぼす可能性があるのか、そして推奨案が承認された場合に chrislacey89/skills のどのファイルを変更する必要があるのかを説明します。

提案を確認した後、ユーザーが実装を依頼した場合は、別のステップとして実装できます。提案を省略してはいけません。

1ターンにつき質問は1つです。 重要な情報が不足している場合は、一度に1つだけ質問し、次の質問をする前にユーザーの回答を待ちます。インシデントの聞き取りやレビューを質問票にしてはいけません。

単一選択を優先します。 ユーザーが方針、優先事項、次のステップを1つ選ぶ場合は、単一選択式の複数選択肢を使用します。

複数選択はできるだけ避けます。 互いに両立する目標、制約、対象外事項、成功基準などに限って使用します。優先順位が重要な場合は、選択した項目のうちどれを最優先するか、続けて質問します。

利用可能な場合は、プラットフォームの質問ツールを使用します。 Claude Code では AskUserQuestion、Codex では request_user_input、Gemini では ask_user を使用します。それ以外の場合は、チャットで番号付きの選択肢を提示し、先に進む前にユーザーの回答を待ちます。

呼び出すタイミング

これは任意のメタスキルであり、デフォルトのパイプライン工程ではありません。

主な教訓がパイプライン自体に関するものである場合は、/improve-pipeline を使用します。

• スキルの境界が不明確で、そのために手戻りが発生した
• 引き継ぎ用の成果物が欠けていた、不十分だった、または誤解を招いた
• ガードレールやチェックリストがあれば防げたはずの失敗が起きた
• 同じ失敗が繰り返されており、パイプラインの仕様が不十分と思われる
• プロンプト、ワークフロー、リポジトリの規約が、過剰な適合や浅いレビューを促した
• /compound または /pre-merge で明らかになった教訓が、下流のアプリリポジトリではなくパイプラインのリポジトリに関するものだった

教訓が主に下流のリポジトリに関するものである場合は、使用しないでください。

• プロジェクト固有のアーキテクチャ上の判断
• アプリ固有のバグ修正
• パイプラインの弱点を示すものではないライブラリ統合時の問題
• そのリポジトリの docs/solutions/ に記録するべき、再利用可能な製品知識やドメイン知識

/compound と /pre-merge は /improve-pipeline を推奨できますが、このスキルが存在し、主な教訓が明らかにパイプラインレベルのものである場合に限ります。自動的に呼び出してはいけません。

このスキルの目的

現場での利用から学ばないデリバリーパイプラインは、やがて、実際に動作する現場ではなく、プロンプトが想定する環境に合わせて最適化されます。最も危険なパイプラインの失敗は、必ずしも明らかな構文ミスとは限りません。境界が曖昧であること、フィードバックループが欠けていること、ガイダンスが重複していること、個別に見ると筋が通っているワークフロー工程が、最初から最後まで実行すると破綻することなども、重大な失敗につながります。

このスキルは、そのループを意図的に閉じるために存在します。現場で起きたインシデントを、局所的な修正ではなく、リポジトリ全体に適用する提案へと変換します。目的は、現在のパイプラインを擁護することでも、衝動的に変更することでもありません。何が起きたのかを理解し、提案された変更が一般化できるかを検証し、リポジトリ全体を強化する、最小限で一貫性のある改善を提示することです。

実行フロー

フェーズ 0：対象リポジトリを確認し、基準となるコンテキストを読み込む

GitHub の issue の対象は、常に chrislacey89/skills です。現在のワークスペース、下流プロジェクトの Git リモート、またはインシデントが発生したリポジトリから、別の対象を推測してはいけません。

インシデントを分析したり、issue を起票したりする前に、chrislacey89/skills の基準となるコンテキストを最低限読み込んでください。skills リポジトリ内で作業する場合は、リポジトリのルートにある原本を読み、下流プロジェクトから呼び出された場合は、このスキルと同じ場所にあるバンドル版を読みます。

• README.md — Skill Kit の概要（リポジトリ内のみ。バンドル版には含まれません）
• references/SYSTEM-OVERVIEW.md（またはリポジトリのルートにある SYSTEM-OVERVIEW.md）— パイプラインの基本方針、状態モデル、引き継ぎ
• CLAUDE.md — このリポジトリ自体を編集する際のルール（リポジトリ内のみ。バンドル版には含まれません）
• references/skill-anatomy.md（またはリポジトリのルートにある docs/skill-anatomy.md）— スキルの変更に求められる品質基準
• references/writing-for-humans.md（またはリポジトリのルートにある docs/writing-for-humans.md）— issue 本文に求められる、平易な言葉での説明の構成と推敲基準

続けて、以下を読みます。

• インシデントに最も関係するスキル
• 境界が重複する隣接スキル
• 同じ指針を定めている共有チェックリスト、テンプレート、リポジトリのドキュメント

先に進む前に、次の内容を含む簡潔なコンテキストの要約を作成してください。

• このリポジトリの目的
• このワークフローで状態を保持する場所
• 提案する変更が影響する可能性が最も高いリポジトリ領域
• 変更が取り込まれた後も維持すべき内容

対象リポジトリを明示的に指定する GitHub コマンドを使います。

gh repo view chrislacey89/skills
gh issue list -R chrislacey89/skills --limit 1

chrislacey89/skills への GitHub アクセスを確認できない場合、またはリポジトリ全体について判断するのに十分な基準コンテキストを読み込めない場合は、そこで停止して確認を求めてください。代替手段として、下流リポジトリに issue を起票してはいけません。

フェーズ 1：現場で発生したインシデントを記録する

望ましい修正案ではなく、実際のインシデントから始めてください。

次の内容を記録します。

1. インシデントが発生した場所 — リポジトリ、ブランチ、機能、または作業のフェーズ
2. 実行されたパイプラインの経路 — 例：/shape → /research → /write-a-prd → /execute → /pre-merge → /compound
3. 期待されていたこと — パイプラインが何を可能にする、または防ぐべきだったか
4. 実際に起きたこと — 混乱、手戻り、分類ミス、成果物の不足、レビューの不備、指針の矛盾など
5. 下流に存在する証拠 — PR、issue、失敗した実行、繰り返し寄せられた質問、または具体例

簡潔に、実行の流れを整理します。

• どのステップで問題が生じたか
• どのステップで問題を検出できなかったか
• どのステップで問題が拡大したか
• 手戻り、不適切な指針、スコープの逸脱、根拠のない確信、見落とされたエッジケース、ユーザーの混乱など、実際に生じたコスト

最も近くに見える失敗が、パイプラインの真の原因だと決めつけてはいけません。出来事そのものと、それを生み出す構造を分けて考えてください。インシデントをユーザーの失敗ではなく、設計上の失敗として捉えます（Norman の責任転嫁反転の原則）。「X を忘れた」はインシデントではありません。「スキルの設計によって、X を忘れやすくなっていた」がインシデントです。

Phase 2: パイプラインの問題であることを確認する

リポジトリの変更を提案する前に、このインシデントが本当にこのリポジトリに属するのかを検証します。

次の点を確認します。

• 主にプロジェクト固有の問題なのに、パイプラインの問題に見えているだけではありませんか？
• 下流のリポジトリだけを改善すれば解決しませんか？
• パイプラインの案内が誤っていた、案内が不足していた、手順の順序が不適切だった、あるいは有効な対策がまったくなかったのでしょうか？
• 一度限りの例外でしょうか、それとも繰り返し発生するパターンでしょうか？

問題を分類します。

• ローカルな事象 — このリポジトリではなく、下流のリポジトリで扱うべき問題です
• パイプラインのパターン — 同じ種類の問題が再発する可能性が高いため、このリポジトリを変更すべきです
• パイプラインの構造 — フィードバックループの欠如、責任範囲の曖昧さ、スキルの境界の重複、またはリポジトリ内の矛盾した案内に起因する問題です
• 冗長または逆効果の案内 — すでにあるテキストを削除または統合すれば、リポジトリの一貫性が向上します。削除も正当な改善であり、追加だけが対象ではありません。
• 規律の問題に見せかけた修正 — ユーザーが何かを覚えておく、気づく、または実行する必要がある改善案です。「パイプラインの構造」に再分類し、案内テキストを追加する前に、知識を環境に持たせる方法（デフォルトの動作、強制する仕組み、構造上の配置）を探します。（Norman、「環境の中の知識」と「頭の中の知識」を参照。）

問題がローカルな事象に限られる場合は、そこで止め、下流のリポジトリで通常のドキュメントまたは /compound フローを使うよう案内します。

Phase 3: 対象範囲をリポジトリ全体に広げる

提案されたパイプラインの変更を単独で評価してはいけません。

編集を推奨する前に、影響を受ける可能性のあるリポジトリ全体を調べます。

• SYSTEM-OVERVIEW.md（スキルのリポジトリ以外から実行する場合は references/SYSTEM-OVERVIEW.md）
• インシデントに最も関係がありそうなスキル
• 責任範囲が重複する隣接スキル
• 同じ案内を記載しているチェックリスト、ドキュメント、テンプレート
• 変更によってユーザーがワークフローを見つけたり実行したりする方法が変わる場合は、README またはその他の案内用ドキュメント

次の点を明示的に検索します。

• 重複していて、変更後に一貫性が損なわれる案内
• この変更によって境界が変わる隣接スキル
• 更新を同期する必要があるプロンプトやテンプレート
• 変更の影響を受けるリポジトリレベルの用語
• パイプラインの規範性、複雑さ、または独自の見解を強めることによる下流への影響

1つのファイルだけを改善してもリポジトリ全体の一貫性を損なう提案は、まだ実施できる段階ではありません。

フェーズ 3.5：ライブラリを参照する

パイプラインの提案は、エージェントやユーザーの意見だけでなく、確立されたソフトウェアエンジニアリングの指針に基づく必要があります。弁証法的議論を実行する前に、インシデントに関連する書籍を /library — ~/.claude/library/ にあるユーザーのローカル書籍インデックス — で確認してください。

手順：

1. インデックスを調べます。 引数なしで /library を実行してカタログを確認するか、インシデントに明確なトピックの手がかりがある場合は /library --search <keywords> を実行します（例：testing、code review、debugging、systems、deep modules、feedback loops、refactoring、domain）。
2. 関連する書籍を1〜3冊選びます。 description または tags がインシデントの種類に直接当てはまる書籍を優先します。このスキルの sources: フロントマターですでに引用されている書籍（Meadows、Duke、Senge、Nygard、Norman）がトピックに関連する場合は、スキルの系譜と実際の推論に一貫性を持たせるため、それらを優先してください。
3. 書籍を読み込みます。 選んだ書籍ごとに /library <name> を実行し、インシデントに関係する具体的な原則、チェックリスト項目、または失敗モードを抽出します。これらを記録してください。フェーズ4とイシュー本文で使用します。
4. 参照しすぎないようにします。 書籍の読み込みにはコンテキストコストがかかります。インシデントが本当に複数領域にまたがる場合を除き、3冊で止めてください。
5. 利用できない場合は適切に対処します。 /library がインストールされていないか、インデックスが空の場合は、「Library consultation: unavailable」と記録して続行してください。イシューの作成を妨げてはいけません。

読み込んだ各書籍から、弁証法的議論で引用できる具体的な内容を得てください。たとえば、名前の付いた原則（「浅いモジュールの兆候」）、チェックリスト項目（「レビュー担当者がXを確認する」）、既知の失敗モード（「ポリシー抵抗」）などです。読み込んだ書籍から引用できる内容が得られなかった場合は、名前だけを挙げず、記録から除外してください。

フェーズ 4：3エージェントによる弁証法的議論を実施する

提案を書く前に、構造化された対立パターンを用います。アドボケイトと懐疑論者を単一のメッセージでサブエージェントとして起動し、それぞれが相手のコンテキストを含まずに冒頭の主張を書けるようにします。同じ瞬間に形成された2つの主張が互いに引きずられることはありません。また、別々に形成されて初めて、両者を比較検討する意味が生まれます。調停者は両者の回答後に実行します。

サブエージェントを利用できない場合は、役割を順番に模擬し、イシュー本文でその実行を劣化モードと明記します。懐疑論者は執筆前にアドボケイトの主張を読むため、独立性は失われており、判定もそれを踏まえて読む必要があります。劣化モードでは返信するサブエージェントがいないため、以下の返信ラウンドは実施しません。

その後、調停者は、以下のゲート条件に従って1回だけ返信ラウンドを実施できます。両方の返信を単一のメッセージで送信し、冒頭の主張を規定した独立性が返信にも適用されるようにします。各返信では、回答する具体的な主張を引用し、譲歩する点と依然として成り立つ点を述べ、250語未満に収めます。役割間で合意する必要はありません。目標は勝利ではなく正しい答えです（Liang et al., Multi-Agent Debate）。

主張を引用せずに譲歩する返信は破棄し、冒頭の2つの主張に基づいて裁定してください。その際、判定で破棄したことを明記します。合意を演じる返信は、このラウンドで最も起こりやすい失敗であり、良い返信とまったく同じように見えます（Du et al. はこれを迎合と呼びます。エージェントが相手の誤りを指摘しながら、結局その誤りを採用することです）。

エージェント 1：提唱者

提唱者は、変更を支持する最も説得力のある誠実な論拠を示します。

提唱者は、次の問いに答えてください。

• どのパイプライン上の問題を解決するのか？
• 現在のリポジトリでは、なぜその問題に対処できていないのか？
• 将来の失敗を減らすには、どのような改善が有効か？
• 対処のために、削除または統合すべき指示、セクション、スキルがあれば、それは何か？ 削減は第一級の選択肢であり、最後の手段ではありません。
• パイプラインを現状のままにするより、提案する変更が優れているのはなぜか？
• 変更が必要と思われる具体的なファイルやスキルは何か？

提唱者は、変更を裏付ける、読み込み済みのライブラリ資料を少なくとも1つ引用する必要があります。引用するのは、原則、チェックリスト項目、設計ガイドラインのいずれかです。調査対象の資料に提案を支持するものがなければ、そのことを明確に述べてください。支持材料のない提唱は、取り繕うべきものではなく、ひとつのシグナルです。

エージェント 2：懐疑論者

懐疑論者は、変更に反対する最も説得力のある誠実な論拠を示します。

懐疑論者は、次の点を確認してください。

• パイプラインを単一の事例に過剰適合させていないか
• すでに別の場所にあるガイダンスと重複していないか
• スキル間の境界を侵食していないか
• 不必要な複雑さや手順を増やしていないか
• パイプラインを改善しようとしていない一般ユーザーに負担をかける提案ではないか
• 問題が構造的なものではなく、下流で発生したという証拠はないか
• その機能のコストを今後のすべてのユーザーが負担することにならないか（Normanのフィーチャリティスと、それに関連するMeadowsのポリシー抵抗）

懐疑論者は、変更に警鐘を鳴らす、または変更によって生じうる既知の失敗モードを示すライブラリ資料や確立された原則を少なくとも1つ引用する必要があります（たとえば、Nygardの偶発的結合、Meadowsのポリシー抵抗、Ousterhoutの浅いモジュール、Fowlerの早すぎる抽象化）。

エージェント 3：仲介者

仲介者は、両者の見解を総合し、リポジトリ全体にとって最善の判断を下します。

結論を書く前に、決定を左右するすべての論点を、いずれかの立場で引用された文章に結び付けてください。決定的な論点にどちらの立場にも出典がない場合、または検証可能な事実について両者の主張が食い違う場合は、回答ラウンドを要求してください。それ以外の場合は、回答ラウンドなしと記録して判断を下してください。論拠を明示することが判断の前提です。独自の論拠を持ち込む仲介者は、その論拠がどちらの立場にもないことに気付けないからです。

仲介者は、次の4つのいずれかの結論を示してください。

• 却下 — パイプラインの問題ではない、または提案する修正が一貫性を損なう
• 保留 — 有望だが、さらなる証拠やリポジトリ全体の調査が必要
• 範囲を限定して進める — 影響範囲を絞った小規模な変更を行う
• 広範囲に進める — 複数の成果物を同期させる必要があるため、リポジトリ横断の更新が妥当

仲介者は、次の点を明示する必要があります。

• 最小限で一貫性のある変更範囲
• リポジトリ全体に及ぶリスク
• 明示的に変更しないもの
• 後日、判断を見直す根拠となる証拠

仲介者は、提唱者と懐疑論者が引用した資料を照らし合わせる必要があります。両者が同じ書籍を引用しながら正反対の結論を導いている場合、その緊張関係を結論の説明で明示し、ひそかに解消してはなりません。同じ資料を原則に基づいて異なる読み方をすることは、将来のレビュー担当者にとって有益な情報です。

フェーズ 5：関連する Issue を検索してから GitHub Issue を作成する

新しい Issue を作成する前に、chrislacey89/skills で関連する Issue を検索します。

gh issue list -R chrislacey89/skills --search "<keywords>" --state all

• パイプライン領域、スキル名、インシデントで確認された最も明確な障害モードのキーワードを使って、オープンおよびクローズ済みの Issue を検索します。
• 既存の Issue が同じ問題をすでに扱っている場合は、重複して作成するのではなく、その Issue を更新するかコメントします。
• 既存の Issue に関連はあるものの別の問題である場合は、新しい Issue を作成し、両方を相互リンクします。

重複がないことを確認してから、提案を chrislacey89/skills の GitHub Issue として作成します。

gh issue create -R chrislacey89/skills

パイプライン領域と改善の機会を示す、簡潔な Issue タイトルを付けます。

タイトルの推奨形式：

[improve-pipeline] <short summary of pipeline change>

例：

[improve-pipeline] Clarify execute skill boundary for behavior-heavy frontend work

## Field Incident と ## Why This Is a Pipeline Problem の各セクションは、この成果物の平易な言葉による説明を担います。半年後に Issue を読む人が、下流のリポジトリを開かなくても何が起きたのか、なぜ重要なのかを理解できる内容にしてください。references/writing-for-humans.md（このスキルに同梱）にある構成と改訂の基準を満たしてください。具体的には、ユーザー自身の言葉によるドメインの説明、要点を冒頭に置いたリード文、推奨する各変更の理由付け、そして **Why it matters:** という目印が必要です。分析セクション（## Advocate Case、## Skeptic Case、## Mediator Verdict）は説明の横に置き、簡潔な箇条書きまたは短い段落にします。これらは説明を繰り返すものではありません。

Recommended Changes テーブルを書く前に。 対象ファイルがある各行について、そのファイルを開き、提案した構成が存在することを確認します。「クイックリファレンスのテーブル項目を追加する」という行が有効なのは、対象ファイルにクイックリファレンスのテーブルがある場合だけです。内容と配置は、別々の読み取りではなく、同じ読み取りの中で決めます。docs/ をルートとする参照資料をバンドルする新しいスキルを追加する提案では、SKILL.md とディスカバリードキュメントの行に加えて、テーブルに scripts/skill-references.manifest の行を含める必要があります。CLAUDE.md § Shared reference files にあるバンドル済み参照資料の不変条件で必須とされており、そうしないとコミット時に scripts/sync-skill-references.sh --check が失敗します。

次の Issue 本文テンプレートを使用します。

**Target repo:** chrislacey89/skills
**Date:** YYYY-MM-DD
**Status:** proposed
**Triggering repo:** <repo-name>
**Triggering context:** <feature, issue, or branch>
**Pipeline area:** <skill, doc, checklist, or repo-wide>
**Change type:** prompt | workflow | checklist | artifact | terminology | boundary | other
**Confidence:** low | medium | high

## Field Incident

[What happened in the downstream repo. Keep this factual and concrete.]

## Pipeline Run Breakdown

- **Path run:** [/shape → /research → ...]
- **Expected behavior:** [What the pipeline should have enabled or prevented]
- **Actual behavior:** [What actually happened]
- **Introduced at:** [Where the weakness entered]
- **Missed by:** [Which step failed to catch it]
- **Cost:** [Rework, confusion, false confidence, missed edge case, etc.]

## Why This Is a Pipeline Problem

[Explain why this belongs in the pipeline repo rather than only in the downstream app repo.]

## Repo-Wide Context

[List the repository areas reviewed and what each implies for the proposal. Include the canonical docs plus the closest affected and adjacent skills.]

- `path/to/file` — [Why it matters]
- `path/to/other-file` — [Why it matters]

## Library Consultation

- **Books surveyed:** [brief notes from `/library` index or `/library --search <keywords>`, or "Library consultation: unavailable"]
- **Books loaded:** [names of books loaded via `/library <name>`]
- **Key principles applied:** [1–3 bullets, each tied to a specific book and the concrete idea borrowed]

## Suggested Further Reading

**From the library** (already available via `/library <name>`):

- `<book-name>` — [one line on why this book is worth loading before implementing or reviewing this proposal]

**Gap in the library** (not yet available; worth acquiring):

- `<Title> — <Author>` — [one line on why this book would have sharpened the analysis and what topic area it fills]

If no gap is identified, remove the Gap subsection rather than leaving a placeholder.

## Advocate Case

[The strongest argument for making the change.]

**Reply:** [The Advocate's answer to the Skeptic. Omit when no reply round ran, or when the reply was discarded.]

## Skeptic Case

[The strongest argument against making the change.]

**Reply:** [The Skeptic's answer to the Advocate. Omit when no reply round ran, or when the reply was discarded.]

## Mediator Verdict

**Verdict:** Reject / Defer / Proceed narrowly / Proceed broadly

[The synthesis. State the minimal coherent change set and the key repo-wide tradeoffs. When the dialectic ran in degraded mode, say so here and say what it cost: the Skeptic read the Advocate's case before writing, so the two positions are not independent and the verdict should be read accordingly.]

## Recommended Changes

| Target file | Change type | Change | Why | Risk if skipped |
|-------------|-------------|--------|-----|-----------------|
| `path/to/file` | add \| modify \| remove \| consolidate | [Specific recommendation] | [Rationale] | [Consequence] |

For any `remove` or `consolidate` row, add a `Text removed (with location):` line directly under the row quoting the exact text being cut and the section it lives in. This prevents Chesterton's-fence deletions and gives reviewers something concrete to evaluate.

## Non-Goals

[What this proposal intentionally does not change.]

## Follow-On Options

- **Proposal only:** stop here and review the issue
- **If approved:** implement the recommended file changes in a separate step in `chrislacey89/skills`

## Related Evidence

- [Link to issue, PR, transcript excerpt, or prior proposal]

セクションを水増ししないでください。内容がないセクションがある場合は、埋め草を書くのではなく提案を簡潔にします。

リポジトリにメンテナンス作業やパイプライン作業用のラベルがある場合は、それを付けます。ない場合は、ラベル管理のために作業を止めないでください。

提案の「Gap in the library」サブセクションで、ライブラリが入手すべき書籍を 1 冊以上挙げている場合は、library-gap ラベルを付けます。これにより、Issue 本文に埋もれず、目に見えるバックログとして蓄積されます。chrislacey89/skills にこのラベルがまだない場合は、次のコマンドで一度だけ作成します。

gh label create library-gap -R chrislacey89/skills \
  --description "Proposal surfaces a book the /library should acquire" \
  --color BFD4F2

その後、この Issue と今後の Issue にラベルを付けます。権限やネットワークの問題でラベルを作成できない場合も、Issue の作成を止めないでください。本文に、後でラベルを付ける必要があることを記載します。

フェーズ 6：実装に着手する前にレビューする

提案を提示し、ユーザーと一度に 1 つずつ質問しながらレビューします。

レビューの最低限の手順：

1. インシデントの説明は正確ですか？
2. Mediator の判定は適切ですか？
3. 推奨する変更案はリポジトリ全体の一貫性を保っていますか？
4. これは後でトリアージする Issue として残しますか、それとも承認後の実装を今すぐ進めますか？

ユーザーが提案をレビューし、実装を明示的に依頼するまでは、パイプラインのファイルの編集を始めないでください。

フェーズ 7：任意の追加実装

実装は任意であり、デフォルトでは実施しません。

ユーザーが実装を承認した場合：

• 提案で指定した、整合性を保つために必要最小限のファイルを更新します
• 中核となるスキルを編集する前に、重複するガイダンスがないか検索します
• 変更する成果物間で用語を統一します
• 構造上の問題を解決するために、リポジトリへの変更はできる限り小さくします
• 提案が呼び出しの境界に影響する場合、その境界を定めている関連スキルをすべて更新します

実装後、以下を報告します：

• 変更したファイル
• 意図的に変更しなかった内容
• どのような今後のインシデントが、この改善の有効性を裏付ける、または否定するか

検証

以下のすべてを満たすまで、/improve-pipeline の実行は完了しません。

• 対象リポジトリを chrislacey89/skills として明示的に扱った
• 正規のコンテキストを README.md、SYSTEM-OVERVIEW.md（または references/SYSTEM-OVERVIEW.md）、CLAUDE.md、docs/skill-anatomy.md（または references/skill-anatomy.md）、docs/writing-for-humans.md（または references/writing-for-humans.md）から読み込んだ
• ## Field Incident と ## Why This Is a Pipeline Problem の各セクションが、references/writing-for-humans.md のウォークスルーの形式と改訂基準を満たしている
• 最も関連性の高いスキルと、隣接する重複の可能性があるスキルを確認した
• Advocate と Skeptic を同じメッセージで起動し、どちらにも相手の主張を渡していない。または、記録したイシューに実行が縮退モードであったことを明記した
• イシューに返信ラウンドの結果を次のいずれかと完全一致する形で記録した：replies kept（各主張のセクションに返信が記載されている）、reply discarded、no reply round（ゲートが発動しなかった）、または degraded mode（返信できるサブエージェントがいなかった）。ラウンドの意義を判断する際に、ゲートが発動しなかったものとして数えるのは no reply round のみ
• /library を調査した（または存在しないことを記録した）。読み込んだ書籍があれば、イシューの Library Consultation および／または Suggested Further Reading に引用した
• イシューを起票または更新する前に、chrislacey89/skills 内の関連イシューを検索した
• chrislacey89/skills でイシューを起票または更新した。または、理由を明記して起票を意図的に保留した
• 提案が削除または統合を推奨する場合、イシューに削除対象の正確な文面と、それが冗長または逆効果になった理由を記載した

リポジトリ全体に適用されるガードレール

• 確立された指針に基づいて提案してください。 起票する前に、/library を参照してインシデントの種類に関連する書籍を確認し、各書籍から得られる知見を課題に記載してください。/library を利用できない場合は、その手順を黙って省略せず、利用できないことを明記してください。
• まず提案してください。 インシデントからリポジトリの編集に進まないでください。
• 過剰に最適化しないでください。 つらいインシデントが1件あっても、それは証拠であって証明ではありません。
• 一般ユーザーを守ってください。 パイプラインのユーザーの大半は、パイプライン自体を進化させるのではなく、作業をリリースしようとしています。
• 編集前に検索してください。 推奨事項が1つのスキルに関係する場合は、変更する前に隣接するスキルや共通ドキュメントを確認してください。
• 影響範囲を明示してください。 すべての提案で、影響を受けるファイル、スキル、規約を示してください。
• 一貫性のある最小限の修正を優先してください。 範囲が広がる「ついでに」行うパイプラインの書き換えは避けてください。
• 削除も検討してください。 診断の結果、指針に重複、矛盾、または価値の低さが見られる場合、適切な修正は新たな項目の追加ではなく、削除または統合です。このスキルの過去の実行では追加に大きく偏っていました。証拠が裏付ける場合は、削除も追加と同等に重視してください。また、追加と同じ水準の証拠を求めてください。
• プロジェクトの知識はプロジェクト内に残してください。 教訓が下流アプリのリポジトリに属する場合は、そのリポジトリで通常使われているドキュメント作成の流れを利用してください。
• 調査結果は GitHub に記録してください。 通常の成果物は、ローカルの提案ファイルではなく、chrislacey89/skills の GitHub issue です。
• 現在のワークスペースのリモートを信用しないでください。 下流リポジトリでインシデントが発生した場合でも、/improve-pipeline の issue 起票先にはなりません。
• 正規のコンテキストを必須としてください。 コアリポジトリのドキュメントと、内容が重なるスキルを確認するまでは、パイプライン改善の issue を起票しないでください。
• 正規のコンテキストまたは GitHub にアクセスできない場合は、停止して確認してください。 推測したり、代替として別の場所に起票したりしないでください。

このスキルの対象外

• /compound とは異なります。 /compound は下流プロジェクトで長期的に役立つ知識を記録します。/improve-pipeline はこのパイプラインのリポジトリに向けた改善を記録します。
• 自動で自己修復するものではありません。 レビューを経た変更を推奨し、必要に応じて実装します。パイプラインをひそかに変更することはありません。
• 責任追及のためのものではありません。 誰が間違えたかではなく、構造的な原因とリポジトリ全体への影響を分析します。
• ローカルパッチを作るものではありません。 リポジトリ全体の整合性を確認せずに、1つのスキルだけを「修正」するべきではありません。

引き継ぎ

• 想定される入力： パイプラインの使用中に発生した実際のインシデントや、繰り返し生じる摩擦。多くの場合、/compound または /pre-merge の実行中に見つかります。
• 生成されるもの： 改善の提案とその根拠となる分析をまとめた、chrislacey89/skills の GitHub issue
• その後に続く可能性のある作業： 承認された提案を chrislacey89/skills で実装すること
• 推奨元となるもの： 主な教訓がパイプラインレベルのものである場合、/compound または /pre-merge が推奨します