qfai 1.6.1 → 1.6.3

package/assets/init/.github/instructions/code-review.instructions.md

@@ -0,0 +1,63 @@
+---
+applyTo: "**/*"
+excludeAgent: "coding-agent"
+---
+
+# Copilot Code Review Instructions (Repository)
+
+Goal:
+
+- Provide high-quality, line-level PR review comments that improve code health.
+- Base the review on the PR description and the diff against the merge target.
+
+Language:
+
+- Default: Japanese.
+- If the PR description includes `Review Language:` (e.g., `ja`, `en`, `ja+en`), follow it.
+- For multi-language requests, write each comment in all requested languages, Japanese first.
+
+Process:
+
+1. Read the PR description (use the PR template sections) and extract:
+   - Why/background
+   - Business/process position
+   - Intended behavior change
+   - Design decisions and alternatives
+   - Risks and tests
+2. Compare the description with the diff. If missing or inconsistent, leave a single top-level review comment requesting clarification.
+3. Review every changed line and surrounding context. Prefer inline comments for concrete issues.
+
+Comment format:
+
+- Prefix severity: [BLOCKER], [MAJOR], [MINOR], [NIT], or [FYI] (if other labels are used, map critical -> [BLOCKER], moderate -> [MAJOR], nit -> [NIT]).
+- Include: Issue -> Why (impact/risk) -> Suggestion (concrete fix or test).
+- Use respectful, code-focused language and explain reasoning.
+- Provide positive feedback when something is notably well done.
+
+Review checklist (from code review best practices):
+
+- Design: fits existing architecture/patterns; avoid over-engineering.
+- Correctness: edge cases, error handling, input validation, concurrency safety.
+- Security/Privacy: secrets, authZ/authN, data exposure, logging.
+- Performance: N+1, unnecessary full scans, expensive operations, caching.
+- Maintainability: duplication, naming clarity, modularity, responsibility boundaries.
+- Tests: appropriate unit/integration/e2e coverage; tests fail when code is wrong.
+- Docs/UX: README/RELEASE/usage steps are consistent and copy-pasteable; UI changes make sense.
+- Consistency/style: follow existing conventions; style-only nits should be labeled [NIT].
+
+Specific checks:
+
+- If the PR claims "no behavior change," verify the diff matches; otherwise raise [MAJOR].
+- For documentation-only PRs, validate that steps are self-consistent and have no contradicting prerequisites.
+
+Library/CLI compatibility checks:
+
+- If a public function signature, exported type, or CLI flag changes, confirm the PR documents the breaking change.
+- Removing or renaming an export requires a CHANGELOG entry and a major version bump justification.
+
+Constraints:
+
+- Copilot reviews are comments only and do not block merging; be explicit about severity.
+- If a change affects user-facing behavior, call out expected impact and any missing tests or docs.
+
+<!-- qfai:language-rules -->

package/assets/init/.github/instructions/principles.instructions.md

@@ -0,0 +1,110 @@
+---
+applyTo: "**/*"
+excludeAgent: "coding-agent"
+---
+
+# Software Engineering Principles Review
+
+ソフトウェア開発・設計の原則やセオリーに照らして、変更が適切かを検証する。
+原則違反を見つけた場合は、どの原則に違反しているかを明示し、改善案を提示すること。
+
+## 設計の基本原則
+
+### SOLID
+
+- **SRP（単一責任）**: 1つのクラス・関数・モジュールが複数の理由で変更される設計になっていないか。名前から責務が一意に読み取れるか。
+- **OCP（開放閉鎖）**: 既存コードを書き換えずに拡張できる設計か。設定値・依存注入・ストラテジーパターン等で切り替え可能か。
+- **LSP（リスコフの置換）**: 派生型やサブタイプが親の契約を破っていないか。事前条件を厳しくしたり事後条件を弱めたりしていないか。
+- **ISP（インターフェース分離）**: クライアントが使わないメソッドへの依存を強要していないか。インターフェースは小さく役割別に分割されているか。
+- **DIP（依存性逆転）**: 高水準モジュールが低水準の具象に直接依存していないか。モジュール境界では抽象（インターフェース）に依存しているか。
+
+### KISS（Keep It Simple）
+
+- 不必要に複雑な実装になっていないか。標準ライブラリや既存ユーティリティで代替可能な自前実装がないか。
+- 認知負荷を下げる書き方か（深いネスト、過度な抽象化、暗黙の挙動を避ける）。
+
+### YAGNI（You Aren't Gonna Need It）
+
+- 現時点で不要な機能・設定・拡張ポイントを先回りして実装していないか。
+- 「将来必要になるかも」で追加されたコードがないか。
+
+### DRY（Don't Repeat Yourself）
+
+- 同一または類似のロジックが複数箇所に重複していないか。共通化・ユーティリティ化の余地がないか。
+- ただし過度な共通化（shotgun surgery を招く）は避け、Rule of Three を意識する。
+
+## モジュール間関係の原則
+
+### Separation of Concerns（関心の分離）
+
+- ビジネスロジック・UI・データアクセス・インフラなど、異なる関心が1つのモジュールに混在していないか。
+
+### Law of Demeter（最小知識の原則）
+
+- `a.getB().getC().doSomething()` のようなメソッドチェーンで遠いオブジェクトに依存していないか。
+- オブジェクトは直接の協力者のみとやり取りしているか。
+
+### Minimise Coupling / Maximise Cohesion
+
+- モジュール間の結合度が不必要に高くないか。変更が他モジュールに波及しにくい設計か。
+- 1つのモジュール内の要素は同じ責務に向かってまとまっているか（高凝集）。
+
+### Composition over Inheritance（継承より合成）
+
+- 「is-a」関係でないのに継承を使っていないか。振る舞いの組み合わせは合成（委譲・ミックスイン）で実現すべきか。
+
+## 堅牢性・安全性の原則
+
+### Fail Fast（早期失敗）
+
+- 不正な入力や前提条件の違反を関数の冒頭で検出し、即座にエラーを返しているか。
+- 無効な状態が伝播して後続処理で不可解な障害を起こす設計になっていないか。
+
+### Defensive Programming（防御的プログラミング）
+
+- 外部入力・API応答・ユーザー入力に対して適切なバリデーションがあるか。
+- null/undefined の安全な処理、リソース解放（finally/using）が適切か。
+
+### Principle of Least Privilege（最小権限）
+
+- 必要最小限のアクセス権限・スコープで動作しているか。過剰な権限を要求していないか。
+
+### Design by Contract（契約による設計）
+
+- 関数の事前条件（引数の制約）・事後条件（戻り値の保証）・不変条件が明確か。
+
+## 可読性・保守性の原則
+
+### Principle of Least Astonishment（驚き最小の原則）
+
+- API・関数の命名と実際の振る舞いが一致しているか。副作用が名前から予測できるか。
+- 言語やフレームワークのイディオムに従っているか。
+
+### Boy Scout Rule（来た時よりきれいに）
+
+- 変更箇所の周辺に明らかな改善余地（命名・型安全・不要コード）があれば併せて改善しているか。
+
+### Avoid Premature Optimization（早すぎる最適化の回避）
+
+- 計測なしに最適化していないか。可読性を犠牲にした最適化がボトルネック以外に適用されていないか。
+
+## 振る舞い・インターフェースの原則
+
+### Tell, Don't Ask（聞くな、命じよ）
+
+- オブジェクトの内部状態を外部で問い合わせて判断するのではなく、オブジェクトに振る舞いを委ねているか。
+
+### Command Query Separation（CQS）
+
+- 状態を変更するメソッド（コマンド）と値を返すメソッド（クエリ）が混在していないか。
+
+### Encapsulation（カプセル化）
+
+- 内部実装の詳細が不必要に外部に露出していないか。公開APIは必要最小限か。
+
+## 適用上の注意
+
+- 原則同士はトレードオフになることがある（DRY vs YAGNI、KISS vs OCP など）。文脈に応じたバランスを評価すること。
+- 原則違反の指摘には [MAJOR] or [MINOR] の重要度を付け、なぜその原則が重要かを簡潔に説明すること。
+
+<!-- qfai:language-rules -->

package/assets/init/.qfai/assistant/instructions/workflow.md

@@ -69,6 +69,9 @@ Prototyping stage policy:
 Implementation stage:
 
 - `/qfai-implement` orchestrates the full TDD micro-cycle (Red/Green/Refactor) one test at a time using `test-list.md` as the execution ledger.
+- Each item requires watch it fail (RED observation confirmed), watch it pass (GREEN observation confirmed), and fresh evidence (command+result pairs, not status-only).
+- Completion requires independent spec review and code quality review gates — both must PASS before an item is marked done.
+- Parallel execution is allowed only for independent slices with no shared state; worktree separation is required.
 
 Legacy note:
 

package/assets/init/.qfai/assistant/skills/qfai-implement/SKILL.md

@@ -56,14 +56,16 @@ Execute the TDD micro-cycle for each pending item in `test-list.md`, transitioni
 
 The execution ledger at `.qfai/specs/spec-XXXX/tdd/test-list.md` tracks progress with these required columns:
 
-| Column    | Description                                        |
-| --------- | -------------------------------------------------- |
-| TDD-ID    | Unique identifier for the TDD item (e.g., TDD-001) |
-| TC-Refs   | References to test cases from `06_Test-Cases.md`   |
-| Layer     | Test layer (Unit, Integration, etc.)               |
-| Test file | Path to the test file                              |
-| Selector  | Test selector/description for targeted execution   |
-| Status    | Current lifecycle status                           |
+| Column    | Description                                              |
+| --------- | -------------------------------------------------------- |
+| TDD-ID    | Unique identifier for the TDD item (e.g., TDD-0001)      |
+| TC-Refs   | References to test cases from `06_Test-Cases.md`         |
+| Layer     | Test layer (Unit, Integration, etc.)                     |
+| Test file | Path to the test file                                    |
+| Selector  | Test selector/description for targeted execution         |
+| Status    | Current lifecycle status                                 |
+| DR-ID     | Decision Record ID for exception items (blank otherwise) |
+| Evidence  | RED/GREEN command+result pairs proving the TDD cycle     |
 
 ### Status Lifecycle
 
@@ -75,7 +77,7 @@ Allowed transitions:
 - `red` -> `green` (make the test pass with minimal code)
 - `green` -> `refactor` (improve code quality while keeping tests green)
 - `refactor` -> `done` (item complete)
-- Any active status -> `exception` (anomaly detected; record DR-ID in Notes column if present)
+- Any active status -> `exception` (anomaly detected; record DR-ID in DR-ID column)
 
 Backward transitions are prohibited. Attempting `green` -> `red` must produce:
 `"Backward transition prohibited: green -> red"`.
@@ -84,8 +86,8 @@ Backward transitions are prohibited. Attempting `green` -> `red` must produce:
 
 When transitioning to `exception`:
 
-- A DR-ID (Decision Record ID) should be recorded in the Notes column if present.
-- If a Notes column exists but is empty, emit warning: `"exception status requires DR-ID in Notes column"`.
+- A DR-ID (Decision Record ID) must be recorded in the DR-ID column.
+- If the DR-ID column is empty, emit error: `"exception status requires DR-ID in DR-ID column"`.
 
 ## Required Process
 
@@ -108,7 +110,9 @@ When transitioning to `exception`:
 
 1. Improve code quality (naming, structure, duplication removal) while keeping all tests green.
 2. Run the full relevant test suite to confirm nothing broke.
-3. Transition status to `refactor`, then immediately to `done`.
+3. Transition status to `refactor`.
+4. Submit for spec review (TDDSpecReviewer) and code quality review (TDDCodeQualityReviewer).
+5. After both reviewers return PASS, run checkpoint verification, then transition to `done`.
 
 ### Completion
 
@@ -124,14 +128,64 @@ When transitioning to `exception`:
 - Orchestrator MUST NOT write test or production code directly.
 - Orchestrator updates `test-list.md` status after each phase completes.
 
-### Sub-agent Roles
+### Formal Sub-agent Roster
 
-| Role        | Responsibility                               |
-| ----------- | -------------------------------------------- |
-| TestWriter  | Writes the failing test (Red phase)          |
-| Implementer | Writes minimal production code (Green phase) |
-| Refactorer  | Improves code quality (Refactor phase)       |
-| TestRunner  | Executes tests and reports pass/fail results |
+This skill delegates to 6 named sub-agents. Each has explicit responsibilities, prohibitions, and handoff contracts.
+RedGreenAuditor is the sole authority for RED/GREEN observation confirmation;
+self-certification by TDDImplementer is prohibited.
+
+#### TDDCycleController
+
+- Responsibilities: reads `test-list.md`, selects the next pending item, enforces Red-Green-Refactor-Review-Checkpoint ordering,
+  blocks advancement until completion conditions are met, oversized item splitting (target: completion within minutes)
+- Prohibitions: must not write test or production code directly, must not edit spec artifacts, must not authorize parallel dispatch without ParallelSliceDispatcher confirmation of independence
+
+#### TDDImplementer
+
+- Responsibilities: implements the selected single item only — writes a failing test first,
+  writes minimal production code to make it pass, performs refactor while keeping tests green, performs local self-inspection before handoff
+- Prohibitions: must not write production code before the failing test exists,
+  must not confirm its own RED/GREEN observations (self-certification prohibited — only RedGreenAuditor may confirm RED/GREEN observations),
+  must not work on more than one item simultaneously, must not perform speculative generalization, must not mix unrelated refactoring
+
+#### RedGreenAuditor
+
+- Responsibilities: sole authority for confirming RED and GREEN observations — verifies that the test actually failed for the expected reason (watch it fail),
+  verifies that the test actually passed after implementation (watch it pass), verifies that refactored code maintains green state
+- Prohibitions: must not accept reasoning-only confirmation without actual test execution output, must not accept setup failures / import errors / typo failures as valid RED observations
+
+#### TDDSpecReviewer
+
+- Responsibilities: reviews alignment with `01_Spec.md`, `06_Test-Cases.md`, `09_delta.md`, `10_Plan.md` — detects scope creep,
+  verifies `test-list.md` updates match spec references, performs spec review as an independent gate
+- Prohibitions: must not issue style-only reviews that skip compliance checks, must not permit spec drift through reviewer notes alone while allowing completion
+
+#### TDDCodeQualityReviewer
+
+- Responsibilities: reviews duplication, naming, hidden coupling, edge cases, error boundaries, security assumptions —
+  verifies refactor achieves design improvement, performs code quality review as an independent gate
+- Prohibitions: must not issue style-nit-only reviews that skip design analysis, must not conflate spec compliance with quality review scope,
+  must not be self-approved by TDDImplementer (TDDImplementer cannot serve as TDDCodeQualityReviewer for its own work)
+
+#### ParallelSliceDispatcher
+
+- Responsibilities: sole authority for authorizing parallel dispatch — evaluates independence of candidate slices, requires worktree/branch separation, defines post-merge integration verify conditions
+- Prohibitions: must not authorize parallel dispatch for slices sharing the same behavior R/G/R cycle, same API surface, same fixture/mock/DI/global setup, or any unexplained independence claim
+
+### Handoff Contracts
+
+All agent-to-agent transitions follow these 8 defined contracts:
+
+1. **TDDCycleController -> TDDImplementer**: Controller selects item, sets status to `red`, hands off item context (TDD-ID, TC-Refs, spec references) to Implementer
+2. **TDDImplementer -> RedGreenAuditor**: Implementer submits RED/GREEN observation
+   (test command + actual output: failing for RED, passing for GREEN) for verification; Auditor confirms or rejects the observation state
+3. **RedGreenAuditor -> TDDImplementer**: Auditor returns RED/GREEN confirmation
+   (RED: proceed to implementation; GREEN: proceed to spec review) or rejection (resubmit with valid and correctly classified test run)
+4. **TDDImplementer -> TDDSpecReviewer**: After GREEN confirmed by RedGreenAuditor, Implementer submits item for spec review with implementation summary and test evidence
+5. **TDDSpecReviewer -> TDDImplementer**: Reviewer returns PASS (proceed to quality review) or FAIL with required fixes
+6. **TDDImplementer -> TDDCodeQualityReviewer**: After spec review PASS, Implementer submits for code quality review
+7. **TDDCodeQualityReviewer -> TDDImplementer**: Reviewer returns PASS (item can be marked done) or FAIL with required fixes
+8. **TDDCycleController -> ParallelSliceDispatcher**: Controller requests parallel dispatch evaluation; Dispatcher returns authorization or denial with rationale
 
 ### Capability Probe (MUST)
 
@@ -163,19 +217,71 @@ Every major artifact in this stage MUST include this table schema:
 
 ## Parallelization Policy
 
-- **Default**: Serial execution. Items are processed one at a time in `test-list.md` order.
+- **Default**: Serial execution. Items are processed one test at a time in `test-list.md` order.
 - **Exception**: When items target completely independent SUT modules with no shared state, parallel processing may be used with explicit user approval.
 - Serial execution ensures that each test is written and verified in isolation before moving to the next.
+- ParallelSliceDispatcher is the sole authority for authorizing parallel dispatch.
+
+### Allow conditions (all must be true)
+
+- Independent SUT (no shared source files under test)
+- Independent test files (no shared test files or fixtures)
+- No shared state (no shared database, global variable, singleton, or DI container)
+- No sequential dependency (Slice B does not depend on Slice A output)
+- Worktree or branch separation is available
+- Post-merge integration verify plan exists
+
+### Deny conditions (any one blocks parallel dispatch)
+
+- Same behavior Red/Green/Refactor cycle across slices
+- Same public API surface modified by multiple slices
+- Shared fixture, shared mock, shared DI container, shared global setup
+- Sequential dependency: "A must finish before B has meaning"
+- Independence claim cannot be explained with concrete file/module evidence
+
+### Post-parallel integration verify
+
+- After parallel slices complete and merge, run integration verify on the merged result
+- If integration verify fails, flag all slices for re-examination and roll back the merge
+- If integration verify passes, state transitions back to TDDCycleController for sequential flow
 
 ## Completion Contract (Shared)
 
-Before declaring completion, you MUST:
+### Item completion checklist (10-point gate)
+
+An item in `test-list.md` may transition to `done` only when ALL of the following are satisfied:
+
+1. Corresponding `TDD-ID` has been selected and is in progress
+2. A failing test was added first (test-first)
+3. RED was observed — RedGreenAuditor confirmed the test failed for the expected reason (watch it fail)
+4. Minimal production code was written to make the test pass
+5. GREEN was observed — RedGreenAuditor confirmed the test passes after implementation (watch it pass)
+6. Refactor was performed and GREEN was re-confirmed after refactor
+7. TDDSpecReviewer returned PASS (spec review gate)
+8. TDDCodeQualityReviewer returned PASS (code quality review gate)
+9. `test-list.md` Status and Evidence columns are updated with fresh evidence
+10. Checkpoint verification passed
+
+### Spec completion conditions
+
+The skill may declare "this spec's implementation is complete" only when:
 
-- All `todo` items in `test-list.md` have been processed.
-- Each processed item reached `done` or `exception` status.
-- All tests pass (`npm test` or equivalent).
-- `test-list.md` reflects the final state accurately.
-- Exception items have DR-IDs recorded (in Notes column if present).
+- All TC-\* from `06_Test-Cases.md` with applicable layer are present in `test-list.md`
+- Each item reached `done` or valid `exception` (with DR-ID)
+- 0 blocking reviewer issues remain
+- Checkpoint verification passed
+- No unresolved Change Request or waiver dependency exists
+
+### Completion prohibition conditions
+
+Completion MUST NOT be declared when any of the following are true:
+
+- No RED fresh evidence exists for the item
+- No GREEN fresh evidence exists for the item
+- Either reviewer (TDDSpecReviewer or TDDCodeQualityReviewer) has not been run or returned FAIL
+- Items with `todo`, `red`, `green`, or `refactor` status still exist (for spec-level completion)
+- Parallel slices were used but integration verify has not been run post-merge
+- Checkpoint boundary was reached but verification was not executed
 
 ## Evidence (MANDATORY)
 
@@ -189,6 +295,28 @@ Required sections:
 - Exception items (if any) with DR-IDs
 - Commands executed
 
+### Per-item evidence contract (fresh evidence required)
+
+Each TDD item MUST have fresh evidence containing at minimum:
+
+- `TDD-ID` — the item identifier
+- `TC-ref` — reference to the test case(s)
+- `RED command` — the exact command executed to observe failure
+- `RED result` — the failure output (result completeness is best-effort; truncated output is acceptable)
+- `GREEN command` — the exact command executed to observe success
+- `GREEN result` — the success output
+- `Refactor verify command` — the exact command re-executed after refactor
+- `Refactor verify result` — the output confirming GREEN is maintained
+- `Spec review` — TDDSpecReviewer result (PASS or FAIL)
+- `Code quality review` — TDDCodeQualityReviewer result (PASS or FAIL)
+
+### Evidence hard rules
+
+- Status-only evidence (e.g., "Status: PASS" with no command) is invalid and MUST be rejected
+- Both command and result are required; "should pass" or "looks good" alone is not acceptable
+- Stale evidence from a previous run MUST NOT be reused to claim completion for a new cycle
+- Empty evidence entries are rejected: minimum evidence per TDD item must be met
+
 ## FINAL CHECKLIST (Check Last)
 
 - [ ] CRITICAL CONSTRAINTS were followed.

package/dist/cli/index.cjs

@@ -1522,8 +1522,8 @@ var import_promises7 = require("fs/promises");
 var import_node_path8 = __toESM(require("path"), 1);
 var import_node_url2 = require("url");
 async function resolveToolVersion() {
-  if ("1.6.1".length > 0) {
-    return "1.6.1";
+  if ("1.6.3".length > 0) {
+    return "1.6.3";
   }
   try {
     const packagePath = resolvePackageJsonPath();
@@ -2758,6 +2758,17 @@ async function runInit(options) {
   await ensureRequiredEmptyScaffoldDirs(destQfai, options.dryRun);
   const removedLegacySkills = options.force ? await pruneLegacySkillFiles(destRoot, options.dryRun) : [];
   const removed = [...removedLegacySkills, ...wrappersResult.removed];
+  const expectedInstructionsDir = import_node_path14.default.join(destRoot, ".github", "instructions");
+  const instructionsCreated = wrappersResult.copied.some(
+    (p) => import_node_path14.default.basename(p).endsWith(".instructions.md") && import_node_path14.default.dirname(p) === expectedInstructionsDir
+  );
+  if (instructionsCreated && !options.dryRun) {
+    info("");
+    info("Copilot \u30B3\u30FC\u30C9\u30EC\u30D3\u30E5\u30FC\u7528 instructions \u3092\u4F5C\u6210\u3057\u307E\u3057\u305F\u3002");
+    info("\u6709\u52B9\u5316: PR \u30B3\u30E1\u30F3\u30C8\u3067 '@github-copilot review' \u3092\u5B9F\u884C\u3059\u308B\u304B\u3001");
+    info("GitHub Actions \u30EF\u30FC\u30AF\u30D5\u30ED\u30FC\u3067\u81EA\u52D5\u30EC\u30D3\u30E5\u30FC\u3092\u8A2D\u5B9A\u3057\u3066\u304F\u3060\u3055\u3044\u3002");
+    info("\u53C2\u8003: https://docs.github.com/en/copilot/using-github-copilot/code-review");
+  }
   report(
     [...rootResult.copied, ...qfaiResult.copied, ...skillsResult.copied, ...wrappersResult.copied],
     [
@@ -2841,6 +2852,20 @@ async function exists7(target) {
     return false;
   }
 }
+function isEnoent(err) {
+  return typeof err === "object" && err !== null && err.code === "ENOENT";
+}
+async function pathExists(target) {
+  try {
+    await (0, import_promises12.lstat)(target);
+    return true;
+  } catch (err) {
+    if (isEnoent(err)) {
+      return false;
+    }
+    throw err;
+  }
+}
 async function configureGitSymlinks(destRoot, dryRun) {
   try {
     await execAsync("git rev-parse --git-dir", { cwd: destRoot });
@@ -2905,6 +2930,31 @@ async function syncIntegrationWrappers(assistantAssetsDir, destRoot, options) {
       await (0, import_promises12.writeFile)(copilotDest, buildCopilotInstructions(), "utf-8");
     }
   }
+  const instructionsFiles = ["code-review.instructions.md", "principles.instructions.md"];
+  for (const fileName of instructionsFiles) {
+    const dest = import_node_path14.default.join(destRoot, ".github", "instructions", fileName);
+    const alreadyExists = await pathExists(dest);
+    if (alreadyExists) {
+      skipped.push(dest);
+    } else {
+      copied.push(dest);
+      if (!options.dryRun) {
+        await (0, import_promises12.mkdir)(import_node_path14.default.dirname(dest), { recursive: true });
+        const templateSrc = import_node_path14.default.join(getInitAssetsDir(), ".github", "instructions", fileName);
+        let content;
+        try {
+          content = await (0, import_promises12.readFile)(templateSrc, "utf-8");
+        } catch (err) {
+          const code = typeof err === "object" && err !== null ? err.code : void 0;
+          const detail = err instanceof Error ? err.message : String(err);
+          throw new Error(
+            `instructions \u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u306E\u8AAD\u307F\u8FBC\u307F\u306B\u5931\u6557\u3057\u307E\u3057\u305F: ${templateSrc} (${code ?? detail})\u3002\u30D1\u30C3\u30B1\u30FC\u30B8\u304C\u6B63\u3057\u304F\u30A4\u30F3\u30B9\u30C8\u30FC\u30EB\u3055\u308C\u3066\u3044\u308B\u304B\u78BA\u8A8D\u3057\u3066\u304F\u3060\u3055\u3044\u3002`
+          );
+        }
+        await (0, import_promises12.writeFile)(dest, content, "utf-8");
+      }
+    }
+  }
   const skillResult = await createSkillSymlinks(destRoot, skills, options);
   copied.push(...skillResult.copied);
   skipped.push(...skillResult.skipped);