phasegate 0.191.0 → 0.212.0

package/skills/doc-freshness-checker/SKILL.md

@@ -1,140 +0,0 @@
----
-name: doc-freshness-checker
-description: 設計文書の鮮度チェック（L4バリデータ拡張）。`phasegate check-freshness` CLIを使い、設計文書の最終更新日が閾値を超えていないか、コード変更と設計文書の乖離がないかを検出する。使用タイミング: 「設計文書が古くなっていないか確認して」「ドキュメントの鮮度チェックを実行して」「L4 freshness チェック」「設計とコードの乖離を調べて」など。
-model: sonnet
-review: opus
-languages: [typescript]
----
-
-# Doc Freshness Checker
-
-## 目的
-
-設計文書の鮮度（freshness）を検証し、古くなった文書や対応コードとの乖離を検出するスキル。
-`phasegate check-freshness` CLIをラップし、結果を解釈・対処する。
-
-## 前提条件
-
-- `phasegate.config.json` に `docFreshnessThresholds` が設定されていること（未設定時はデフォルト値使用）
-- git リポジトリ内で実行すること（最終更新日は `git log` で判定）
-
-## 入力
-
-- 対象ディレクトリ: `--dir <path>` または `phasegate.config.json` の `constructionDir`（デフォルト `docs/`）
-- 閾値: `--threshold <days>` または `docFreshnessThresholds`（未設定時はデフォルト30日）
-- git 履歴（最終更新日の判定に使用）
-
----
-
-## ⚠️ 2フェーズ実行ルール
-
-- **Phase 1（計画）**: チェック対象スコープを確認し、人間の承認を得る
-- **Phase 2（実行）**: CLIを実行し、結果を解釈してアクションを提案する
-
-**Phase 1/2を同時に実行してはならない。**
-
----
-
-## Phase 1: チェック計画（plan）
-
-### 出力（会話内のみ）
-
-```markdown
-# Doc Freshness チェック計画
-
-## チェック対象スコープ
-- ディレクトリ: {phasegate.config.json の constructionDir、デフォルト: docs/}
-- 閾値: {phasegate.config.json の値 or デフォルト 30日}
-
-## 実行コマンド
-npx phasegate check-freshness [--dir {path}] [--threshold {days}]
-
-## QA
-[Question] Q1: ...
-[Answer]
-```
-
-### Phase 1 完了条件
-- スコープを報告した
-- 人間にボールを渡した
-- **CLIはまだ実行していない**
-
----
-
-## Phase 2: 実行（execution）
-
-### Step 1: CLIの実行
-
-```bash
-npx phasegate check-freshness
-```
-
-オプション:
-- `--dir <path>` — チェック対象ディレクトリ（デフォルト: `phasegate.config.json` の `constructionDir`）
-- `--threshold <days>` — 警告閾値（日数）
-
-### Step 2: 結果の解釈
-
-`CheckDocFreshnessOutput` の構造:
-
-| フィールド | 意味 |
-|-----------|------|
-| `results[].status` | `ok` / `warn` / `error` |
-| `results[].documentPath` | チェック対象ファイルパス |
-| `results[].daysSinceUpdate` | 最終更新からの日数 |
-| `results[].threshold` | 設定閾値 |
-| `summary.error` | エラー件数（即対応必要） |
-| `summary.warn` | 警告件数（確認推奨） |
-
-### Step 3: アクションの提案
-
-| 状態 | 推奨アクション |
-|------|--------------|
-| `error`（閾値超過） | cascade-updater で上位設計文書を更新 |
-| `warn`（閾値近接） | 設計文書の内容確認・必要に応じて更新 |
-| `ok` | 対応不要 |
-
-### 出力フォーマット
-
-```markdown
-# Doc Freshness チェック結果
-
-## サマリー
-- 総ドキュメント数: N
-- ok: N / warn: N / error: N
-
-## 要対応（error）
-| ファイル | 最終更新 | 閾値超過日数 | 推奨アクション |
-|---------|---------|------------|--------------|
-
-## 要確認（warn）
-| ファイル | 最終更新 | 残り日数 |
-|---------|---------|---------|
-
-## 次のアクション
-（errorがある場合は `cascade-updater` の実行を提案）
-```
-
----
-
-## phasegate.config.json 設定例
-
-```json
-{
-  "docFreshnessThresholds": {
-    "domain_model.md": 90,
-    "logical_design.md": 60,
-    "unit_test_design.md": 30,
-    "default": 30
-  }
-}
-```
-
----
-
-## 関連スキル
-
-| スキル | 用途 |
-|-------|------|
-| `cascade-updater` | errorが検出された設計文書の更新 |
-| `consistency-checker` | 文書間整合性の検証（freshness修正後の確認） |

package/skills/implementation-planner/SKILL.md

@@ -1,169 +0,0 @@
----
-name: implementation-planner
-description: "Unit仕様とドメインモデル設計を元に実装計画を立てる。WI IDや機能名から関連Unitを特定し、API設計・レイヤー別実装方針を整理してmdファイルで出力する。使用タイミング: 実装計画を立てて、WI-XXXの実装方針を決めて、この機能の設計を整理して、など実装前の計画策定時。"
-model: sonnet
-review: opus
-languages: [typescript]
----
-
-# Implementation Planner
-
-## 目的
-
-UnitドキュメントとConstructionのドメインモデル設計を元に、**設計フェーズの実装計画**を体系的に立案する。
-
-## ⚠️ `story-implementor` との役割分担
-
-| 観点 | `implementation-planner`（本スキル） | `story-implementor` |
-|------|-------------------------------------|---------------------|
-| **目的** | 設計段階で実装方針を整理・合意する | TDD実装を実行する |
-| **タイミング** | 論理設計の前後（設計の方向性確認） | テスト設計・カバレッジ検証の後 |
-| **出力** | 実装計画書（API設計・レイヤー別方針） | TDD実装計画 → 実装コード |
-| **テスト設計** | 参照しない（設計フェーズのため） | 必須（テスト設計完了が前提） |
-
-**使い分けの指針:**
-- 「この機能どう実装する？」→ `implementation-planner`
-- 「テスト設計も終わった、TDD実装を始めたい」→ `story-implementor`
-
-## ⚠️ 3フェーズ実行ルール
-
-**このスキルは3フェーズで実行する。**
-- **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
-- **Phase 2（実行）**: 委任先モデルに委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
-- **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
-
-**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照（consumer プロジェクトでは `node_modules/phasegate/docs/principles/model-routing.md`、phasegate 自リポジトリでは `docs/principles/model-routing.md` を参照する）。**
-
----
-
-## ワークフロー
-
-## 前提条件チェック（Pre-flight, BLOCKING）
-
-Before generating any plan, verify `docs/inception/{unit}/WI-XXX/description.md` exists.
-If not, halt and ask the user to create the WI first, or offer to run `phasegate scaffold-wi <unit> <story|issue|chore>`.
-
-```
-入力解析 → Unit特定 → ドメインモデル確認 → 既存実装確認 → 計画作成 → 出力
-```
-
-### Step 1: 入力解析
-
-ユーザー入力から抽出:
-- WI ID（WI-XXX形式）
-- 機能名・タスク説明
-- 優先度・制約条件
-
-### Step 2: Unit特定
-
-1. `docs/product/units/integration_contract.md`を読み込み
-2. 関連する公開APIエンドポイントを特定
-3. 該当Unitの`{unit}.md`を確認
-4. Unit間依存関係を整理
-
-**検索方法:**
-- Grep/Globツールを使用して `docs/product/units/` 配下からストーリーIDやキーワードを検索する
-- `integration_contract.md` から関連する公開APIエンドポイントを特定する
-
-### Step 3: ドメインモデル確認
-
-1. `docs/product/construction/{context}/domain_model.md`を読み込み
-2. 以下を把握:
-   - 集約と不変条件
-   - エンティティ・値オブジェクト
-   - ドメインイベント
-   - 状態遷移
-3. 必要に応じて`shared_kernel/domain_model.md`を参照
-
-### Step 4: 既存実装確認
-
-- Glob/Readツールを使用してプロジェクトの実装ディレクトリ構造を確認する
-- 既存の実装パターンを検索し、コードスタイル・ファイル配置を把握する
-
-### Step 5: 計画作成
-
-[references/plan-template.md](references/plan-template.md)のフォーマットに従って:
-1. API設計（新規/既存拡張）
-2. レイヤー別実装内容
-3. 実装ステップ分解
-4. 影響範囲特定
-
-## 出力ファイル
-
-### Step 6: 出力
-
-計画をmdファイルとして出力。パスの推奨:
-```
-docs/inception/{task_id}_plan.md
-docs/inception/{unit}/WI-XXX/tdd_implementation_plan.md
-```
-
-> **パス注記**: 本スキルが扱う設計文書パス（`docs/inception/...` / `docs/product/units/...` / `docs/product/construction/...`）は既定値であり、consumer が `phasegate.config.json` の `paths` 設定で上書きしている場合はそちらが優先される。
-
-**[Question][Answer]セクション必須**: 不明点や確認事項をまとめ、ユーザーからのフィードバックを受け取れるようにする。
-
----
-
-## 入力（参照ドキュメント）
-
-| ファイル | 用途 |
-|----------|------|
-| `docs/product/units/integration_contract.md` | Unit間API定義・依存関係 |
-| `docs/product/units/{unit}.md` | ユーザーストーリー・機能要件 |
-| `docs/product/construction/{context}/domain_model.md` | ドメインモデル設計 |
-
-**詳細は以下を参照:**
-- [document-structure.md](references/document-structure.md): ドキュメント構造リファレンス
-- [workflow.md](references/workflow.md): 詳細ワークフロー
-- [plan-template.md](references/plan-template.md): 出力テンプレート
-
----
-
-## Unit一覧（クイックリファレンス）
-
-実行時に `docs/product/units/` 配下のUnit定義ファイルを動的に読み取ること。ハードコードしない。
-
----
-
-### Phase 2 最低出力基準（Sonnet委任時の品質制約）
-
-以下の基準を満たさない出力は不完全とみなし、Phase 3レビューでBLOCKとする。
-
-| 基準 | 最低要件 |
-|------|---------|
-| Unit特定 | 対象ストーリー/機能に関連するUnitが正しく特定されていること |
-| ドメインモデル参照 | 関連する集約・エンティティ・値オブジェクトが列挙されていること |
-| API設計 | 新規/既存拡張のエンドポイントが具体的に定義されていること |
-| レイヤー別実装内容 | 各層（Domain/UseCase/Controller/Infrastructure）の実装内容が記載されていること |
-| 実装ステップ | 実装順序が具体的なステップに分解されていること |
-| 影響範囲 | 変更が他Unit・他コンポーネントに与える影響が分析されていること |
-| QAセクション | 不明点・確認事項が[Question][Answer]形式で記載されていること |
-
----
-
-## Phase 3: レビュー（Opus review）
-
-### 実行主体
-メインセッション（model-routing.md の Architect ロール）が実行する。Sonnetへの再委任は行わない。
-
-### レビュー手順
-1. Sonnetが出力したファイルを読み込む
-2. `docs/principles/model-routing.md` の「レビュー観点」節に沿って検証する
-3. **スキル固有レビュー観点**を検証する
-4. 判定結果を出力する
-
-### スキル固有レビュー観点（BLOCK基準）
-- [ ] 対象Unit/ドメインモデルの特定が正確か
-- [ ] API設計が統合契約と整合しているか
-- [ ] レイヤー間の依存方向が正しいか（Domain → Port → UseCase → Controller）
-- [ ] 実装ステップの順序が論理的か（依存関係に沿っているか）
-- [ ] 影響範囲の分析が漏れなく行われているか
-
-### 判定と修正
-- **BLOCK項目にFAIL** → Opusが直接修正してから完了とする
-- **WARNのみFAIL** → Opusが直接修正してから完了とする
-- **全PASS** → 完了
-
-## コードベース構成（クイックリファレンス）
-
-実行時にプロジェクトのディレクトリ構造を動的に確認すること。ハードコードしない。

package/skills/implementation-planner/references/document-structure.md

@@ -1,116 +0,0 @@
-# ドキュメント構造リファレンス
-
-## Units ドキュメント (`docs/product/units/`)
-
-各Unitは境界づけられたコンテキストを表す。
-
-| ファイル | 内容 |
-|----------|------|
-| `integration_contract.md` | Unit間連携API定義・技術スタック・依存関係図 |
-| `{unit}_unit.md` | ユーザーストーリー・機能要件・外部依存 |
-
-### integration_contract.md の構造
-
-```
-- 技術スタック概要（Auth/Gateway/API Server/DB/Worker/UI/Realtime）
-- ユニット間依存関係図（Mermaid）
-- 公開APIエンドポイント定義（各Unit）
-- 共通データフォーマット
-- 認証・認可
-```
-
-### Unit一覧
-
-| Unit | 責務 |
-|------|------|
-| IAM Unit | 認証・JWT発行・ユーザー情報 |
-| Admin Unit | ユーザー・チーム管理・権限付与 |
-| Client Unit | クライアント（BPO委託元企業）管理 |
-| Knowledge Unit | クライアントごとの業務ナレッジ管理 |
-| Partner Master Unit | 取引先マスタ管理 |
-| Workflow Dashboard Unit | プロセス一覧・状態管理 |
-| Estimate Unit | 見積書作成プロセス管理（コアドメイン） |
-| Audit Unit | 監査ログ記録・閲覧 |
-
----
-
-## ドメインモデル (`docs/product/construction/`)
-
-各境界づけられたコンテキストのドメイン設計。
-
-### ディレクトリ構成
-
-```
-docs/product/construction/
-├── {context}/domain_model.md    # 各コンテキストのドメインモデル
-├── shared_kernel/domain_model.md # 共有カーネル
-├── architecture_image.md         # アーキテクチャ図
-└── flow_image.md                 # フロー図
-```
-
-### domain_model.md の構造
-
-```
-1. コンテキスト概要
-   - 境界づけられたコンテキスト
-   - ユビキタス言語
-   - コンテキストマップ
-
-2. 集約 (Aggregates)
-   - 集約ルート定義
-   - 不変条件
-   - 状態遷移図
-
-3. エンティティ (Entities)
-
-4. 値オブジェクト (Value Objects)
-
-5. ドメインイベント (Domain Events)
-
-6. ポリシー (Policies)
-
-7. リポジトリ (Repositories)
-
-8. ドメインサービス (Domain Services)
-
-9. クラス図（Mermaid）
-
-10. イベントソーシング実装（該当する場合）
-```
-
----
-
-## コードベース構成
-
-### functions/ (API Server - Cloud Run)
-
-```
-functions/
-├── src/
-│   ├── model/           # ドメインモデル層
-│   ├── usecase/         # ユースケース層
-│   ├── port/            # ポートインターフェース
-│   ├── controller/      # コントローラー層
-│   ├── gateway/         # 外部通信ゲートウェイ
-│   └── infrastructure/  # インフラ層
-└── tests/               # テスト
-```
-
-### hosting/ (Frontend - React)
-
-```
-hosting/
-├── src/
-│   ├── pages/           # ページコンポーネント
-│   ├── components/      # 共通コンポーネント
-│   ├── hooks/           # カスタムフック
-│   └── api/             # API通信
-└── tests/               # テスト
-```
-
-### supabase/ (Edge Functions)
-
-```
-supabase/
-└── functions/           # Edge Functions
-```

package/skills/implementation-planner/references/plan-template.md

@@ -1,177 +0,0 @@
-# 実装計画テンプレート
-
-以下のフォーマットで計画ファイルを出力する。
-
----
-
-```markdown
-# 実装計画: {タスク名}
-
-生成日時: {YYYY-MM-DD HH:mm}
-ステータス: DRAFT / REVIEWING / APPROVED
-
----
-
-## 1. 概要
-
-### 1.1 実装目的
-{何を実現するか、ビジネス価値}
-
-### 1.2 対象ユーザーストーリー
-| ID | ストーリー | 優先度 |
-|----|-----------|--------|
-| US-XXX | ... | MVP/後続 |
-
----
-
-## 2. 関連Unit分析
-
-### 2.1 プライマリUnit
-{メインで影響を受けるUnit}
-
-### 2.2 依存Unit
-| Unit名 | 依存タイプ | 理由 |
-|--------|-----------|------|
-| ... | 参照/イベント発行/API呼び出し | ... |
-
-### 2.3 公開APIエンドポイント
-| Method | Endpoint | 用途 | 新規/既存 |
-|--------|----------|------|----------|
-| ... | ... | ... | ... |
-
----
-
-## 3. ドメインモデル設計
-
-### 3.1 集約
-{対象となる集約とその変更内容}
-
-### 3.2 エンティティ・値オブジェクト
-{新規追加または変更が必要なもの}
-
-### 3.3 ドメインイベント
-| イベント名 | トリガー | ペイロード |
-|-----------|---------|-----------|
-| ... | ... | ... |
-
-### 3.4 ドメインサービス
-{必要な場合のみ}
-
----
-
-## 4. レイヤー別実装方針
-
-### 4.1 Model層
-```
-対象ファイル:
-- functions/src/model/{context}/...
-
-実装内容:
-- ...
-```
-
-### 4.2 UseCase層
-```
-対象ファイル:
-- functions/src/usecase/{context}/...
-
-実装内容:
-- ...
-```
-
-### 4.3 Port層
-```
-対象ファイル:
-- functions/src/port/{context}/...
-
-実装内容:
-- ...
-```
-
-### 4.4 Controller層
-```
-対象ファイル:
-- functions/src/controller/{context}/...
-
-実装内容:
-- ...
-```
-
-### 4.5 Repository層
-```
-対象ファイル:
-- functions/src/infrastructure/repository/...
-
-実装内容:
-- ...
-```
-
-### 4.6 Frontend (必要な場合)
-```
-対象ファイル:
-- hosting/src/pages/...
-- hosting/src/components/...
-
-実装内容:
-- ...
-```
-
----
-
-## 5. 実装ステップ
-
-### Phase 1: ドメインモデル実装
-- [ ] Step 1.1: {具体的なタスク}
-- [ ] Step 1.2: {具体的なタスク}
-
-### Phase 2: UseCase実装
-- [ ] Step 2.1: {具体的なタスク}
-- [ ] Step 2.2: {具体的なタスク}
-
-### Phase 3: API実装
-- [ ] Step 3.1: {具体的なタスク}
-- [ ] Step 3.2: {具体的なタスク}
-
-### Phase 4: テスト
-- [ ] Step 4.1: ユニットテスト作成
-- [ ] Step 4.2: 統合テスト作成
-
----
-
-## 6. 影響範囲と考慮事項
-
-### 6.1 既存コードへの影響
-{変更が必要な既存コード}
-
-### 6.2 マイグレーション
-{DBスキーマ変更がある場合}
-
-### 6.3 リスクと対策
-| リスク | 影響度 | 対策 |
-|--------|-------|------|
-| ... | 高/中/低 | ... |
-
----
-
-## 7. [Question][Answer]
-
-### 未解決の質問
-
-**Q1: {質問内容}**
-> A1: {回答待ち / 回答内容}
-
-**Q2: {質問内容}**
-> A2: {回答待ち / 回答内容}
-
-### 追加情報リクエスト
-- {必要な追加情報1}
-- {必要な追加情報2}
-
----
-
-## 変更履歴
-
-| 日付 | 変更者 | 内容 |
-|-----|-------|------|
-| YYYY-MM-DD | AI | 初版作成 |
-```