geju

Geju

中国語の読者は、SKILL.zh_CN.md を参照してください。英語版の SKILL.md が実行時の信頼できる情報源です。

概要

方案讨论の場では設計の可能性を広げ、最小限のパッチではなく、適切な目標モデルを提案します。出力するのは格局判断です。つまり、明確な主張と、それを規律正しく検証する方法です。

基本原則

大胆に仮説を立て、慎重に検証する。

Geju は、必ず正しい答えを出すものではありません。設計の可能性を広げる、影響力の大きい挑発的な仮説を提示します。主張は、神託ではなく、検証すべき強い仮説として扱ってください。まず大胆に判断し、その後で慎重な検証手順を定めます。

リファクタリングの難しさ、互換性への懸念、既存実装の形、局所的な詳細は、考慮すべき制約ではありますが、従うべき指針ではありません。これらに方向性を早々に決めさせないでください。

視野を広げる方法

思い込みをあぶり出すための方法を1つか2つ選びます。選択肢をすべて実行しないでください。利用できる方法は、最終状態からのバックキャスト、レガシーがないと仮定する思考実験、誤った概念の排除、10倍にする問い、制約の逆転、譲れない原則、センスのある削除、仮説を先に立てた検証です。詳しい指針や例が必要な場合は、references/frame-opening-moves.md を参照してください。

対処すべきこと

これらは、回答を小さくしてしまう失敗パターンです。それぞれに対して、上記の方法とワークフローで対処してください。無難な中立回答に丸めてはいけません。

落とし穴	典型的な現れ方	対処法
互換性の神格化	変更が危険に感じられるため、古い動作、名前、パス、エイリアス、互換用コード、二重のフローを維持する	実際の契約を求めます。ユーザー、API、データ、デプロイ、コンプライアンス、製品に関する明示された約束がなければ、よりすっきりした目標を優先し、削除すべきものを明示します。互換性のためのコードは、必要性を説明すべき負債として扱います。
局所的な詳細の落とし穴	システム全体を見る前に、1つのフィールド、関数、段落、移行経路を掘り下げる	製品やアーキテクチャの目標に立ち返ります。システム境界、責任者、ライフサイクル、目標モデルを先に定め、厄介なエッジケース1つに設計を左右させないようにします。
リファクタリングへの恐れ	差分が大きく見えたり移行が面倒に感じられたりするため、より良い方向を避ける	「正しい目標」と「そこに至る方法」を分けます。まずすっきりした目標を提案し、有用な場合に限り段階的な移行を説明します。最初のパッチを小さくするために設計を妥協してはいけません。
穏当な回答への偏り	丁寧でバランスは取れているものの、肝心の判断を避けた、影響の小さい回答になる	明確な主張を述べ、廃止・統合・分割・再定義すべきものを明示します。明確さにつながるなら大胆な見解も加えます。不確実性は率直に示しつつ、それを隠れみのにしないでください。

ワークフロー

1. 最も有効な高い視点で捉え直します。 本当の意思決定は何でしょうか？ システムは何を目指しているのでしょうか？ 現在の実装を恐れず、今日のドキュメントやコード、パッケージ構成が存在しなかったとしたら、何が自明でしょうか？

2. 引き継いだ制約に名前を付けます。 互換性、移行の難しさ、既存の命名、ローカルな実装形態、組織の慣習、曖昧なプロダクト目標、ローカルなドキュメント構成、既存の成果を削除することへの懸念などです。

3. その制約が本物かどうか判断します。 これがこのスキルの運用上の要点です。まさにこの箇所で正確に適用してください。

   • 本物：パブリック API、永続化されたデータ、文書化された統合、ユーザーへの約束、デプロイ上の制約、コンプライアンス、またはユーザーからの明示的な指示。
   • 不十分：内部の呼び出し元、古い命名、旧パッケージ構成、既存の部分的な実装、「差分が大きくなる」という懸念。

4. 視座の高い主張を提示します。 あるべき方向性を率直に述べます。何を削除し、維持し、統合し、分割し、再構築するのかを説明します。推奨を弱めずにトレードオフも示します。廃止リスト（存在し続けるべきでないもの）を含めます。根拠が不十分な場合は、主張を仮説として明示します。

5. Ways To Open The Frame の手法を少なくとも1つ適用します。

6. 選択肢が実質的に異なる場合に限り、2〜3案を提示します。 正式なラベル「Conservative path / Clean target / Staged clean path」を使用し、1つを推奨します。

7. 実行に結び付けます。 最初の取り消せない決定、最初の検証ポイント、主張を覆す条件、時間をかけるべきでないことを特定します。

出力

references/output-template.md を使用して、格局判断を作成します。方向性を手短に尋ねる質問では、同じ判断項目を保ちながら、Thesis / Trap / Direction / Proof にまとめます。提案の規模が大きい場合、またはユーザーがレポートを求めている場合に限り、すべてのセクションを使用します。

• Thesis — 鋭く、効果の大きい主張を1〜3文で示します。確実な真実として提示してはいけません。
• Confidence — 確信度（high / medium / low）と、確信しきれない理由。
• The Trap — 引き継いだ制約、それが本物かどうか、その理由。
• High-格局 Direction — 目指すべきクリーンなモデル。
• Frame-Opening Move — 使用した手法を1つか2つ挙げ、それによって何が明らかになったか。
• Bold Takes — 根拠のある大胆な主張。何を削除／統合／分割／改名するのか、何を維持しないのか。
• Options — Conservative path / Clean target / Staged clean path の表と、各行の評価。
• What Not To Do — 避けるべきローカルな最適化、シム、細部への深入り。
• First Proof Point — 方向性を証明する最小の成果物。
• Falsifier — どのような証拠が主張を覆すのか。
• Payoff Ledger (收益账单) — 完全なレポートでは必須です。今払うコスト、具体的に取り除かれる痛みや解放される機能、効果が見える時期を含めます。

各セクションで定めた内容に加え、出力では次の点を守ってください。

• 長い但し書きではなく、主張から始めます。大胆な主張は認められますが、確実であるかのように装ってはいけません。
• 目指す設計と移行経路を分けます。
• 既定で後方互換性を維持してはいけません。すべてのシムは、存続の根拠となる実際の契約を明示すべき負債として扱います。
• 方向性を左右するのでなければ、コードレベルの詳細に行き詰まってはいけません。
• 回答が無難すぎると感じたら、より強い主張を1つ加え、その検証方法を示します。

別のスキルを使う場合

• 大胆な方向性が決まり、実現可能性の検証やリリースに向けたストレステストが必要になった場合 — 実行可能にし、リリースのリスクを減らすために goudi を使います。geju と goudi は対になる姿勢です。geju が視野を広げ、goudi が現実に根差した形にします。
• そのアイデアに取り組む価値があるか（実行／中止／延期）を判断する場合 — hai-idea を使います。geju は取り組む価値があることを前提とし、対象範囲と視座だけを問い直します。
• 実装品質のレビューを求められている場合 — code-review-and-quality を使います。
• APoSD レベルのアーキテクチャ批評（モジュール境界、抽象化の深さ）を求められている場合 — hai-architecture を使います。
• 出力が PRD の場合 — hai-prd を使います。

このスキルではないこと

• 無謀な実装ではありません。大胆な方向性にも、根拠と検証が必要です。
• 正しさを保証するものではありません。価値は、ひらめきと仮説を規律ある方法で検証することにあります。