A-ISL Compile（エージェント内コンパイラ）
ISL から bin-<stackId>/ を出力します（デフォルトのスタック react-js → bin-react-js）。Builder / queue / packet / lock / preflight CLI は使用可能です。有料の isl-generator / Gemini / OpenAI は 禁止 です。
このスキルを読み込んだ任意のコーディングエージェント（Cursor, Claude Code, GitHub Copilot, …）で動作します。リポジトリルート の同じ npm ランタイムを使用します。
ユーザー要求ゲート（譲歩不可）
bin への変更はコンパイル経由でのみ行われ、当然ユーザーの要求があった場合にのみ行われます。
- 人間が明示的にコンパイルを要求した場合のみ（例：
compila,/a-isl-compile, "build bin", "regenerate implementation", "run compile for …"）、このスキルに入り /bin-*以下に書き込みます。 - スペックのみのメッセージ、自然言語の機能アイデア、またはUXの調整で、明示的なコンパイル要求がない 場合は、実装への書き込みをトリガーしてはならず、a-isl-spec-author（またはSpecフェーズ）に送信して停止します。
- "デモが壊れるから" や "ループを完了させるため" といった理由で、Spec編集後に自動コンパイルしては いけません。
- 実装フォルダは、このCompileワークフロー（パケット → 書き込み → ロック）を のみ 通して更新されます。人間が明示的に一回限りの例外を要求しない限り、
bin-*下へのアドホックなパッチをA-ISLのパスとして扱ってはいけません。 - 人間がコンパイルを要求していない場合：
bin-*の編集を拒否し、明示的なコンパイル要求が必要であることを伝えます。
使用タイミング
- 人間がSpecフェーズを完了し、ビルド/コンパイル/再生成を 要求した 場合
- 人間がCompileを要求したため、プロジェクトの
bin-<stack>/を更新された*.isl.mdに 合わせる 場合
厳格な制約
- 有料のジェネレーターやAPIコード生成クライアントを 実行しないでください。
- あなた自身 がパケットの
targetPathからスタックのバイナリディレクトリの下に各実装ファイルを書きます（完全なコード、TODOスタブなし）。 gen-lock.jsonだけを更新してもコンパイルには なりません —bin-<stack>/下への実際の書き込みを行った後にのみロックします。- ISLがあいまいまたは矛盾している場合：停止 して、ユーザーに a-isl-spec-author に戻るよう伝えます。要件をでっち上げないでください。
- Compile中は
vendor/isl-spec/を開かないでください（Spec Agentのみ）。ユーザーが明示的に要求した場合を除きます。 queue --next+ 軽量パケット を使用して、一度に1ユニットずつ 処理することを推奨します。デフォルトでキュー全体のJSONや.build.md全体を読み込まないでください。
出力ディレクトリ
デフォルト: スペックの隣にある bin-<stackId>（例：--stack react-js → bin-react-js）。必要に応じて --bin でオーバーライドします。同じワークスペースに bin-react-js と bin-csharp を共存させることができます。
低トークンワークフロー（デフォルト）
preflight → builder (1回) → ループ: queue --next → packet → [テスト後] impl書き込み → (バッチ) lock
→ (オプション) npm run verify
0. Preflight（1回）
npm run preflight -- --root examples/connect-four-workspace
構造/グラフ/リントゲートのみ — 実装の正確性は 証明しません。失敗した場合は、コンパイル前にSpec/リントを修正します。
1. Builder（バッチごとに1回）
npm run builder -- examples/connect-four-workspace
トポロジカルオーダーは build/build-manifest.json（スクリプト管理）にあります。コンパイル順序を考案してはいけません。
2. 次のユニットのみ
npm run queue -- --root examples/connect-four-workspace --next
ループ内のすべてのqueue/packet呼び出しで --stack <id> を渡します（デフォルト react-js → bin-react-js/）:
npm run queue -- --root <project> --next --stack blazor
npm run packet -- --root <project> --next --stack blazor
ID: react-js, blazor, winforms, csharp（ライブラリのみ）, python, python-fastapi。オプションの --bin <path> で出力フォルダを上書きします。
ターゲット再コンパイル — 人間が1つまたは少数のユニットを再生成するよう要求した場合（ロックはそれらをスキップするはずです）:
npm run queue -- --root <project> --next --only dungeon --stack react-js
npm run packet -- --root <project> --next --only dungeon --stack react-js
# または名前でパケット:
npm run packet -- --root <project> --only dungeon --stack react-js
--only は繰り返し使用できます。トークン: ユニットのbasename（dungeon）, dungeon.isl.md, または ./dungeon。キューJSON内の理由: force-only。サブセットのみが要求された場合にワークスペース全体の --force を使用しては いけません。
next.buildFile / next.targetPath を使用します。next が null の場合は停止します（キューが空）。
フルの --json キューは、人間が概要を求めた場合にのみ使用します。
3. 軽量パケット（デフォルトコンテキスト）
npm run packet -- --root examples/connect-four-workspace --build-file "<abs.build.md>"
# または
npm run packet -- --root examples/connect-four-workspace --next
パケットに含まれるもの: このユニットの SOURCE マークダウン、ターゲットパス、スタック制約サブセット、同じ bin-<stack>/ 内の依存ファイルへの パス。
インライン化された .ref.md ブロブは 含まれません。
パケットからファイルを書き込みます（以下の EXT-001 順序を参照）。リストされたパスから実際の依存モジュールをインポートします。
3a. 依存宣言検索（EXT-002）
このユニットを書き込む前に、依存シンボル（メソッド/関数/型）の 正確な宣言 が必要な場合:
npm run lookup-decl -- --stack <id> --name <SpecOrCallName> --file <abs-or-rel-bin-path> [--workspace <project>]
# または bin フォルダをスキャン（生成された *.test.* / *.Tests.cs は --include-tests の場合を除きスキップ）:
npm run lookup-decl -- --stack <id> --name <Name> --dir <bin-<stack>> --workspace <project>
- 終了コード 0 = ヒット, 2 =
no_match, 3 = 使用法/パス/スタックエラー。 - stdout JSONを読み取ります:
candidates[selected]（signatureText,leadingContext,enclosingType, 候補ごとのkind）を使用します。正規表現を考案したり、依存ファイル全体を開いてシグネチャを探したりしてはいけません。 - パターンと
callSymbolはスタック設定（declaration-patterns.ts/stacks.config.ts）にあります — スキルは このCLIのみを呼び出す 必要があります。 - パスは
--workspaceとbin-*セグメントの下で解決される必要があります（シンボリックリンクエスケープ → exit 3）。
3b. EXT-001 生成テスト（Specがオプトインした場合）
検証可能なシナリオ = `id: …` と - Call: … の両方を持つテストシナリオ（docs/isl-agent-profile.md を参照）。Spec Authorが決定します。どのロールでもオプトイン可能です。
ユニットごとに、同じターンで:
- SOURCEに1つ以上の該当シナリオがある場合: 最初に 生成テストファイルを 上書き します（パス = impl basename +
stack.verify.testSuffix、同じbin-<stack>/下、例:domain-sheet.test.js/domain-sheet.Tests.cs）。Specシナリオ + シグネチャからのみアサートします。Callをstack.verify.callSymbol（stacks.config.ts内のas-is|pascal-case|snake-case）を介してシンボルにマッピングします。react-js Domain/Logic: 各Callは 名前付き エクスポートである必要があります。テストはimport { <Call> } from "./<file>"としなければなりません — 決してimport Unit from …; Unit().<Call>()としてはいけません。ワークスペースにbench/call-map.jsonがある場合、"<unit>.<Call>"からexportを解決し、その名前をインポートします（凍結スコアと同じ契約）。散文のみのシナリオのためにケースをでっち上げてはいけません。テストファイルが書き込まれる前に impl ファイルを開いたり編集したりしてはいけません。 - 次に、それらのテストと契約を満たすように、
targetPathに impl を書き込みます。react-js Domain/Logic: すべてのCapabilityに対してexport function <Call>/export const <Call>を使用します。Capabilityをラップする default-export ファクトリは禁止です。 - 該当シナリオが0の場合: implのみ書き込みます。そのユニットの以前に生成されたテストファイルがまだ存在する場合は 削除 します。それでもDomain/Logicには名前付きCapabilityエクスポートを使用します。
- verify 失敗 時:
--onlyで implのみ を再コンパイルしても構いません（テストファイルは保持）。テストをパスさせるためにテストを書き換えては なりません（名前付きインポートをデフォルトファクトリに変更することを含む）。シナリオ/Call/期待値が間違っているように見える場合 → STOP して、人間を a-isl-spec-author に送ります。 - Domain/Logic（または他の該当）バッチの後、
npm run verify -- --root <project> --stack <id>を提案しても 構いません。グリーンをロックの必要条件にしては いけません。ロックはビルドハッシュキャッシュのままです。
Spec変更後のフルユニット再コンパイル: 現在のSpecからテストファイル 全体 を再生成し、次にimpl（古いテストとのマージではありません）。
4. ロック（可能な場合はバッチ）
1～5の正常な書き込み後:
npm run lock -- --root examples/connect-four-workspace --build-file "<abs1>" --build-file "<abs2>"
5. 複雑性によるエージェントバッチ処理（コンテキスト衛生）
多くのユニットをコンパイルする1つの長いエージェントセッションは、後のユニットや大きなパケットを 過小実装 する傾向があります（コンテキストが以前のbinで満たされる）。以下を推奨します:
| ユニットの種類 | コンパイル方法 |
|---|---|
| リーフ / 小規模 | 同じエージェントで、複数の queue --next → write → lock を バッチ 処理 |
| ヘビー / ハブ | 新しいエージェント / 新しいチャット: --only <unit> → packet → SOURCEの すべての 機能を実装 → lock |
| レビュー/プレイテスト後の 修復 | 新しいエージェント + 失敗したユニットのみに対して --only |
以下のいずれかに該当する場合、ユニットを ヘビー として扱います（スタック非依存）:
- 長いSOURCE / 1つの
.isl.mdに多数の####機能がある - 高いファンイン: 多くの他のユニットがそれを参照している、またはそれが多くの依存関係を参照している
- グラフの大部分を オーケストレーション するプレゼンテーションまたはロジック（シェル/ファサード/セッション境界）
- そのユニットのパケットまたは以前のコンパイルに、省略されたFlowの履歴がある
デフォルトでリーフごとに1つのエージェントを生成しては いけません（コスト）。ハブでリフレッシュせずに、1つのエージェントで大きなワークスペース全体を実行しては いけません。
ヘビーユニットのプロンプト: リポジトリルート、--stack、--only <unit>、「SOURCEのすべての機能を実装し、Flowを省略しないこと。」agent-skills/a-isl-compile/SKILL.md（または .cursor/skills、.claude/skills、.github/skills 下のホストコピー）に従います。
エスカレーションテーブル（軽量アクセスで不十分な場合）
| 状況 | アクション |
|---|---|
| パケットOK、依存binが存在、ISL明確 | 軽量のみ → ファイル書き込み |
パケット終了 / missingDependencyBins | STOP — キュー/順序を修正。APIをでっち上げない |
| 依存の正確な宣言/シグネチャが必要 | npm run lookup-decl（EXT-002）; JSON selected を使用 — APIをでっち上げない |
lookup-decl exit 2（no_match） | Spec Call/名前 + 依存パスを再確認。シグネチャをでっち上げない |
| パケット不完全 / SOURCEマーカーなし | このユニットの fullBuildFile を1回読む |
| あいまい/矛盾したISL | STOP → Spec Agent。vendorへのダイブ禁止 |
| 人間が完全な再監査を要求 | --force / フルキュー --json 許可 |
ユニットごとの書き込みルール
すべての生成ファイルのヘッダー:
/**
* このファイルを直接編集しないでください
* ----------------------------------
* このファイルはISLコンパイラによって生成されました。
* ソース: <basename-of-.isl.md>
* 代わりにISLファイルを編集してください。
*/
スタックルール（デフォルト react-js）に従います。完全な実装 — TODOスタブはありません。
パス
| ツール | エントリ |
|---|---|
| Preflight | npm run preflight -- --root <project> |
| Builder | npm run builder -- <project> |
| Queue next | npm run queue -- --root <project> --next |
| Packet | npm run packet -- --root <project> --next |
| Lock | npm run lock -- --root <project> --build-file <abs>… |
| Verify | npm run verify -- --root <project> [--stack <id>] [--only <unit>] |
| Lookup decl | `npm run lookup-decl -- --stack --name --file |
| Lint | npm run lint -- <file.isl.md> |