> For the complete documentation index, see [llms.txt](https://livlog-llc.gitbook.io/engineering-handbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://livlog-llc.gitbook.io/engineering-handbook/codexwoshitana/19-development-flow.md). # 19. Codexを使った開発の全体フロー ## 目的 Codexとの開発を、単発のコード生成ではなく、調査、判断、実装、確認、固定、改善の連続した工程として扱います。 ## 全体フロー ``` 1. 開発テーマを決める 2. docs/requirements.md を作る 3. Codexに既存リポジトリ調査を依頼する 4. docs/design.md を作る 5. docs/tasks.md に作業を分解する 6. docs/test-plan.md に確認観点を書く 7. docs/codex-instructions.md を作る 8. Codexに小さな単位で実装を依頼する 9. 動作確認する 10. 必要なテストを追加する 11. リファクタリングする 12. READMEやdocsを更新する 13. 差分をレビューして取り込む ``` この流れは、リブログの開発サイクルをCodex協調開発へ具体化したものです。 ``` 最小実装 → 動作・業務確認 → テスト追加 → リファクタリング ``` ## 1. 開発テーマを決める 解決したい問題と最小の成果を人間が決めます。「管理画面全体を改善する」ではなく、「一覧に状態を表示し、担当者が未処理を識別できる」のように絞ります。 ## 2. 要件を書く `docs/requirements.md`へ背景、目的、対象利用者、期待する振る舞い、実現しないこと、完了条件を書きます。Codexには曖昧な表現や不足している異常系の指摘を依頼します。 ## 3. 既存リポジトリを調査する READMEだけで判断せず、ビルド、実行、CI、DB、アプリケーション構造、テストを確認させます。この段階では原則として実装させません。調査結果には根拠となるファイルパスを含めます。 ## 4. 設計方針を作る 調査結果を基に、既存パターンへ合わせた最小変更を設計します。Codexに案を出させても、API契約、DB設計、権限、互換性の最終判断は人間が行います。 ## 5. 作業を分解する `docs/tasks.md`へ、調査、実装、テスト、文書の順にタスクを書きます。バックエンド、フロントエンド、DBを一度に混ぜず、差分をレビューできる大きさにします。 ## 6. 確認観点を書く `docs/test-plan.md`へ正常系、異常系、境界値、権限、DB、画面、API、既存機能への影響を書きます。探索中の仕様でも、何を見て採否を判断するかは先に決めます。 ## 7. Codex向け指示を固定する `docs/codex-instructions.md`へ参照文書、変更可能範囲、禁止事項、実装方針、確認コマンド、報告形式を書きます。小規模変更では、ここに要件とテスト観点を集約しても構いません。 ## 8. 最小実装を依頼する Codexには1つの責務ごとに依頼します。最初から完成形を求めず、画面が表示できる、APIが1つの正常系を返せるなど、動作を確認できる最小単位を作ります。 ## 9. 動作と業務を確認する テスト結果だけでなく、人間が画面、APIレスポンス、DB状態、ログを確認します。期待と違う場合は、実装を直す前に要件または設計のどこが変わったかを記録します。 ## 10. 振る舞いをテストで固定する 正しいと判断した正常系、異常系、境界値を自動テストへ追加します。不具合修正では、可能な限り再現テストを先に作ります。高リスク処理は探索段階からテストを厚くします。 ## 11. リファクタリングする テストで振る舞いを固定した後、命名、重複、責務、読みやすさを改善します。仕様変更と混ぜず、「既存仕様を変えない」と明示してCodexへ依頼します。 ## 12. 文書を更新する README、API仕様、画面仕様、運用メモに加え、要件、設計、タスク、テスト計画を実装結果へ合わせます。Codexには差分から更新候補を抽出させ、人間が採否を決めます。 ## 13. レビューして取り込む 人間が全差分、テスト結果、未確認事項、Secrets混入の有無を確認します。Codexのレビューは補助として利用し、最終的なマージ判断は人間が行います。 機能を継続的に更新するときは、このフローの開始前に現在仕様と変更履歴を確認します。更新専用の進め方は「[29. 機能の継続更新](/engineering-handbook/codexwoshitana/29-continuous-feature-updates.md)」を参照してください。 ## 途中で戻る判断 工程は一方向ではありません。動作確認で要件不足が見つかれば要件へ戻り、実装中に既存制約が分かれば設計へ戻ります。ただし、変更した判断は文書へ反映し、会話だけに残さないようにします。 ## Codexに依頼すること * 現在の工程と対象タスクを明示して作業する * 次工程に進む前に、変更内容と未確認事項を報告する * 要件変更が必要になった場合は、実装を続けず理由を提示する * 実行したコマンドと結果を正確に記録する ## 人間が確認すること * 各工程で判断すべき事項が確認済みか * 最小実装がそのまま無秩序に拡大していないか * テストが実装詳細ではなく採用した振る舞いを固定しているか * 文書と実装が一致しているか --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://livlog-llc.gitbook.io/engineering-handbook/codexwoshitana/19-development-flow.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.