Codex実務OSガイド

codex-work-os

営業、PM、経営補助、調査、カスタマーサポートなどの実務に対して、Codex が散らかった情報を一定の型で整理し、実際に使える出力へ変換しやすくするための skills-first リポジトリです。

Published by NicheWorks · View this page in English

GitHubを見る使い方を見る支援する

現在地

5つの core pack、flow / gate / artifact、cross-pack 実例、検証スクリプトまで含めた公開版構成です。

中核構成

skills を主役に、flows・gates・artifacts・shared・install・scripts が支える構造になっています。

代表シナリオ

pilot-rollout という end-to-end 実例で、1つの散らかった状況が複数 pack をまたいで整理される流れを見られます。

Repository

GitHubで開く Skills、docs、examples、install、validation を一式まとめて公開しています。

このページでわかること

今後の保守・実例追加・改善を支援する

このページやリポジトリが役に立った場合は、今後のメンテナンス、ドキュメント改善、実例追加の支援ができます。

💌 OFUSE ☕ Ko-fi

これは何か

codex-work-os は、Codex に「文章をうまく書かせる」ためだけのリポジトリではない。むしろ、仕事の現場で実際に起きる散らかった情報を、使える仕事の成果物へ変換させるための運用基盤に近いものです。

現実の実務では、入力は最初からきれいに整理されていません。Slack の断片、雑なメモ、途中の調査メモ、まとまりのない問い合わせ、引き継ぎしにくいサポート案件など、前提が崩れた状態から始まることが多いです。

そういう場面で必要なのは、AI が賢そうに返答することではなく、営業返信、PMブリーフ、経営向け要約、意思決定メモ、サポート用エスカレーション文のような、実際に使える形へ整えることです。

誰向けか

codex-work-os は、Codex をコード補助だけでなく、営業・PM・調査・経営補助・CS のような実務にも使いたい人に向いています。

毎回ゼロから書き直すのではなく、一定の型で output を出したい人
散らかった会話やメモを、そのまま使える成果物に変えたい人
AI を単なるチャットではなく、仕事の運用部品として扱いたい人
flows や gates を含めて、出力の品質を安定させたい人

逆に、雑談向けのプロンプト集や、広く浅い業務知識集を探している人にはあまり向いていません。これは実務用の構造を持ったリポジトリです。

5つの core pack

sales-pack

営業返信、問い合わせ整理、提案前メモのための pack。曖昧な相談を返信可能な形へ寄せます。

pm-pack

進捗整理、週報、ブロッカー整理、判断待ちの可視化のための pack。

exec-assist-pack

責任者・上位層向けの短く高シグナルな要約や、会議前後のブリーフ作成に向く pack。

research-pack

比較検討、意思決定メモ、根拠整理のための pack。情報の羅列ではなく判断材料の構造化に寄せます。

cs-pack

長文化したサポート案件を、エスカレーションや引き継ぎに使える形へ圧縮する pack。

どういう構造か

codex-work-os は playbook-first ではなく、skills-first の設計です。主役は skills/ 配下の domain pack で、その周囲を他のレイヤーが支えています。

Skills

リポジトリの中核。各 pack は SKILL.md、テンプレート、参考資料、実例、検証スクリプトを持ちます。

Flows

営業返信、PMブリーフ、比較メモ、引き継ぎなど、仕事の進め方を支える再利用可能な流れです。

Gates

送信してよいか、引き継ぎとして足りるか、判断材料として十分かを確認する品質レイヤーです。

Artifacts

返信文、週報、意思決定メモ、エスカレーションノートなど、最終成果物の型を定義します。

Shared / install / scripts

共通テンプレート、導入補助、検証スクリプトを含み、読むだけでなく実際に使える構成にしています。

このリポジトリに top-level の playbooks/ がないのは、一本道の工程を前提にしていないからです。ここでは「今どの段階か」ではなく、「今どんな種類の仕事か」を起点に pack を選ぶ設計を採っています。

どう使うか

一番わかりやすい使い方は、単なるファイル集としてではなく、1つの作業システムとして読むことです。

README.md と AGENTS.md で全体思想を把握する
docs/architecture.md と docs/pack-mapping.md で pack・flow・gate・artifact の関係を理解する
examples/end-to-end/pilot-rollout/ を見て、1つのケースがどう変換されるか確認する
自分の仕事に合う pack を選ぶ
必要に応じて対応する flow・gate・artifact を合わせて使う

ざっと全体像をつかみたいなら end-to-end 実例から入るのが早いです。実務に組み込む前提なら、architecture と pack mapping から先に読む方が理解しやすいです。

end-to-end 実例: `pilot-rollout`

このリポジトリの代表例は pilot-rollout です。これは、以下のような複数の問題が混じった散らかった状況から始まります。

軽量な pilot を始めたい prospect からの相談
社内で二つの導入方針が割れている状況
PM 側で ownership が曖昧なまま残っている課題
最近の設定変更後に起きた intermittent な missed alerts

その一つの入力が、次のような複数の成果物へ変換されます。

research memo
PM brief
executive brief
sales reply
CS escalation

これにより、codex-work-os が単なる template 集ではなく、複数視点の実務出力を支えるシステムであることが見えます。

なぜ NicheWorks が公開するのか

NicheWorks は、実際の作業で使える小さなツールや運用資産を公開しています。codex-work-os もその延長にあります。理論だけを並べるのではなく、今の時点で使い始められる構造を持ち、今後も実例や docs を増やしながら育てられる前提の資産です。

FAQ

これは単なる prompt 集ですか？

違います。prompt 的に使える要素はありますが、主眼は skills・flows・gates・artifacts を組み合わせた運用構造です。

Codex 専用ですか？

構造は Codex-native を前提にしていますが、発想そのものは他の agent 的な実務環境にも応用できます。

なぜ playbook-first ではないのですか？

このリポジトリが扱うのは一本道の工程ではなく、入口が毎回違う cross-functional work だからです。まず必要なのは「どの段階か」ではなく「どんな仕事か」の判定です。

end-to-end の実例はありますか？

あります。pilot-rollout が、1つの散らかった状況が複数 pack をまたいで整理される代表例です。

最初はどこから読めばいいですか？

README.md、AGENTS.md、その後に examples/end-to-end/pilot-rollout/ が最短です。

リンク

GitHub を開く NicheWorks へ戻る View in English

このプロジェクトを支援する

このページやリポジトリが役立った場合は、今後の保守、ドキュメント追加、実例拡張の支援ができます。