genesis

genesis：エージェント型プリミティブのアーキテクチャ（設計規律）

アーキテクトのペルソナ

このスキルでは、エージェント型プリミティブモジュールを設計するための規律あるプロセスを定めます。LLM を導く Markdown はコードです。設計なしに本番コードを書くことはありません。このスキルの成果物は、完成したモジュールではなく、設計成果物です。別のコーディング工程で、成果物から自然言語のモジュールを作成します。

有効にするタイミング

• 新しいスキル、ペルソナのスコープ定義ファイル、スコープに紐づくルールファイル、またはオーケストレーターワークフローを作成するとき。
• SoC、合成、またはスレッド化のルールに違反している既存のモジュールをリファクタリングするとき（例：ファンアウトが適しているのに、単一ループで順次処理している場合）。
• 複数のプリミティブモジュールにまたがる横断的な再設計を行うとき。
• 構成（ドメインの内容ではなく）が問題となるレビューを行うとき。

厳守するルール

• 自然言語のモジュール本文より先に、図を作成します。
• ペルソナの推論およびこの SKILL.md には、ハーネス固有の構文を含めません。ハーネス構文は assets/runtime-affordances/per-harness/<harness>.md にのみ記述し、手順 7 でのみ読み込みます。
• 複数のハーネスを対象とするプリミティブは、まず assets/runtime-affordances/common.md に基づいて設計する必要があります。ハーネス別アダプターを使う場合は、assets/runtime-affordances/portability-rules.md に従って、正当な理由を明示する必要があります。
• 手順 6 の引き継ぎパケットだけを次の工程に渡す成果物とします。暗黙のコンテキストは認めません。

プロセス

   1 intent + scope (+ cost stance, optional cap)
        v
   2 component diagram   <-- load assets/mermaid-conventions.md
        v                    load assets/primitives.md
        v                    load assets/design-patterns.md
        v                    load assets/architectural-patterns.md
        v                    load assets/refactor-patterns.md
   3 thread / sequence diagram
        v
 3.1 tradeoff check       <-- load assets/pattern-tradeoffs.md
        v                    (only if two patterns fit one slot)
 3.2 cost check           <-- load assets/token-economics.md
        v                    load assets/runtime-affordances/model-catalog.md
        v                    (mandatory; mirrors 3.1)
 3.5 composition decision  <-- load assets/composition-substrate.md
        v                    (per-box: inline | sibling | external module)
   4 SoC pass against existing modules
        v
   5 classic + PROSE + LLM-physics compliance check
        v
   6 handoff packet (diagrams + interface sketch + declared targets
                     + module composition table + cost projection
                     + todos)
        v             [PERSIST PACKET to plan store; truth #5]
        v                                      [DESIGN ENDS HERE]
   ----- caller / coder thread takes over -----
   7a portability check
        v                  load runtime-affordances/common.md (always)
   7b draft natural-       load runtime-affordances/per-harness/<x>.md
      language module      ONLY if step 7a flagged a per-harness need
        v                  load module-system-adapters/<tool>.md
        v                  ONLY if step 3.5 declared external modules
        v                  RELOAD plan before each module / spawn
   8 validate against diagrams + lint (PROSE 5-axis, size budget,
     ASCII, coherent unit, portability honored, declared external
     modules wired correctly, cost projection honored)

手順 1 - 意図とスコープ

ユーザー向けの機能、起動条件、境界（何をしないか）を 1 段落で記述します。単一責任の原則を適用します。段落に、異なる 2 つの機能を結ぶ「and」が含まれている場合は、2 つの設計に分割します。

また、このモジュールのフロントマター description となるディスパッチの説明も作成します。トリガーとなる名詞と動詞、境界、想定される呼び出しモード（FORCED | DISCOVERY | BOTH）を明記します。これはディスパッチャー LLM が照合する関数シグネチャです。ペルソナの「スキルのディスパッチ」セクションを参照してください。

説明は、MODULE ENTRYPOINT プリミティブに関する標準仕様の 4 つのルールに従います（assets/primitives.md を参照。agentskills.io の description 最適化ページが主要な根拠となるため、現在の URL で確認してください）。

• 命令形で表現します。エージェントへの指示として記述します。「このスキルを使うのは……のときです」のような宣言文ではなく、「……のときにこのスキルを使ってください」とします。
• 手段よりユーザーの意図を優先します。スキル内部の手順ではなく、ユーザーが達成しようとしていることを説明します。
• 間接的なトリガーを明示します。ユーザーがドメインを直接指定していなくても、スキルを適用する状況を列挙します。積極的に示してください。
• 文字数の上限は 1024 文字です（assets/primitives.md の MODULE ENTRYPOINT に定められた仕様上の厳格な上限で、これを超えると通知なしに拒否されます）。

オペレーターの COST STANCE（frugal / balanced（デフォルト）/ quality / unbounded）と、任意の COST BUDGET CAP（一般的な実行におけるドル、トークン、またはプレミアムリクエストの上限）も確認します。スタンスによって選択されるパターンが変わります。コストを理由に genesis が実行を拒否する唯一の条件は上限であり、手順 6 で適用します。指定方法については references/cost-economics-process.md を参照してください。

手順 2 - コンポーネント図（mermaid）

以下を読み込みます。

• assets/primitives.md
• assets/design-patterns.md
• assets/architectural-patterns.md
• assets/refactor-patterns.md
• assets/mermaid-conventions.md

設計で使用するすべてのプリミティブモジュールと、それらがリンクを介して依存する他のモジュールを示す flowchart を出力します。既存モジュールと新規モジュールを区別します。各モジュールには、PERSONA、SKILL、RULE、ORCHESTRATOR、ASSET のいずれかを表示します。

ステップ 3 - スレッド／シーケンス図（mermaid）

次を示す sequenceDiagram を出力します。

• どのスレッドがどのスレッドを起動するか（サブエージェントへのファンアウト）。
• 親が待機する場所（ファンイン／統合）。
• 共有シンクに対するインターロック（単一書き込みルール）。

パターンの選択は、必ず次の階層順で行います。

1. 既存のモジュールグラフ全体に対して、リファクターパターンのトリガー（assets/refactor-patterns.md）を実行します。R1 SPLIT または R3 EXTRACT が欠落すると、後続のすべてのパターン決定が歪みます。
2. assets/architectural-patterns.md から TIER 3 のアーキテクチャパターンを選びます。設計の形状が PANEL、PIPELINE、ORCHESTRATOR-SAGA、STAFFED PLAN、WAVE EXECUTION、EVENT-DRIVEN、または RECONCILIATION LOOP に合致する場合は、そのパターンを明記し、アンチパターンをそのまま継承します。非決定性の下で、各項目を終端状態に導くキューが意図に含まれる場合は RECONCILIATION LOOP が適切です（トリガーフレーズ：「項目のキュー」、「各イシュー／PR／ファイルに対して」、「終端状態に導く」、「すべて成功するまで」、「ドリフト修正」、「照合」、「バックログの一括処理」）。必要なのは、サブエージェントのディスパッチ＋永続状態＋基盤からの完了シグナルのみで、ベンダー固有の追加機能は不要です。
3. GoF の軸に沿って、TIER 2 の設計パターン（assets/design-patterns.md）に分解します。ATTENTION ANCHOR（B8）と PLAN MEMENTO（B4）は、あらゆる非自明な作業で必須です。
4. TIER 1 のイディオム（assets/runtime-affordances/per-harness/<x>.md）は、コード生成時（ステップ 7b）にのみ読み込みます。今は読み込みません。

設計に、共有状態のない独立した視点が 3 つ以上あり、図が単一スレッドのループを示している場合は、やり直します。これはファンアウトの機会です。この形状のデフォルトは、PANEL（A1）を実現する FAN-OUT + SYNTHESIZER（B1）です。

ステップ 3.1 - トレードオフの確認（代替案が競合する場合のみ）

ステップ 3 で同じスロットに適合するパターンが 2 つ以上見つかった場合は、assets/pattern-tradeoffs.md を読み込みます。選択を決定するマトリックス（幻覚への対策、ゲートの種類、グラウンディングの原則、スレッド構成、統合スタイル、ペルソナ構成、プランの永続化、リファクタートリガー）を探します。最初に適合したパターンではなく、対処しようとしている障害モードに合うセルを選びます。レビュー担当者が選択を再現できるよう、ステップ 6 の引き継ぎパケットにマトリックスと行を記載します。

ステップ 3 でパターンを一意に選べた場合は、このステップを省略します。

ステップ 3.2 - コストの確認（必須、3.1 と同様）

assets/token-economics.md と assets/runtime-affordances/model-catalog.md を読み込みます。各モジュールについて、次を選びます。ROLE CLASS（必要な能力を満たす最安のもの）、PREFIX SHAPE（キャッシュ無効化要因を監査し、B13 を適用）、OUTPUT VOLUME バンド（ファンアウトにおける L = R5 のトリガー）、TOOL SURFACE（カタログが 20 を超える場合は B15 または S7）、WORKFLOW SHAPE（異種のステージ = A12）。

ステップ 1 で読み取った方針を適用します。2 つのコストパターンが同じスロットに適合する場合は、assets/pattern-tradeoffs.md のセクション 10 にあるコスト形状マトリックスの行を記載します。手順の全文は references/cost-economics-process.md を参照してください。方針が unbounded で、かつオペレーターがコストの記録を拒否した場合に限り、ステップ 3.2 を省略します。

計画されている task() の起動ごとに、references/audience-boundary.md に従って PER-SPAWN DECLARATION TABLE（Audience/Tier/Brief mode/Receipt mode/Justification）を記入します。デフォルトの INTERNAL は、B14b/B14c に従って caveman です。

Step 3.5 - 構成の決定

assets/composition-substrate.md を読み込みます。コンポーネント図の各ボックスについて、構成モードを決定し、その根拠を記録します。

• INLINE アセット。このプリミティブ内に配置します（このモジュール固有のコンテンツの場合のデフォルト）。
• LOCAL SIBLING プリミティブ。同じソースツリー内に配置します（コンテンツがこのプロジェクト内でのみ再利用される場合のデフォルト）。配置する前に、次の点を確認します。ユーザー向けバンドルで、このコンテンツは実行時に必要ですか？ 不要な場合（評価シナリオ、コントリビューター用スクリプト、開発用フィクスチャなど）は、メンテナーの担当範囲です。ユーザー向けモジュールの配布境界の外側（コントリビューター専用ディレクトリ）に配置します。必要な場合、モジュールには BUNDLE LEAKAGE が発生します（アンチパターンについては composition-substrate.md を参照）。
• EXTERNAL MODULE。プロジェクトのモジュールシステムを介して取り込みます（次の条件のうち少なくとも1つを満たすコンテンツの場合のデフォルトです。ルール・オブ・スリー、つまり3つ以上のプロジェクトで必要とされること。独立したリリースサイクルがあること。別のチームが所有していること。利用者間でバージョンを固定するメリットがあること）。

次に、このモジュールに加えて、宣言済みの外部モジュールと、名前を挙げられる推移的依存関係のエッジを示す flowchart LR の依存関係グラフを作成します。各エッジには構成モードを記載します。

生成する各アーティファクトについて、composition-substrate §7 AUDIENCE BOUNDARY に従って対象読者を明記します。INTERNAL → caveman（B14b/B14c）、EXTERNAL → 通常の文章。シンセサイザーは境界で展開します。

外部モジュールを宣言した場合は、次の2点が必要になります。（1）引き継ぎパケットの「external modules required」にそのモジュールを記載し、コーダーステップ（7b）でモジュールシステムアダプターを読み込めるようにします。（2）そのモジュールに依存する生成モジュールは、自身の配布面で依存関係を宣言する必要があります。そうしないと、モジュールには PHANTOM DEPENDENCY が発生し、下流のローダーがアダプターを提供できません。選択した宣言メカニズムを引き継ぎパケット（ステップ6）に記録します。選択肢は次のとおりです。

• manifest 依存関係エントリー。生成モジュールが、そのようなエントリーをサポートするモジュールシステムを通じて配布される場合。
• SKILL.md / README 本文におけるコンパニオンモジュールの推奨と、使用箇所でのツール呼び出しによるプローブ。これは、このスキルがステップ7bでモジュールシステムアダプターに適用する A9 SUPERVISED EXECUTION フローに準じます。
• 両方。モジュールシステムが manifest 依存関係に対応しており、かつ生成モジュールが、そのモジュールシステムを実行しないユーザー向けにも単体で配布される場合。

Step 4 - SoC パス

コンポーネント図の各モジュール（ステップ 3.5 の構成モードを付記済み）について、次を確認します。

• 既存のモジュールがすでにこの処理を行っていますか？ そうであれば、リンク経由で依存し、重複させないでください。既存のモジュールがこのプロジェクトの外部にある場合は、EXTERNAL MODULE とマークし、ステップ 3.5 を再確認してください。
• このモジュールは、兄弟モジュールのトリガー条件と重複していますか？ そうであれば、境界を引き直してください。
• このモジュールのディスパッチの説明は、インストール済みの兄弟モジュールの説明と衝突していますか？ そうであれば、どちらかを絞り込むか、統合してください。（DISPATCH COLLISION、重大度 HIGH。）
• モジュールの本体は、R1 SPLIT のトリガー（説明の連言、断片化された呼び出し元、予算超過の本体、複数の観点を含む本体、変更頻度の相違）に該当しますか？ そうであれば、R1 に従って再設計してください。該当するものがないのに設計を分割する場合は、PREMATURE SPLIT としてフラグを立ててください。
• このモジュールの存在は、兄弟モジュールと常に一緒に読み込まれる短い本体ひとつに集約されますか？ R2 FUSE を適用してください。
• 本体に、別のペルソナ／ルール／アセットに属する内容がインライン化されていますか？ R3 EXTRACT を適用してください。
• 呼び出し元がひとつで参照先もひとつの、薄いプロキシプリミティブが存在しますか？ R4 INLINE を適用してください。
• 本体に、重大な副作用（apply、delete、post、deploy、migrate、状態の変更）または真でなければならない事実（現在の状態、バージョン、ハッシュ、ファイルの内容）が記述されているにもかかわらず、LLM が主張する文章のままになっていますか？ そうであれば、そのステップでは必ず S7 DETERMINISTIC TOOL BRIDGE を経由する必要があります。S7 の選択ルールに従って、拡張パス（プリロード済みターミナル、カスタム CLI／スクリプト／API、または MCP サーバー）を選んでください。インストール済みの CLI ですでに処理できる場合は、プリロード済みターミナルをデフォルトとして使用してください。作業が計画＋実行＋検証にまたがる場合は、A9 SUPERVISED EXECUTION でラップしてください。 トリガーの全項目については、assets/refactor-patterns.md を参照してください。

Step 5 - コンプライアンスチェック

ペルソナの従来の原則の表にある各行を適用し、違反に重大度（BLOCKER／HIGH／MEDIUM／LOW）を付けてください。次に、PROSE の制約（Progressive Disclosure、Reduced Scope、Orchestrated Composition、Safety Boundaries、Explicit Hierarchy）と、長期にわたって有効な 7 つの LLM の真実を適用してください。BLOCKER がひとつでもあれば設計を中止し、ステップ 2 に戻ってください。

また、MODULE ENTRYPOINT の標準仕様への準拠行も必ず確認してください（不適合があれば BLOCKER とし、assets/primitives.md からリンクされている最新の仕様と照合してください）。

• name フィールドは 1～64 文字で、小文字の [a-z0-9-] のみを使用し、先頭／末尾／連続するハイフンを含まず、親ディレクトリ名と一致している必要があります。一致しない場合、ハーネスはモジュールを拒否します。
• SKILL.md の本体は 500 行以下、かつ 5000 トークン以下である必要があります。超過分を本体に残してはいけません。references/<topic>.md に移動し、一般的な「references を参照してください」ではなく、明示的な読み込みトリガー条件を付けて、本体からリンクしてください（例：「API が 200 以外を返した場合は references/api-errors.md を読みます」）。

ステップ 6 - 引き継ぎパケット（これが計画です。永続化してください）

以下を含む単一の成果物を作成します。

• コンポーネント図（ステップ 2）。
• スレッド／シーケンス図（ステップ 3）。
• 依存関係グラフ図（ステップ 3.5）。
• モジュールごとの簡潔なインターフェース概要：名前、トリガーの説明、 入力、出力、依存関係（相対リンク）。
• モジュール構成表：各ボックスについて、INLINE | LOCAL SIBLING | EXTERNAL MODULE と、その根拠。
• 必要な外部モジュールの一覧（ステップ 7b でモジュールシステムアダプターを 読み込むかどうかを決定します）。外部モジュールごとに、ステップ 3.5 で選んだ DECLARATION MECHANISM も記録します（manifest dep | companion-module recommendation + tool-call probe | both）。 これは、出力されたモジュールに PHANTOM DEPENDENCY が含まれていないことを ステップ 8 で検証するために使用します。
• 宣言するターゲットセット：common-only | <list of harnesses>。
• モジュールごとの想定される呼び出しモード：FORCED | DISCOVERY | BOTH。（説明の衝突に関するレビューの厳密さを決定します。）
• 未解決のコンプライアンス上の指摘（重大度を含む）。
• TODO リスト（ドラフト作成対象のモジュールごとに 1 項目、および検証項目）と、 項目間に依存関係がある場合はその依存関係。
• references/audience-boundary.md のテンプレートに従った PER-SPAWN DECLARATION TABLE、SPAWN_BRIEFS、RECEIPT_SCHEMAS、 EXTERNAL_ARTIFACT_SPEC。
• HUMAN_RATIONALE セクション（全文で記述し、SPA WN_BRIEF には決して コピーしないことを明記）。
• EVALS PLAN（MODULE ENTRYPOINT プリミティブ evaluating-skills + optimizing-descriptions の標準仕様。assets/primitives.md を参照）。最低限、以下を 含めます。
  • CONTENT EVALS を 2～3 件：プロンプトと期待される出力。スキルを読み込んだ場合と 読み込まない場合の両方で 2 回ずつ実行し、価値の差がわかるようにします。 with_skill と without_skill の出力に違いが見られない場合、そのスキルに価値は ありません。再設計するか削除してください。
  • ディスパッチの説明に対する TRIGGER EVALS を約 20 件：トリガーされるべきクエリを 8～10 件、トリガーされるべきでない類似クエリを 8～10 件用意し、60/40 で train/val に分割します。検証用分割はリリース判定基準です。
• COST PROJECTION（unbounded とオプトアウトを選択する場合を除き必須）。 含める内容：モジュールごとの定性的な区分（役割クラス、プレフィックス／出力の 区分、ターン数／キャッシュ比率）、ワークフロー全体の定量的な範囲（入力／出力 トークン数、代表的な実行あたりのドル換算範囲。ハーネスごとのアダプターの 料金に関する脚注を出典とする）、3 つのワークロードシナリオ（S trivial／M known module／L repo-wide）、引用したコスト形状マトリクスの行、宣言した方針、 上限チェック（L シナリオが上限を超える場合は停止）。区分は契約です（ステップ 8 で検証します）。範囲は予測です（オペレーターが参照します）。 完全なテンプレートは references/cost-economics-process.md にあります。

パケットを永続化してください。真理 #5（実行前に計画する）と 基盤の概念 6（PLAN PERSISTENCE）に従い、引き継ぎパケットはステップ 7b を 開始する前に、ランタイムの計画ストアへ書き込まなければなりません。 正確な保存先はハーネスによって異なります（セクション 6 の runtime-affordances/per-harness/<x>.md を参照してください）。基盤では、 サポートされているすべてのハーネスに保存先が確保されています。不明な場合は、 セッションの作業領域に plan.md という名前の Markdown ファイルとして 書き込んでください。これは移植可能です。

設計はここで終了です。停止してください。自然言語の文章は作成しないでください。

ステップ 7a - 移植性チェック（呼び出し元側）

呼び出し元は assets/runtime-affordances/common.md を読み込みます。引き継ぎパケット内の 各モジュールについて、必要なアフォーダンスがすべて共通の基盤に含まれているか確認します。

含まれている場合 -> 宣言するターゲット = common-only。7b に進み、 common.md のみを読み込みます。

含まれていない場合 -> assets/runtime-affordances/portability-rules.md を参照します。 特定のハーネスアダプターに依存することを正当化してモジュールヘッダーに制約を 宣言するか、共通の基盤に適合するよう再設計します（ステップ 2 に戻ります）。

Step 7b - 自然言語のモジュールを作成する（呼び出し側）

読み込んだ基盤を使用し（妥当な理由がある場合はハーネスごとのアダプターも使用して）、各モジュールの本文を出力します。現在の構文に触れるのは、このステップだけです。

各モジュールの作成前、各スポーンの前、スポーンからの応答後に、必ずプランを再読み込みしてください。実行者が劣化した記憶に頼らず、都度、認識を正しい状態に戻せるよう、プランはステップ6で永続化されています（truth #1、substrate concept 6、patterns B4 PLAN MEMENTO + B8 ATTENTION ANCHOR）。 各モジュールが完了するたびに、TODO リストを更新してください。

引き継ぎパケットの「external modules required」に EXTERNAL MODULE が記載されている場合は、マニフェスト、CLI、ロックファイルの内容を出力する前に、MODULE-SYSTEM ADAPTER を読み込む必要があります。その構文を担うのはアダプターであり、アーキテクトのペルソナはそれを知らないままで構いません。現在の正規アダプターは apm-usage（microsoft/apm-guide）です。ほかのアダプターが存在する場合もあり、今後作成されることもあります。

ここでは A9 SUPERVISED EXECUTION を適用してください。アダプターにアクセスできることは、必ず真でなければならない事実です（truth #2 CONTEXT EXPLICIT + truth #6 HARNESSES BRIDGE）。プローブを省略しないでください。そうしない場合、PHANTOM DEPENDENCY が失敗モードになります。

1. ツール呼び出しで PROBE します。インストール済みスキルを一覧表示する、コンパニオンスキルのレジストリを調べる、またはプロジェクトルートに既存のマニフェストがあるか確認してください。文章だけを根拠にアダプターが読み込まれていると思い込まないでください。
2. PROBE HIT → アダプターを読み込み、マニフェスト／CLI／ロックファイルに関する用語や構文をアダプターに委ねる形で、モジュール本文を作成します。
3. PROBE MISS → モジュール本文を出力する前に、オペレーターに確認してください。次の3つの選択肢を提示します。
   • 正規アダプターをインストールする： apm install microsoft/apm/packages/apm-guide （その後、再度プローブします）。
   • raw-file フォールバック：プリミティブなフォルダーのみを出力し、マニフェストは作成しません。オペレーターが予期しない事態にならないよう、「これらをモジュールシステムに手動で組み込む必要があります」という明示的なバナーを表示します。
   • 読み込む別のアダプターハンドルを指定する。
4. LLM の記憶を頼りに apm.yml、package.json、または特定のマニフェストフィールドを決して出力しないでください。アダプターから用語や構文が提供された場合（probe hit）か、オペレーターが raw-file フォールバックを選択した場合に限ります。それ以外の場合の失敗の連鎖は、TOOLLESS ASSERTION -> HAND-ROLLED HALLUCINATION -> silent drift です。

バンドルするコンテンツには、次の正規ディレクトリ構成を使用してください（assets/primitives.md からリンクされている MODULE ENTRYPOINT 仕様が正式な情報源です。内容が移動していないか確認してください）。

• scripts/ - スキル本文から相対パスで呼び出す実行可能プログラムです。非対話型にしてください（エージェントは TTY のないシェルで実行されるため、プロンプトがあると無期限に停止します）。単発コマンドではツールのバージョンを固定してください（例：npx [email protected]）。--help で使い方を説明してください。構造化データ（JSON／CSV）は stdout に、診断情報は stderr に出力してください。エージェントが見つけられるよう、バンドルされたスクリプトを SKILL.md の本文に列挙してください。
• references/ - 必要に応じて読み込むドキュメントです。本文からのリンクにはすべて、読み込みを開始する条件を明記してください（ステップ5を参照）。
• assets/ - スキルが出力する、または組み合わせて使用するテンプレートとデータです。

規定の細かさはセクションごとに調整してください。壊れやすい操作や順序が重要な操作は具体的に指示し、判断を要する場面では柔軟性を持たせてください。本文全体を一律に細かく指示すると制約が強すぎ、一律に自由にすると十分な根拠を与えられません。特定の一例に対して何を出力するかを宣言するより、問題の種類にどう取り組むかという手順を優先してください。スキルが生成する必要のある構造化出力については、必ずテンプレートを本文中に含めてください。エージェントは、文章による説明よりも、具体的な構造をパターンとして認識しやすいためです。

ステップ 8 - 検証（呼び出し側）

• 出力された各モジュールが、引き継ぎパケット内のインターフェース概要と一致している。
• 基盤で指定されている場合、トークン数／行数の上限を守っている（SKILL.md 本文は 500 行以下かつ 5000 トークン以下。超過分は references/ に移動）。
• name フィールドが正規表現に一致し、親ディレクトリ名とも一致している。
• description が 1024 文字以下で、命令形かつ意図を先に示し、間接的なトリガーを明記している。
• ASCII のみ。
• 一貫した単位（単一の責務）。
• 宣言されたターゲットを遵守している。common-only モジュールにハーネス固有の構文が漏れていない。
• 引き継ぎパケットに記載された外部モジュールごとに、出力されたモジュールがステップ 6 で記録された仕組み（マニフェスト項目／コンパニオンモジュールの推奨と使用箇所でのツール呼び出しプローブ／両方）を通じて、配布面で依存関係を宣言している。依存関係ハンドルに言及するだけでは宣言にならない。これは PHANTOM DEPENDENCY（アーキテクトのアンチパターンを参照）。
• 同梱スクリプトは非対話型で、バージョンが固定され、--help の説明があり、stdout と stderr が分離されている。
• 評価ゲート（ステップ 6 の評価計画より）：
  • evals/evals.json（または同等のもの）が存在し、with_skill と without_skill を比較して実行されている。測定可能な差がなければ、再設計するか削除する。出荷してはならない。
  • トリガー評価の検証分割に合格している。トリガーすべきクエリでは率が 0.5 以上、トリガーすべきでないニアミスクエリでは 0.5 未満。
• コストチェックリスト（ステップ 6 より。人が適用し、リンタースクリプトではない）： 出力された各モジュールの役割クラスが投影帯に一致している。新たなキャッシュ無効化要因がない。引用されたコストパターンがすべて何らかのモジュールに具体化されている。スタンスで必須となるパターンが含まれている（frugal -> B12 / B15 / B16、quality -> planner クラスへの昇格）。上限も引き続き守られている。不合格は重大度が HIGH ですが、出荷を妨げるものではありません。運用担当者が受け入れるか再設計するか判断できるよう、問題を明らかにします。手順の全容は references/cost-economics-process.md を参照してください。
• 対象者の境界：呼び出しごとの宣言表がある。INTERNAL 行には簡潔な説明を使うか、例外の正当な理由を示す。SPAWN_BRIEF と RECEIPT_SCHEMA を対にする。EXTERNAL 仕様では通常の文章で宣言する。
• 実タスクによる改善：構造リンターを通過した後、少なくとも 1 つの実タスクでスキルを実行し、トレースを記録して、予想ではなく実際に起きたことに基づいて改訂する。実行に一度も使われていない一度きりのドラフトは完成ではない。

デフォルトのパターン選択

迷ったときは、1 つのスレッド内でコンテキストの劣化を最小限に抑えるパターンを選びます。

• 1 つのレンズ、1 つの手順 -> 単一ループの逐次処理。
• 3 つ以上の独立したレンズ、共有状態なし -> ファンアウト + 統合。
• 逐次的な依存関係を持つ 2 つのレンズ -> その間に検証ゲートを挟んだ単一ループの逐次処理。
• 複数セッションにまたがる長期的な作業 -> フェーズ間で永続化されたアーティファクトを使うオーケストレーター。

設計パターンのカタログ（GoF の軸）は assets/design-patterns.md を、アーキテクチャパターン（システムトポロジーの形状）は assets/architectural-patterns.md を参照してください。

設計に 1 つ以上の task() スポーンが含まれる場合、引き継ぎパケットのステップ 6 をドラフトする前に references/audience-boundary.md を読み込んでください。

作業例

作業例は assets/ ではなく、この SKILL.md ファイルと同じ階層の examples/ に格納されています。これらは必要なときにのみ読み込むものであり、オペレーターが明示的に例を求めた場合、または設計工程で参考となる形が必要な場合に限って読み込んでください。アセットに関する段階的開示のルールは例には適用されません。事前に読み込まないでください。

• examples/01-readme-iteration.md -- コールドトラフィックのコンバージョンが重要で、目標の逸脱が現実的なリスクとなる、クリエイティブな複数ラウンドの成果物（README、ランディングページ、PR の説明、告知投稿）における標準的な構成です。A8 ALIGNMENT LOOP ＋ A1 PANEL ＋ A7 ADVERSARIAL REVIEW ＋ COLD READER SIMULATION ＋ B9 GOAL STEWARD ＋ B10 HUMAN CHECKPOINT を組み合わせます。
• examples/02-review-panel-architecture.md -- 複数の視点を持つモジュール（パネル、監査、多角的な批評）の再設計に関する標準的な手引きです。実際のパネルを題材に、単一ループのアンチパターンからファンアウト＋親シンセサイザーへの移行を順に説明します。
• examples/03-release-notes-single-skill.md -- 最小限の出力の参考例です。A1 PANEL が不要な場合（視点数のゲートが作動しなかった場合）を示します。A9 SUPERVISED EXECUTION ＋ S7 ＋ S4 を単一スレッドで使用します。
• examples/04-pr-review-advisory.md -- 複数プリミティブを使ったパネルの参考例です。A6 EVENT ＋ A1 PANEL ＋ DISSENT-WEIGHTED arbiter を使用し、コメントの投稿以外は記録システムに副作用を及ぼしません。
• examples/05-pr-review-verdict.md -- 重大な書き込みの参考例です。04 と同じパネルに判定の出力を追加しています。S7 ＋ S4 ＋ A9 による検証の強化を示し、WHEN 節に基づいて A8 ／ B5 ／ R1 を明示的に却下します。利害の大きさを理由に新たなオーケストレーション層を追加したくなった場合に読んでください。
• examples/06-cost-aware-panel.md -- コスト構成の参考例です。example 02 のパネルに A12 GRADIENT WORKFLOW ＋ B12 MODEL ROUTER ＋ B13 CACHE-AWARE PREFIX ＋ R5 COST PRUNE パスを加えています。スタンスが frugal の場合、またはファンアウトの幅が 4 以上で日次の頻度で実行する場合に読んでください。

出力

設計セッションでは、次の成果物が作成されます。

• 引き継ぎパケット（「Step 6」セクション）。設計対象のモジュールと一緒にコミットするか、それらを導入する PR にコメントとして投稿します。
• 自然言語で記述したモジュール本文（ステップ 7b で起草）。

引き継ぎパケットは、今後のリファクタリングにおける信頼できる唯一の情報源です。このスキルを再実行する場合は、出力された自然言語ではなく、引き継ぎパケットを起点とします。