Codex Product Shipping Playbooks

これは何か

Codex Product Shipping Playbooks は、リポジトリを前提にした実務向けのワークフローシステムです。単なるプロンプト集でも、汎用PMテンプレ集でもなく、既存のコードベース内で実際に変更を進めるときの流れを整理するために作られています。

このリポジトリが目指しているのは、「こういう変更をしたい」という要求を、「どこが関係するのか」「何を変えるのか」「何をもって完了とするのか」「出荷前後に何を残すべきか」までつながった形にすることです。つまり、実装そのものだけでなく、その前後にある運用上の仕事も含めて扱います。

そのため、発想段階のアイデア整理や抽象的な計画論よりも、実際のコードベースに対して変更を進めるためのワークフロー資産として読むのが正しい使い方です。

誰向けか

このプロジェクトは、既存リポジトリを前提に Codex や agent-assisted development を使いたい人、変更要求から出荷までの流れを曖昧にせず整理したい人に向いています。acceptance や pre-ship review、release note、retro をバラバラな書類ではなく、一連の運用ループとして扱いたい人には特に相性がよいです。

• 既存のリポジトリ上で Codex を使った変更作業を進めたい人。
• spec delta、実装計画、acceptance、出荷判定を明確にしたい人。
• release note、changelog、diff review、retro を同じ流れの中で残したい人。
• 抽象論ではなく、再利用できる実務資産を求める人。

逆に、汎用PM理論集、GTM向けテンプレート集、何でも入りのプロンプトパックを探している場合には少し方向が違います。

このリポジトリの全体フロー

現在のコアフローは、リポジトリ理解から始まり、出荷後の振り返りまでを一つの線でつなぐ構成です。各段階で曖昧さを減らし、issue から release までの流れを再利用しやすくすることが目的です。

含まれているもの

このリポジトリは、複数の再利用レイヤーで構成されています。毎回ゼロから考えるのではなく、複数の変更作業に使い回せるように整理されているのが特徴です。

Playbooks

repo intake、spec delta、計画、acceptance、ship check、release writing、実装レビュー、retro といった各段階の実行単位です。

Artifacts

spec delta、change plan、acceptance、release note、changelog、diff review、retro などの再利用可能なテンプレートです。

Gates

各段階で「次に進めてよいか」を判断するための実務的なチェックポイントです。

Flows

複数の playbook を end-to-end でつなぎ、実際の変更フローとしてどう回るかを示す導線です。

Examples

抽象論で終わらず、実際にどう使うかを確認できる worked example 群です。

どう使うか

このページは、GitHub を開く前に「このリポジトリが何で、どう読めばよいか」を把握できるように作っています。実際には、単なるファイル一覧として読むのではなく、一定の順番で辿ると理解しやすいです。

1. まず AGENTS.md を読む。 このリポジトリの使い方や前提ルールを最初に掴みます。
2. 次に spec/ を読む。 ファイルの並びではなく、ワークフロー全体の設計意図を理解しやすくなります。
3. examples/issue-driven/filter-persistence/ を開く。 一つの例で end-to-end の流れを見るのが最速です。
4. その後に playbooks/ を読む。 実例を見たあとだと、各 playbook の役割がかなり分かりやすくなります。
5. 最後に artifacts/、gates/、flows/ を見る。 実務で再利用するための骨格部分を確認します。

まず全体像だけ掴みたいなら example までで十分です。実務で使うつもりなら、example のあとに reusable layer に戻ると理解しやすいです。

実例: filter-persistence

このリポジトリの主要な worked example は、filter-persistence という synthetic scenario です。実際の本番リポジトリのログをそのまま使っているわけではありませんが、実務に近い形でワークフローの流れを確認できるように設計されています。

この例では、issue report から repo context memo、spec delta、change plan、acceptance definition、pre-ship review、release note、changelog entry、diff review、retro までを一通り確認できます。つまり、このリポジトリが何を目指しているかを最も短時間で理解できる導線です。

このワークフローが自分の作業に合うかを判断したいなら、まずこの example を見るのが最適です。テンプレートの集合ではなく、接続された一つのシステムとして見えてきます。

なぜ NicheWorks が公開するのか

NicheWorks は、実務で使える小さなツールやワークフロー資産を公開するラインです。Codex Product Shipping Playbooks もその一つで、既存リポジトリの中で現実に使える開発導線として公開されています。

これは理論をきれいに見せるためのものではなく、時間をかけて実例、テンプレート、出荷規律を改善していくための運用資産として置かれています。

FAQ

関連リンク