create-ai-project 1.12.0 → 1.13.0

package/.claude/skills/documentation-criteria/SKILL.md

@@ -1,193 +0,0 @@
----
-name: documentation-criteria
-description: PRD、ADR、Design Doc、作業計画書を含むドキュメント作成基準とテンプレート。
----
-
-# ドキュメント作成基準
-
-## 作成判定マトリクス
-
-| 条件 | 必要ドキュメント | 作成順序 |
-|-----|--------------|---------|
-| 新機能追加 | PRD → [ADR] → Design Doc → 作業計画書 | PRD承認後 |
-| ADR条件該当（下記参照） | ADR → Design Doc → 作業計画書 | 即座に開始 |
-| 6ファイル以上 | ADR → Design Doc → 作業計画書（必須） | 即座に開始 |
-| 3-5ファイル | Design Doc → 作業計画書（推奨） | 即座に開始 |
-| 1-2ファイル | なし | 直接実装 |
-
-## ADR作成条件（いずれか該当で必須）
-
-### 1. 型システム変更
-- **3階層以上のネスト型追加**: `type A = { b: { c: { d: T } } }`
-  - 判断理由: 深いネストは複雑性が高く、影響範囲が広い
-- **3箇所以上で使用される型の変更・削除**
-  - 判断理由: 複数箇所への影響は慎重な判断が必要
-- **型の責務変更**（例: DTO→Entity）
-  - 判断理由: 概念モデルの変更は設計思想に関わる
-
-### 2. データフロー変更
-- **保存場所変更**（DB→ファイル、メモリ→キャッシュ）
-- **3ステップ以上の処理順序変更**
-  - 例: 「入力→検証→保存」から「入力→保存→非同期検証」
-- **データ受け渡し方法変更**（props→Context、直接参照→イベント）
-
-### 3. アーキテクチャ変更
-- レイヤー追加・責務変更・コンポーネント再配置
-
-### 4. 外部依存変更
-- ライブラリ・フレームワーク・外部API導入・置換
-
-### 5. 複雑な実装ロジック（規模に関わらず）
-- 3つ以上の状態を管理
-- 5つ以上の非同期処理の連携
-
-## 各ドキュメントの詳細定義
-
-### PRD（Product Requirements Document）
-
-**目的**: ビジネス要件とユーザー価値を定義
-
-**含むもの**:
-- ビジネス要件とユーザー価値
-- 成功指標とKPI（測定可能な形式）
-- ユーザーストーリーとユースケース
-- MoSCoW法による優先順位（Must/Should/Could/Won't）
-- MVPとFutureフェーズの分離
-- ユーザージャーニー図（必須）
-- スコープ境界図（必須）
-
-**含まないもの**:
-- 技術実装詳細（→Design Doc）
-- 技術選定理由（→ADR）
-- **実装フェーズ**（→作業計画書）
-- **タスク分解**（→作業計画書）
-
-### ADR（Architecture Decision Record）
-
-**目的**: 技術的決定の理由と背景を記録
-
-**含むもの**:
-- 決定事項（何を選択したか）
-- 根拠（なぜその選択をしたか）
-- 選択肢の比較（最低3案）とトレードオフ
-- アーキテクチャへの影響
-- 実装への原則的な指針（例:「依存性注入を使用」）
-
-**含まないもの**:
-- 実装スケジュール、期間（→作業計画書）
-- 実装手順の詳細（→Design Doc）
-- 具体的なコード例（→Design Doc）
-- 担当者の割り当て（→作業計画書）
-
-### Design Document
-
-**目的**: 技術的実装方法を詳細定義
-
-**含むもの**:
-- **既存コードベース分析**（必須）
-  - 実装パスマッピング（既存と新規の両方を記載）
-  - 統合点の明確化（新規実装でも既存との接続点を記載）
-- 技術的実装アプローチ（垂直/水平/ハイブリッド）
-- **技術的依存関係と実装制約**（実装の必要順序）
-- インターフェース定義と型定義
-- データフローとコンポーネント設計
-- **統合ポイントでのE2E確認手順**
-- **受入条件（EARS形式: When/While/If-then/無印）**
-- 変更影響マップ（直接影響/間接影響/波及なしを明記）
-- 統合点の完全な列挙
-- データ契約の明確化
-- **合意事項チェックリスト**（関係者との合意内容）
-- **前提となるADR**（共通ADR含む）
-
-**必須構造要素**:
-```yaml
-変更影響マップ:
-  変更対象: [コンポーネント/機能]
-  直接影響: [ファイル/関数]
-  間接影響: [データ形式/処理時間]
-  波及なし: [影響を受けない機能]
-
-インターフェース変更マトリクス:
-  既存: [メソッド名]
-  新規: [メソッド名]
-  変換必要性: [あり/なし]
-  互換性確保: [方法]
-```
-
-**含まないもの**:
-- なぜその技術を選んだか（→ADR参照）
-- いつ実装するか、期間（→作業計画書）
-- 誰が実装するか（→作業計画書）
-
-### 作業計画書
-
-**目的**: 実装タスクの管理と進捗追跡
-
-**含むもの**:
-- **フェーズ構成**（Design Docの技術的依存関係を基に作成）
-- タスク分解と依存関係（最大2階層まで）
-- スケジュールと期間見積もり
-- **Design DocのE2E確認手順を各フェーズに配置**
-- **最終フェーズに品質保証を含む**（必須）
-- 進捗記録（チェックボックス形式）
-
-**含まないもの**:
-- 技術的な根拠（→ADR）
-- 設計の詳細（→Design Doc）
-- 技術的依存関係の決定（→Design Doc）
-
-**タスク完了定義の3要素**:
-1. **実装完了**: コードが動作する
-2. **品質完了**: テスト・型チェック・リントがパス
-3. **統合完了**: 他コンポーネントとの連携確認
-
-## 作成プロセス
-
-1. **問題分析**: 変更規模判定、ADR条件確認
-2. **ADR選択肢検討**（ADR時のみ）: 3案以上比較、トレードオフ明記
-3. **作成**: テンプレート使用、測定可能な条件記載
-4. **承認**: レビュー後「Accepted」で実装可
-
-## 保存場所
-
-| ドキュメント | パス | 命名規則 | テンプレート |
-|------------|-----|---------|------------|
-| PRD | `docs/prd/` | `[機能名]-prd.md` | `prd-template.md` |
-| ADR | `docs/adr/` | `ADR-[4桁]-[タイトル].md` | `adr-template.md` |
-| Design Doc | `docs/design/` | `[機能名]-design.md` | `design-template.md` |
-| 作業計画書 | `docs/plans/` | `YYYYMMDD-{type}-{description}.md` | `plan-template.md` |
-
-※作業計画書は`.gitignore`で除外
-
-## ADRステータス
-`Proposed` → `Accepted` → `Deprecated`/`Superseded`/`Rejected`
-
-## AI自動化ルール
-- 5ファイル以上: ADR作成提案
-- 型・データフロー変更検出: ADR必須化
-- 既存ADR確認してから実装
-
-## 図表作成要件
-
-各ドキュメントで必須の図表（mermaid記法使用）：
-
-| ドキュメント | 必須図表 | 目的 |
-|------------|---------|-----|
-| PRD | ユーザージャーニー図、スコープ境界図 | ユーザー体験と範囲の明確化 |
-| ADR | 選択肢比較図（必要時） | トレードオフの視覚化 |
-| Design Doc | アーキテクチャ図、データフロー図 | 技術構造の理解 |
-| 作業計画書 | フェーズ構成図、タスク依存関係図 | 実装順序の明確化 |
-
-## 共通ADRとの関係性
-1. **作成時**: 共通技術領域（ログ、エラーハンドリング、非同期処理等）を特定し、既存共通ADRを参照
-2. **不足時**: 必要な共通ADRが存在しない場合は作成を検討
-3. **Design Doc**: 「前提となるADR」セクションで共通ADRを明記
-4. **準拠確認**: 設計が共通ADRの決定事項と整合しているかを検証
-
-## テンプレート
-
-テンプレートは`references/`ディレクトリにあります：
-- [Design Documentテンプレート](references/design-template.md)
-- [PRDテンプレート](references/prd-template.md)
-- [作業計画書テンプレート](references/plan-template.md)
-- [ADRテンプレート](references/adr-template.md)

package/.claude/skills/documentation-criteria/references/adr-template.md

@@ -1,64 +0,0 @@
-# [ADR番号] [タイトル]
-
-## ステータス
-
-[Proposed | Accepted | Deprecated | Superseded]
-
-## 経緯
-
-[この決定が必要になった背景と理由を説明。問題の本質、現在の課題、制約を含む]
-
-## 決定事項
-
-[実際に行った決定を説明。具体的で明確な記述を心がける]
-
-### 決定の詳細
-
-| 項目 | 内容 |
-|-----|-----|
-| **決定** | [一文で決定内容] |
-| **なぜ今か** | [今このタイミングで必要な理由] |
-| **なぜこれか** | [代替案との比較理由（1-3行）] |
-| **既知の不確実性** | [現時点で少なくとも1つの不確実性] |
-| **撤回基準** | [この決定を見直すべきシグナル1つ] |
-
-## 根拠
-
-[なぜこの決定を行ったか、代替案と比較して最善である理由を説明]
-
-### 検討した選択肢
-
-1. **選択肢1**: [説明]
-   - メリット: [利点をリストアップ]
-   - デメリット: [欠点をリストアップ]
-
-2. **選択肢2**: [説明]
-   - メリット: [利点をリストアップ]
-   - デメリット: [欠点をリストアップ]
-
-3. **選択肢3（採用）**: [説明]
-   - メリット: [利点をリストアップ]
-   - デメリット: [欠点をリストアップ]
-
-## 影響
-
-### ポジティブな影響
-
-- [プロジェクトやシステムへの良い影響をリストアップ]
-
-### ネガティブな影響
-
-- [受け入れる必要のある負の影響やトレードオフをリストアップ]
-
-### 中立的な影響
-
-- [良くも悪くもない変化をリストアップ]
-
-## 実装指針
-
-[原則的な方向性のみ。実装手順はDesign Docへ]
-例: 「依存性注入を使用」○、「Phase 1で実装」×
-
-## 関連情報
-
-- [関連するADR、ドキュメント、Issue、PRなどへのリンク]

package/.claude/skills/documentation-criteria/references/design-template.md

@@ -1,242 +0,0 @@
-# [機能名] 設計書
-
-## 概要
-
-[この機能の目的と概要を2-3文で説明]
-
-## 設計サマリー（メタ）
-
-```yaml
-design_type: "新機能|拡張|リファクタリング"
-risk_level: "低|中|高"
-main_constraints:
-  - "[制約1]"
-  - "[制約2]"
-biggest_risks:
-  - "[リスク1]"
-  - "[リスク2]"
-unknowns:
-  - "[不確実性1]"
-  - "[不確実性2]"
-```
-
-## 背景と経緯
-
-### 前提となるADR
-
-- [ADRファイル名]: [関連する決定事項]
-- 共通技術ADRも該当する場合は参照
-
-### 合意事項チェックリスト
-
-#### スコープ
-- [ ] [変更対象の機能/コンポーネント]
-- [ ] [追加する機能]
-
-#### スコープ外（明示的に変更しないもの）
-- [ ] [変更しない機能/コンポーネント]
-- [ ] [維持する既存ロジック]
-
-#### 制約
-- [ ] 並行運用: [する/しない]
-- [ ] 後方互換性: [必要/不要]
-- [ ] パフォーマンス計測: [必要/不要]
-
-### 解決すべき課題
-
-[この機能が解決しようとする具体的な問題や課題]
-
-### 現状の課題
-
-[現在のシステムの問題点や制限事項]
-
-### 要件
-
-#### 機能要件
-
-- [必須の機能要件をリストアップ]
-
-#### 非機能要件
-
-- **パフォーマンス**: [レスポンス時間、スループットの要件]
-- **スケーラビリティ**: [負荷増大時の対応要件]
-- **信頼性**: [エラー率、可用性の要件]
-- **保守性**: [コードの可読性、変更容易性]
-
-## 受入条件（AC）- EARS形式
-
-各ACはEARS形式で記述。キーワードがテストタイプを決定。
-
-### [機能要件1]
-
-- [ ] **When** ユーザーが有効な認証情報でログインボタンをクリックすると、システムは認証を行いダッシュボードにリダイレクトする
-- [ ] **If** 認証情報が無効な場合、**then** システムはエラーメッセージ「認証情報が無効です」を表示する
-- [ ] **While** ユーザーがログインしている間、システムはセッションを60分間維持する
-
-### [機能要件2]
-
-- [ ] システムはデータリストを1ページ10件のページネーション付きで表示する
-- [ ] **When** 検索フィールドに入力すると、システムはリアルタイムでフィルタリングを適用する
-  - **Property**: `filtered.every(item => item.name.includes(query))`
-
-## 既存コードベース分析
-
-### 実装パスマッピング
-| 種別 | パス | 説明 |
-|-----|-----|-----|
-| 既存 | src/[実際のパス] | [現在の実装] |
-| 新規 | src/[計画パス] | [新規作成予定] |
-
-### 統合ポイント（新規実装でも記載）
-- **統合先**: [何と連携するか]
-- **呼び出し方式**: [どのように呼び出されるか]
-
-## 設計
-
-### 変更影響マップ
-
-```yaml
-変更対象: [変更するコンポーネント/機能]
-直接影響:
-  - [直接変更が必要なファイル/関数]
-  - [インターフェース変更箇所]
-間接影響:
-  - [データ形式の変更]
-  - [処理時間の変化]
-波及なし:
-  - [明示的に影響を受けない機能]
-```
-
-### アーキテクチャ概要
-
-[この機能がシステム全体の中でどのように位置づけられるか]
-
-### データフロー
-
-```
-[図やシュードコードでデータの流れを表現]
-```
-
-### 統合ポイント一覧
-
-| 統合ポイント | 箇所 | 旧実装 | 新実装 | 切替方式 |
-|------------|-----|-------|-------|---------|
-| 統合ポイント1 | [クラス/関数] | [既存処理] | [新処理] | [DI/Factoryなど] |
-| 統合ポイント2 | [別の箇所] | [既存] | [新規] | [方式] |
-
-### 主要コンポーネント
-
-#### コンポーネント1
-
-- **責務**: [このコンポーネントの責務範囲]
-- **インターフェース**: [提供するAPIや型定義]
-- **依存関係**: [他のコンポーネントとの関係]
-
-### 型定義
-
-```typescript
-// 主要な型定義をここに記載
-```
-
-### データ契約
-
-#### コンポーネント1
-
-```yaml
-入力:
-  型: [TypeScript型定義]
-  前提条件: [必須項目、形式の制約]
-  バリデーション: [検証方法]
-
-出力:
-  型: [TypeScript型定義]
-  保証: [常に満たされる条件]
-  エラー時: [例外/null/デフォルト値]
-
-不変条件:
-  - [処理前後で変わらない条件]
-```
-
-### エラーハンドリング
-
-[エラーの種類とその処理方法]
-
-### ロギングとモニタリング
-
-[ログに記録する内容とモニタリング方法]
-
-## 実装計画
-
-### 実装アプローチ
-
-**選択したアプローチ**: [アプローチ名または組み合わせ]
-**選択理由**: [プロジェクト制約と技術的依存関係を考慮した理由]
-
-### 技術的依存関係と実装順序
-
-#### 必要な実装順序
-1. **[コンポーネント/機能A]**
-   - 技術的理由: [なぜ先に実装する必要があるか]
-   - 依存要素: [これに依存する他のコンポーネント]
-
-2. **[コンポーネント/機能B]**
-   - 技術的理由: [Aの後に実装する技術的必要性]
-   - 前提条件: [事前に必要な実装]
-
-### 統合ポイント
-各統合ポイントでE2E確認が必要：
-
-**統合ポイント1: [名称]**
-- コンポーネント: [コンポーネントA] -> [コンポーネントB]
-- 確認方法: [統合が動作することの検証方法]
-
-### 移行戦略
-
-[技術的な移行アプローチ、後方互換性の確保方法]
-
-## テスト戦略
-
-### 単体テスト
-
-[単体テストの方針とカバレッジ目標]
-- 機能受入条件の個別要素を検証
-
-### 統合テスト
-
-[統合テストの方針と重要なテストケース]
-- 機能受入条件の組み合わせ動作を検証
-
-### E2Eテスト
-
-[E2Eテストの方針]
-- 受入条件のシナリオ全体を検証
-- ユーザー視点での機能動作を確認
-
-## セキュリティ考慮事項
-
-[セキュリティ上の懸念点と対策]
-
-## 代替案
-
-### 代替案1
-
-- **概要**: [代替案の説明]
-- **メリット**: [利点]
-- **デメリット**: [欠点]
-- **不採用理由**: [採用しなかった理由]
-
-## リスクと対策
-
-| リスク | 影響度 | 発生確率 | 対策 |
-|-------|-------|---------|-----|
-| [リスク1] | 高/中/低 | 高/中/低 | [対策] |
-
-## 参考資料
-
-- [関連するドキュメントやリンク]
-
-## 更新履歴
-
-| 日付 | バージョン | 変更内容 | 作成者 |
-|-----|-----------|---------|-------|
-| YYYY-MM-DD | 1.0 | 初版作成 | [名前] |

package/.claude/skills/documentation-criteria/references/plan-template.md

@@ -1,130 +0,0 @@
-# 作業計画書: [タイトル]
-
-作成日: YYYY-MM-DD
-種別: feature|fix|refactor
-想定影響範囲: Xファイル
-関連Issue/PR: #XXX（該当する場合）
-
-## 関連ドキュメント
-- 設計書: [docs/design/XXX.md]
-- ADR: [docs/adr/ADR-XXXX.md]（該当する場合）
-- PRD: [docs/prd/XXX.md]（該当する場合）
-
-## 目的
-[なぜこの変更が必要か、何を解決するか]
-
-## 影響範囲
-### 対象ファイル
-- [ ] src/domain/xxx
-- [ ] src/application/xxx
-- [ ] src/infrastructure/xxx
-- [ ] src/presentation/xxx
-
-### テストファイル
-- [ ] __tests__/xxx.test.ts
-- [ ] __tests__/xxx.test.ts
-
-### ドキュメント
-- [ ] ADR作成が必要（アーキテクチャ変更の場合）
-- [ ] 設計書更新が必要
-- [ ] README更新が必要
-
-## 実装計画
-
-（注: フェーズ構成はDesign Docの技術的依存関係と実装アプローチに基づいて決定）
-
-### Phase 1: [フェーズ名]（想定コミット数: X）
-**目的**: [このフェーズで達成すること]
-
-#### タスク
-- [ ] タスク1: 具体的な作業内容
-- [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
-- [ ] 単体テスト: 関連する全テストがパス
-
-#### フェーズ完了条件
-- [ ] [機能完了条件]
-- [ ] [品質完了条件]
-
-#### 動作確認手順
-1. [動作確認ステップ]
-2. [期待結果の確認]
-3. [パフォーマンス確認（該当する場合）]
-
-### Phase 2: [フェーズ名]（想定コミット数: X）
-**目的**: [このフェーズで達成すること]
-
-#### タスク
-- [ ] タスク1: 具体的な作業内容
-- [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
-- [ ] 統合テスト: 機能全体の動作確認
-
-#### フェーズ完了条件
-- [ ] [機能完了条件]
-- [ ] [品質完了条件]
-
-#### 動作確認手順
-1. [動作確認ステップ]
-2. [期待結果の確認]
-3. [パフォーマンス確認（該当する場合）]
-
-### Phase 3: [フェーズ名]（想定コミット数: X）
-**目的**: [このフェーズで達成すること]
-
-#### タスク
-- [ ] タスク1: 具体的な作業内容
-- [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
-- [ ] 統合テスト: コンポーネント連携の検証
-
-#### フェーズ完了条件
-- [ ] [機能完了条件]
-- [ ] [品質完了条件]
-
-#### 動作確認手順
-[Design Docの該当する統合ポイントE2E確認をコピー]
-
-### 最終Phase: 品質保証（必須）（想定コミット数: 1）
-**目的**: 全体品質保証とDesign Doc整合性検証
-
-#### タスク
-- [ ] Design Docの全受入条件達成を確認
-- [ ] 品質チェック（型、lint、format）
-- [ ] 全テスト実行
-- [ ] カバレッジ70%以上
-- [ ] ドキュメント更新
-
-#### 動作確認手順
-[Design DocからE2E確認手順をコピー]
-
-### 品質保証
-- [ ] 段階的品質チェック実施（詳細: technical-specスキル参照）
-
-## リスクと対策
-| リスク | 対策 |
-|-------|-----|
-| [想定されるリスク] | [対処方法] |
-
-## 完了条件
-- [ ] 全フェーズ完了
-- [ ] 各フェーズの動作確認手順を実施
-- [ ] Design Docの受入条件を満たす
-- [ ] 段階的品質チェック完了（エラー0件）
-- [ ] 全テストパス
-- [ ] 必要なドキュメント更新
-- [ ] ユーザーレビュー承認取得
-
-## 進捗記録
-### Phase 1
-- 開始: YYYY-MM-DD HH:MM
-- 完了: YYYY-MM-DD HH:MM
-- 備考: [特記事項]
-
-### Phase 2
-- 開始: YYYY-MM-DD HH:MM
-- 完了: YYYY-MM-DD HH:MM
-- 備考: [特記事項]
-
-## 備考
-[特記事項、参考情報、注意点など]