mcpField
M
mold

mold

github.com/paulnsorensen開発19663 回インストール6 日前に更新
リポジトリ

mold について

moldは、目標の明確化や設計上の選択を経て、検証済み仕様を作成する開発スキルです。簡易なミニ仕様から本格的な計画まで対応し、Cookの実行前に対象範囲の明示的な選択を求めます。

主な機能

  1. 01Quick・Light・Fullの計画段階
  2. 02目標と非目標の整理
  3. 03根拠に基づく設計対話
  4. 04インターフェースとモジュールの形状確認
  5. 05検証済み仕様ドラフト
  6. 06範囲を限定した作業の型付き計画

活用シーン

  1. 01曖昧なアイデアの仕様化
  2. 02報告されたバグや障害の調査
  3. 03実装前のアプローチ比較

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/paulnsorensen/easy-cheese --skill mold

インストール後、Claude Code で/moldを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

wedge.toml
references/
adr.md
commands.md
context-budget.md
curd-count.md
curdle.md
early-curds.md
evals.md
fork-questions.md
gate-graph.md
grounding.md
handoff-menus.md
handshake.md
mini-spec-mode.md
modes.md
prototype-cycle.md
review-canvas.md
shape-check.md
tiers.md
validate-cycle.md
scripts/
mold.dot

詳細

/mold

作業に応じて手順の規模を調整します。Bounds パスでは、references/tiers.md から 3 つのティアのいずれかを選びます。Quick では検証済みのミニ仕様を書き、Light では未解決の分岐に必要な対話モードのみを実行し、Full では以下の Flow 全体を実行します。仕様の保存に抽出の承認は必要ありません。Cook の実行には、引き続きユーザーからの明示的なリクエストが必要です。/cheese のティア 1 エスカレーションではミニ仕様モードに入ります。## エージェント起動のミニ仕様モード を参照してください。

フロー

  1. 範囲の確認 — 目標を1文で固定したうえで、Goal / Decided / Asking / [AGENT-DECIDED] 台帳を開きます。明示的なユーザーの分岐選択があった場合に限り、目標を変更します。これを G-n 条項に分割します(references/handshake.md § Goal coverage)。各入力の目標と非目標を、1行の [AGENT-DECIDED] にまとめます。目標が本当に不明な場合、またはレバレッジのトリガーが発生した場合に限り、ユーザーに質問します。形状チェックを実行し、その理由とともにティアを告知します(references/tiers.md)。ここでは、書き込み承認を求めるターンを挟まずに ## Agent-invoked mini-spec mode へ移行できます。証拠が変わった場合はティアを引き上げ、暗黙のうちに引き下げてはいけません。
  2. ルーティング — references/modes.md からセカンダリモードを選び、告知してから、誤った前提を正します。
  3. 対話 — 重要な分岐はユーザーが選択します。分岐が重要かどうかは、../age/references/voice.md のレバレッジの記述に従います。それ以外の分岐はすべて [AGENT-DECIDED] とします。質問する前に、選択肢、トレードオフ、証拠を提示します。重要な主張はすべて、コード、Validate Cycle、または Prototype Cycle に基づいて裏付けます。矛盾はすべて解消します。分岐について3回連続で質問した後、または要望があった場合に、意思決定マップを提示します。
  4. スケッチ — 複数のモジュールにまたがる作業、または新しいパブリックインターフェースを扱う場合は、references/shape-check.md を実行します。識別と役割を表す名詞を、コード上の参照先に結び付けます。配置ブロックを記録し、本文は記載しません。
  5. 計画と検証 — 新しいコンテキストで分岐の一貫性を確認する試験として、python3 skills/mold/scripts/mold.pyz taste-test を実行します。失敗した場合は、指定された分岐のみを再検討します。判定が3回失敗したら停止します。テイストレビューは仕様を導くためのものであり、Cook の実行参照ではありません。拘束されたカード作業では、型付きの PlannerRequest をディスパッチし、PlannerResultWriterView を検証します(1回再試行し、それでも失敗した場合は実行可能な入力を付けずに保存)。正規化はホスト側で行います。明確な単一カードのタスクでは、プランナーを使わず、単独の Cook を使用できます。Cook を選択する前に、意味上のカードとウェーブを提示します。references/curdle.md § "Typed planner dispatch" を参照してください。
  6. 準備状況の確認 — 保存前に、一貫性のセルフチェックと厳格な仕様検証を実行します。未解決の親作業が残っている場合はドラフトを保存し、各保留事項を execution_holds: に記録します。項目が残っている間は、最終化しても準備完了になりません。書き込みにユーザーの承認は必要ありません。Cook の前に、ユーザーがスコープとルートを明示的に選択していることを必須とします。references/handshake.md と references/early-curds.md を参照してください。
  7. カード化 — python3 skills/mold/scripts/mold.pyz artifact-path specs <slug> で永続仕様のパスを解決し、JSON 応答から path を読み取ります。検証済みドラフトを書き込み、読み戻して確認します。型付きの計画証拠と未解決の保留事項を保持します。ローカルの課題ドラフトと永続的な決定を書き込み、後続作業はそれぞれ承認を得てから公開します。Mold が親の形状を整えている間に、具体的で範囲の明確なカードを references/early-curds.md に従って進められます。選択した仕様パスは単独の Cook に渡せます。拘束されたカードの実行では、ポインターではなく、検証済みの直接参照も渡されます。
  8. Cook を提示するか、形状の調整を続ける — 調整後、python3 skills/mold/scripts/mold.pyz curd-count を実行します。ドラフトを保存しただけでは、実行リクエストにはなりません。ユーザーが拘束されたカードの実行を選択した場合は、scripts/mold.pyz finalize を実行し、準備完了の直接入力のみを渡します。単独で明確なタスクは、マシンによる最終化を行わず、仕様パスで Cook に渡せます。それ以外の場合は、形状の調整を続けるか、Cook コマンドを実行せずに停止します。

移植性:ルール。スラッシュコマンドはホスト上での表示形式であり、制御モデルではありません。

フォローアップ候補

すべての非目標と、対話の中で明示的に先送りされた事項を、[FOLLOW-UP?] のフォローアップ候補にします。実行可能な Cook への引き渡し前に、候補をすべて処理してください。詳細は references/handshake.md § Follow-up disposition を参照してください。

モード

モード使用する場面目標
Exploreアイデアが曖昧な場合実際の問題と課題を特定する
Groundファイル、バグ、既存のドキュメントが指定されている場合証拠に照らして事実を確認する
Shape目標は明確だが、アプローチが定まっていない場合実行可能な選択肢を比較する(必ず「何もしない」を含める)
Sketchインターフェースやモジュールの境界が重要な場合責任範囲と接続点を確定する
Grill有力なアプローチを厳しく検証する必要がある場合各項目の最も説得力のある論拠を示し、設計を変える判断はすべて選択肢としてユーザーに提示する
Diagnose症状、障害、トレースが提示された場合ループを構築する → 再現する → 仮説を立てる → 根本原因を確認する

モード:references/modes.md。評価:references/evals.md。キャンバス:review-canvas.md。

エージェント呼び出しのミニ仕様モード

/cheese の Tier 1 エスカレーションでは、呼び出し元が Cook のファストパスのチェックをすべて通過した後に /mold を呼び出します。Quick Tier は書き込み承認のターンを挟まず、同じモードに入ります。設計に関する対話は行わず、検証済みのドラフトを作成します。仕様のパスを返します。仕様の検証後、その内容を表示し、Cook への直接的な質問を 1 つだけ行います。ユーザーが明示的に選択したら、明確な単独作業については /cook --spec <path> を実行します。ポインターを捏造したり、プランナーを必須にしたりしないでください。ユーザーが指定した場合は --hard を追加します。

このモードでは、完全な一貫性チェックリストは実行されません。エージェントが持ち込んだスコープのチェックは、引き続き暗黙的に実行されます。区別を生む名詞はすべて、ユーザーの入力、または Tier 2 の /culture//briesearch による統合結果から得る必要があります。黙って追加してはいけません。

全手順、ミニ仕様のスキーマ、## Provenance のルール:references/mini-spec-mode.md。

優先ツールと代替手段

code-intelligence-routing.md に従って、ソースコードの検索、読み取り、編集のバックエンドを呼び出します。Shape のチェックでは、セマンティックな呼び出し元検索と依存関係のコンテキストを使用します。手順:references/shape-check.md。

Mold 固有のツール(ソースコードのルーティング以外):

必要なもの優先代替手段
外部検証Context7/Tavily を使った /briesearchユーザードキュメント、リポジトリのドキュメントを使うか、未検証として記録する
Wiki による根拠付け(Ground の開始時と判断ポイントで実施。範囲は references/grounding.md の § When to probe を参照)repo:<repo>:wiki に対する mcp__hallouminate__list_corpora + mcp__hallouminate__ground台帳に hallouminate: absent と記録し、コードの証拠に基づいて進める。設計の根拠が重要な場合は、確度を speculating までに制限する

最初の構造化された質問より先に、根拠付けの記録を残します。 台帳にはまず、引用または hallouminate: absent の調査結果を記録します。裏付けのない主張には、確定するまでそれぞれ [?] を付けます。

サブエージェントのコンテキストゲート

対話、矛盾の解消、保存承認の状態は /mold が管理します。これらを委任してはいけません。証拠の収集が中心となるコード作業は新しいコンテキストの explorer に、外部調査は researcher に委任します。Shape では explorer の要約を入力として使用します。 親コンテキストでの調査は、品質が低下した経路として記録します。予算とチェックポイントについては references/context-budget.md を参照してください。

ゲートグラフ

python3 skills/mold/scripts/mold.pyz gate-graph --render dot|svg|png|mermaid は、1 つのゲートモデルをレンダリングします。Graphviz を使用できない場合、画像出力には Mermaid を使用します。テストでは、ゲートノードとハンドシェイクのチェックリストが一致するように保たれます。references/gate-graph.md を参照してください。

仕様の出所とテスト契約

Mold が生成するすべての仕様には、フロントマターに出所マーカーが含まれます。

source: mold-handshake | agent-mini-spec | mold-curd-mini-spec

仕様には disposition フィールドがありません。## Test Contracts は任意です。仕様に含めてもよく、どのゲートでも必須ではありません。行レベルのルール:references/curdle.md § Test Contracts。

フォークの味見ゲート

python3 skills/mold/scripts/mold.pyz taste-test は、判定をドラフトの SHA256 と各確定済みフォークに紐付けます。古い判定、不完全な判定、またはブロックされた判定は失敗となります。失敗時に再開されるのは指定されたフォークのみで、ラウンドは 2 回までです。承認済みの仕様は、単独作業の場合、変更されていないメタデータのまま /cook --spec <spec-path> に渡します(ユーザーが選択した場合に限り --auto を追加します)。紐付け済みのカード作業では /cook --auto --result <result-path> を使用します。

各フォークは Approach、Interface sketches、Acceptance に記載し、ドラフトに Test Contracts がある場合はそこにも記載します。セクション名は変更しないでください。該当する行にフォーク ID のタグを付け、ディスパッチ前に taste-test --precheck を実行します。goal は Problem statement 内で逐語的に維持する必要があります(goal-drift)。各 G-n 条項には、Acceptance または disposition のタグを付けます(goal-coverage)。references/curdle.md § Spec template と references/gate-graph.md を参照してください。

実行ゲート

Mold は、承認のターンを挟まずに、検証済みの親仕様や初期のカード用ミニ仕様を保存できます。成果物が確定済みとして何を示すかは、引き続きエージェントの一貫性チェックによって決まります。Cook の選択肢を提示する前に、範囲の絞り込み差分(taste-test --coverage)とスコープ監査テーブルを出力してください。未解決の決定事項は、暗黙の承認として扱わず、保留事項として明示したままにします。references/handshake.md を参照してください。

保存済みの仕様、沈黙、--auto、または一般的な設計承認を根拠に Cook を開始してはなりません。ユーザーが対象のカードまたは親スコープと Cook の実行経路を正確に選択する必要があります。スコープまたは計画が変更された場合は、新たな選択が必要です。紐付けられた最終確定に失敗した場合、実行可能な参照を持たないドラフトが保存されます。references/early-curds.md を参照してください。

--hard

Mold はメタ認知チェックを実行しません。検証済みアーティファクトの境界で実行するのは Plate のみです。ユーザーがフラグを渡した場合、Mold は出力するすべての Cook コマンドに --hard を追加します。Cure は同じフラグを Plate に転送します。../hard-cheese/references/composition.md を参照してください。

引き継ぎ

パイプライン: culture → [mold] → cook (⇄ press) → age → cure → plate

Curdle のフェーズ 2 が完了したら、影響範囲のダイジェストを得るため、python3 skills/mold/scripts/mold.pyz curd-count を実行します。ドラフトから Cook コマンドを提示してはなりません。Cook を明示的に選択した場合、単独作業では選択された仕様のパスを保持します。紐付け済みのカード作業では、出力された最終確定コマンド /cook --auto --result <result-path> をディスパッチします。結果には request_id、spec_ref、planner_result_ref、plan_ref、および正確な coverage が含まれます。共有の引き継ぎゲート(policy)を通じて選択を促し、先回りして選択してはなりません。適用可能性、契約、味見レビューのメタデータは変更せずに維持します。ユーザーがフラグを渡した場合は --hard を追加します。

ダイジェストの mode は状況把握のためのものであり、スキルや Cook のゲートではありません。decomposable、candidate_curds、verdict、mode から固定の影響範囲メニューを生成します。references/handoff-menus.md を参照してください。

ルール

  • 対話が先で、成果物はその副産物です。
  • 段階別の文字選択肢。 重大な分岐では、../cheese/references/ask-user-question.md の質問形式を使って A/B/C/D の選択肢を提示します。決定をひそかに下してはいけません。レバレッジラインより下の項目は、既定で [AGENT-DECIDED] です。判断を下し、台帳に拒否可能な代替案を一行で記録し、質問はしないでください。分岐が有効なのは、その深度がまず対話の中で示されている場合に限ります。構造化された質問の前には必ず、分岐と根拠を比較検討する文章を表示してください。未解決の選択肢は一つに保ちます。
  • 分岐カード。 重大な質問の前には毎回、何を決めるのか、何に影響するのか、各分岐を記した分岐カードを提示します。各分岐は記号表またはプレーンテキストのグラフで示してください。選択肢として Explain more を提示します。不明瞭な回答があった場合は、同じ分岐に詳しい背景情報を加えて再提示します(fork-questions)。
  • 高度タグ。 Asking の分岐には、動かす受け入れ基準、公開シーム、または非目標を明記します。いずれも動かさない分岐や、レバレッジラインより下の分岐は、ユーザーへの質問ではなく、[AGENT-DECIDED] とするか、フォローアップ候補にします。
  • 決定台帳。 各ラウンドでは、目標を一字一句そのまま記載したうえで、Goal / Decided / Asking / [AGENT-DECIDED] を出力します。Curdle は重大な決定を ADR に、軽微な決定を仕様に記録します。taste verdict では、確定した重大な項目を一つずつ、正確に一度ずつ挙げます。
  • 決定マップと分岐ラウンドの上限。 新たな根拠を加えない分岐ラウンドが3回連続した場合、高度タグを満たさない分岐が3回連続した場合、またはユーザーが決定マップを要求した場合は、そこで停止します。完了した分岐、残っている分岐、および準備完了またはブロックの verdict を示します。4回目のラウンドには、新たな根拠付け、委任された要約、または /wheypoint チェックポイントが必要です。マップには台帳の状態を示します。成果物は作成しません。
  • コードを実装してはいけません。
  • Mold で本番ファイルを書き込んではいけません。仕様を保存しても Cook の実行は許可されません。
  • 不確かな主張をひそかに確定してはいけません。
  • ../age/references/voice.md にある共通のボイスカーネルを適用します。誤った前提は訂正します。重要な主張それぞれの確信度を certain | speculating | don't know で示します。退ける前に、相手の主張を最も説得力のある形で捉えます。重大な分岐はユーザーに提示します。深度は質問の参考にしますが、質問の代わりにはなりません。

生成された ../cheese/references/schema-intertwine.md には、公開済みのスキーマとその契約モデルがすべて記載されています。

エージェントの解決

../cheese/references/agent-resolution.md を参照して委任先を解決します。

作業優先する種類権限/分離最低限の能力労力フォールバック
コードベースの調査explorer読み取り専用、新規コンテキスト既定中互換性のある explorer、次に general
外部制約の調査researcher読み取り専用、新規コンテキスト既定中互換性のある researcher、次に general
承認用の計画planner, general読み取り専用、新規コンテキスト高性能高互換性のある planner、次に general

標準の mold 仕様またはミニ仕様には、共通の agent_resolution ブロックを含めます。 コマンド:references/commands.md。

コメント