ChatGPTアプリの使い方入門｜資料作成・コーディングをClaude Codeのようにする方法

/my-project
 |
 ├── /.codex
 |    |
 |    ├── config.toml ※codexに関する設定
 |    |
 |    ├── /rules ※sandbox外で実行できるコマンド制御の設定
 |    |    |
 |    |    └── default.rules
 |    |
 |    ├── /agents ※サブエージェントを利用する場合の例
 |    |    |
 |    |    ├── orchestrator.toml ※指揮者（全体制御）
 |    |    |
 |    |    ├── tester.toml ※テスター（テストコード作成・検証）
 |    |    |
 |    |    ├── implementer.toml ※実装者（テストコードを通すように実装）
 |    |    |
 |    |    └── reviewer.toml ※レビュワー（設計や品質チェック）
 |    |
 |    ├── /workflows ※ワークフローを利用する場合の例
 |    |    |
 |    |    └── tdd_flow.md ※TDD（テスト駆動開発）のフロー
 |    |
 |    └── /skills ※Agent Skillsを利用する場合
 |
 ├── AGENTS.md ※ルートディレクトリ用（共通ルール）
 |
 ├── /src
 |    └── AGENTS.md ※サブディレクトリ用（専用ルール）
 |
 └── /docs ※詳細仕様にファイル分割して格納（各種AGENTS.mdから指定する）
      |
      └── /rules
           |
           ├── architecture.md ※設計思想のルール定義
           |
           ├── database.md ※DB設計のルール定義
           |
           ├── sub.md ※サブディレクトリ用のルール定義
           |
           └── testing.md ※テスト用のルール定義

model = "gpt-5.5"
model_reasoning_effort = "medium"

sandbox_mode = "workspace-write"

# --- ディスク破壊（即禁止） ---
prefix_rule(
    pattern=["mkfs", "dd if=", "wipefs"],
    decision="forbidden",
    justification="ストレージ破壊操作"
)

# --- Git履歴破壊（即禁止） ---
prefix_rule(
    pattern=["git push --force", "git push -f", "git push --force-with-lease"],
    decision="forbidden",
    justification="履歴改変（強制push）によるリポジトリ破壊の可能性"
)

# --- GitHub CLI 危険操作 ---
prefix_rule(
    pattern=["gh repo delete"],
    decision="forbidden",
    justification="リポジトリ削除（不可逆）"
)

prefix_rule(
    pattern=["gh pr merge --admin"],
    decision="prompt",
    justification="保護ルール無視の強制マージ"
)

prefix_rule(
    pattern=["gh workflow run"],
    decision="prompt",
    justification="CI/CDの強制実行"
)

prefix_rule(
    pattern=["gh secret set", "gh secret delete"],
    decision="prompt",
    justification="機密情報の変更"
)

# --- 危険削除（確認） ---
prefix_rule(
    pattern=["rm -rf", "sudo rm"],
    decision="prompt",
    justification="不可逆削除の可能性"
)

# --- 権限昇格 ---
prefix_rule(
    pattern=["sudo"],
    decision="prompt",
    justification="システム影響が大きい"
)

# TDD開発フロー

本フローは orchestrator の指示を起点として進行するが、各エージェントは自身の責務に従い独立して実行する。

本プロジェクトは「OpenAPI駆動 + TDD（Red → Green → Refactor）」を前提とする。

## 1. 開発フロー

1. orchestratorが要件を整理し、タスクとして分解する
2. API開発の場合はpmがOpenAPI定義を確定し、コード生成まで完了させる
3. testerが失敗するテストを書く（RED）
4. reviewerがテスト内容をレビューする（REDレビュー）
5. implementerがテストを通す（GREEN）
6. reviewerが実装をレビューする（GREENレビュー）
7. 問題があれば修正ループに戻る

name = "orchestrator"
description = "全体の進行管理とタスク分解を行うプロダクトマネージャー"
model_reasoning_effort = "high"
sandbox_mode = "workspace-write"

developer_instructions = """
あなたは開発全体を指揮するプロダクトマネージャーです。

役割：
- 要件を整理し、タスクに分解する
- API開発ではOpenAPI仕様を確定し、RED開始前にコード生成まで完了させる
- tester → reviewer → implementer → reviewer の順でタスクを割り振る
- 各エージェントのアウトプットを評価し、次の行動を決める

ルール：
- 必ずTDDサイクル（RED → GREEN → REVIEW）を守る
- API仕様の確定は実装ではなく、REDより前の仕様定義として扱う
- 不完全な実装は次に進めない
- 問題があれば前の工程に差し戻す

出力形式：
- 次に行動するエージェント名
- 依頼内容（具体的に）
"""

---
name: auto-commit
description: 修正したコードをステージングしたうえで差分を解析し、適切なコミットメッセージを生成してgit commitまでを自動で実行する
---

# auto-commit

## 概要
このスキルは、コード修正後の未ステージ状態から変更を検出し、自動でステージング、差分解析、コミットメッセージ生成、git commit実行までを一貫して行う。

## 処理フロー

### 1. 未ステージの変更をステージ

以下のコマンドを実行し、未ステージの変更をすべてステージする。

```bash
git add -A
```

---

### 2. ステージ済み差分の取得

以下のコマンドを実行し、ステージ済みの変更内容の差分情報を取得する。

```bash
git diff --cached
```

---

### 3. 差分解析

取得したコードの差分情報から以下を解析する：

- 変更の目的（機能追加 / バグ修正 / リファクタリング / 雑務）
- 影響範囲（ファイル・モジュール）
- ユーザー視点での変化
- 変更が単一責務かどうか

---

### 4. コミットメッセージ生成

コードの差分情報の解析結果をもとに、
Conventional Commits形式でコミットメッセージを生成する。

#### フォーマット

`<type>: <summary>`

#### type一覧

- test(red): TDDで先に追加する失敗テストコード
- test: 通常のテストコードの追加・修正
- feat: 新規機能追加
- fix: バグ修正
- refactor: 振る舞いを変えないコード改善・リファクタリング
- perf: 性能改善を主目的とした修正
- docs: ドキュメント修正
- chore: その他

#### コミットメッセージの例

- test(red): 有効期限切れトークンの失敗テストを追加
- test: 新規アカウント作成のインテグレーションテストを追加
- feat: ログイン機能を追加
- fix: データの重複登録バグの修正
- refactor: 重複コードを共通化
- perf: 全てのデータ取得SQLの発行回数を削減
- docs: READMEの更新
- chore: GitHub Actions設定を整理

---

### 5. コミット実行

生成したコミットメッセージを用いて以下のコマンドを実行し、コミットを実行する。

```bash
git commit -m "<generated commit message>"
```

---

## 動作ルール

### 0. 実行順序

- 処理は必ず「git add → diff確認 → commit可否判定」の順で実行する
- git add は処理の最初に一度だけ実行する（追加実行は禁止）

---

### 1. 変更検知・終了条件

- 変更が存在しない場合は、git add / commit は実行せず処理を終了する
- git diff --cached の結果が空の場合も同様にコミットを行わない
- git add 後に再度差分を確認し、変更がない場合は即終了する
- 空コミットは絶対に作成しない

---

### 2. 安全性チェック（危険変更の制御）

- .env, secrets, credential系ファイルの変更が含まれる場合は必ず停止する
- 破壊的変更（大量削除・ファイル削除が多数）の場合は警告を出し、停止する

- 破壊的変更の定義：
  - 削除ファイルが5件以上
  - または差分行数の削除が追加の2倍以上

- 上記条件を満たす場合は自動実行せず、必ず停止してユーザー確認を求める

---

### 3. コミット構造ルール

- 1つのコミットは必ず単一の目的（単一責務）になるようにする
  - 複数の変更目的が混在している場合は論理的にまとめるか警告扱いとする

- 大規模変更（複数モジュールにまたがる変更）の場合は、可能であれば分割コミットを優先する

---

### 4. コミットメッセージ生成ルール

- コミットメッセージは必ず変更内容に基づいて生成し、推測や一般論で補完しない
  - 差分から読み取れない情報は含めない

- メッセージは簡潔にしつつ、変更の「意図」が分かる表現にする
  - 実装内容の羅列ではなく、何が改善されたかを優先する

- コミットメッセージは50〜72文字程度を目安にする

- 英語・日本語のどちらを使うかはプロジェクトの既存コミットに合わせて統一する

---

### 5. 変更分類ルール

- 変更内容が以下に該当する場合は chore に分類する
  - フォーマット修正のみ
  - コメント修正のみ
  - 空白・改行整理のみ
  - 自動生成ファイルの更新

---

### 6. コミット実行ルール

- commit 実行前に最終的なメッセージを内部で確定させること
- git commit は確定したメッセージのみで実行する

---

## まとめ

このスキルは以下を保証する：

- 安全な自動コミット（事故防止）
- 意味ベースのコミット生成
- 単一責務の維持
- 変更意図の明確化
- チーム規約との整合性

# アーキテクチャ設計のルール定義

このファイルは本プロジェクトにおける「構造の意味」を定義します。

コードの配置判断や依存ルールは扱いません。それらはそれぞれ以下に委譲：

- `docs/rules/module-classification.md`（配置判断）
- `docs/rules/dependency-rules.md`（依存関係）

## 1. 本プロジェクトのディレクトリ構成

```
/my-project
 |
 └── /src
      |
      ├── /cmd
      |    |
      |    ├── /migrate/main.go（DBのマイグレーション用スクリプト）
      |    |
      |    └── /seed/main.go（マスタデータ登録用スクリプト）
      |
      ├── /internal
      |    |
      |    ├── /core（中核の業務領域）
      |    |
      |    ├── /supporting（補完的なの業務領域）
      |    |
      |    ├── /generic（一般的な業務領域）
      |    |
      |    ├── /shared（横断関心）
      |    |
      |    ├── /di（DIコンテナ層）
      |    |    |
      |    |    └── container.go
      |    |
      |    ├── /infrastructure（共通インフラストラクチャ層）
      |    |
      |    └── /presentation（プレゼンテーション層）
      |         |
      |         ├── /handler（ハンドラー層）
      |         |
      |         └── /router（ルーター設定）
      |
      ├── /openapi（OpenAPIの定義）
      |
      └── /tests（インテグレーションテスト・e2eテスト用）
```

## 2. アーキテクチャの基本思想

本プロジェクトは以下を前提として設計される：

- OpenAPI定義からのGoコード生成（oapi-codegen）
- TDD（Test Driven Development）の徹底
- ドメイン志向のモジュール分割
- 依存関係を厳密に制御した制約ベースアーキテクチャ

本プロジェクトは「DDDの概念を一部取り入れた構造」であるが、
DDDの厳密なレイヤー構造・依存ルールには従わない。

# 全体のルール定義

## 概要

本プロジェクトはマルチエージェント構成（Codex Agents）を前提とする。

以下のエージェントが `.codex/agents` に定義されており、
すべての開発は責務分離されたTDDフローに従って実行される。

本プロジェクトは以下を前提とする：

- OpenAPI駆動開発
- TDD（Red → Green → Refactor）
- 制約ベースアーキテクチャ（DDD簡略モデル）

## エージェント構成

### orchestrator

- 要件整理・仕様定義
- ユーザーストーリー作成
- タスク分解・優先順位決定
- 実装詳細には踏み込まない

## ワークフロー

開発は必ず以下のTDDフローに従う：

- `.codex/workflows/tdd_flow.md`

## ルール参照構造

エージェントは実装判断前に以下を参照する：

### アーキテクチャ

- `docs/rules/architecture.md`

## 実装ルール

実装詳細はすべて以下に委譲する：

- `src/AGENTS.md`

※ implementer は必ずこれに従う

## ブランチ運用ルール

すべての実装・修正・テスト作成は、必ずブランチを切ってから開始すること。

### ブランチ命名規則

```
<prefix>/<short-description>
```

例：

- feat/user-registration
- fix/user-login-error

---

### ブランチプレフィックス定義

種別の分類：

- feat: ユーザーに価値を提供する新機能
- fix: 不具合の修正
- refactor: 挙動を変えない内部改善
- perf: 性能改善を主目的とした修正
- docs: ドキュメントの追加・更新
- test: テストの追加・修正
- infra: インフラ・CI/CD・環境構築
- chore: 上記に当てはまらない雑務（極力使わない）

---

### ブランチ作成ルール（必須）

- テスト作成前に必ずブランチを作成する
- 実装開始前に必ずブランチを作成する
- 1タスク = 1ブランチを原則とする
- ブランチは短命に保つ

---

### TDDとの関係

- REDフェーズ開始前にブランチを作成する
- GREEN実装は必ず当該ブランチ内で行う
- reviewerのNGによる再実装も同一ブランチで継続する

・・・

[projects."対象のプロジェクトのフルパス"]
trust_level = "trusted"

・・・

brew install --cask codex

codex -V

cd dev/sample
codex