phasegate 0.191.0 → 0.222.0

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 | 初版作成 |
-```

package/skills/implementation-planner/references/workflow.md

@@ -1,164 +0,0 @@
-# 実装計画ワークフロー
-
-## フェーズ1: 要件理解
-
-### Step 1.1: 入力の整理
-ユーザー入力から以下を抽出:
-- 実装対象（ストーリーID、機能名、タスク説明）
-- 優先度・制約条件
-
-### Step 1.2: ストーリー確認
-ユーザーストーリーが指定されている場合:
-```bash
-# US-XXXの場合、以下のファイルを検索
-grep -r "US-XXX" docs/product/units/
-```
-
----
-
-## フェーズ2: Unit特定
-
-### Step 2.1: integration_contract.md確認
-```
-Read: docs/product/units/integration_contract.md
-```
-以下を把握:
-- 関連しそうなUnit
-- そのUnitの公開API
-- 依存関係
-
-### Step 2.2: 関連Unit仕様確認
-```
-Read: docs/product/units/{unit}_unit.md
-```
-各Unitファイルから:
-- 担当ユーザーストーリー
-- 機能要件
-- 外部依存
-
-### Step 2.3: Unit間依存の整理
-Mermaid図を参照し、以下を特定:
-- データの流れ
-- イベント発行先
-- 参照関係
-
----
-
-## フェーズ3: ドメインモデル確認
-
-### Step 3.1: プライマリコンテキスト確認
-```
-Read: docs/product/construction/{context}/domain_model.md
-```
-以下を把握:
-- 集約とその責務
-- エンティティ・値オブジェクト
-- ドメインイベント
-- 状態遷移
-
-### Step 3.2: 関連コンテキスト確認
-依存先のdomain_model.mdを確認:
-- 共有カーネルの定義
-- 参照するエンティティ
-
-### Step 3.3: 設計パターン確認
-```
-Read: docs/product/construction/shared_kernel/domain_model.md
-```
-共通で使用する型・パターンを把握
-
----
-
-## フェーズ4: 既存実装確認
-
-### Step 4.1: ディレクトリ構造確認
-```bash
-ls -la functions/src/model/{context}/
-ls -la functions/src/usecase/{context}/
-ls -la functions/src/controller/{context}/
-```
-
-### Step 4.2: 関連コード検索
-```bash
-# 関連するクラス・関数を検索
-grep -r "ClassName" functions/src/
-grep -r "usecaseName" functions/src/
-```
-
-### Step 4.3: 既存パターン把握
-同コンテキストの既存実装からパターンを学習:
-- Model定義方法
-- UseCase構造
-- Controller実装
-- Repository実装
-
----
-
-## フェーズ5: 計画作成
-
-### Step 5.1: API設計
-integration_contract.mdを参照し:
-- 新規APIか既存APIの拡張か判断
-- エンドポイント設計
-- リクエスト/レスポンス設計
-
-### Step 5.2: レイヤー別実装内容決定
-Clean Architectureに従い:
-1. Model層: ドメインモデル実装
-2. UseCase層: ビジネスロジック
-3. Port層: インターフェース定義
-4. Controller層: API実装
-5. Repository層: データアクセス
-
-### Step 5.3: 実装ステップ分解
-依存関係を考慮して順序付け:
-1. ドメインモデル（依存なし）
-2. Port定義
-3. UseCase実装
-4. Repository実装
-5. Controller実装
-6. テスト
-
-### Step 5.4: 影響範囲特定
-- 既存コードの変更箇所
-- DBマイグレーション要否
-- フロントエンド変更要否
-
----
-
-## フェーズ6: 出力と確認
-
-### Step 6.1: 計画ファイル出力
-`references/plan-template.md`の形式で出力
-
-### Step 6.2: 質問整理
-不明点を[Question][Answer]セクションにまとめ
-
-### Step 6.3: ユーザー確認
-計画をユーザーに提示し、フィードバックを収集
-
----
-
-## 探索パターン
-
-### パターン1: ストーリーID指定
-```
-1. grep "US-XXX" docs/product/units/*.md
-2. 該当Unit特定
-3. domain_model確認
-4. 既存コード確認
-```
-
-### パターン2: 機能名指定
-```
-1. integration_contract.mdのAPI定義検索
-2. 関連Unit特定
-3. 以降同様
-```
-
-### パターン3: 技術タスク指定
-```
-1. constructionディレクトリから関連コンテキスト特定
-2. Unit仕様確認
-3. 既存コード確認
-```

package/skills/pointer-validator/SKILL.md

@@ -1,105 +0,0 @@
----
-name: pointer-validator
-kind: advisory
-description: 設計文書内のファイルポインタ（相対パス参照）の有効性を検証するスキル（L4バリデータ拡張）。`phasegate validate-pointers` CLIを使い、ドキュメント内で参照されているファイルパスが実際に存在するかチェックする。使用タイミング: 「ドキュメントのリンク切れを確認して」「ポインタ検証を実行して」「broken pointer を探して」「設計文書の参照が正しいか確認して」など。
-model: sonnet
-review: opus
-languages: [typescript]
----
-
-# Pointer Validator
-
-## 目的
-
-設計文書内のファイルパス参照（ポインタ）の有効性を検証するスキル。
-`phasegate validate-pointers` CLIをラップし、broken pointer を検出・修正案を提示する。
-
-## 入力
-
-- 対象ディレクトリ: `--dir <path>`（デフォルト `docs/`）配下の設計文書
-- 検証対象ポインタ: Markdown `[text](path)` リンク / `@file:` `@ref:` / `filePath:` フィールドのパス参照（`http(s)://` URL は対象外）
-
-## CLIの動作
-
-`p2:validate-pointers` は以下を検出する:
-- Markdownの `[text](path)` 形式のリンク
-- `@file:` / `@ref:` 形式のポインタ
-- `filePath:` YAML/JSON フィールド内のパス参照
-- URLポインタはスキップ（`http://` / `https://` は検証対象外）
-
----
-
-## ワークフロー（単一フェーズ）
-
-このスキルは軽量チェックのため単一フェーズで実行する。
-
-### Step 1: CLIの実行
-
-```bash
-npx phasegate validate-pointers
-```
-
-オプション:
-- `--dir <path>` — スキャン対象ディレクトリ（デフォルト: `docs/`）
-- `--fix` — 自動修正可能なポインタを修正（要確認）
-
-### Step 2: 結果の解釈
-
-`ValidateDocPointersOutput` の構造:
-
-| フィールド | 意味 |
-|-----------|------|
-| `results[].documentPath` | ポインタを含む文書ファイル |
-| `results[].pointerTarget` | 参照先パス |
-| `results[].pointerType` | `file-path` / `url` |
-| `results[].isResolvable` | 解決可能かどうか |
-| `results[].errorMessage` | エラー内容（nullなら正常） |
-| `summary.brokenPointers` | broken件数 |
-| `summary.skippedUrlPointers` | URLスキップ件数 |
-| `passed` | 全ポインタ有効ならtrue |
-
-### Step 3: 修正戦略の判断
-
-| broken原因 | 推奨アクション |
-|-----------|--------------|
-| ファイルが移動された | ポインタのパスを新パスに更新 |
-| ファイルが削除された | ポインタを削除 or 代替ファイルに変更 |
-| タイポ | パス修正 |
-| 未作成ファイルへの参照 | 意図的な前方参照として `[TODO]` マーカーを追加 |
-
-### 出力フォーマット
-
-```markdown
-# Pointer Validation 結果
-
-## サマリー
-- チェックドキュメント数: N
-- 総ポインタ数: N
-- broken: N / URL(スキップ): N
-
-## Broken Pointers（要修正）
-| 文書ファイル | 参照先 | エラー | 推奨修正 |
-|------------|--------|--------|---------|
-
-## 次のアクション
-（brokenがある場合）
-1. 上記テーブルの broken pointer を修正
-2. `npx phasegate validate-pointers` を再実行して0件を確認
-```
-
----
-
-## 注意事項
-
-- URL（`http://` / `https://`）は検証対象外（ネットワーク依存を避けるため）
-- `--fix` オプションは明確な移動・リネームのみ自動修正。曖昧なケースはスキップ
-- broken件数 > 50 の場合は `--dir` でスコープを絞って段階的に対処する
-
----
-
-## 関連スキル
-
-| スキル | 用途 |
-|-------|------|
-| `doc-freshness-checker` | 設計文書の鮮度チェック（セットで実行推奨） |
-| `consistency-checker` | 文書間の内容整合性チェック |