@einja/dev-cli 0.1.41 → 0.1.44

package/presets/default/.claude/skills/einja-npm-release/SKILL.md

@@ -0,0 +1,242 @@
+---
+name: einja-npm-release
+description: "NPMパッケージ（@einja/dev-cli、create-einja-app）の変更検出・ビルド・テスト・リリースを統合的に実行するSkill。公開、リリース、publish、releaseが必要な場合に使用。"
+user-invocable: true
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - TodoWrite
+  - TodoRead
+  - Task
+  - MCPSearch
+---
+
+# einja-npm-release Skill: NPM パッケージ統合リリースエンジン
+
+## 役割
+
+モノレポ内のNPMパッケージ（`@einja/dev-cli`、`create-einja-app`）の変更を自動検出し、ビルド・テスト・NPM公開を統合的に実行します。
+
+## パッケージ定義テーブル
+
+| キー | `@einja/dev-cli` | `create-einja-app` |
+|------|-------------|-------------------|
+| path | `packages/cli` | `packages/create-einja-app` |
+| pnpm filter | `@einja/dev-cli` | `create-einja-app` |
+| workflow | `release-cli.yml` | `release-create-einja-app.yml` |
+| tag prefix | `cli-v` | `create-einja-app-v` |
+| commit scope | `cli` | `create-einja-app` |
+| build/test | build, test, typecheck | build, test, typecheck, lint |
+
+## 参照ドキュメント
+
+- `packages/cli/RELEASING.md` - @einja/dev-cli リリース手順、トラブルシューティング、NPM_TOKEN設定方法
+- `packages/create-einja-app/RELEASING.md` - create-einja-app リリース手順
+
+## 実行手順
+
+### Step 1: 前提条件の確認
+
+```bash
+git branch --show-current    # mainブランチであること
+git status --porcelain       # 未コミット変更の確認
+```
+
+#### 未コミット変更がある場合
+
+**AskUserQuestion**で対処方法を確認:
+
+- **コミットしてからリリース**: 全ての変更をコミット・プッシュ後にリリース
+- **スタッシュしてリリース**: 変更を一時退避してリリース後に復元
+- **そのままリリース**: 未コミット変更は放置し、**package.jsonのバージョン更新のみ**コミットしてリリース
+
+### Step 2: 変更パッケージの自動検出
+
+各パッケージについて、最新タグからの差分を検出:
+
+```bash
+# @einja/dev-cli: 最新タグ取得
+git tag --list 'cli-v*' --sort=-version:refname | head -1
+
+# create-einja-app: 最新タグ取得
+git tag --list 'create-einja-app-v*' --sort=-version:refname | head -1
+
+# 各パッケージの差分をチェック
+git diff --name-only {latest_tag}..HEAD -- packages/cli/
+git diff --name-only {latest_tag}..HEAD -- packages/create-einja-app/
+```
+
+結果をテーブル表示:
+
+```markdown
+| パッケージ | 現バージョン | 最新タグ | 変更ファイル数 |
+|-----------|------------|---------|-------------|
+| @einja/dev-cli | x.y.z | cli-vx.y.z | N |
+| create-einja-app | x.y.z | create-einja-app-vx.y.z | M |
+```
+
+### Step 3: リリース対象の確認
+
+**AskUserQuestion** で確認:
+
+#### 両方に変更がある場合
+
+```yaml
+question: "どのパッケージをリリースしますか？"
+header: "リリース対象"
+options:
+  - label: "両方リリース（推奨）"
+    description: "@einja/dev-cli (変更N件) と create-einja-app (変更M件) の両方をリリース"
+  - label: "@einja/dev-cli のみ"
+    description: "@einja/dev-cli のみリリース"
+  - label: "create-einja-app のみ"
+    description: "create-einja-app のみリリース"
+```
+
+#### 片方のみ変更がある場合
+
+```yaml
+question: "{パッケージ名} に変更があります。リリースしますか？"
+header: "リリース確認"
+options:
+  - label: "はい"
+    description: "{パッケージ名} をリリースする"
+  - label: "いいえ"
+    description: "リリースをキャンセル"
+```
+
+**注**: 変更がない場合でも「Other」選択肢でリリースできる。
+
+### Step 4: バージョン種別の決定
+
+対象パッケージごとに**AskUserQuestion**:
+
+```yaml
+question: "{パッケージ名} のバージョン種別を選択してください（現在: v{current}）"
+header: "バージョン"
+options:
+  - label: "patch（推奨）"
+    description: "バグ修正・軽微な改善"
+  - label: "minor"
+    description: "後方互換性のある機能追加"
+  - label: "major"
+    description: "破壊的変更"
+```
+
+複数パッケージの場合、順番に確認。
+
+### Step 5: ビルド・テスト
+
+対象パッケージごとに実行（並列実行可能）:
+
+```bash
+# @einja/dev-cli
+pnpm --filter @einja/dev-cli build && pnpm --filter @einja/dev-cli test && pnpm --filter @einja/dev-cli typecheck
+
+# create-einja-app
+pnpm -F create-einja-app build && pnpm -F create-einja-app test && pnpm -F create-einja-app typecheck && pnpm -F create-einja-app lint
+```
+
+### Step 6: バージョン更新・コミット・プッシュ
+
+**順次実行**（gitコミットは直列化が必要）。全パッケージ統一で `--no-git-tag-version` + 手動タグ方式:
+
+```bash
+# 1. バージョン更新（タグなし）
+npm version {type} --no-git-tag-version --prefix {path}
+
+# 2. package.jsonのみコミット
+git add {path}/package.json
+git commit -m "chore({scope}): v{version}にバージョンアップ"
+
+# 3. タグ作成
+git tag {tag_prefix}{version}
+```
+
+全パッケージ分のコミット・タグ作成が完了してから一括プッシュ:
+
+```bash
+git push origin main
+git push origin {tag1}
+git push origin {tag2}  # 2パッケージの場合
+```
+
+task-committer には委託しない（全変更をコミットしてしまうため）。
+
+### Step 7: GitHub Actions 監視・自律修正
+
+対象パッケージごとにワークフローを監視（並列監視可能）:
+
+#### 7.1 監視ループ
+
+```bash
+# 最新のワークフロー実行を取得
+gh run list --workflow={workflow} --limit=1 --json databaseId,status,conclusion
+```
+
+- `status: in_progress` → 30秒待機して再確認
+- `status: completed, conclusion: success` → 成功、Step 8へ
+- `status: completed, conclusion: failure` → 失敗、7.2へ
+
+#### 7.2 失敗時の原因特定
+
+```bash
+gh run view {run_id} --log-failed
+```
+
+#### 7.3 原因別の自律修正
+
+| 原因 | 対処 |
+|------|------|
+| ビルドエラー | コードを修正 |
+| テストエラー | テストを修正 |
+| NPM_TOKEN エラー | ユーザーに設定確認を依頼して終了 |
+| バージョン重複 | 次のpatchバージョンで再実行 |
+
+#### 7.4 修正後の再リリース
+
+**重要**: 同じタグ名は使えないため、バージョンを上げて再リリース
+
+```bash
+# 1. 修正をコミット
+git add {修正ファイル}
+git commit -m "fix({scope}): CIエラーを修正"
+
+# 2. 新しいバージョンに更新
+npm version patch --no-git-tag-version --prefix {path}
+
+# 3. バージョン更新をコミット
+git add {path}/package.json
+git commit -m "chore({scope}): v{new_version}にバージョンアップ"
+
+# 4. 新しいタグを作成・プッシュ
+git tag {tag_prefix}{new_version}
+git push origin main
+git push origin {tag_prefix}{new_version}
+```
+
+#### 7.5 リトライ制限
+
+最大3回まで自動リトライ。3回失敗したらユーザーに報告して終了。
+
+### Step 8: 完了報告
+
+```markdown
+## 📦 NPM パッケージリリース完了
+
+| パッケージ | バージョン | タグ | Actions |
+|-----------|----------|-----|---------|
+| @einja/dev-cli | {old} → {new} | cli-v{version} | ✅ |
+| create-einja-app | {old} → {new} | create-einja-app-v{version} | ✅ |
+
+### 確認コマンド
+npm view @einja/dev-cli
+npm view create-einja-app
+```
+
+---
+
+**最終更新**: 2026-03-04

package/presets/default/.claude/skills/einja-skill-creator/SKILL.md

@@ -60,13 +60,26 @@ Skillが完成した後（順序は柔軟）、Skillのdescription最適化も
 
 ユーザーインタビューに基づいて以下を記入：
 
-- **name**: Skill識別子
+- **name**: Skill識別子。ディレクトリ名と一致させること
+  - インナーSkill（他Skillから内部的に参照される、プロトコル定義、出力テンプレート等）
+    は `_` プレフィックスをつける（例: `_einja-output-format`）
+  - プロジェクト固有のSkillには名前空間プレフィックスをつけない
+  - プロジェクトの名前空間プレフィックスはCLAUDE.mdに定義される
 - **description**: いつトリガーするか、何をするか。主要なトリガーメカニズム。Skillが何をするかと使用する具体的なコンテキストの両方を含める。「いつ使用するか」情報はすべてここに。本文はトリガー後に読み込まれるため、本文の「使用すべき場合」セクションはClaudeに役立たない。注意：現在Claudeはスキルを「アンダートリガー」する傾向がある。対策としてdescriptionを少し「積極的」にする
 - **compatibility**: 必要なツール、依存関係（オプション、まれに必要）
 - **Skillの残りの部分 :)**
 
 ### Skill記述ガイド
 
+#### ディレクトリ命名規則
+
+ディレクトリ名はSkillの配布範囲を決定する:
+- `{namespace}-{name}/` — 配布対象のユーザー向けSkill（例: `einja-task-commit/`）
+- `_{namespace}-{name}/` — 配布対象のインナーSkill（例: `_einja-output-format/`）
+- `{name}/` — プロジェクト固有Skill、配布されない（例: `cli-package-specs/`）
+
+`name` フィールドはディレクトリ名と一致させること。
+
 #### Skillの構造
 
 ```
@@ -207,7 +220,7 @@ Skillドラフト作成後、2-3のリアルなテストプロンプトを作成
 
 ### ステップ3: 実行完了時にタイミングデータをキャプチャ
 
-各サブエージェントタスク完了時、通知に`total_tokens`と`duration_ms`が含まれる。このデータを即座に`timing.json`に保存：
+各サブエージェントタスク完了時、通知に`total_tokens`と`duration_ms`が含まれる。**このデータを即座に`timing.json`に保存**すること — タスク通知は1回限りで、後からバッチ処理できない：
 
 ```json
 {
@@ -221,7 +234,7 @@ Skillドラフト作成後、2-3のリアルなテストプロンプトを作成
 
 全実行完了後：
 
-1. **各実行を採点** — 採点サブエージェントを起動し`agents/grader.md`を読ませて各アサーションを出力に対して評価。`grading.json`に保存。grading.jsonの期待値配列は`text`、`passed`、`evidence`フィールドを使用すること。プログラムでチェック可能なアサーションは、目視ではなくスクリプトを書いて実行。
+1. **各実行を採点** — 採点サブエージェントを起動し`agents/grader.md`を読ませて各アサーションを出力に対して評価。`grading.json`に保存。grading.jsonの期待値配列は `text`、`passed`、`evidence` フィールドを使用すること（`name`/`met`/`details` やその他のバリアントは不可 — ビューアがこの正確なフィールド名に依存している）。プログラムでチェック可能なアサーションは、目視ではなくスクリプトを書いて実行。
 
 2. **ベンチマークに集計** — skill-creatorディレクトリから集計スクリプトを実行：
    ```bash
@@ -250,7 +263,20 @@ Skillドラフト作成後、2-3のリアルなテストプロンプトを作成
 
 ### ステップ5: フィードバックの読み込み
 
-ユーザーが完了を告げたら、`feedback.json`を読む。空のフィードバックはユーザーがOKと判断したことを意味する。具体的な指摘があるテストケースに改善を集中する。
+ユーザーが完了を告げたら、`feedback.json`を読む：
+
+```json
+{
+  "reviews": [
+    {"run_id": "eval-0-with_skill", "feedback": "チャートに軸ラベルがない", "timestamp": "..."},
+    {"run_id": "eval-1-with_skill", "feedback": "", "timestamp": "..."},
+    {"run_id": "eval-2-with_skill", "feedback": "完璧、気に入った", "timestamp": "..."}
+  ],
+  "status": "complete"
+}
+```
+
+空のフィードバックはユーザーがOKと判断したことを意味する。具体的な指摘があるテストケースに改善を集中する。
 
 ビューアサーバーが不要になったらkillする。
 
@@ -303,7 +329,11 @@ SKILL.mdフロントマターのdescriptionフィールドは、ClaudeがSkill
 
 クエリは現実的で、Claude CodeやClaude.aiユーザーが実際にタイプするもの。抽象的ではなく、具体的で詳細なリクエスト。ファイルパス、個人的なコンテキスト、カラム名、会社名、URL等。少しの背景。一部は小文字や略語やタイプミスやカジュアルな話し方。長さを混ぜ、明確なケースよりエッジケースに焦点。
 
-**トリガーすべき**クエリ（8-10個）はカバレッジを考える。**トリガーすべきでない**クエリ（8-10個）はニアミス — キーワードを共有するが実際には異なるものが必要なクエリ。
+**Bad**: `"Format this data"`, `"Extract text from PDF"`, `"Create a chart"` — 抽象的すぎて何もテストしない
+
+**Good**: `"ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think"` — 具体的、カジュアル、背景あり
+
+**トリガーすべき**クエリ（8-10個）はカバレッジを考える。異なるフレーズ、フォーマル/カジュアル混在、スキル名を明示しないが明らかに必要なケース、珍しいユースケース。**トリガーすべきでない**クエリ（8-10個）はニアミス — キーワードを共有するが実際には異なるものが必要なクエリ。「フィボナッチ関数を書いて」のような明らかに無関係なクエリは避ける — テストにならない。
 
 ### ステップ2: ユーザーとレビュー
 
@@ -327,10 +357,11 @@ python -m scripts.run_loop \
   --skill-path <path-to-skill> \
   --model <model-id-powering-this-session> \
   --max-iterations 5 \
+  --holdout 0.4 \
   --verbose
 ```
 
-セッションのモデルIDを使用。60% train / 40% test分割。各クエリ3回実行で信頼性のあるトリガー率を取得。extended thinkingのClaudeで改善を提案。train/testの両方で再評価し、最大5回反復。完了時にHTMLレポートを開き、`best_description`をJSONで返す。
+セッションのモデルIDを使用（`--model`）。`--holdout 0.4`（デフォルト）で60% train / 40% test分割。各クエリ3回実行で信頼性のあるトリガー率を取得。extended thinkingのClaudeで改善を提案（改善専用モデルは`--improve-model`で変更可）。train/testの両方で再評価し、最大5回反復。テストスコアは改善モデルに見せない（blinded_history）ため過学習を防止。完了時にHTMLレポートをブラウザで自動起動し、`best_description`をJSONで返す。`--results-dir <dir>`で全出力をタイムスタンプ付きサブディレクトリに保存可能。
 
 ### スキルトリガーの仕組み
 
@@ -352,11 +383,13 @@ python -m scripts.package_skill <path/to/skill-folder>
 
 ## Claude.ai固有の手順
 
-Claude.aiではサブエージェントがないため：
-- **テスト実行**: 各テストケースを順次に自分で実行。ベースラインはスキップ
-- **結果レビュー**: ブラウザが使えない場合、会話内で直接結果を提示
-- **ベンチマーク**: スキップ
-- **Description最適化**: `claude` CLIが必要なためスキップ
+Claude.aiではサブエージェントがないため、一部の手順を変更する。コアワークフロー（ドラフト→テスト→レビュー→改善→繰り返し）は同じ。
+
+- **テスト実行**: サブエージェントなし＝並列実行不可。各テストケースを順次に自分で実行。これはサブエージェント版より厳密性が低い（スキル作成者がスキル実行者でもあるため完全なコンテキストを持つ）が、有用なサニティチェックであり、人間のレビューステップが補完する。ベースライン実行はスキップ
+- **結果レビュー**: ブラウザが使えない場合、会話内で直接結果を提示。出力がファイルの場合はパスを伝える
+- **ベンチマーク**: スキップ（ベースライン比較がサブエージェントなしでは意味をなさない）
+- **Description最適化**: `claude` CLI（`claude -p`）が必要なためスキップ
+- **ブラインド比較**: サブエージェントが必要。スキップ
 
 ---
 
@@ -364,7 +397,7 @@ Claude.aiではサブエージェントがないため：
 
 - サブエージェントあり、メインワークフロー（テスト並行実行等）は動作する
 - ブラウザがないため、ビューア生成時は`--static <output_path>`を使用
-- フィードバックは`feedback.json`としてダウンロード
+- フィードバックは`feedback.json`としてダウンロード（ファイルアクセスのリクエストが必要な場合がある）
 - テスト実行後は**必ず**`generate_review.py`で評価ビューアを生成してから自己評価すること
 
 ---
@@ -396,6 +429,29 @@ scripts/init_skill.py <skill-name> --path <output-directory>
 scripts/package_skill.py <path/to/skill-folder> [output-directory]
 ```
 
+---
+
+コアループの再掲（見落とし防止）：
+
+- Skillの目的を理解する
+- Skillをドラフトまたは編集する
+- テストプロンプトでSkill付きClaudeを実行する
+- ユーザーと共に出力を評価する：
+  - benchmark.jsonを作成し`eval-viewer/generate_review.py`でユーザーレビューを支援
+  - 定量的評価を実施
+- 満足するまで繰り返す
+- 最終Skillをパッケージ化してユーザーに返す
+
+**TodoList**: ステップを見失わないよう、TodoListが利用可能であればステップを追加すること。特にCowork環境では「evalsのJSONを作成し `eval-viewer/generate_review.py` を実行して人間がテストケースをレビューできるようにする」を必ずTodoListに含める。
+
+### 横断比較ツール（compare_runs.py）
+
+複数スキルの`run_loop.py`出力を横断比較する場合は`compare_runs.py`を使用：
+
+```bash
+python -m scripts.compare_runs result1.json result2.json --verbose --json
+```
+
 <!-- @einja:excluded:start -->
 ## プロジェクト固有セクションの記入