propose

スキル：提案

WHAT

目的とコンテキスト

• 目的： コードを書く前に機能や変更を計画します。既存機能への影響を明らかにし、実装前に合意を得ます。
• 使用するタイミング：
  • 新しい機能、エンドポイント、コンポーネント、動作が求められたとき
  • 共有コードやコアコードに変更が及ぶとき
  • 範囲が不明確、または複数の解釈が可能なとき
• 対象外： コードは書きません（承認ゲートで STOP）。コードレベルの実行計画は作成しません（それは /plan の役割で、SPEC の承認後に実行します）。求められない限りユーザーにインタビューしません（/br interview）。

メンタルモデル

request → force-query wiki (Context) → unknowns → impact + side-effect → Approaches (2–3, 選択理由も提示) → SPEC draft .md (FR/SC id, Assumptions (default)/[要確認]) + companion .html (各タスクのarchify図 + 説明文) → self-review → STOP 承認ゲート → /plan。

このスキルが作成するもの — 意図的に作成しないもの

/propose は SPEC（設計書）を作成します。これは承認ゲートで承認するために人間が読むものです。実行計画ではありません。 コードレベルの計画（正確なパス、関数シグネチャ、テスト、コードの手順）は、/plan スキルの役割で、SPEC の承認後に実行します。

分離する理由（obra/superpowers との比較、spec:plan の比率 ≈ 1:8 — 82–511 行に対して 673–2621 行）：コードレベルの内容を SPEC に詰め込むと、承認者が審査対象を読めないほどドラフトが膨らみ、承認ゲートが機能しなくなります。文書は2つ、読者も2者です。

入力と出力の契約

	フィールド	必須？	意味
入力	機能／変更の要件	はい	ステップ1で1文に言い換えます
入力	wiki（concepts/、entities/、sources/adr/、decisions.md）	はい	ドラフト作成前に必ず照会します
出力	llmwiki/wiki/sources/draft/DDMMYY-feature-name-module.md	はい	frontmatter は type: draft。R7 の全項目（Context、Global constraints、Non-goals、Approaches、Plan、FR、SC、Assumptions、Agent Task Assignment、Sequence diagram、Self-review）を含みます
出力	llmwiki/html/DDMMYY-feature-name-seq.html + 各タスクの spec/artifact archify	はい	エンジン図と各タスクの完全な説明文、双方向リンク
出力	llmwiki/wiki/index.md と llmwiki/wiki/log.md の行	はい
出力	タスク ID T-YYMMDD-NN	いいえ（fail-open）	frontmatter の task:
出力	ドラフトの出力レポート	はい（成果物が0件の場合を除く）	Delivery 項目

ルールと機能

• RULE-01（必須）：OKF v0.1（R9）： ドラフトは YAML frontmatter ブロック（---）で始め、type: draft（title／status／tags／timestamp／task は任意）を含めます。sources/draft/_template.md をコピーします。R7 が状態をチェックできるよう、本文に **Status:** proposed を残します。
• RULE-02（必須）：このスキルの実行中は、実装を開始しないでください。
• RULE-03（必須）：提案は .md + .html のペアです（タスクごとに図を1つ）。Validator R7 は、不完全な提案を作成時およびコミット時にブロックします。承認を求める前に修正してください。
• RULE-04（必須）：影響を受ける項目がない場合は、「既存コードへの影響はありません」と明記してください。
• RULE-05（必須）：複数のアプローチがある場合は、トレードオフを示してください。黙って選択してはいけません。
• 機能：wiki とリポジトリを読み取って事実を確認する、wiki にドラフト・HTML ページ・図の仕様を書く、描画エンジンで図をレンダリングする、未確定事項の記録とタスク ID の記入（fail-open）、製品コードは書かない。

失敗時の境界

• SPEC に未回答の [要確認] が残っている → 承認ゲートで ブロック（R7-n）。
• ドラフトに R7 の項目（Context／Global constraints／placeholder など）が不足している → Validator が作成時とコミット時にブロックします。承認を求める前に修正してください。
• 仕様を2回修正しても図のレンダリング結果が赤のまま → 停止してユーザーに確認し、検証を繰り返さないでください。
• code-logger.py --task が失敗または不足している → 「スキップ」と出力し、task: は空欄のままにします。ブロックしません（fail-open）。
• ユーザーがまだ承認していない → ステップ9で停止します。PLAN がない状態でディスパッチしてはいけません。

HOW

メインワークフロー

Step	Type	Inputs	Action	Outputs/exit	Failure/next
W01	deterministic	wiki	手順 0：wiki を強制検索 → ## Context	コンテキスト + 引用	—
W02	judgment	request	手順 0b：不明点を洗い出し、事実（調査）／判断（(default)・後で確認・[要確認]）に分類	階層化された不明点の一覧	アーキテクチャに関わる階層に問題 → [要確認]
W03	judgment	request, repo	手順 1–5：言い換え、影響、サイドエフェクト、最小限の計画、成功条件	SPEC の内容	影響がない場合 → 「既存コードへの影響はありません。」と記載
W04	effect	W01–W03	手順 6：R7 の全項目 + タスク ID + インデックス／ログを含むドラフト .md を作成	ディスク上のドラフト	R7 でブロック → 修正
W05	effect	Plan	手順 7：コンパニオン HTML — 各タスクの spec を archify し、1 つのシェルコマンドをレンダリングし、iframe + 説明文を埋め込み、シェルは docs-site-macos	.html + 成果物	2 回の反復後も赤 → 停止して確認
W06	judgment	draft	手順 8：3 つの観点からセルフレビューし、その場で修正	## Self-review	—
W07	effect	draft + html	手順 9：STOP、ドラフト + HTML URL を表示し、承認を待つ	承認／方向転換	未承認 → cancelled/redirect
W08	effect	SPEC duyệt	手順 10：/plan に引き渡す	PLAN	—

各手順の詳細（W01–W08 の信頼できる情報源）： 0. 草案を作成する前に必ず wiki を検索する — 関連するコンセプト／ADR／決定事項を見つけるため、wiki（concepts/、entities/、sources/adr/、decisions.md）を検索して読みます。草案の ## Context に要約し、[[wikilink]]／パスを引用します。根拠なく提案してはいけません（R7-f により、内容のある ## Context がない草案はブロックされます）。 0b. 草案を作成する前に不明点を探す（地図 ≠ 領土、GH#40 — fdk/wiki/concepts/map-not-territory.md を参照）：モデルは強力であるほど、曖昧な部分を自信たっぷりの回答で埋めてしまいます。SPEC の一行目を書く前に、「この作業を正しく進めるために、私がまだ知らないことは何か？」を簡潔に列挙します。地図が嘘をつきやすい 5 つの点を確認します。(a) 依頼者の暗黙の意図、(b) wiki や CLAUDE.md に記載されていない部族的な慣習、(c) 実際のデータ形状（スキーマ、サンプル、境界）、(d) 実行環境（バージョン、環境変数、権限）、(e) wiki が書かれてから変更されたこと。各不明点は、以下の ## Assumptions の適切な層に記載します。事実 → 調査する。リスクの低い決定 → (default)。再確認が必要 → (default, find-out-later → unknown-ledger)。誤っているとアーキテクチャが壊れる → [要確認]。不明点がないのは、すでに理解した証拠ではなく、まだ探していない証拠です。

1. 理解を確認するため、依頼内容を 1 文で言い換えます。
2. 影響を受ける、または変更が必要な既存のファイル、関数、モジュールをすべて列挙します。
3. 副作用で壊れる可能性のある既存の機能や動作をすべて列挙します。
4. 最小限の実装計画を番号付きの手順で提案します。
5. 成功の状態（検証可能な基準）を示します。
6. llmwiki/wiki/sources/draft/DDMMYY-feature-name-module.md に草案ファイルを作成します（例：260425-new-approval-button-fe.md）。手順 1～5 の提案内容を含めます。草案には次の項目を必ず含めてください（バリデーター R7 により、欠落時は書き込み時およびコミット時にブロックされます）。
   • ## Context — 手順 0 で検索した関連 wiki（コンセプト／ADR／決定事項）の要約。[[wikilink]]／パスを引用します（強制的な検索に基づく根拠づけ — 欠落または空の場合、R7-f によりブロックされます）。
   • ## Global constraints — すべてのタスクに適用される制約。wiki／ADR／ポリシーに記載された実際の値をそのまま転記します（最低バージョン、依存関係の制限、命名規則、push 前に必須のゲートなど）。各タスクはこのセクションを暗黙に引き継ぎます。実行エージェントには自分のタスクしか見えないため、共通制約は誰にでも注入できる場所に記載する必要があります。欠落または空の場合、R7-h によりブロックされます。
   • ## Non-goals — 意図的に実施しないことを記載します。この項目がないと、実行中にスコープがぶれてしまいます。
   • ## Approaches — 本質的に異なる 2～3 個の方法、それぞれのトレードオフ、選択した方法とその理由を記載します。暗黙の選択は禁止です。
   • ## Plan — タスクを - [ ] 形式のチェックリスト項目として記載します。
   • ## Requirements (FR) — 各機能要件に安定した IDを付与します。例：**FR-001**: システムは…しなければなりません。 これは PLAN が逆方向に追跡するためのアンカーです（R18 により、PLAN で ID が 1 つでも漏れるとブロックされます）。
   • ## Success criteria (SC) — 各基準に安定した IDを付与します。例：**SC-001**: …。以下の「基準は機械ではなく人を測ること」という項目を参照してください。
   • ## Assumptions — ユーザーが述べていないのにモデルが補ったすべての項目を記載し、各行に (default) タグを付けます。以下の「補ってよいか、質問すべきか」という項目を参照してください。

Fact か Decision か — 先に調べ、後で尋ね、間は自分で埋める

「自分で埋めるか、尋ねるか」より先に考えるべき問いがあります。これは FACT か DECISION か？

• Fact — 正解があり、環境を調べれば確認できます。ファイルを読む、コマンドを実行する、grep する、git remote -v を確認する、package.json を読む、などです。→ 調べてください。絶対に尋ねないでください。 ツールで答えられることをユーザーに尋ねるのは、ユーザーの時間を無駄にし、環境を読み取る能力がないと思わせてしまいます。
• Decision — 正解がなく、選択を要するものです。ここで初めて、以下の (default) / [CẦN LÀM RÕ] に分かれます。決定するのはユーザーです。ただし、リスクの低い決定のほとんどは、妥当なデフォルトを自分で設定して明示し、リスクが高い場合にだけ尋ねてください。

境界線はこうです。コマンド一つで見つけられるなら、それは fact です。調べてください。合理的な人同士でも異なる選択をする可能性があるなら、それは decision です。以下の階層に従って処理してください。

ユーザーが明示していない DESIGN の選択は、リスクの低い decision です。デフォルトから埋め、尋ねないでください。 brief に UI が含まれていて、ユーザーがマクロ構造、テーマ、書体の組み合わせ、基調色を明示していない場合、聞き取りをしてはいけません。[[design-foundation]] のカタログ（参照元：skills/hallmark/references/macrostructures/ + references/genres/）から brief に合うデフォルトを埋め、(default) タグを付け、選んだマクロ構造とテーマの名前を ## Assumptions に記載してください。ユーザーは一目で機械が選んだ内容を確認でき、気に入らなければ一行変更するだけです。マクロ構造の選択を誤っても、すぐに修正できます。認証や金銭の問題ではありません。これは、設計上の未知の項目を埋めるための参照元であり、適切な (default) の仕組みに組み込まれています。creative-intent を含む brief に合うテーマがない場合、hallmark は自動的に Custom 分岐に進みます。それでも 6 discipline + slop-test は維持されます。

自分で埋めるか、尋ねるか — デフォルトは「自分で埋める」

ユーザーは、自分が知っていることをすべて説明しています。知らないことについて聞き取りをしないでください。妥当なデフォルトを自分で埋め、そのことを明示してください。

• (default) — モデルが自分で選択します。そのまま進めて、尋ねません。レビュー担当者は ## Assumptions に目を通すだけで、どこがユーザーの言葉で、どこが機械の言葉かをすぐに見分けられます。同意できない箇所があれば、その行を修正できます。

• (default, find-out-later → [[unknown-<slug>]] U-NN) — 中間の階層です。作業を止めないよう、モデルが今すぐデフォルトを埋めますが、黙って済ませず、記録された負債として残します。デフォルトにリスクがあり、後で確認が必要だと分かっている場合に使います。[CẦN LÀM RÕ] を下げる場合も同様です（ユーザーが「いったん埋めて、後で考える」と言った場合）。python3 harness/scripts/unknown-ledger.py --add … で負債を記録すると、U-NN が出力されます。これを Assumptions の行に貼り付けてください。この負債はゲートを止めません。埋もれないように /lint に表示されるだけです。[[150726-unknown-ledger]] を参照してください。

• [CẦN LÀM RÕ: <câu hỏi cụ thể>] — モデルは推測を拒否し、SPEC の該当箇所にそのまま置きます。デフォルトを誤るとアーキテクチャやユーザーに重大な悪影響がある項目にのみ使います。これは CLAUDE.md の例外条件に一致します。

  • 認証／権限の仕組み（誰が何をできるか）
  • データの保存：何を、どこに、どれくらいの期間保存するか、誰が読めるか
  • 金銭／決済／上限
  • 法的またはコンプライアンス上の影響があるもの
  • あらゆる信頼境界（外部からの入力、システム境界）

  SPEC に回答されていない [CẦN LÀM RÕ] が残っている場合、R7-n がレビューゲートをブロックします。 ユーザーが回答したら、実際の値に置き換えます。ユーザーが「推測していい」と言った場合は、意図的に (default) に下げ、記録を残します。

色付きのボタンを間違えても、修正にかかるのは三十秒です。認証の仕組みを間違えると、その (default) がひそかにアーキテクチャ上の決定となり、レビュー担当者は「完了したように見える」ため見落としてしまいます。(default) だけでは推測を正当化する道具になってしまいます。[CẦN LÀM RÕ] と組み合わせて初めて安全に使えます。

Interview はユーザーが要求した場合にのみ実行します（/br interview）。実行する場合も、質問は最大5つで、（Impact × Uncertainty）に基づいて選びます。

選択肢から回答する形式の Interview には、必ず最後に「今はデフォルトを埋めて、後で調べる（unknown として記録）」という選択肢を用意します。 ユーザーが自信を持てず、考えるために作業を止めたくもないが、モデルに黙って推測されたくもない場合は、この選択肢を選びます。モデルは妥当なデフォルトをすぐに埋めて作業を続け、後で返すための unknown を台帳に記録します。これにより、回答の準備ができていない問いにも、追跡可能性を保ったまま対処できます。回答を強制せず、黙って推測することもありません。

不明点の負債を返済する — 実際の情報が得られたとき

記録した不明点（(default, find-out-later)）をそのまま忘れてはいけません。実際の情報が得られたら：

1. 正しい値を元のSPEC/PLANに記入する — (default, find-out-later → …) の行を実際の値に置き換えます。
2. 台帳を閉じる： python3 harness/scripts/unknown-ledger.py --resolve --file unknown-<nguồn>.md --id U-NN --value "<giá trị đúng>" --fixed "<sửa ở đâu>" --date <YYYY-MM-DD>。台帳には記入済みの値と正しい値の両方を残します（監査用 — 6か月後に、モデルが何を推測し、それが正しかったか、どこを修正したかを確認できます）。
3. 誤ったデフォルトがすでに誤ったコードを生んでいる場合（推測した値に基づいてすでに実行済みの場合）→ /orca-issue（まず再現）または /raise-issue を開き、本文で U-NN にリンクします。

未解決の負債は /lint に表示されます（レポートのみで、処理はブロックしません）— unknown-ledger.py --list。負債の返済は、人またはエージェントが意図的に行う操作です。スキルは手順を提供するだけで、代わりに「調べる」ことはしません。

質問するとき — 適切な方法で質問する：

• 一度に質問は1つ。 回答を待ってから次の質問をします。質問をまとめて投げると相手を困惑させ、回答もいい加減になりがちです。
• 必ず推奨案を添え、最初に提示します。 そうすればユーザーは「同意」／「最初の案」と一言返すだけで済み、自分で回答を考える必要がありません。

基準はマシンではなく人を測ること

SC-xxx は測定可能で、技術に依存しないものでなければなりません — マシンが何をするかではなく、ユーザーが何を得られるかを示します：

• ✅ 「ユーザーが2分以内にアカウントを作成できる」 · 「性能を低下させずに同時接続ユーザー1000人に対応できる」 · 「Xに関するサポートチケットを50％削減する」
• ❌ 「pytest の実行結果が exit 0」 · 「validator が 2 を返す」 — これはマシンを測るものです。システムがすべて正常でも、役に立たないことはあります。 コンピューター層での確認は引き続き記録しますが、SC-xxxの証拠として記録するのであり、置き換えるものではありません。
  • ## Agent Task Assignment — table | Task | Agent (CLI) | Lý do chọn | Status |。タスクごとに1行、Agentセルを空欄にしないこと。Status=pending。コスト表に基づいてエージェントを選んでください。すべてを1つのエージェントに割り当てる場合は、その理由を記載してください。
  • **Sequence diagram:** — 対応する.htmlへのリンク（ディスク上に存在している必要があります）
  • 永続的なタスクID（柱3 — ベストエフォート、fail-open）： python3 harness/scripts/code-logger.py --task new title="<feature>" → T-YYMMDD-NNを出力します。frontmatterにtask: T-YYMMDD-NNを記載してください。このコマンドはfail-openです。古いインストール環境で--taskが不足している場合、またはストアでエラーが発生した場合は、「スキップ」と表示してtask:は空欄のままにし、提案をブロックしないでください。このIDは、gate／dispatch／verifyがライフサイクルを進め、不変の監査証跡（events.jsonl chained）に紐づけるために使用します。 llmwiki/wiki/index.mdに行を追加し、llmwiki/wiki/log.mdに追記してください。

7. 対応するHTMLページをllmwiki/html/DDMMYY-feature-name-seq.htmlに作成してください。Plan内の各タスクについて、このページには両方の要素、つまり実際の図と内容豊かな文章を含める必要があります。文章だけ、または図のように見せかけた手順リストだけのページは未完成です（100926のR7-c：ページに埋め込まれたarchify成果物のみを数え、タスクごとに1つ必要です）。
   • (A) タスクごとのシーケンス図 — エンジンで描画し、手作業では作成しないでください。 タスクごとにarchifyのsequence仕様を1つ作成します（llmwiki/html/DDMMYY-feature-name-tN.sequence.json。participants = lifelines、message variant：indigo = 既存、emerald = 追加／変更、amber = ブロック／失敗）。/diagram → archify経由でレンダリングしてください。すべてのタスクを1回のシェル呼び出しでまとめて処理し、N個の図を1回のモデルターンで作成します。for s in llmwiki/html/DDMMYY-feature-name-t*.sequence.json; do o="${s%.sequence.json}.html"; node ~/.agents/skills/archify/bin/archify.mjs deliver sequence "$s" "$o" --json && node ~/.agents/skills/archify/bin/archify.mjs visual-check "$o" --json; done。仕様修正は最大2ラウンドまでです。2回目の修正後も赤判定なら停止してユーザーに確認してください。validateを繰り返してはいけません（100926の計測では、1ページに57 validateターン、約430kのコンテキスト、約44Mのキャッシュ読み取りトークンが消費されました）。meta.visual_presetは未設定のままにしてください（インストール時のデフォルトmacosがページのシェルに一致します）。archify/examples/*.jsonからsignal-flowをコピーしてはいけません。別のプリセットを設定できるのはユーザーが希望した場合のみです。その場合はページに<meta name="overstack-preset" content="<preset>">を宣言してください（宣言がないとR20がテーマに合わない埋め込みをブロックします）。各成果物はdocs-site-macosの「§Nhúng artifact ngoài」レシピに従って埋め込んでください。<iframe class="archify-embed" src="DDMMYY-feature-name-tN.html">と、その自動高さ調整スクリプト、「Mở sơ đồ riêng ↗」リンクを含めます（固定高さのフレームでは必ず図が切れます。ビューアーの高さは905～1565pxです）。タスク名と割り当てられたエージェントを示すバッジをタイトルに付けてください。旧リストテンプレート（diagram-box + .lifelineチップ + .msg行）はシーケンス図ではなく、現在は対象として数えません。
   • (B) 詳細な説明文 — 各図に添えて、読みやすく、完全な文章で説明してください（簡潔な図ラベルではなく）。何がなぜ変わるのか、実行時のデータ／フロー、安全な分岐とブロックされる分岐、具体的なリスクを説明します。これは人が読むドキュメントです。文章ルール（CLAUDE.md 2026-06-27）に従い、ぶっきらぼうな表現や過度な圧縮は避けてください。図は骨格、文章は本体です。両方とも必要です。
   • スタイル： Skillツールで/docs-site-macosを読み込み、ページのシェル（ヘッダー、文章カード、バッジ）にそのまま従ってください。液体ガラスの見た目（明るいグラデーションの背景＋屈折レイヤー＋ガラス調の第2階層カード＋Appleカラーのバッジ）と、§Navigationサイドバー（セクション／タスクごとに1リンク、.nav-toggle／.nav-close、スクロール位置追跡、テーマ切り替え）を使用します。スキルを読み込まずに見た目だけを模倣した結果、メニューのない11セクションのページが作られました（GH#155）。現在はR20により、*/html/*.htmlのページにセクションが3つを超え、<nav>がない場合はブロックされます。暗色やフラットなテーマを独自に作らないでください（教訓250626「見た目がひどい」）。古い*-seq.htmlの図の部分を複製しないでください。あれは手順リストであり、図ではありません（教訓100926）。
   • 作成の分担 — Claudeが考え、より安価なCLIがレンダリング： .mdは内容そのもの（Claudeの担当）であり、レンダリング可能な状態にしてください。Planと説明文に加えて、タスクごとの図の順序付き手順（各手順にlegacy／add／blockのタグを付与）と完全な説明段落を記載した## Render briefセクションを含めます。その後、.htmlはこのbriefを機械的にレンダリングしたものとし、オーケストレーション実行では、より安価なCLI（OpenCode big-pickle／agy／kiro、$0）に任せてもかまいません（orca-workflowを参照）。単独の/proposeではClaudeが直接レンダリングするため、## Render briefは任意です。委任すればレンダリングは無料なので、.htmlは削ぎ落としたページではなく、docs-site-macosのFullな豊かさを優先してください。Claudeのトークンコストは内容の作成分のみで、HTMLのリッチさによって増えることはありません。
   • 双方向にリンクします：.md ↔ .html
8. 自己レビュー — 新鮮な目で見直し、その場で修正します。 草稿の## Self-reviewに結果を記録してください（3つの確認項目）。
   1. 要件の網羅性 — リクエスト内の各要件は、ちょうど1つのタスクに対応している必要があります。不足があればタスクを追加します。
   2. プレースホルダーの確認 — TBD、TODO、「適切にエラーを処理する」、「エッジケースに対応する」、「Task Nと同様」を残してはいけません。R7-gがブロックします。
   3. 名前と型の一貫性 — 同じものは草稿全体を通して同じ名前で呼ぶ必要があります。Task 3で関数がclearLayers()、Task 7でclearFullLayers()となっているのは、作成中に実際に生まれたバグです。 問題を見つけたら、その場で直接修正してください。2回目のレビューは不要です。
9. 停止します。コードは作成しません。草稿の内容とHTMLプレビューURLを提示してください。ユーザーの承認または指示を待ちます。
10. ユーザーの承認後 — /plan（Skillツール → plan）に引き継ぎ、このSPECを実行可能なDDMMYY-<tên>-PLAN.mdに拡張します。PLANができる前にタスクをdispatchしてはいけません。低コストのCLIエージェントをヘッドレスで動かしてもコンテキストは引き継がれず、質問もできません。与えられた情報だけで作業します（教訓250626：briefが薄いと納品量は約1/5）。

分岐

ID	種類	条件	動作	スキップ／失敗	再合流
B01	user_optional	ユーザーが interview を要求（/br interview）	最大5つの質問を行う（Impact × Uncertainty）。1ターンにつき1つの質問とし、推奨事項と「今はデフォルトを入力し、後で調べる」という回答を提示する	要求がなければ → (default) を自動入力	W03
B02	conditional_required	デフォルトにリスクがあり、後で確認が必要だと分かっている	(default, find-out-later → …) を記入し、unknown-ledger.py --add で U-NN を取得する	—	W03
B03	recovery	記録済みの unknown に関する実情報が得られた	SPEC/PLAN に正しい値を記入し、unknown-ledger.py --resolve … を実行する。不適切なデフォルトからコードが生成済みの場合は /orca-issue または /raise-issue を実行する	—	メインループの外
B04	capability_optional	オーケストレーションされたフローで実行	## Render brief から .html を生成する処理は、安価な CLI に委任できます（orca-workflow を参照）	スタンドアロン → Claude が直接レンダリング	W06
B05	conditional_required	brief に UI が含まれ、ユーザーがマクロ構造／テーマについて述べていない	[[design-foundation]] から補完し、マクロ構造とテーマの名前を ## Assumptions に記録する	—	W03

検証と停止

Validator R7（分岐 R7-c/f/g/h/n）、R18、R20 は記述時とコミット時に決定論的にブロックします。3つの観点によるセルフレビューはレビュー工程です。仕様図の修正ループは最大2回です。このスキルは常に W07 で停止し、コードに進む経路はありません。

例

• 成功例：「承認画面にクイック承認ボタンを追加」→ wiki を検索して関連する ADR を取得し、Assumptions にボタンの色を (default) と記録。260425-new-approval-button-fe.md と、タスクごとに archify 図を含む 260425-new-approval-button-seq.html のドラフトを作成 → セルフレビューで問題なし → STOP。ドラフトと URL を表示し、承認を待つ。
• 境界／失敗例：「顧客が支払い履歴を閲覧できるようにする」というリクエストで、誰がデータを閲覧できるのか明確でない → SPEC に [要確認：誰が他人の支払い履歴を閲覧できますか？] と記録 → ユーザーが回答するまで R7-n が承認ゲートをブロックする。

提出 — 出力レポート

メインスキルのすべてのタスクが完了したら、wiki に提案ドラフトを作成します。

手順

1. ファイル名を作成する：

• 形式：DDMMYY-<ten>.md
• DDMMYY = 今日の日付（例：2026年6月2日の場合は 020626）
• <ten> = 実施内容を要約した2～4語の kebab-case（例：landing-page-coteccons、brand-kit-fintech、ingest-auth-spec）

2. llmwiki/wiki/sources/draft/DDMMYY-<ten>.md に書き込む：

---
type: draft
title: "DDMMYY-<ten>"
status: proposed
tags: [<skill-name>, output-report]
timestamp: YYYY-MM-DD
---

# DDMMYY-<ten>
**Type:** draft
**Status:** proposed
**Tags:** <skill-name>, output-report
**Proposed:** YYYY-MM-DD

## What
<One sentence — what this skill invocation produced or decided>

## Output
<Key artefacts, files created/modified, or decisions made>

## Files
| File | Action |
|------|--------|
| `path/to/file` | created / modified |

## Notes
- Invoked via: `/<skill-name>` skill

## Origin
- **Draft:** `wiki/sources/draft/DDMMYY-<ten>.md`
- **Commit:** _(filled by verify-before-commit)_
- **Date promoted:** _(filled by verify-before-commit)_

3. wiki のインデックスとログを更新する：

• llmwiki/wiki/index.md — 次の行を1行追加する：| [DDMMYY-<ten>](sources/draft/DDMMYY-<ten>.md) | draft | YYYY-MM-DD |
• llmwiki/wiki/log.md — 次を追加する：## YYYY-MM-DD — <skill-name> — <ten>

スキルが成果物も決定事項も生成しない場合（例：/caveman-stats のような表示のみのモード）に限り、スキップします。