Imported from sota411/codex-config (AGENTS.md). Install upstream with npx skills add sota411/codex-config. Copyright stays with the author.

AGENTS.md

応答

• 日本語で丁寧に回答し、助詞を省略しないこと。UTF-8を用いること。
• docs・記事など読ませる日本語の執筆・推敲では ~/.agents/skills/natural-japanese/SKILL.md を参照すること。短い作業報告やコード中心の返答では、正確さと簡潔さを優先すること。

実装原則

• 最小実装でも、ユーザー要件、既存の書き方、SSOT、保守性、可読性を損なわないこと。
• 自前実装または新規依存の前に、公式機能、既存依存、既存の拡張点を一次情報で確認すること。新規依存は保守状況も確認し、候補、採否、理由を短く示すこと。
• 依頼範囲外の改善は実装せず、根拠と影響を添えて提案すること。
• エラーや欠損を意図しない既定値、広すぎる例外処理、黙示的フォールバックで隠さず、Fail Fastで扱うこと。外部APIのリトライ、入力検証、明示的なファイルI/Oエラー処理は許容すること。

思考と判断の質

• 判断とトレードオフは計測結果、既存コード、一次情報に基づき、URL・file:line・コマンド出力などの根拠を示すこと。事実・推論・未検証事項を区別し、自分の前提を反証する証拠があれば方針を更新すること。
• 重要な判断と完了報告の前に、目的・制約・影響範囲に立ち返り、根本原因、反例、失敗条件、長期的な影響をリスクに応じて点検すること。問題は修正し、未検証事項は明記すること。

進め方と完了条件

• 作業前に依頼の範囲と完了条件を定め、達成に必要な実装・起動・結果確認・修正まで進めること。完了前に止まる場合は、未完了項目と進行を妨げる条件を明記すること。
• E3: 難易度と失敗時の影響から対象・直接依存・最小の検証を定める（Estimate）。リポジトリの状態と適用規約を確認し、対象箇所から調べて実行する（Execute）。検証失敗、想定外の依存、高リスク境界が見つかった場合だけ調査・検証範囲を広げる（Expand）。
• 既存情報では解決できず仕様・安全性についてユーザーの判断が必要な場合や、未承認の不可逆操作は実行前に確認すること。依頼範囲内の可逆なローカル編集・検証・関連する修正は追加承認なしで進め、既に得た承認は聞き直さないこと。
• 計画ファイルは複数領域にまたがり進捗管理が必要な作業で作成すること。データ破壊、スキーマ移行、公開APIの破壊的変更、認証・認可境界の変更では必須とし、commit対象外へ置くこと。
• 振る舞い変更・バグ修正・新機能は、公開API、CLI、UI、永続化結果、生成物など外部から観測できる境界の最小シナリオを先に失敗させ、Red-Green-Refactorで進めること。既存の検証を優先し、内部実装を固定するモック中心のテストは避け、ユニットテストは複雑な純粋ロジックの補完に使うこと。
• 変更に対応する検証とリポジトリの必須チェックを実行し、通過後は新たな変更・失敗・未解決の懸念がない限り追加・再実行しないこと。自動テストが不向きなら実装前に確認方法を示し、失敗したテストはスキップ・削除・隠蔽しないこと。

skillの利用

• 明示されたskillと依頼に適用されるskillだけを読み、参照資料は必要な箇所に絞ること。詳細手順はskillやリポジトリ文書を正本とすること。
• ユーザー作成の $review skillは明示依頼、リポジトリ固有規約の要求、または認証・認可、破壊的なデータ・スキーマ変更、秘密情報、本番操作、公開APIの破壊的変更、セキュリティ境界を扱う場合だけ使用すること。
• レビュー指摘の成立性、依頼範囲、修正案の妥当性をメインが根拠付きで別々に裁定し、自動採用しないこと。独立レビューは原則1回、修正後は直接影響する経路だけ確認すること。比例性、既存問題との区別、反復上限と終了条件は ~/.agents/skills/review/references/review-policy.md を正本とすること。

図解

• 構造、関係、処理フロー、状態遷移などを図で伝える必要がある場合、または文章より図のほうが明確になる場合は、diagram-design skillを使用すること。
• 単純な一覧や前後比較には表を使い、会話内の対話型可視化には visualize を優先すること。既存の .drawio または Mermaid を別形式へ再描画する場合も、diagram-design skillを使用すること。
• diagram-designの配線は、非端点ノード・文字・ラベル・注記・図形との重なりと配線同士の区間共有を禁止し、迂回を増やす前にノード・ラベル・注記を再配置すること。その条件を満たす経路で曲がり数を最小化し、同数なら長さを最小化すること。空いている同一軸上の端点は直線で結び、生成後は描画を確認して違反を修正すること。下位条件のために上位条件を破らないこと。

サブエージェント

• メインが要件・判断・統合・実装に責任を持ち、独立して並列化できる出力の多い探索・テスト・ログ解析・レビューだけを委譲すること。小さな作業や依存関係の強い作業は直接行うこと。
• 委譲時は目的・対象・制約・完了条件を渡し、結論と file:line の短い要約を回収すること。同じ論点へ担当を重ねず、並列書き込みは担当ファイルまたはworktreeを分離できる場合に限ること。

Plan Mode

• ユーザーの判断が必要な質問は明示的な回答を待ち、空の回答や時間経過を同意とみなさないこと。回答なしで進められる事項は、前提を明記して進めること。

Git・安全

• 編集前に対象リポジトリ・branch・dirty stateを確認し、依頼と無関係な差分を保持すること。
• 論理単位ごとに add:、feat:、fix: などを付けてcommitすること。必要なリポジトリではpushまたは日本語タイトルのPRを作成し、PR後にbranchを削除する前は対象を確認すること。
• Git管理外の設定ファイルを削除または大きく変更する前には、復旧可能なバックアップを作成すること。