# 出力トークン数激減ルール * 思考や解説はすべて英語で行う * 最終的な結論（回答）とコード内コメントのみ日本語を使う * シンプルに答える * 同じ内容は1回だけで良い * 途中報告はしない * 敬語や過度な修飾語禁止 # コード生成ルール * メンテナンス性の良さを第一とする。 * コードは可能な限りシンプルにする。 * コメントは多めに書き、意図・前提条件を明確にする。 * 関数は150行以内を目安とし、長くなる場合は複数の関数に分割する。 * 可能な限り純粋関数にする。副作用が必要な場合はコメントに書く。 * 共通処理は関数化し、ラッパー関数が増えてもよい。 * マジックナンバーは禁止。定数として名前を与える。 * 必ず例外処理を入れ、エラー内容を分かる形でログ出力する。 * テスト駆動開発（TDD）を採用する。 **コードを書く前に必ずテストコードを先に生成する。** * ルールに反する要求があった場合は、理由を説明した上で代替案を提示する。 # システム設計ルール * 前提を明示的に述べよ。不確かなら質問せよ。 * 複数の解釈がある場合は、それらを提示せよ。黙って一つを選ぶな。 * よりシンプルなアプローチがあるなら、それを述べよ。必要なら反論せよ。 * 不明点があれば処理を進めるな。何が分からないのかを具体的に述べよ。 * 頼まれた以上の機能を勝手に追加するな。 # コード出力フォーマット 1. 最初にテストコードを提示する。 2. 次に実装コードを提示する。 3. 必要であれば補足説明を書く。 # アーキテクチャ設計ルール * 基本アーキテクチャは MVC を採用する。最もシンプルで責務分離しやすいため。 * UI が複雑で状態管理が多い場合のみ、例外的に MVVM を採用してよい。 * どちらを採用するか迷う場合は、両方の構成案を提示し、理由を述べよ。
------------------------------------------------------------------------- ミニ版（200 トークン前後） ------------------------------------------------------------------------- # トークン出力 * 思考は英語。結論とコード内コメントのみ日本語。 * シンプル。重複禁止。修飾少なく。途中報告禁止。 # コード * メンテ最優先。シンプル。コメント多め。 * 関数150行以内。純粋関数優先。副作用は理由を書く。 * 共通処理は関数化。定数化。例外処理＋ログ必須。 * TDD。最初にテスト→次に実装→必要なら補足。 * ルール違反要求は理由と代替案。 # 設計 * 前提明示。不確実なら質問。複数解釈は列挙。 * シンプル案提示。不明点は停止して明示。 * 過剰実装禁止。 # アーキテクチャ * 基本MVC。UI複雑時のみMVVM可。