phasegate 0.183.0 → 0.212.0

package/skills/release-publisher/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: release-publisher
+kind: advisory
+description: phasegate のリリース手順（version bump / git tag / npm publish）の厳格ガイド。この npm アカウントは security key (FIDO/WebAuthn) 認証のため publish は必ず `npm publish --auth-type=web`。使用タイミング:「リリースして」「publish して」「npm に上げて」「バージョンを上げてタグを打って」「EOTP エラーが出た」「npm publish が認証で失敗する」など、version bump・タグ付与・npm publish・publish 認証トラブルに関わる場面。
+model: sonnet
+review: opus
+languages: [typescript]
+---
+
+# Release Publisher
+
+## 目的
+
+phasegate パッケージのリリース（version bump → git tag → npm publish）を、誤操作・認証事故なしに完遂するための厳格手順ガイド（advisory）。正となる規範は `CLAUDE.md` の「バージョニングルール」「npm publish ルール」節、および `DEVELOPMENT.md` の「Versioning and Release」「Troubleshooting npm publish authentication」節。本スキルはそれらを実行手順として展開する。
+
+## 絶対ルール（違反禁止）
+
+1. **この npm アカウントは security key (FIDO/WebAuthn) 認証**。publish は必ず:
+
+   ```bash
+   npm publish --auth-type=web   # ブラウザで security key 認証 → publish
+   ```
+
+2. **禁止事項**:
+   - `npm publish --otp=<code>` を実行すること（`--otp` フラグは TOTP 専用。security key 認証では拒否される）
+   - ユーザーに OTP を尋ねること
+   - authenticator アプリの参照を提案すること
+3. **EOTP エラーが出たら、OTP を聞き返さずに直ちに `--auth-type=web` に切り替える。**
+4. **コミットごとに `package.json` の minor バージョンを上げる**（`"0.X.0"` → `"0.(X+1).0"`）。タグ `vX.Y.Z` を付与して push する。
+
+## リリース手順
+
+### Step 1: 事前クロスチェック（3点照合）
+
+local の `package.json` は npm registry と乖離しうる（過去に registry v0.32.0 / local v0.38.0 の乖離事例あり）。publish 前に必ず 3 つを照合する:
+
+```bash
+npm view phasegate version       # registry latest
+git tag --list | tail -5         # local tags
+grep '"version"' package.json    # local version
+```
+
+乖離があれば原因（publish 漏れ / tag 漏れ）を特定してから進む。
+
+### Step 2: version bump と CHANGELOG
+
+1. `package.json` の `version` を minor bump（例: `0.5.0` → `0.6.0`）
+2. `CHANGELOG.md` にエントリを追加
+
+### Step 3: commit / tag / push
+
+```bash
+git add package.json CHANGELOG.md
+git commit -m "fix: vX.Y.Z — description"
+git tag vX.Y.Z
+git push origin main --tags
+```
+
+### Step 4: 認証確認と dry-run
+
+```bash
+npm whoami                # 未ログインなら: npm login --auth-type=web
+npm publish --dry-run     # tarball の内容を確認
+```
+
+### Step 5: publish
+
+```bash
+npm publish --auth-type=web
+```
+
+ブラウザが開くので security key で認証すると publish が完了する。
+
+## 認証トラブルシューティング
+
+`npm publish` の挙動はアカウントの 2FA モードに依存する:
+
+| 2FA モード | publish の挙動 | 対処 |
+|---|---|---|
+| 無効 | そのまま通る | `npm publish` |
+| TOTP (authenticator アプリ) | `EOTP` エラー → OTP 要求 | `npm publish --otp=<6桁>` |
+| Email OTP (Enhanced Login Verification) | `EOTP` エラー → メールでコード送付 | 受信箱を確認して `--otp=<6桁>` |
+| **Security key / Passkey (FIDO/WebAuthn)** ← このアカウント | `EOTP` エラー（`--otp` は TOTP 専用のため使用不可） | **`npm publish --auth-type=web`** — ブラウザが開き、キーで認証して publish 完了 |
+
+**security key アカウントの鉄則**: 常に `--auth-type=web` を使う。`--otp` フラグは TOTP 専用であり拒否される。EOTP エラーを見たら OTP を探しに行かず、直ちに `--auth-type=web` で再実行する。
+
+**CI / 自動化**: https://www.npmjs.com/settings/&lt;username&gt;/tokens から **Granular Access Token**（scope: 対象パッケージ、permissions: Read and write、Bypass 2FA: enabled）を発行し、`.npmrc` の `//registry.npmjs.org/:_authToken=<TOKEN>` または `NPM_TOKEN` 環境変数で注入する。
+
+## よくある失敗と回避
+
+| 症状 | 原因 | 回避 |
+|------|------|------|
+| `EOTP` エラーで停止し OTP を探し始める | `--otp` が TOTP 専用であることを知らない | 直ちに `--auth-type=web` に切替（OTP を聞き返さない） |
+| registry と local version の乖離 | publish 漏れ・tag 漏れの蓄積 | Step 1 の 3 点照合を必ず実施 |
+| tag なしで publish | 手順の省略 | Step 3 の tag + `--tags` push を省略しない |
+| CHANGELOG 未更新のまま publish | version bump のみ実施 | Step 2 で CHANGELOG エントリ追加を必ずセットで行う |
+
+## 参照
+
+- `CLAUDE.md` — 「バージョニングルール（必須）」「npm publish ルール（必須）」
+- `DEVELOPMENT.md` — 「Versioning and Release」「Troubleshooting npm publish authentication」「Cross-check before publishing」

package/skills/scenario-test-designer/SKILL.md

@@ -18,9 +18,11 @@ languages: [typescript]
 
 ### 任意インプット（あれば参照）
 - **UIモック** — `/mock/*.html`（画面フローの参考）
-- **テスト規約** — `docs/principles/testing-rules.md`
+- **テスト規約** — `docs/principles/testing-rules.md`（consumer プロジェクトでは `node_modules/phasegate/docs/principles/testing-rules.md`、phasegate リポジトリ自体では `docs/principles/testing-rules.md` を参照）
 - **既存シナリオテスト** — 既存パターンの参考
 
+> **設計文書パスの注記:** 上記および本スキルが扱う `docs/product/construction/{unit}/...` / `docs/inception/...` パスは既定値。consumer が `phasegate.config.json` の paths 設定を上書きしている場合はそちらに従う。
+
 ---
 
 ## ⛔ スキップ禁止
@@ -36,14 +38,18 @@ languages: [typescript]
 ```
 scenario-test-designer（本スキル）← テストケース設計の最初
         ↓
-it-test-designer
+uiux-designer ← シナリオテスト設計を入力にUI/UX定義
         ↓
 unit-test-designer
         ↓
+it-test-designer
+        ↓
 test-coverage-checker ← カバレッジ検証
         ↓
 テストロジック設計
         ↓
+implementation-readiness-checker
+        ↓
 story-implementor ← TDD実装
 ```
 
@@ -96,7 +102,7 @@ story-implementor ← TDD実装
 
 **このスキルは3フェーズで実行する。**
 - **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
-- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
+- **Phase 2（実行）**: 委任先モデルに委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
 - **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
 
 **Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
@@ -168,11 +174,11 @@ story-implementor ← TDD実装
 ## Phase 3: レビュー（Opus review）
 
 ### 実行主体
-メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+メインセッション（model-routing.md の Architect ロール）が実行する。Sonnetへの再委任は行わない。
 
 ### レビュー手順
 1. Sonnetが出力したファイルを読み込む
-2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+2. `docs/principles/model-routing.md` の「レビュー観点」節に沿って検証する
 3. **スキル固有レビュー観点**を検証する
 4. 判定結果を出力する
 
@@ -208,37 +214,44 @@ story-implementor ← TDD実装
 
 ## 次ステップへの誘導
 
-シナリオテストケース設計完了後、以下の順序で進めてください：
+シナリオテストケース設計はテストケース設計フェーズの最初に位置づけられる（成果物 `scenario_test_design.md` は `uiux-designer` の必須インプット）。完了後、以下の順序で進めてください：
 
-### テストケース設計フェーズ（続き）
-1. **ITテストケース設計** — UseCase/Repository/Controllerのテストケース
-   - `it-test-designer` スキルを実行
+### UI/UX設計フェーズ
+1. **UI/UX定義** — シナリオテスト設計・論理設計・既存UIを加味した最終UI/UX策定
+   - `uiux-designer` スキルを実行
 
+### テストケース設計フェーズ（続き）
 2. **ユニットテストケース設計** — Entity/ValueObjectのテストケース
    - `unit-test-designer` スキルを実行
+3. **ITテストケース設計** — UseCase/Repository/Controllerのテストケース
+   - `it-test-designer` スキルを実行
 
 ### カバレッジ検証フェーズ
-3. **テストカバレッジ検証** — テストケース設計の網羅性チェック
+4. **テストカバレッジ検証** — テストケース設計の網羅性チェック
    - `test-coverage-checker` スキルを実行
    - カバレッジ90%以上を確認
 
 ### テストロジック設計フェーズ
-4. **テストロジック設計** — 各レベルの実装ロジック
+5. **テストロジック設計** — 各レベルの実装ロジック
    - `unit-test-logic-designer` → `it-test-logic-designer` → `scenario-test-logic-designer`
 
 ### TDD実装フェーズ
-5. **TDD実装** — Unit → IT → E2E の順序で実装
-   - `story-implementor` スキルを実行
+6. **実装準備検証・TDD実装** — Unit → IT → E2E の順序で実装
+   - `implementation-readiness-checker` → `story-implementor` スキルを実行
 
 **推奨フロー図:**
 ```
 scenario-test-designer（本スキル）
         ↓
-it-test-designer → unit-test-designer
+uiux-designer
+        ↓
+unit-test-designer → it-test-designer
         ↓
 test-coverage-checker
         ↓
 *-test-logic-designer（各レベル）
         ↓
+implementation-readiness-checker
+        ↓
 story-implementor
 ```

package/skills/scenario-test-logic-designer/SKILL.md

@@ -14,7 +14,7 @@ languages: [typescript]
 
 ```
 テストケース設計フェーズ
-  unit-test-designer → it-test-designer → scenario-test-designer
+  scenario-test-designer → uiux-designer → unit-test-designer → it-test-designer
                           ↓
               test-coverage-checker
                           ↓
@@ -25,7 +25,7 @@ languages: [typescript]
 └────────────────────────────────────────────┘
                           ↓
 TDD実装フェーズ
-  story-implementor
+  implementation-readiness-checker → story-implementor
 ```
 
 ## 前提条件チェック
@@ -36,9 +36,11 @@ TDD実装フェーズ
 
 ### 推奨インプット（あれば参照）
 - **カバレッジレポート** — `docs/product/construction/{unit}/coverage_report.md`
-- **既存シナリオテスト** — `e2e/tests/**/*.spec.ts`（パターン参考）
+- **既存シナリオテスト** — 対象プロジェクトの構成（package.json scripts, playwright 設定, `phasegate.config.json` の paths）からテスト配置を特定してパターン参考にする。例（モノレポ構成の場合）: `e2e/tests/**/*.spec.ts`
 - **UIUX設計** — `docs/inception/{unit}/{story_id}/uiux_design.md`
-- **テスト規約** — `docs/principles/testing-rules.md`
+- **テスト規約** — `docs/principles/testing-rules.md`（consumer プロジェクトでは `node_modules/phasegate/docs/principles/testing-rules.md`、phasegate リポジトリ自体では `docs/principles/testing-rules.md` を参照）
+
+> **設計文書パスの注記:** 本スキルが扱う `docs/product/construction/{unit}/...` / `docs/inception/...` パスは既定値。consumer が `phasegate.config.json` の paths 設定を上書きしている場合はそちらに従う。
 
 ---
 
@@ -63,7 +65,7 @@ TDD実装フェーズ
 ## ⚠️ 3フェーズ実行ルール
 
 - **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
-- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
+- **Phase 2（実行）**: 委任先モデルに委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
 - **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
 
 **Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
@@ -184,11 +186,11 @@ TDD実装フェーズ
 ## Phase 3: レビュー（Opus review）
 
 ### 実行主体
-メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+メインセッション（model-routing.md の Architect ロール）が実行する。Sonnetへの再委任は行わない。
 
 ### レビュー手順
 1. Sonnetが出力したファイルを読み込む
-2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+2. `docs/principles/model-routing.md` の「レビュー観点」節に沿って検証する
 3. **スキル固有レビュー観点**を検証する
 4. 判定結果を出力する
 
@@ -225,7 +227,7 @@ Phase 2 で設計するシナリオ / E2E テストファイル（`*.spec.ts` /
 - **テストコードは生成しない**（設計文書のみ）— 実装は `story-implementor` スキル（codex-delegator経由、またはメインセッションで直接実行）が行う
 - 疑似コードは実装の指針となる詳細レベルで記載する
 - TDDの「RED」フェーズで正しく失敗するテストを設計する
-- 既存のテストパターン（`e2e/tests/**/*.spec.ts`）を参照してスタイルを統一する
+- 既存のテストパターンを参照してスタイルを統一する（テスト配置は対象プロジェクトの構成から特定する。例（モノレポ構成の場合）: `e2e/tests/**/*.spec.ts`）
 - クリーンアップを確実に行い、テスト間の独立性を保つ
 
 ---

package/skills/scenario-test-logic-designer/references/msw-patterns.md

@@ -2,12 +2,14 @@
 
 scenario-test-logic-designer スキルで使用する MSW (Mock Service Worker) パターンのリファレンス。
 
+> **配置パスについて:** 以下のモック配置ディレクトリ（`e2e/mocks/` 等）は対象プロジェクトの構成（`package.json` scripts, playwright 設定, `phasegate.config.json` の paths）から特定すること。本ファイルの具体値は例（モノレポ構成の場合）であり、テンプレート構造自体はそのまま流用してよい。
+
 ---
 
 ## ハンドラー テンプレート
 
 ```typescript
-// e2e/mocks/{context}/handlers.ts
+// 例（モノレポ構成の場合）: e2e/mocks/{context}/handlers.ts
 import { http, HttpResponse } from 'msw';
 
 export const {context}Handlers = [

package/skills/scenario-test-logic-designer/references/playwright-patterns.md

@@ -186,7 +186,7 @@ export const {SEED_NAME}_SEED = {
 };
 
 export async function seed{SeedName}(): Promise<void> {
-  // Supabase CLIまたはAPIでデータ投入
+  // プロジェクトが採用する DB/BaaS のツール・APIでデータ投入（例: Supabase CLI/API）
 }
 
 export async function cleanup{SeedName}(): Promise<void> {
@@ -222,6 +222,8 @@ export async function create{Entity}(page: Page, data: {Entity}Data): Promise<st
 
 ## 8. テスト実行コマンド
 
+実行コマンドは対象プロジェクトの構成（`package.json` scripts, playwright 設定, `phasegate.config.json` の paths）から特定する。以下は例（pnpm モノレポ構成の場合）。
+
 ```bash
 # 全シナリオテスト実行
 pnpm --filter e2e test