create-ai-project 1.20.9 → 1.22.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/agents-en/acceptance-test-generator.md +112 -50
- package/.claude/agents-en/task-decomposer.md +40 -4
- package/.claude/agents-en/ui-spec-designer.md +2 -0
- package/.claude/agents-en/work-planner.md +98 -29
- package/.claude/agents-ja/acceptance-test-generator.md +113 -49
- package/.claude/agents-ja/task-decomposer.md +44 -8
- package/.claude/agents-ja/ui-spec-designer.md +2 -0
- package/.claude/agents-ja/work-planner.md +96 -29
- package/.claude/commands-en/add-integration-tests.md +8 -0
- package/.claude/commands-en/build.md +75 -23
- package/.claude/commands-en/front-build.md +56 -25
- package/.claude/commands-en/front-plan.md +7 -6
- package/.claude/commands-en/front-review.md +81 -19
- package/.claude/commands-en/implement.md +36 -5
- package/.claude/commands-en/plan.md +9 -8
- package/.claude/commands-en/prepare-implementation.md +191 -0
- package/.claude/commands-en/project-inject.md +84 -56
- package/.claude/commands-en/review.md +79 -20
- package/.claude/commands-ja/add-integration-tests.md +8 -0
- package/.claude/commands-ja/build.md +77 -25
- package/.claude/commands-ja/front-build.md +59 -28
- package/.claude/commands-ja/front-plan.md +8 -7
- package/.claude/commands-ja/front-review.md +81 -19
- package/.claude/commands-ja/implement.md +36 -5
- package/.claude/commands-ja/plan.md +10 -9
- package/.claude/commands-ja/prepare-implementation.md +191 -0
- package/.claude/commands-ja/project-inject.md +84 -56
- package/.claude/commands-ja/review.md +79 -20
- package/.claude/skills-en/documentation-criteria/references/plan-template.md +22 -0
- package/.claude/skills-en/documentation-criteria/references/ui-spec-template.md +2 -0
- package/.claude/skills-en/frontend-typescript-testing/references/e2e.md +81 -7
- package/.claude/skills-en/integration-e2e-testing/SKILL.md +48 -23
- package/.claude/skills-en/integration-e2e-testing/references/e2e-design.md +31 -13
- package/.claude/skills-en/project-context/SKILL.md +2 -15
- package/.claude/skills-en/project-context/references/external-resources-api.md +76 -0
- package/.claude/skills-en/project-context/references/external-resources-backend.md +76 -0
- package/.claude/skills-en/project-context/references/external-resources-frontend.md +74 -0
- package/.claude/skills-en/project-context/references/external-resources-infra.md +76 -0
- package/.claude/skills-en/project-context/references/template.md +154 -0
- package/.claude/skills-en/subagents-orchestration-guide/SKILL.md +36 -14
- package/.claude/skills-en/task-analyzer/references/skills-index.yaml +0 -5
- package/.claude/skills-ja/documentation-criteria/references/plan-template.md +22 -0
- package/.claude/skills-ja/documentation-criteria/references/ui-spec-template.md +2 -0
- package/.claude/skills-ja/frontend-typescript-testing/references/e2e.md +81 -7
- package/.claude/skills-ja/integration-e2e-testing/SKILL.md +48 -23
- package/.claude/skills-ja/integration-e2e-testing/references/e2e-design.md +31 -13
- package/.claude/skills-ja/project-context/SKILL.md +2 -15
- package/.claude/skills-ja/project-context/references/external-resources-api.md +76 -0
- package/.claude/skills-ja/project-context/references/external-resources-backend.md +76 -0
- package/.claude/skills-ja/project-context/references/external-resources-frontend.md +74 -0
- package/.claude/skills-ja/project-context/references/external-resources-infra.md +76 -0
- package/.claude/skills-ja/project-context/references/template.md +154 -0
- package/.claude/skills-ja/subagents-orchestration-guide/SKILL.md +36 -14
- package/.claude/skills-ja/task-analyzer/references/skills-index.yaml +0 -5
- package/.husky/pre-commit +1 -0
- package/CHANGELOG.md +55 -6
- package/README.ja.md +3 -2
- package/README.md +3 -2
- package/docs/guides/en/use-cases.md +18 -3
- package/docs/guides/ja/use-cases.md +18 -3
- package/package.json +2 -1
- package/scripts/check-skills-index.mjs +173 -0
|
@@ -124,6 +124,27 @@ description: サブエージェントのタスク分担と連携を調整。規
|
|
|
124
124
|
|
|
125
125
|
## 構造化レスポンス仕様
|
|
126
126
|
|
|
127
|
+
すべてのサブエージェント呼び出しは **Agent ツール** を使用し、以下を渡す:
|
|
128
|
+
- `subagent_type`: エージェント名(例: "task-executor")
|
|
129
|
+
- `description`: 簡潔なタスク記述(3〜5語)
|
|
130
|
+
- `prompt`: 成果物のパスを含む具体的な指示
|
|
131
|
+
|
|
132
|
+
### オーケストレーターの許可ツール
|
|
133
|
+
|
|
134
|
+
オーケストレーターは以下のツールのみで作業を統制する:
|
|
135
|
+
|
|
136
|
+
| ツール | 用途 |
|
|
137
|
+
|------|------|
|
|
138
|
+
| Agent | サブエージェントの呼び出し |
|
|
139
|
+
| AskUserQuestion | ユーザー確認・質問 |
|
|
140
|
+
| TaskCreate / TaskUpdate | 進捗追跡 |
|
|
141
|
+
| Bash | シェル操作(git commit、ls、検証コマンド) |
|
|
142
|
+
| Read | サブエージェント間の情報橋渡しのための成果物ドキュメント参照 |
|
|
143
|
+
|
|
144
|
+
実装作業(Edit、Write、MultiEdit)はすべてサブエージェントが実施する。オーケストレーター自身は行わない。
|
|
145
|
+
|
|
146
|
+
### サブエージェント応答形式
|
|
147
|
+
|
|
127
148
|
サブエージェントはJSON形式で応答。オーケストレーター判断に必要なフィールド:
|
|
128
149
|
|
|
129
150
|
| Agent | 主要フィールド | 判断ロジック |
|
|
@@ -136,8 +157,8 @@ description: サブエージェントのタスク分担と連携を調整。規
|
|
|
136
157
|
| document-reviewer | approvalReady (true/false) | trueで次ステップへ。falseで修正を依頼 |
|
|
137
158
|
| design-sync | sync_status (NO_CONFLICTS/CONFLICTS_FOUND) | CONFLICTS_FOUND時: 矛盾をユーザーに提示してから進む |
|
|
138
159
|
| integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | needs_revision時: 同じ task_file と requiredFixes[] を渡してルーティング先の executor を Fix Mode で再実行 |
|
|
139
|
-
| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | needs_revision時:
|
|
140
|
-
| acceptance-test-generator | status, generatedFiles
|
|
160
|
+
| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | needs_revision時: `requiredFixes[].location` から影響ファイルパスを抽出して Target Files に投入した統合修正タスクファイルを作成し、その task_file と `requiredFixes[]` 配列を渡してルーティング先の executor を Fix Mode で起動。続いて quality-fixer を実行し、最後に security-reviewer を再起動して解消を検証する。blocked 時: ブロッキング findings を添えてユーザーにエスカレーション — エージェント層の権限外の修正である |
|
|
161
|
+
| acceptance-test-generator | status, generatedFiles.{integration,fixtureE2e,serviceE2e}(レーンごとに path\|null), budgetUsage(レーン別), e2eAbsenceReason(E2Eレーンごと。出力時は null。reason の enum 定義は acceptance-test-generator と integration-e2e-testing スキルが所有) | 非nullの各 `generatedFiles.<lane>` パスがディスク上に存在することを確認し、レーン別のパスと不在理由を work-planner に渡す |
|
|
141
162
|
|
|
142
163
|
### quality-fixer blockedハンドリング
|
|
143
164
|
|
|
@@ -186,6 +207,15 @@ quality-fixerが `status: "blocked"` を返した場合、`reason`で判別:
|
|
|
186
207
|
|
|
187
208
|
注: 小規模スケールでも実装ステップは task-executor を介して標準の4ステップサイクル(`task-executor → エスカレーション判定 → quality-fixer → commit`)で実行する。オーケストレーターによる直接編集は行わない。
|
|
188
209
|
|
|
210
|
+
### Implementation Readinessマーカー
|
|
211
|
+
|
|
212
|
+
Medium / Large規模では、一括承認後、作業計画書のヘッダに `Implementation Readiness:` 行が含まれる(work-plannerが`pending`を出力する。`ready` または `escalated` への昇格は外部オーケストレーションの関心事である)。マーカーは以下3値のいずれかを取る:
|
|
213
|
+
- `pending` — work-plannerが設定する初期状態
|
|
214
|
+
- `ready` — readiness検証が完了し残存ギャップなし。タスク実行サイクルを安全に開始できる
|
|
215
|
+
- `escalated` — readiness検証は完了したが残存ギャップが存在し、実行前にユーザー判断が必要
|
|
216
|
+
|
|
217
|
+
`pending`から先へマーカーを昇格させるプロデューサと、task-executor呼び出し前にマーカーを読むコンシューマは、いずれも外部オーケストレーションが所有する。本ガイドはエージェント層の上位にあるオーケストレーターを呼び出さない。エージェントは明示的に依頼された場合にのみマーカーを読み書きする。
|
|
218
|
+
|
|
189
219
|
## レイヤー横断オーケストレーション
|
|
190
220
|
|
|
191
221
|
requirement-analyzerが複数レイヤー(backend + frontend)にまたがる機能と判定した場合(`crossLayerScope`で判断)、以下の拡張を適用。ステップ番号は大規模フロー基準。中規模フローではDesign Doc作成がステップ2から始まるため、同じパターンをステップ2a/2b/3/4として適用する。
|
|
@@ -321,21 +351,13 @@ requirement-analyzerが複数レイヤー(backend + frontend)にまたがる
|
|
|
321
351
|
|
|
322
352
|
#### *1 acceptance-test-generator → work-planner
|
|
323
353
|
|
|
324
|
-
**acceptance-test-generatorへの入力**:
|
|
325
|
-
- Design Doc: [パス]
|
|
326
|
-
- UI Spec: [パス](存在する場合)
|
|
354
|
+
**acceptance-test-generatorへの入力**: Design Doc のパス、UI Spec のパス(存在する場合)。
|
|
327
355
|
|
|
328
|
-
|
|
329
|
-
- `generatedFiles.integration`が有効なパスであり(nullでない場合)、ファイルが存在すること
|
|
330
|
-
- `generatedFiles.e2e`が有効なパスであり(nullでない場合)、ファイルが存在すること
|
|
331
|
-
- `generatedFiles.e2e`がnullの場合、`e2eAbsenceReason`が存在すること — これは意図的な不在であり、エラーではない
|
|
356
|
+
**オーケストレーターの検証**: 非nullの各 `generatedFiles.<lane>` パスがディスク上に存在すること。nullのレーンごとに `e2eAbsenceReason.<lane>` が存在すること — これは意図的な不在であり、エラーではない。
|
|
332
357
|
|
|
333
|
-
**work-plannerへの入力**:
|
|
334
|
-
- 統合テストファイル: [パス](各フェーズの実装と同時に作成・実行)
|
|
335
|
-
- E2Eテストファイル: [パス]またはnull(提供された場合のみ最終フェーズで実行)
|
|
336
|
-
- E2E不在理由: [理由](E2Eがnullの場合 — work-plannerがE2Eギャップチェックをスキップするために渡す)
|
|
358
|
+
**work-plannerへの入力**: 統合テスト / fixture-e2e / service-integration-e2e の各ファイルパス(レーンごとに値またはnull)、レーン別の不在理由、およびタイミングガイダンス — 統合テストは各フェーズ実装と並行して作成、fixture-e2e テストは UI 機能フェーズと並行して作成、service-integration-e2e テストは最終フェーズでのみ実行。
|
|
337
359
|
|
|
338
|
-
**エラー時**:
|
|
360
|
+
**エラー時**: status != completed で統合テストファイル生成が予期せず失敗した場合はユーザーにエスカレーションする。E2Eレーンがnullかつ妥当な不在理由がある場合はエラーではない。
|
|
339
361
|
3. **ADRステータス管理**: ユーザー判断後のADRステータス更新(Accepted/Rejected)
|
|
340
362
|
|
|
341
363
|
## 重要な制約
|
package/.husky/pre-commit
CHANGED
package/CHANGELOG.md
CHANGED
|
@@ -5,6 +5,55 @@ All notable changes to this project will be documented in this file.
|
|
|
5
5
|
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
|
|
6
6
|
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
7
7
|
|
|
8
|
+
## [1.22.0] - 2026-05-10
|
|
9
|
+
|
|
10
|
+
### Added
|
|
11
|
+
|
|
12
|
+
- **External Resources section in project-context skill** (skills) — Captures access methods for resources outside the repository (design source, design system, schema source, secret store, IaC source, deployment trigger) across four domains: frontend, backend, API contract, infrastructure. Each domain reference (`references/external-resources-{frontend,backend,api,infra}.md`) defines four structured axes plus a self-declaration phase. Per-axis output schema records three fields: Source type, Location, Access method. Multiple-instance and cross-axis-reference rules cover primary/analytics splits and resources shared across domains
|
|
13
|
+
- **Template-driven /project-inject command** (commands) — Section catalog and hearing protocol live in `.claude/skills/project-context/references/template.md`; new dimensions are added by editing the template. Section-level hearing supports five dispositions (`add` / `keep` / `update` / `remove` / `skip`) for incremental updates without re-running the full flow. Vagueness rejection filter sends back subjective rules for measurable rephrasing during hearing
|
|
14
|
+
|
|
15
|
+
### Changed
|
|
16
|
+
|
|
17
|
+
- **project-context skill scope** (skills) — Expanded from domain constraints / development phase / directory conventions to also cover external-resource access methods. Description frontmatter advertises all four axes with explicit "Use when" trigger phrases (session start, project structure check, domain rules, external resources). Configured SKILL.md is shaped by /project-inject from the catalog; unconfigured stub ships as a minimal one-line invitation to run /project-inject
|
|
18
|
+
- **skills-index validator: dynamic-content skills allowed** (tooling) — `scripts/check-skills-index.mjs` treats yaml entries with no sections as dynamic content (logged, skipped) rather than failing. Releases the prior implicit requirement that every skill have at least one static section, removing the need for stub-padding workarounds for skills whose content is populated at runtime
|
|
19
|
+
|
|
20
|
+
## [1.21.0] - 2026-05-03
|
|
21
|
+
|
|
22
|
+
### Added
|
|
23
|
+
|
|
24
|
+
- **prepare-implementation recipe** (commands) — New optional readiness phase between work-plan approval and the build/implement phase. Verifies five readiness criteria (Verification Strategy references, E2E preconditions, Phase 1 observability, UI rendering surface, local lane procedure), generates Phase 0 prep tasks through the standard 4-step cycle when gaps exist, and exits no-op when readiness is already satisfied. Routes prep-only targets (`docs/**`, `scripts/**`, `tests/fixtures/**`, `tests/e2e/data/**`) to the backend executor; mixed/unrecognized targets escalate. Persists `## Implementation Readiness Report` into the work plan body and promotes the header marker to `ready` or `escalated`
|
|
25
|
+
- **Implementation Readiness gate** (agents, commands) — work-planner emits `Implementation Readiness: pending` in the plan header for medium/large scale. build / front-build / implement read the marker and halt-and-confirm via AskUserQuestion when the status is `pending` or `escalated`. subagents-orchestration-guide describes the marker contract abstractly (values: `pending` | `ready` | `escalated`)
|
|
26
|
+
- **E2E lane split (fixture-e2e / service-integration-e2e)** (agents, skills) — fixture-e2e: browser harness with mocked backend / fixture-driven state, MAX 3 per feature, runs alongside the UI feature phase, ROI ≥ 20 floor for non-reserved slots. service-integration-e2e: against a running local stack, MAX 1-2 per feature, executed only in the final phase, ROI > 50 beyond the reserved slot. acceptance-test-generator output schema replaces `generatedFiles.e2e` with `generatedFiles.{integration, fixtureE2e, serviceE2e}`; `e2eAbsenceReason` becomes a per-lane object whose enum is lane-specific (`no_real_service_dependency` is service-lane-only). work-planner E2E gap check evaluates each lane independently. integration-e2e-testing skill, e2e-design reference, and frontend-typescript-testing/references/e2e updated with lane definitions, ROI thresholds by lane, and Fixture-Based Backend patterns (`page.route()` interception, fixture loaders)
|
|
27
|
+
- **UI Spec Component → Task Mapping** (agents, skills) — work-planner produces a UI Spec Component → Task Mapping table when a UI Spec is among the inputs. task-decomposer propagates matching component sections (with state hints) into each task's Investigation Targets. ui-spec-designer enforces component heading uniqueness with a disambiguation rule. plan-template / ui-spec-template carry the new sections
|
|
28
|
+
- **Connection Map** (agents, skills) — work-planner produces a Connection Map table when implementation crosses runtime/deployment boundaries (with strict inclusion criteria — separate processes, serialized contract, observable failure signal — and explicit exclusion of in-process imports). task-decomposer propagates boundary context to implementation tasks on each side via Investigation Targets and a "Boundary Context" note
|
|
29
|
+
- **Per-finding routing in review recipes** (commands) — review / front-review Step 4 changes from a single fix-all toggle to per-finding routing: `c` (code-side fix), `d` (design-side update), `s` (skip), with an "accept all recommended" default offer. New Step 5d invokes technical-designer (update mode) → document-reviewer → design-sync (when multiple Design Docs exist) before code-side fixes. Recommendation rule keys off existing code-reviewer schema only (`acceptanceCriteria` status, `identifierMismatches` rename pattern, `qualityFindings` categories) — no fuzzy intent inference. Early exit when verdict is `pass` and all finding arrays are empty
|
|
30
|
+
- **Consumed Task Set restriction** (commands) — build / front-build / implement compute a restricted Consumed Task Set excluding prep, overview, completion, review-fix, and integration-test patterns. Layer-aware consumption per the routing table: build owns `*-task-*` and `*-backend-task-*`; front-build owns only `*-frontend-task-*`. `$ARGUMENTS` takes priority over auto-resolution. Auto-resolution to most-recent plan requires positive backend-signal verification (Target Files match backend markers, Design Doc filename identifies as backend, or title/objective explicitly says backend) AND zero frontend signals; otherwise stops and asks for `$ARGUMENTS`
|
|
31
|
+
- **Final Cleanup pattern** (commands) — Each task-creating recipe (build / front-build / implement / review / front-review / add-integration-tests / prepare-implementation) deletes its consumed task files at completion. implement is scale-agnostic and cleans all three layer patterns
|
|
32
|
+
- **subagents-orchestration-guide: Orchestrator's Permitted Tools subsection** (skills) — Explicit table of orchestrator-permitted tools (Agent / AskUserQuestion / TaskCreate / TaskUpdate / Bash / Read) with the constraint that all implementation work is performed by subagents
|
|
33
|
+
- **subagents-orchestration-guide: Implementation Readiness Marker subsection** (skills) — Documents the marker contract abstractly (values, producer, consumer) with the explicit note that promotion beyond `pending` and consumption before execution are external orchestration concerns
|
|
34
|
+
- **scripts/check-skills-index.mjs** (tooling) — Deterministic consistency checker that walks every entry in `.claude/skills-{en,ja}/task-analyzer/references/skills-index.yaml`, extracts H2 headings from each corresponding `SKILL.md`, and exits non-zero on any order or text mismatch. Scope is narrow (sections are deterministic; tags / typical-use remain manual). Wired as `npm run check:skills-index` and registered in `.husky/pre-commit`
|
|
35
|
+
|
|
36
|
+
### Changed
|
|
37
|
+
|
|
38
|
+
- **acceptance-test-generator: lane-aware ROI selection** (agents) — Phase 3 push-down analysis adds a lane assignment step (default fixture-e2e for UI journeys; promote to service-integration-e2e only when verification depends on real cross-service behavior). Phase 4 selection algorithm reserves slots per lane (fixture-e2e reserved for any user-facing journey; service-integration-e2e reserved only when real cross-service correctness is required) and applies per-lane ROI gates. Generation Report contract expanded to per-lane fields with a per-lane absence-reason matrix
|
|
39
|
+
- **work-planner: scale-aware readiness emission and lane-aware test placement** (agents) — Header MUST include `Implementation Readiness: pending` for medium/large. E2E gap check evaluates fixture-e2e and service-integration-e2e independently. Test placement rules split into integration / fixture-e2e (alongside UI feature phase) / service-integration-e2e (final phase only). Quality Checklist gains UI Spec Component → Task Mapping, Connection Map, and the readiness-marker entry
|
|
40
|
+
- **task-decomposer: layer-aware naming convention clarified** (agents) — Bare `*-task-*` is reserved for backend single-layer per Layer-Aware Agent Routing. Frontend single-layer must use `*-frontend-task-*`. Multi-layer uses both `*-backend-task-*` and `*-frontend-task-*`. Investigation Targets gain rows for frontend component implementation, frontend integration / fixture-e2e tests, and cross-package boundary implementation. UI Spec Propagation and Connection Map Propagation sections describe how table rows flow into task files
|
|
41
|
+
- **subagents-orchestration-guide: per-lane test info routing and security-reviewer fix runbook** (skills) — acceptance-test-generator → work-planner handover documents per-lane paths and absence reasons plus timing guidance. The security-reviewer row replaces the prior cross-recipe reference with an inline runbook (consolidated fix task file → routed executor in Fix Mode → quality-fixer → re-invoke security-reviewer; on `blocked`, escalate)
|
|
42
|
+
- **plan-template: Implementation Readiness header line and new section blocks** (skills) — Header carries the readiness marker on its own line for medium/large scale so downstream parsers extract a bare status (small scale uses task-template instead). New `## UI Spec Component → Task Mapping` and `## Connection Map` sections with reference-key rules and gap status semantics
|
|
43
|
+
- **ui-spec-template: component heading uniqueness call-out** (skills) — `### Component: [ComponentName]` (Japanese: `### コンポーネント: [ComponentName]`) carries a uniqueness rule that downstream agents reference components by exact heading text
|
|
44
|
+
- **All command files: $ARGUMENTS-honoring resolution** (commands) — When `$ARGUMENTS` is provided it is used directly. Auto-resolution from task files is the fallback; the resolution table cleanly separates `$ARGUMENTS`-supplied paths from layer-verified auto-resolved paths. front-build stops rather than auto-fallback when only frontend tasks are missing
|
|
45
|
+
- **integration-e2e-testing: ROI thresholds by lane** (skills) — Replaces the single E2E threshold with a per-lane table. Reserved slot rules apply per lane and override the threshold; below-floor candidates beyond the reserved slot are not emitted (budget intentionally unfilled rather than padded with low-value tests). Includes worked examples for both lanes
|
|
46
|
+
- **frontend-typescript-testing/references/e2e: lane selection guidance** (skills) — New Lane Selection table maps each lane to its backend setup and applicable patterns. Fixture-Based Backend (fixture-e2e) section documents `page.route()` interception and fixture loader patterns. E2E Environment Prerequisites section now explicitly scopes to service-integration-e2e
|
|
47
|
+
- **Dependency direction enforcement** (skills) — subagents-orchestration-guide no longer names specific recipes in the security-reviewer row; the actionable runbook is inline. acceptance-test-generator, task-decomposer, ui-spec-designer, work-planner reference cross-cutting concerns abstractly via guide section names
|
|
48
|
+
|
|
49
|
+
### Fixed
|
|
50
|
+
|
|
51
|
+
- **skills-index drift between yaml and SKILL.md headings** (tooling) — pre-commit `check:skills-index` catches future drift before commit. All 26 skills (13 en + 13 ja) currently consistent
|
|
52
|
+
- **Dangling section references in command files** (commands) — Command files referencing `subagents-orchestration-guide "Orchestrator's Permitted Tools"` resolve to a real section in the guide
|
|
53
|
+
- **acceptance-test-generator integration test example budget header** (agents) — Updated from the pre-lane-split `Budget Used: 2/3 integration, 0/2 E2E` to the new schema (`2/3 integration, 0/3 fixture-e2e, 0/2 service-integration-e2e`)
|
|
54
|
+
- **front-build orphan command line** (commands) — Removed an isolated `! ls -la docs/plans/*.md | head -10` left between the Scope Boundary block and the autonomous-mode prompt
|
|
55
|
+
- **frontend-typescript-testing/references/e2e Skeleton Comment Format** (skills) — Skeleton format requires the `@lane:` annotation and shows lane-specific `@dependency` choices (`full-ui (mocked backend)` for fixture-e2e, `full-system` for service-integration-e2e), matching the lane contract
|
|
56
|
+
|
|
8
57
|
## [1.20.9] - 2026-05-01
|
|
9
58
|
|
|
10
59
|
### Added
|
|
@@ -21,7 +70,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
|
|
21
70
|
- **subagents-orchestration-guide: scale-aware Small Scale flow** (skills) — Small Scale (1-2 files) flow now declares that work-planner emits a single task-template-format file directly under `docs/plans/tasks/` and that path is what task-executor receives as `task_file`. Document Requirement table Small row carries the same contract
|
|
22
71
|
- **work-planner: `scale` input parameter and Output Mode by Scale table** (agents) — `scale: small | medium | large` controls output: `small` produces a single task-template-format file under `docs/plans/tasks/` (no separate plan + decomposition); `medium` / `large` produce a plan-template-format work plan under `docs/plans/`. Step 7 branches accordingly
|
|
23
72
|
- **All JSON-returning agents: Output Protocol section** (agents) — Single-sentence directive that the final message is exactly one JSON object matching the schema below (begins with `{`, ends with `}`, no code fence) and that progress text appears only in earlier messages
|
|
24
|
-
- **Self-Validation [BLOCKING — before output] sections** (agents) — Replaces former `## Output Self-Check` blocks across JSON-returning agents. Includes return-to-step recovery rule when any item is unsatisfied
|
|
73
|
+
- **Self-Validation [BLOCKING — before output] sections** (agents) — Replaces former `## Output Self-Check` blocks across JSON-returning agents. Includes return-to-step recovery rule when any item is unsatisfied
|
|
25
74
|
- **subagents-orchestration-guide: explicit subagent prompt construction rules** (skills) — Two new rules: subagents see only the Agent tool prompt and files they read (so paths, prior JSON, parameters, scope constraints must be injected explicitly); every `[placeholder]` in the call examples must be replaced with concrete values before invoking the Agent tool
|
|
26
75
|
- **task-template: `## Investigation Notes` section** (skills) — New section between Investigation Targets and Implementation Steps. Implementation observations are appended here before implementation begins
|
|
27
76
|
|
|
@@ -39,15 +88,15 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
|
|
39
88
|
- **subagents-orchestration-guide: Subagent I/O table updates** (skills) — task-executor row carries the full `escalation_type` enum and Fix Mode signal description; quality-fixer row documents `filesModified`; integration-test-reviewer / security-reviewer rows describe Fix Mode routing (security-reviewer routes through a consolidated fix task file)
|
|
40
89
|
- **task-decomposer: English canonical headings in generated tasks** (agents) — Task Structuring step explicitly instructs use of task-template's English headings (`## Target Files`, `## Investigation Targets`, `## Implementation Steps (TDD: Red-Green-Refactor)`, `## Quality Assurance Mechanisms`, `## Operation Verification Methods`, `## Completion Criteria`) with a note that headings are not translated, so executor extraction stays consistent across language environments
|
|
41
90
|
- **task-template: machine-read identifiers preserved as English** (skills) — Section headings and `Metadata:` keys (`Dependencies:`, `Provides:`, `Size:`, `Deliverable:`) kept as English so executor parsing remains language-independent. Body prose remains natural Japanese
|
|
42
|
-
- **
|
|
43
|
-
- **
|
|
44
|
-
- **
|
|
91
|
+
- **Japanese routing markers in agent frontmatter** (agents) — "Use when / Use PROACTIVELY / MUST BE USED PROACTIVELY" rendered as "使用するシーン: / 積極的に使用するシーン: / 必ず積極的に使用するシーン:" in JA agents; keyword pairs that aid routing preserved
|
|
92
|
+
- **Japanese terminology in commands and skills** (commands, skills) — Standardized JA renderings: `step N` → ステップN; `cross-layer` → レイヤー横断; `Layer-Aware Agent Routing` → レイヤー別エージェントルーティング; `INVOKE` → 呼び出す; `consolidated fix task file` → 統合修正タスクファイル; `stub-detection` → 未完成実装検出
|
|
93
|
+
- **Six largest agent files compressed** (agents) — task-executor / -frontend, quality-fixer / -frontend, technical-designer / -frontend reduced in length. All decision criteria, `escalation_type` enum, Fix Mode contract, Gate ordering, and JSON schemas preserved
|
|
45
94
|
|
|
46
95
|
### Fixed
|
|
47
96
|
|
|
48
|
-
- **subagents-orchestration-guide: acceptance-test-generator I/O row
|
|
97
|
+
- **subagents-orchestration-guide: acceptance-test-generator I/O row restored to full contract** (skills) — Row carries `budgetUsage`, `integration: path|null` (was `string`), `e2eAbsenceReason` enum values (`no_multi_step_journey | below_threshold_user_confirmed`), and the "verify files exist" instruction
|
|
49
98
|
- **task-executor / -frontend: typo** (agents) — テスト嚗空化 → テスト空洞化 in Step 2 Quality Standard Violation Check
|
|
50
|
-
- **
|
|
99
|
+
- **Japanese content cleanup** (agents, commands, skills) — Legacy "JSON format is mandatory" boilerplate, "Output Self-Check" sections, "Final response is the JSON output" checklist items, and prior Task Registration wording removed (superseded by the Output Protocol / Self-Validation [BLOCKING] structure also added this release). Spacing around inline contract terms (`ルーティング先のexecutor`, `executorをFix Mode`, `task-template を用いて 統合`) tightened
|
|
51
100
|
|
|
52
101
|
## [1.20.8] - 2026-04-17
|
|
53
102
|
|
package/README.ja.md
CHANGED
|
@@ -135,6 +135,7 @@ Claude Codeで利用できる主要なコマンド
|
|
|
135
135
|
| `/task` | スキルに基づいた単一タスクの実行 | バグ修正、小規模な変更 |
|
|
136
136
|
| `/design` | 設計書の作成 | アーキテクチャの計画時 |
|
|
137
137
|
| `/plan` | 設計書から作業計画書を作成 | 設計承認後 |
|
|
138
|
+
| `/prepare-implementation` | `/build` 実行可能な状態にする(readinessを検証しギャップを解消) | `/build`の前に計画が実装可能であることを担保したいとき |
|
|
138
139
|
| `/build` | 既存の計画から実行 | 作業の再開時 |
|
|
139
140
|
| `/review` | コードの準拠性確認 | 実装完了後 |
|
|
140
141
|
| `/diagnose` | 問題診断ワークフロー | デバッグ、トラブルシューティング |
|
|
@@ -178,9 +179,9 @@ Claude Codeで利用できる主要なコマンド
|
|
|
178
179
|
| `documentation-criteria` | PRD、ADR、Design Doc、UI Spec基準 |
|
|
179
180
|
| `technical-spec` | アーキテクチャ、環境設定、ビルドコマンド |
|
|
180
181
|
| `implementation-approach` | 戦略パターン、タスク分解 |
|
|
181
|
-
| `integration-e2e-testing` |
|
|
182
|
+
| `integration-e2e-testing` | 統合テストと二レーンE2E(fixture-e2e / service-integration-e2e)、ROIベース選択、ジャーニー定義 |
|
|
182
183
|
| `frontend-typescript-rules` | Reactコンポーネント設計、Props駆動パターン |
|
|
183
|
-
| `frontend-typescript-testing` | React Testing Library、MSW、Playwright E2E |
|
|
184
|
+
| `frontend-typescript-testing` | React Testing Library、MSW、Playwright E2E(fixture / service-integrationパターン) |
|
|
184
185
|
| `frontend-technical-spec` | Reactアーキテクチャ、環境設定、データフロー |
|
|
185
186
|
| `project-context` | AIの実行精度のためのプロジェクト前提情報(`/project-inject`で設定) |
|
|
186
187
|
|
package/README.md
CHANGED
|
@@ -135,6 +135,7 @@ Essential commands for Claude Code:
|
|
|
135
135
|
| `/task` | Single task with skill-based precision | Bug fixes, small changes |
|
|
136
136
|
| `/design` | Create design docs only | Architecture planning |
|
|
137
137
|
| `/plan` | Create work plan from design | After design approval |
|
|
138
|
+
| `/prepare-implementation` | Get the plan ready for `/build` (verify readiness and resolve gaps) | Before `/build` to ensure the plan is implementable |
|
|
138
139
|
| `/build` | Execute from existing plan | Resume work |
|
|
139
140
|
| `/review` | Check code compliance | Post-implementation |
|
|
140
141
|
| `/diagnose` | Problem diagnosis workflow | Debugging, troubleshooting |
|
|
@@ -178,9 +179,9 @@ This boilerplate provides the principles used in agentic implementation workflow
|
|
|
178
179
|
| `documentation-criteria` | PRD, ADR, Design Doc, UI Spec standards |
|
|
179
180
|
| `technical-spec` | Architecture, environment, build commands |
|
|
180
181
|
| `implementation-approach` | Strategy patterns, task decomposition |
|
|
181
|
-
| `integration-e2e-testing` | Integration
|
|
182
|
+
| `integration-e2e-testing` | Integration tests and two-lane E2E (fixture-e2e / service-integration-e2e), ROI-based selection, journey definition |
|
|
182
183
|
| `frontend-typescript-rules` | React component design, Props-driven patterns |
|
|
183
|
-
| `frontend-typescript-testing` | React Testing Library, MSW, Playwright E2E |
|
|
184
|
+
| `frontend-typescript-testing` | React Testing Library, MSW, Playwright E2E (fixture and service-integration patterns) |
|
|
184
185
|
| `frontend-technical-spec` | React architecture, environment, data flow |
|
|
185
186
|
| `project-context` | Project-specific prerequisites for AI accuracy (set via `/project-inject`) |
|
|
186
187
|
|
|
@@ -77,9 +77,10 @@ Creates design documents, conducts LLM self-review, requests user review as need
|
|
|
77
77
|
Execute Design → Plan → Build individually. You can work more incrementally by specifying phases directly in the command arguments.
|
|
78
78
|
|
|
79
79
|
```bash
|
|
80
|
-
/design
|
|
81
|
-
/plan
|
|
82
|
-
/
|
|
80
|
+
/design # Create design docs
|
|
81
|
+
/plan # Create work plan
|
|
82
|
+
/prepare-implementation # (Optional) Bring the plan to implement-ready state
|
|
83
|
+
/build implement phase 1 # Execute implementation (with phase specification)
|
|
83
84
|
```
|
|
84
85
|
|
|
85
86
|
## Want to resume work?
|
|
@@ -204,6 +205,20 @@ Use when not adopting the full design-to-implementation process via `/implement`
|
|
|
204
205
|
Creates work plan from Design Doc. Also creates integration/E2E tests required for implementation.
|
|
205
206
|
Use when not adopting the full design-to-implementation process via `/implement`.
|
|
206
207
|
|
|
208
|
+
### /prepare-implementation
|
|
209
|
+
**Purpose**: Bring the work plan to implement-ready state
|
|
210
|
+
**Args**: [work plan path] (optional)
|
|
211
|
+
**Prerequisite**: Approved work plan must exist
|
|
212
|
+
**Process**:
|
|
213
|
+
1. Load work plan and verify five readiness criteria (Verification Strategy references, E2E preconditions, Phase 1 observability, UI rendering surface, local lane procedure)
|
|
214
|
+
2. Generate Phase 0 prep tasks for any failing criteria
|
|
215
|
+
3. User confirmation gate before executing prep tasks
|
|
216
|
+
4. Execute prep tasks via the standard 4-step cycle
|
|
217
|
+
5. Re-scan and promote the work plan's `Implementation Readiness:` header to `ready` or `escalated`
|
|
218
|
+
|
|
219
|
+
Brings the work plan to implement-ready state before `/build`. Resolves gaps via Phase 0 prep tasks (fixture entries, seed scripts, local startup docs, etc.) so the implementation is observable from the first phase, then promotes the readiness marker accordingly. Exits no-op when readiness already holds, so it is safe to invoke unconditionally.
|
|
220
|
+
Use when not adopting the full design-to-implementation process via `/implement`, or when extra confidence in plan readiness is wanted before a long autonomous build run.
|
|
221
|
+
|
|
207
222
|
### /build
|
|
208
223
|
**Purpose**: Automated implementation execution
|
|
209
224
|
**Args**: [task file name] (optional)
|
|
@@ -77,9 +77,10 @@ LLMが規模を自動判定して、必要なドキュメントを作成して
|
|
|
77
77
|
設計 → 計画 → 実装を個別に実行してください。コマンド引数でさらに詳細なフェーズを指定することで、より段階的な作業が可能になります。
|
|
78
78
|
|
|
79
79
|
```bash
|
|
80
|
-
/design
|
|
81
|
-
/plan
|
|
82
|
-
/
|
|
80
|
+
/design # 設計書作成
|
|
81
|
+
/plan # 作業計画作成
|
|
82
|
+
/prepare-implementation # (任意)作業計画書をimplement-readyにする
|
|
83
|
+
/build フェーズ1まで実装して # 実装実行(フェーズ指定)
|
|
83
84
|
```
|
|
84
85
|
|
|
85
86
|
## 途中から実装を再開したいときは?
|
|
@@ -194,6 +195,20 @@ Agentic Coding(LLMが自律的に判断し、実装タスクを遂行する)
|
|
|
194
195
|
Design Docから作業計画書を作成します。また、実装に必要な結合/E2Eテストも同時に作成します。
|
|
195
196
|
`/implement`による設計〜実装の一連のプロセスを採用しない場合に、活用してください。
|
|
196
197
|
|
|
198
|
+
### /prepare-implementation
|
|
199
|
+
**用途**: 作業計画書をimplement-ready状態に持っていく
|
|
200
|
+
**引数**: [作業計画書のパス](省略可)
|
|
201
|
+
**前提**: 承認済みの作業計画書が存在すること
|
|
202
|
+
**実行内容**:
|
|
203
|
+
1. 作業計画書を読み込み、5つのreadiness基準(検証戦略の参照、E2E前提条件、Phase 1の観測性、UI描画面、ローカルレーン手順)を検証
|
|
204
|
+
2. 失敗した基準に対するPhase 0 prepタスクを生成
|
|
205
|
+
3. prepタスク実行前にユーザー確認
|
|
206
|
+
4. 標準4ステップサイクルでprepタスクを実行
|
|
207
|
+
5. 再スキャン後、作業計画書の `Implementation Readiness:` ヘッダを `ready` または `escalated` に昇格
|
|
208
|
+
|
|
209
|
+
`/build` 起動前に作業計画書をimplement-ready状態へ持っていきます。Phase 0 prepタスク(fixtureエントリ、seedスクリプト、ローカル起動手順の文書化等)でギャップを解消することで実装を最初のフェーズから観測可能にし、その結果に応じてreadinessマーカーを昇格させます。readiness基準が既に満たされている場合はno-opで終了するため、無条件に呼び出しても安全です。
|
|
210
|
+
`/implement`による設計〜実装の一連のプロセスを採用しない場合や、長時間の自律build前に計画readinessをより確実にしたい場合に活用してください。
|
|
211
|
+
|
|
197
212
|
### /build
|
|
198
213
|
**用途**: 実装の自動実行
|
|
199
214
|
**引数**: [タスクファイル名](省略可)
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "create-ai-project",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.22.0",
|
|
4
4
|
"packageManager": "npm@10.8.2",
|
|
5
5
|
"description": "TypeScript boilerplate with skills and sub-agents for Claude Code. Prevents context exhaustion through role-based task splitting.",
|
|
6
6
|
"keywords": [
|
|
@@ -51,6 +51,7 @@
|
|
|
51
51
|
"check:fix": "biome check --write src",
|
|
52
52
|
"check:unused": "knip --include exports",
|
|
53
53
|
"check:deps": "dpdm --no-warning --no-tree --exit-code circular:1 --ext .ts --exclude \"__tests__|.test.ts$|.spec.ts$\" --tsconfig ./tsconfig.json -T \"src/**/*.ts\"",
|
|
54
|
+
"check:skills-index": "node scripts/check-skills-index.mjs",
|
|
54
55
|
"check:code": "npm run check && npm run check:unused && npm run check:deps && npm run build",
|
|
55
56
|
"check:all": "npm run check:code && npm run test",
|
|
56
57
|
"cleanup:processes": "bash ./scripts/cleanup-test-processes.sh",
|
|
@@ -0,0 +1,173 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
import { readFile, access } from 'node:fs/promises'
|
|
3
|
+
import { dirname, join, resolve } from 'node:path'
|
|
4
|
+
import { fileURLToPath } from 'node:url'
|
|
5
|
+
|
|
6
|
+
const ROOT = resolve(dirname(fileURLToPath(import.meta.url)), '..')
|
|
7
|
+
const LANGUAGES = ['en', 'ja']
|
|
8
|
+
|
|
9
|
+
function parseSkillsIndex(content) {
|
|
10
|
+
const skills = {}
|
|
11
|
+
const lines = content.split('\n')
|
|
12
|
+
|
|
13
|
+
let currentSkill = null
|
|
14
|
+
let inSections = false
|
|
15
|
+
|
|
16
|
+
for (const line of lines) {
|
|
17
|
+
const skillMatch = /^ {2}([\w-]+):\s*$/.exec(line)
|
|
18
|
+
if (skillMatch) {
|
|
19
|
+
currentSkill = skillMatch[1]
|
|
20
|
+
skills[currentSkill] = { sections: [] }
|
|
21
|
+
inSections = false
|
|
22
|
+
continue
|
|
23
|
+
}
|
|
24
|
+
|
|
25
|
+
if (!currentSkill) continue
|
|
26
|
+
|
|
27
|
+
if (/^ {4}sections:\s*$/.test(line)) {
|
|
28
|
+
inSections = true
|
|
29
|
+
continue
|
|
30
|
+
}
|
|
31
|
+
|
|
32
|
+
if (/^ {4}[\w-]+:/.test(line)) {
|
|
33
|
+
inSections = false
|
|
34
|
+
continue
|
|
35
|
+
}
|
|
36
|
+
|
|
37
|
+
if (inSections) {
|
|
38
|
+
const itemMatch = /^ {6}- "(.*)"\s*$/.exec(line)
|
|
39
|
+
if (itemMatch) {
|
|
40
|
+
skills[currentSkill].sections.push(itemMatch[1])
|
|
41
|
+
}
|
|
42
|
+
}
|
|
43
|
+
}
|
|
44
|
+
|
|
45
|
+
return skills
|
|
46
|
+
}
|
|
47
|
+
|
|
48
|
+
function extractH2Headings(markdown) {
|
|
49
|
+
return markdown
|
|
50
|
+
.split('\n')
|
|
51
|
+
.filter((line) => line.startsWith('## '))
|
|
52
|
+
.map((line) => line.replace(/^## /, '').trim())
|
|
53
|
+
}
|
|
54
|
+
|
|
55
|
+
function diffArrays(expected, actual) {
|
|
56
|
+
const max = Math.max(expected.length, actual.length)
|
|
57
|
+
const mismatches = []
|
|
58
|
+
for (let i = 0; i < max; i++) {
|
|
59
|
+
if (expected[i] !== actual[i]) {
|
|
60
|
+
mismatches.push({ index: i, expected: expected[i] ?? '<missing>', actual: actual[i] ?? '<missing>' })
|
|
61
|
+
}
|
|
62
|
+
}
|
|
63
|
+
return mismatches
|
|
64
|
+
}
|
|
65
|
+
|
|
66
|
+
async function exists(path) {
|
|
67
|
+
try {
|
|
68
|
+
await access(path)
|
|
69
|
+
return true
|
|
70
|
+
} catch {
|
|
71
|
+
return false
|
|
72
|
+
}
|
|
73
|
+
}
|
|
74
|
+
|
|
75
|
+
async function checkLanguage(lang) {
|
|
76
|
+
const skillsDir = join(ROOT, '.claude', `skills-${lang}`)
|
|
77
|
+
const indexPath = join(skillsDir, 'task-analyzer', 'references', 'skills-index.yaml')
|
|
78
|
+
|
|
79
|
+
if (!(await exists(indexPath))) {
|
|
80
|
+
return { lang, skipped: true, reason: `no skills-index.yaml at ${indexPath}`, failed: 0, total: 0, reports: [] }
|
|
81
|
+
}
|
|
82
|
+
|
|
83
|
+
const indexContent = await readFile(indexPath, 'utf8')
|
|
84
|
+
const skills = parseSkillsIndex(indexContent)
|
|
85
|
+
const skillNames = Object.keys(skills)
|
|
86
|
+
|
|
87
|
+
if (skillNames.length === 0) {
|
|
88
|
+
return {
|
|
89
|
+
lang,
|
|
90
|
+
skipped: false,
|
|
91
|
+
failed: 1,
|
|
92
|
+
total: 0,
|
|
93
|
+
reports: [`[${lang}] check-skills-index: no skill entries parsed from skills-index.yaml — parser may be broken`],
|
|
94
|
+
}
|
|
95
|
+
}
|
|
96
|
+
|
|
97
|
+
const reports = []
|
|
98
|
+
let failed = 0
|
|
99
|
+
|
|
100
|
+
for (const name of skillNames) {
|
|
101
|
+
const skillMdPath = join(skillsDir, name, 'SKILL.md')
|
|
102
|
+
let markdown
|
|
103
|
+
try {
|
|
104
|
+
markdown = await readFile(skillMdPath, 'utf8')
|
|
105
|
+
} catch {
|
|
106
|
+
reports.push(`[${lang}] ✗ ${name}: SKILL.md not found at ${skillMdPath} (yaml entry references a non-existent skill)`)
|
|
107
|
+
failed++
|
|
108
|
+
continue
|
|
109
|
+
}
|
|
110
|
+
|
|
111
|
+
const expected = skills[name].sections
|
|
112
|
+
const actual = extractH2Headings(markdown)
|
|
113
|
+
|
|
114
|
+
if (expected.length === 0) {
|
|
115
|
+
reports.push(`[${lang}] - ${name}: dynamic content (no static sections to validate)`)
|
|
116
|
+
continue
|
|
117
|
+
}
|
|
118
|
+
|
|
119
|
+
const mismatches = diffArrays(expected, actual)
|
|
120
|
+
if (mismatches.length === 0) {
|
|
121
|
+
reports.push(`[${lang}] ✓ ${name}: ${expected.length} sections match`)
|
|
122
|
+
} else {
|
|
123
|
+
reports.push(`[${lang}] ✗ ${name}: ${mismatches.length} mismatch(es)`)
|
|
124
|
+
for (const m of mismatches) {
|
|
125
|
+
reports.push(` [${m.index}] yaml: "${m.expected}"`)
|
|
126
|
+
reports.push(` md: "${m.actual}"`)
|
|
127
|
+
}
|
|
128
|
+
failed++
|
|
129
|
+
}
|
|
130
|
+
}
|
|
131
|
+
|
|
132
|
+
return { lang, skipped: false, failed, total: skillNames.length, reports }
|
|
133
|
+
}
|
|
134
|
+
|
|
135
|
+
async function main() {
|
|
136
|
+
let totalFailed = 0
|
|
137
|
+
let totalChecked = 0
|
|
138
|
+
const allReports = []
|
|
139
|
+
|
|
140
|
+
for (const lang of LANGUAGES) {
|
|
141
|
+
const result = await checkLanguage(lang)
|
|
142
|
+
if (result.skipped) {
|
|
143
|
+
allReports.push(`[${lang}] skipped: ${result.reason}`)
|
|
144
|
+
continue
|
|
145
|
+
}
|
|
146
|
+
allReports.push(...result.reports)
|
|
147
|
+
totalFailed += result.failed
|
|
148
|
+
totalChecked += result.total
|
|
149
|
+
}
|
|
150
|
+
|
|
151
|
+
for (const line of allReports) {
|
|
152
|
+
console.log(line)
|
|
153
|
+
}
|
|
154
|
+
|
|
155
|
+
if (totalChecked === 0) {
|
|
156
|
+
console.error('\ncheck-skills-index: no skills checked across any language')
|
|
157
|
+
process.exit(1)
|
|
158
|
+
}
|
|
159
|
+
|
|
160
|
+
if (totalFailed > 0) {
|
|
161
|
+
console.error(`\ncheck-skills-index: ${totalFailed} skill(s) failed`)
|
|
162
|
+
console.error('Either update .claude/skills-<lang>/task-analyzer/references/skills-index.yaml to match the SKILL.md headings,')
|
|
163
|
+
console.error('or update the SKILL.md headings to match the yaml. Order matters.')
|
|
164
|
+
process.exit(1)
|
|
165
|
+
}
|
|
166
|
+
|
|
167
|
+
console.log(`\ncheck-skills-index: all ${totalChecked} skill(s) consistent across ${LANGUAGES.join(', ')}`)
|
|
168
|
+
}
|
|
169
|
+
|
|
170
|
+
main().catch((err) => {
|
|
171
|
+
console.error(err)
|
|
172
|
+
process.exit(1)
|
|
173
|
+
})
|