culture

/culture

2 つのモードがあります。ユーザーのフラグではなく、呼び出しのコンテキストによってモードが選択されます。

1. 内部モード（デフォルト）。 他のワークフロースキルは、/cheese 自体も含め、思考の工程として /culture を暗黙に呼び出します。質問を言い換え、前提を列挙し、候補となる選択肢を挙げ、簡単な形状チェックを行い、次のアクションを決めます。この対話はユーザーには表示されません。表示されるのは、記録台帳を引き継いだ結果の判断と、呼び出し元のスキルが行うコード編集のみです。よくある呼び出し元は次のとおりです。
   • /cheese のステップ 1 — アナウンス前の、暗黙の分類推論。
   • /cheese の ティア 2 エスカレーション（skills/cheese/SKILL.md § エスカレーションを参照）— 生の入力に対するクック・ファストパスの明確さチェックが失敗した場合に、不足しているコンテキストを補います。統合した内容はミニ仕様の ## Provenance セクションに記載されます。
   • その他のワークフロースキルにおける、ディスパッチ前の独自の推論工程（mold、cook のテイストテストなど）。
2. ユーザー向けモード。 ユーザーは何かを作るのではなく、考えを整理したいとしています。本番コードも仕様書も PR も作成しません。これは culture の継続的なドメインモデリングモードです。質問に必要なだけ深く調査し、収束を無理に促すのではなく、ターンやセッションをまたいで話題を継続し、考え、決定、情報が固まるたびに記録します（## 記録台帳）。最後に、後からモデリングを再開できるよう、永続的な /wheypoint を作成します。ユーザーが「書き込みなしで」／「壁打ちして」／「ただ話したい」と述べた場合、問題について考え抜きたいと依頼した場合（「このバグは関連している気がする」「修正する前に理解したい」など）、または思考とモデリングのタスクをここに振り分けた場合は、このモードに入ります。

ユーザーが仕様書の作成（/mold）、実装（/cook）、バグの診断や修正（/pasteurize）、レビュー（/age）、外部情報の収集（/briesearch）を求めている場合は、ユーザー向けモードを使用しないでください。これらの依頼には内部モードで対応し、呼び出し元のスキルが作業を行います。

会話によるナビゲーション（プロトタイプ）

ユーザー向けセッションでは、ユーザーは通常の会話を通じて問題のレベルを調整します。これはナビゲーションであり、別個の開始経路ではありません。 高度のナビゲーションは、以下のフローを補完します。 証拠からパターンや、挙動と目標の間の隔たりが明らかになった場合は、有用な高度の変更を提案します。 解釈を明示し、合意した証拠の範囲内にとどまります。 提案があっても、広範な監査や後続工程への移行が許可されたことにはなりません。 レベル間を移動するとき、共通の原因を検証するとき、または関係性を導き出すときは、問題の高度を読んでください。 暗黙の内部推論は変更しないでください。参照資料を読み込んだり、ユーザーへの聞き取りを始めたりすることはありません。 記録台帳とセッション終了時の引き継ぎは、引き続き Culture が担当します。 挙動の評価には、プレッシャーシナリオを使用してください。

不変条件

/culture は本番コードや仕様書を書かず、変更をコミットしたり、PR を作成したり、プロジェクトの状態を変更したりしません。作成するのはナレッジです。ユーザー向けモードでは、## 記録台帳 を通じて考え、決定、情報を記録し、各セッションの最後に、永続的な引き継ぎを /wheypoint に委任して作成します（## 引き継ぎスラッグを参照）。この wheypoint はセッション終了時にのみ作成し、対話中には決して作成しません。セッションが終了したと宣言するのはユーザーです。エージェントがユーザーに代わって収束を宣言することはありません。話題がまとまったように感じるか尋ねることはできますが、そうでなければ話題を引き継ぎます。ユーザー向けの会話で何かを作る必要があるとわかった場合は、wheypoint を作成した後に /mold または /cook に振り分けます。内部モードでは、判断を返すだけで、呼び出し元のスキルに対応を委ねます。

フロー

どちらのモードも、この推論ループを共有します。各ステップで異なるのは、内部モードでは判断を返し、ユーザー向けモードでは対話を表示する点です。

1. 質問や論点を一文で言い換えます。質問の前提が誤っている場合や、誘導的な仮定に基づいている場合は、それを明示します。
2. 前提、制約、判断基準を特定します。
3. トレードオフと、影響が及ぶ範囲を検討します。トレードオフの判断が「何に影響するか」にかかっている場合は、候補となる接合点について読み取り専用の構造チェックを実施します。意味的な呼び出し元検索と、選択したバックエンドから得られる依存関係／影響範囲のコンテキストを使い、各選択肢に [low | medium | high blast radius] のラベルを付けます。手順は ../mold/references/shape-check.md に準じます。culture は結論で止め、シグネチャの草案は作成しません。推奨案を決める前に、却下する選択肢の最も説得力のある論拠を示します。
4. 質問に必要な深さまで根拠を集めます。まず軽く Wiki を調べ、すでに決定済み、または既知の内容かを確認します。これは ../cheese/references/optional-plugins.md の検出して縮退する契約に従います。内部モードでは ground の呼び出しは最大 1 回とし、ユーザー向けモードでは有用な範囲で増やします。hallouminate がない場合は調査を省略し、その不在について一度だけ記し、設計の根拠が中心となる場合は確信度を speculating に上限設定します。内部モードでは呼び出し元のスキルを高速に保つため、残りの調査も軽くします。簡単な構造チェックにとどめ、深い調査は行いません。ユーザー向けモードでは、有用な範囲で深く調査します。読み取り専用の explorer エージェントにコードの根拠調査を依頼し、その要約を受け取ります。生の読み取り結果を対話にそのまま流し込まないでください。エージェントを利用できない場合は、選択したソースコードバックエンドを直接呼び出します。
5. 次の動きを決めます。内部モードでは、推奨案を一つ返して終了します。ユーザー向けモードでは、必ずしも結論を一つに絞る必要はありません。簡潔な要約、Ideas / Decisions / Info の台帳、確信度を付けた未解決の質問（certain | speculating | don't know）を示し、その後、後続のスキルを推奨するか、判断を保留してスレッドを引き継ぎます。ユーザーがスレッドの終了を告げたら、台帳を反映し、ウィーポイント（## Handoff slug）を書いてセッションを終了します。ウィーポイントの next: には、モデリングの着地点を記録します。

ユーザーに尋ねることが目的です。重要な分岐はすべてユーザー自身が決められるよう、決定を代行せず選択肢として提示します。分岐が重要かどうかは、../age/references/voice.md のレバレッジ基準に従います。それより影響の小さい事項は、拒否可能な代替案を添えてすべて [AGENT-DECIDED] とします。提示する詳細さ（完全なシグネチャ、具体的なエッジケース、ファイルと行番号の根拠）は、それぞれの質問に役立つものであり、質問することの代わりにはなりません。ユーザー向けモードでは、対話の中で分岐を会話形式で提示します。構造化された質問ツールを使うのは、セッション終了時の引き継ぎ確認に限ります。重要な分岐を複数、一つの質問にまとめてはいけません。

記録台帳

思考は記録に残す価値があります。ユーザー向けの各ラウンドでは、未解決の質問と併せて Ideas / Decisions / Info 台帳を表示し、各項目はコードではなく、永続的なナレッジレーンに必ず記録します。

種類	該当するもの	hallouminate がある場合の保存先	ない場合の代替先
Decision	ユーザーが実際に却下した代替案がある選択肢を決定したもの	../mold/references/adr.md の形式と解決方法に従った、repo:<repo>:wiki 内の adr/ 配下の ADR	docs/adr/<slug>-NNN.md
Idea	誰も確定していない、再検討する価値のある方向性	wiki 内の ideas/<slug>.md	docs/culture/<slug>.md § Ideas
Info	対話の途中で得られた事実、制約、注意点	拡張先の wiki ページに追記します（ground → read_markdown → add_markdown { overwrite: true }）。該当するページがない場合に限り新しいページを作成します	docs/culture/<slug>.md § Info

adr_target() と同じ方法で保存先を解決します。現在のリポジトリにある repo:<repo>:wiki コーパスの形状に合わせ、リテラル名は決して使いません。hallouminate がない場合は、追跡対象の代替先に書き込み、その旨を目立つ一行で伝えます。ユーザーが record that、note that、または remember that と言ったら、その場で項目を記録します。残りは、ユーザーがスレッドの終了を告げた時点で、wheypoint を作成する前にまとめて記録し、その後 wheypoint から各記録を成果物の下にリンクします。ユーザーが確定も記録の依頼もしていない、ふとした考えは決して記録せず、wheypoint に残します。内部モードでは何も書き込みません。呼び出し元のスキルが永続化できるよう、決定の中に台帳を返します（Mold の Curdle は決定を ADR にし、ミニ仕様書では ## Provenance の下に引用します）。

優先ツールと代替手段

code-intelligence-routing.md に従って、ソースコード検索と読み取りのバックエンドを直接呼び出します。影響範囲を調べる際は、セマンティックな呼び出し元検索と、バックエンドが提供している場合は読み取り専用の依存関係／形状チェックを使用します。

ソースコードのルーティングに加えて、カルチャー固有のツールがあります。

必要なこと	優先する手段	代替手段
差分や例の可視化	delta	通常の git diff
外部の妥当性確認	/briesearch	仮定であることを明示する
Wiki による根拠付け（根拠確認のステップ。内部モードでは ground は最大 1 回）	repo:<repo>:wiki に対する mcp__hallouminate__list_corpora と mcp__hallouminate__ground。詳細は ../cheese/references/optional-plugins.md を参照	省略し、不足していることに一度だけ触れ、設計根拠が重要な場合は speculating の段階にとどめる

任意ツールが使えなくても、会話を中断してはいけません。内部モードでは、ツールの使用を最小限にします。これは素早く思考するための段階です。ユーザー向けモードでは、質問に応じてツールの使用範囲を広げます。モデリングの根拠が必要な場合は、explorer エージェントによる調査、またはそれが使えないときはソースコードのバックエンドを直接呼び出すことが想定されています。

出力

Flow のステップ 5 を参照してください。

引き継ぎ用スラッグ

モデリングを再開できるよう、すべてのユーザー向けセッションの最後に、永続的な wheypoint を必ず作成します。/wheypoint <focus> を呼び出し、圧縮、秘密情報の削除、状態に対応した推奨スキルのセクション、再開可能なスラッグの管理を任せます。Culture は独自のスキーマを管理しません。スラッグの契約（status ／ next ／ mode ／ artifact と ## Document 本文）は、唯一の信頼できる情報源である skills/wheypoint/SKILL.md で定義されています。

Culture に関連する next: の値は次のとおりです。後のセッションでモデリングを再開する場合（収束を保留する場合）は culture または hold、曖昧なアイデアを仕様に進める場合は mold、依頼が明確で実装に進める場合は cook、ユーザーがスレッドを本当に終了したと判断した場合は done です。次のステップが人間の判断待ちで止まっている場合は、next: の値ではなく status: gated: を設定します。

引き継ぎ

パイプライン： [文化] → 成形 → 調理（⇄圧搾）→ 熟成 → 仕上げ → 盛り付け

セッションの終了時には、まず永続的な wheypoint を記録し（/wheypoint を呼び出します）、その後、会話から実際の作業が明らかになった場合は、../cheese/references/handoff-gate.md の共有引き継ぎゲートを通じて確認します。このゲートに届く構造化された確認事項はすべて、../cheese/references/ask-user-question.md の鮮度ルールを満たす必要があります。つまり、今のセッションで会話を通じてすでに話し合われた分岐だけを、ここで構造化された質問として提示できます。各選択肢は、動詞（ユーザーが次に「何をしたい」か）から始め、スキルのコマンドは補足情報として記載します。質問する前に、後続のスキルが議論の内容を失わずに処理を開始できるよう、簡潔なコンテキストパケットを提示してください。

handoff_context:
  source_skill: /culture
  summary: <one factual sentence>
  open_questions: [<only blockers, if any>]
  artifact: .cheese/notes/<slug>.md  # the session wheypoint, always written
  records: [<wiki page or fallback path per written ledger entry>]

既定の選択肢（以下から最大3つと、停止を選択します）：

• これを文書化された仕様にまとめる（アイデアがまだ曖昧な場合に推奨）— コンテキストパケットを添えて /mold を実行します。ノートのスラッグがある場合は /mold .cheese/notes/<slug>.md を実行します。
• そのまま実装する（依頼が明確で曖昧さがない場合に推奨）— 合意済みの仕様としてコンテキストパケットを添えて /cook を実行します。
• 実装して自動レビューする — /cook --auto をコンテキストパケットとともに実行します。Cook の Press ループを実行した後、/age → /cure と自動的に連鎖し、最大2回の cure パスにわたって、中程度以上の指摘事項と、低コスト（範囲が限定された修正）の軽微な指摘事項をすべて修正します。最終の cure パスで停止します。PR の作成または更新は手動で行う必要があります。会話の中で曖昧さのない仕様に合意できた場合は、これをあらかじめ選択します。ユーザーが各ステップでの承認を希望する場合は、代替案として自動実行しない /cook を提示します。
• まずさらに調査する（会話で見つかった事実の不足を、外部ドキュメントで補える場合）— /briesearch を実行します。
• 一時停止して後で再開する — 何も実行しません。セッションの wheypoint に状態がすでに記録されているため、いつでも /cheese --continue <slug> で再開できます。

停止以外を選択した場合は、コンテキストパケットを添えて、選択された後続スキルを直ちに実行します。文化工程から次に /age を実行することはありません。レビューには確認する差分が必要です。

ルール

• 書き込むのはナレッジのみです。## Record ledger の記録とセッション終了時の wheypoint に限り、コード、仕様、コミット、PR は作成しません。## Invariant を参照してください。
• 作業の方向性を決める判断はユーザーに尋ねます。探索中は、一度に重要な分岐を一つずつ確認し、自分で決めないでください。それ以外は自分で決定し、記録します。
• 合意が妥当な場合は合意し、バランスを取っているように見せるためだけに反論を作り出さないでください。
• 外部の根拠から別の選択肢が浮かんだ場合（「X は Y または Z を使います」など）は、対話の中でトレードオフを示し、候補の選択肢として提示します。「両方追加する」や「設定項目を設ける」と黙って推奨してはいけません。重要な設計判断は、引用情報からエージェントが推測するのではなく、ユーザーによる明示的な判断が必要です。影響力の小さい判断は一つを選び、代替案を記録します。
• 共有のボイスカーネル（../age/references/voice.md にあります）を適用します。まず答えを述べ、確信度を certain | speculating | don't know で示し、最も有力な反対意見を公平に扱い、会話の各ターンを通じて矛盾を追跡します。