デザインセッション
何も記録される前に、オーナーと一緒に設計を練り上げます。オーナーが主導し、エージェントは選択肢を広げ、それぞれの意味を示し、会話を正直に保ちます。最後のプロモートステップでオーナーが何を組み込むかを選択するまで、何もシステム設計に到達しません。
システム設計が存在する前、マイルストーン計画中、またはマイルストーンの途中など、いつでも使用できます。用語（システム設計、追加チェック、レビュー対象表面、settled/working、owner/proposed、マイルストーン、スパイク、暫定コード、オーナー設定、2回上書きルール）は、system-designスキルの terms.md で定義されています。そこで定義されている通りに使用してください。
ファイル
<DocDir>/SystemDesign/
Overview.md システム設計 (system-design); プロモートステップでのみ変更されます
Sessions/<date>-<Short_Topic>.md このスキルのスクラッチノート。プロモートステップ後に削除されます
<date> は YYYY-MM-DD 形式です。Short_Topic は 2～3 単語のスネークケース（例: 2026-11-01-Review_Import.md）です。ノートは自由形式です。ID、ステータス、合意マーク、質問上限はありません。オーナーのスケッチ、検討された形状とその図、追跡された結果、発見された矛盾とその解決方法、スパイク結果、オーナーの意向が含まれます。会話が進むたびに更新し、途中でセッションが中断してもファイルから再開できるようにします。
ワークフロー
1. 読み取り、そしてオーナーに主導させる
システム設計とトピックが触れるサブシステムドキュメント、ロードマップの現在のマイルストーン、<DocDir>/Taxonomy.md、プロジェクトルールファイル（CLAUDE.md または同等のもの）、およびオーナー設定ファイル ${DANNY_SKILLS_STATE_DIR:-$HOME/.local/state/danny-agent-skills}/owner-preferences.md（存在する場合）を読み取ります。このトピックのノートファイルが Sessions/ に存在する場合は、そこから続行します。それ以外の場合はノートファイルを作成し、そのパスを宣言します。
オーナーが何を考えているかを尋ね、そのスケッチを数行で、そして2つ以上の部分がある場合は図で反映します。形状を変更する可能性がある質問のみをし、デフォルトとして述べられることは決して質問しません。
2. 代替形状を提案する
2～3 の形状（オーナー自身のスケッチを1つとして数える）を提案します。それぞれについて: plan-milestone スキルの diagrams.md に従った Mermaid 図（ノードラベルはシステム設計のコンポーネント名を正確に、新しい部分は sketched、形状が変更するものは touched とマーク）、プロジェクトのケースでの動作の平易な例、および1行の賛成・反対。その後、1つを推奨するか、「推奨なし」とその理由を述べます。新しいものには、その機能に基づいて名前を付けます（terms.md, 「名前とラベル」）。diagrams.md の指示に従って各図のレンダリングチェックを行います。
3. 結果を追跡する
オーナーが傾いている形状について、何が変更されるかを述べます: サブシステム、シーム、データモデル、レビュー対象表面（フィールドごとにのみ）、名前、脅威とプライバシーセクション。後続の各マイルストーンの行に対して追加チェックを実行します。後続のマイルストーンを再構築せずに追加できない場合は、どのシームを今決定する必要があるかを述べます。システム設計がない場合、または後続のマイルストーン行がない場合は、マイルストーンが存在するまで追加チェックをスキップします。チェック対象のマイルストーンを発明してはいけません。形状が変更する settled アイテムをすべて名前を挙げます。settled アイテムを変更することは再計画のトリガーです。シーム内部の内部実装は未決定のままにし、細部は「実行後に決定」リストに回します。
4. 矛盾を指摘する
オーナーの発言が、このセッションでの以前の発言、settled アイテム、オーナー設定、プロジェクトルール、または Taxonomy.md の名前と矛盾する場合は、はっきりと述べます。両方の側面を引用し、どちらが有効かを尋ねます。回答をノートに記録します。
5. 使い捨てスパイクを提案する
何かを実行することだけが疑問を解決する場合（十分に速いか、API がこれを返すか、プラットフォームがそれを実行できるかなど）、それを解決する最小の実行を提案します: 何をするか、どの結果がどちらの方向を示すか、およその所要時間。オーナーが承諾した場合のみ、製品コード外（スクラッチディレクトリまたは使い捨てブランチ）でそれを構築し、実行し、結果をノートに記録します。コードは破棄されます。オーナーが保持したい場合は、ステップ6で暫定コードとしてプロモートされます。
6. プロモート
オーナーが完了したと言った場合、または会話が収束した場合、システム設計に入力できるノート内のすべてのアイテムを、presenting-for-review.md の形式でリストし、それぞれに推奨される結果を付けます:
settledとしてプロモート またはworkingとしてプロモート（再訪ノート「次の場合は再訪: …」付き）。- 後続のマイルストーンに Park（マイルストーン名を明記）。
- Drop.
同じメッセージ内で、2回上書きルールに従ってオーナー設定行を提案します: このセッションでオーナーが同じ種類の形状を2回上書きした場合、または好みを直接述べた場合のみ。1行ずつ（設定、1つの例、日付）、それがクロスプロジェクトオーナー設定ファイルとプロジェクトルールファイルのどちらに属するかを示します。単一の判断は決定であり、設定ではありません。このスキルの動作に関するフィードバックはレトロスペクティブに行き、ここではありません。オーナーの言葉（名前、結果テキスト、シーム）の各項目について、同じメッセージで system-design スキルのステップ4の明確化オファーを1回行います: 各あいまいさをリストし、元のバージョンの隣に明確化されたバージョンを示します。オーナーはそれを受け入れるか、編集するか、そのまま保持します。最後に1つの質問で終わります。
オーナーの決定をシステム設計 (overview-template.md) に通常の編集として適用します:
| プロモートされたアイテム | 配置場所 |
|---|---|
| コンポーネント | Components 行（sketched、Build target、Agreement）と、その深さクラスのみを持つ図ノード（決して touched ではない） |
| シーム | Seams and interfaces 行とその Agreement |
| テーブル、API、または公開シンボル | レビュー対象表面、フィールドごと、そのマーク付き |
| エンティティまたはリレーションシップ | データモデル |
| 名前 | Names、次に <DocDir>/Taxonomy.md、残りとセットでレビュー |
| 形状間の選択 | Decisions 行: 次に空いている D ID、Kind choice、Agreement settled または working (revisit if …)、Why に拒否された形状を指定 |
| セッションで見つかった未知 | Risks 行とその最も安価な実験 |
| 後のマイルストーンへの変更 | その Scope and milestones 行と Additive check セル |
| オーナーが保持するスパイクコード | Provisional code 行、およびコード内の PROVISIONAL マーカー |
| 一時停止された構造的アイテム | Open questions 行に、それが待機するマイルストーンを指定（例: 「Q4 (M3まで一時停止、変更を記録): …」） |
| 一時停止された細部 | それを解決するマイルストーンの下の「実行後に決定」リスト |
合意マークはテンプレートに従います: オーナーが記述または編集したアイテムは owner と読みます（例: settled · owner）。オーナーが変更せずに受け入れたアイテムには proposed マークは付きません。新しい ID はドキュメントのシーケンスを継続し、決して再利用されません。合意済みアイテムへの変更は、決定ログを通じて行われ、無言の編集は行われません。プロモートされたアイテムが settled アイテム（シームなど）を変更する場合、またはオーナーリクエストが現在のマイルストーンに構造を追加する場合、再計画が必要であることを明確に述べ、以下のコミット後にハンドオフノートを書き、/rung が後続のセッションで再計画をルーティングできるようにします: <DocDir>/Handoff/replan-<date>.md に Route: replan、Model: opus、Waiting on: re-plan after the design session on <topic>、Date:、および変更されたアイテムとコミットを記載した本文 (handoff.md)。ドロップされたアイテムは記録されません。git 履歴内のノートファイルがそれらを保持します。受け入れられた設定行は、オーナーが選択したファイルに書き込みます。
システム設計がまだ存在しない場合は、プロモートされたアイテムを、テンプレートのヘッダー (Status: draft) と、それらが埋めるセクションのみを持つ新しい Overview.md に書き込みます。system-design はそこから続行します。
コミットします。明示的なパスでステージングし、システム設計、Taxonomy.md、変更されたプロジェクトルールファイル、およびノートファイルを、Design session: <topic> としてコミットし、履歴がノートを保持するようにします。次に git rm でノートファイルを削除し、Remove design session notes: <topic> としてコミットします。skill design-session 1.0.1 および kind design-session で step イベントをログに記録します（他のフィールドは tasklist-run のメトリクスログに従う）。(他のフィールドは tasklist-run のメトリクスログに従う)。さらに、プロモーションのために提案したアイテムの数を記録します: proposed、accepted（変更なし）、edited、rejected。
何が変更され、次のステップは何かを平易な文で終了し、次に Next: /rung を追加し、そのステップに Opus が必要な場合（合意すべきシステム設計、マイルストーン計画、またはステップ6で必要とされた再計画）は (Opus: /model opus) を追加します。
オーナーがプロモート前に停止した場合は、ノートファイルをコミットせずにそのままにし、そのパスを伝えます。トピックに関する次のデザインセッションはそこから続行します。
リンクされたファイルまたはスキルがない場合
リンクされたファイルがない場合でも停止しないでください。ここで最小限のものを使い、何が欠けているか、それをインストールする方法を1行か2行で一度だけ伝えます（claude plugin install project-planning@danny-sung-agent-skills、または npx skills add dannys42/agent-skills --skill <skill-name> を同じスキルディレクトリに実行して相対リンクが解決されるようにします）。
terms.mdがない場合:settledは保持されることが期待されます。workingは開始するのに十分であり、何が再訪を引き起こすかを示します。ownerアイテムはオーナーの言葉、proposedはエージェントの言葉です。追加チェックは、後続の各マイルストーンを再構築せずに追加できるかどうかを尋ねます。diagrams.mdがない場合: Mermaidflowchart、すべてのラベルを引用、ラベルはコンポーネント名、深さごとに1つのクラス（sketched破線、designed細線、built太線）。presenting-for-review.mdがない場合: 重要なアイテムを最初に（最大5つ、元に戻すのが難しいか影響範囲が広い）、それぞれにオプション、平易な例、賛成と反対、推奨事項を付けます。最後に1つの質問で終わります。overview-template.mdがない場合: システム設計の既存のセクションにプロモートし、そのテーブルとマークに合わせます。
判断
- オーナーが主導します。 形状と結果を提供します。尋問したり、自分の好きな方向に誘導したりしないでください。形状を変更しない質問は尋ねる価値がありません。
- 自由に探索し、狭くプロモートします。 セッションでは何でも議論できますが、構造のみがシステム設計に入ります: サブシステム、シーム、データモデル、レビュー対象表面、名前、決定、リスク。内部実装は除外します。
- スパイクは議論に勝ります。 オーナーとエージェントが、短い実行で解決できる事実について意見が異なる場合は、議論する代わりに実行を提案します。