@sk8metal/michi-cli 0.13.0 → 0.14.1

package/templates/claude/skills/e2e-first-planning/SKILL.md

@@ -1,360 +0,0 @@
----
-name: e2e-first-planning
-description: |
-  E2Eファースト開発計画策定ガイド。
-  Walking Skeleton、MVP計画、縦割りタスク分割をサポート。
-allowed-tools: Read, Grep, Glob
----
-
-# E2Eファースト計画策定スキル
-
-## 目的
-
-E2E（End-to-End）ファーストの開発計画を策定し、リスクを早期発見し、価値を段階的に提供する。
-
-## E2Eファーストとは
-
-### 定義
-
-**E2Eファースト**: ユーザーの視点から始めて終わりまで動作する最小限の機能を最優先で実装するアプローチ。
-
-### 重要な原則
-
-1. **価値の早期提供**: ユーザーが触れる機能を優先
-2. **リスクの早期発見**: インテグレーション問題を早期に検出
-3. **継続的なフィードバック**: 動くものを見せて方向性を確認
-4. **技術的実現可能性の検証**: 最初から本番環境を意識
-
-### なぜE2Eファーストが重要か
-
-| 利点 | 説明 |
-|------|------|
-| 🎯 **ユーザー価値重視** | 常に動作する機能を提供 |
-| 🚨 **早期リスク発見** | 統合の問題を早期に検出 |
-| 🔄 **継続的フィードバック** | ステークホルダーとの早期合意 |
-| 🏗️ **技術的実現可能性** | アーキテクチャの妥当性を検証 |
-| 📊 **進捗の可視化** | 動作する機能 = 進捗 |
-
-## アンチパターン: 横割り開発
-
-### ❌ 避けるべき開発順序
-
-```
-Phase 1: UI全体を作る
-Phase 2: API全体を作る
-Phase 3: DB全体を作る
-Phase 4: 統合（← ここで大量の問題発見）
-```
-
-**問題点:**
-- 統合まで動作する機能がゼロ
-- リスクが最後に集中
-- ユーザーフィードバックが遅い
-- 見積もりの精度が低い
-
-### ✅ 推奨: 縦割り開発（E2Eスライス）
-
-```
-Phase 1: ログイン機能（UI + API + DB）← 動作する
-Phase 2: ダッシュボード（UI + API + DB）← 動作する
-Phase 3: データ編集（UI + API + DB）← 動作する
-```
-
-**利点:**
-- 各フェーズで動作する機能を提供
-- リスクを段階的に管理
-- 継続的なフィードバック
-- 見積もりの精度向上
-
-## 計画策定フレームワーク
-
-### フェーズ1: Skeleton（骨組み）
-
-**目的**: プロジェクトの基本構造を定義
-
-**成果物:**
-- システムアーキテクチャ図
-- 主要コンポーネントの識別
-- 技術スタックの決定
-- 開発環境のセットアップ
-
-**期間**: 1-3日
-
-**チェックリスト:**
-- [ ] プロジェクト構造が明確か
-- [ ] 技術スタックが決定したか
-- [ ] 開発環境が構築できたか
-- [ ] チーム全員が構造を理解したか
-
-### フェーズ2: Walking Skeleton（歩く骨組み）
-
-**目的**: 最小限のE2E機能を実装
-
-**成果物:**
-- ユーザーから見て動作する最小機能
-- CI/CD パイプラインの構築
-- 本番環境へのデプロイ
-- 監視・ログの基本設定
-
-**期間**: 1-2週間
-
-**例: Webアプリケーション**
-```
-ユーザー → ログイン → 簡単なダッシュボード表示 → ログアウト
-（UI + API + DB + デプロイ）
-```
-
-**チェックリスト:**
-- [ ] E2Eで動作するか
-- [ ] 本番環境にデプロイできるか
-- [ ] CI/CDが機能するか
-- [ ] 監視が動作するか
-
-### フェーズ3: MVP（Minimum Viable Product）
-
-**目的**: 実際のユーザーに価値を提供できる最小限の機能セット
-
-**成果物:**
-- コア機能の実装
-- ユーザーが実際に利用できる状態
-- フィードバック収集の仕組み
-- ドキュメント
-
-**期間**: 4-8週間
-
-**チェックリスト:**
-- [ ] ユーザーが価値を感じるか
-- [ ] フィードバックを収集できるか
-- [ ] スケールするアーキテクチャか
-- [ ] 運用可能な状態か
-
-## タスク分割の原則
-
-### 縦割り（推奨）
-
-**定義**: 機能単位でUI→API→DBまで完結させる
-
-**例:**
-```
-タスク1: ユーザー登録機能
-  - UI: 登録フォーム
-  - API: POST /api/users
-  - DB: usersテーブル作成
-  - Test: E2Eテスト
-
-タスク2: ログイン機能
-  - UI: ログインフォーム
-  - API: POST /api/auth/login
-  - DB: sessionsテーブル
-  - Test: E2Eテスト
-```
-
-**利点:**
-- 各タスク完了時に動作する機能ができる
-- 統合の問題を早期発見
-- 進捗が可視化しやすい
-
-### 横割り（非推奨）
-
-**定義**: レイヤー単位で全機能を作る
-
-**例:**
-```
-タスク1: UI全画面作成
-タスク2: API全エンドポイント作成
-タスク3: DB全テーブル作成
-タスク4: 統合（← ここで問題発覚）
-```
-
-**問題点:**
-- 最後まで動作する機能がゼロ
-- 統合時に大量の問題
-- 進捗が見えにくい
-
-## E2Eスライスの特定方法
-
-### Step 1: ユーザーストーリーから始める
-
-```
-ユーザーストーリー:
-「ECサイトの管理者として、商品を登録したい」
-
-E2Eスライス:
-1. 商品登録フォームを表示（UI）
-2. 入力データを受け取る（API）
-3. データベースに保存（DB）
-4. 成功メッセージを表示（UI）
-```
-
-### Step 2: 最小限の実装を定義
-
-```
-Phase 1 (Walking Skeleton):
-- 商品名のみ登録可能
-- 画像・説明・価格は後回し
-- バリデーションは最小限
-
-Phase 2 (MVP):
-- 画像アップロード追加
-- 価格・在庫管理追加
-- 詳細なバリデーション
-```
-
-### Step 3: 依存関係を整理
-
-```
-優先度1: ログイン機能（他の機能の前提）
-優先度2: 商品一覧表示（データ確認のため）
-優先度3: 商品登録（メイン機能）
-優先度4: 商品編集（登録の拡張）
-```
-
-## マイルストーン設計
-
-### マイルストーン1: Walking Skeleton
-
-**目標**: 基本的なE2E動作を確認
-
-**成果物:**
-- ログイン → ダッシュボード表示 → ログアウト
-- CI/CDパイプライン
-- デプロイ自動化
-
-**期間**: 1-2週間
-
-**完了条件:**
-- [ ] 本番環境にデプロイ済み
-- [ ] E2Eテストが通る
-- [ ] CI/CDが動作する
-
-### マイルストーン2: MVP
-
-**目標**: ユーザーに価値を提供
-
-**成果物:**
-- コア機能3つ
-- ユーザードキュメント
-- フィードバック収集の仕組み
-
-**期間**: 4-6週間
-
-**完了条件:**
-- [ ] ユーザーが実際に利用できる
-- [ ] フィードバックを収集できる
-- [ ] パフォーマンステスト済み
-
-### マイルストーン3: 機能拡張
-
-**目標**: ユーザーフィードバックを基に機能追加
-
-**成果物:**
-- 追加機能
-- パフォーマンス最適化
-- セキュリティ強化
-
-**期間**: 継続的
-
-## 計画ドキュメントフォーマット
-
-### E2E計画テンプレート
-
-```markdown
-# プロジェクト名 - E2E計画
-
-## 概要
-- プロジェクトの目的
-- ターゲットユーザー
-- 提供価値
-
-## Walking Skeleton（1-2週間）
-
-### 目標
-最小限のE2E機能を動作させる
-
-### E2Eスライス
-1. ログイン機能（UI + API + DB）
-2. ダッシュボード表示（UI + API + DB）
-
-### 技術的準備
-- [ ] CI/CDパイプライン構築
-- [ ] デプロイ自動化
-- [ ] 監視設定
-
-## MVP（4-6週間）
-
-### 目標
-ユーザーに価値を提供できる最小機能セット
-
-### E2Eスライス（優先順）
-1. ユーザー登録（UI + API + DB）
-2. データ一覧表示（UI + API + DB）
-3. データ編集（UI + API + DB）
-
-### 完了条件
-- [ ] ユーザーが実際に利用できる
-- [ ] フィードバック収集可能
-- [ ] パフォーマンステスト済み
-
-## リスク管理
-
-| リスク | 対策 | 担当 |
-|--------|------|------|
-| 外部API統合の遅延 | モックAPIを先行実装 | チームA |
-| パフォーマンス問題 | 早期負荷テスト | チームB |
-
-## タイムライン
-
-```
-Week 1-2: Walking Skeleton
-Week 3-4: MVP Core機能
-Week 5-6: MVP追加機能
-Week 7+: フィードバック対応
-```
-```
-
-## チームへの共有方法
-
-### キックオフミーティング
-
-1. **E2Eファーストの説明**（15分）
-   - なぜ横割りではなく縦割りか
-   - 各フェーズの目標
-
-2. **Walking Skeletonのデモ**（10分）
-   - どこまで動くものを作るか
-   - 技術的な準備作業
-
-3. **タスク分割の確認**（15分）
-   - 各E2Eスライスの説明
-   - 依存関係の確認
-
-### 定期レビュー
-
-- **毎週**: E2Eスライス単位でデモ
-- **隔週**: マイルストーン進捗確認
-- **月次**: ユーザーフィードバック共有
-
-## よくある質問
-
-### Q1: すべてを最初から完璧に作る必要はないか？
-
-A: **不要です**。Walking Skeletonは最小限の実装で十分。重要なのは「E2Eで動作すること」。
-
-### Q2: 横割りの方が効率的では？
-
-A: **短期的には効率的に見えますが**、統合時の問題で結果的に遅延します。E2Eファーストは早期リスク発見により全体効率を向上します。
-
-### Q3: レガシーシステムでもE2Eファーストは可能か？
-
-A: **可能です**。まず新機能を小さなE2Eスライスで実装し、段階的に既存システムと統合します。
-
-### Q4: チームメンバーがフルスタック対応できない場合は？
-
-A: **ペアプログラミングや知識共有**で対応。または、E2Eスライス単位でフロント/バック担当を決めて密に連携。
-
-## 参考資料
-
-- [Walking Skeleton - Alistair Cockburn](https://alistair.cockburn.us/walking-skeleton/)
-- [Vertical Slice Architecture - Jimmy Bogard](https://jimmybogard.com/vertical-slice-architecture/)
-- [Shape Up - Basecamp](https://basecamp.com/shapeup)
-- [The Lean Startup - Eric Ries](http://theleanstartup.com/)

package/templates/claude/skills/mermaid-validator/SKILL.md

@@ -1,261 +0,0 @@
----
-name: mermaid-validator
-description: |
-  Mermaid図の構文検証と修正を行うスキル。
-  architecture.md生成時のパースエラーを防止。
-allowed-tools: Bash, Read, Grep, Glob, WebFetch, Edit, Write
----
-
-# Mermaid Validator スキル
-
-## 目的
-
-Mermaid図の構文エラーを検出し、自動修正を行うことで、ドキュメント生成時のパースエラーを防止する。
-
-## 対象ファイル
-
-### 自動検証対象
-
-- `docs/**/architecture.md`
-- `docs/**/design.md`
-- `docs/**/sequence.md`
-- `*.md` (Mermaid図を含むすべてのMarkdownファイル)
-
-### 主な検証ポイント
-
-1. **構文エラー検出**
-   - 未閉じの括弧、引用符
-   - 無効なキーワード
-   - インデントの問題
-
-2. **C4モデル構文検証**
-   - `C4Context`, `C4Container`, `C4Component` の正しい使用
-   - `Person()`, `System()`, `Rel()` の引数チェック
-
-3. **シーケンス図検証**
-   - `participant` 宣言の確認
-   - 矢印記法（`->>`, `-->>`, `->>`）の正しい使用
-
-4. **グラフ構文検証**
-   - ノード定義の正しい記法
-   - サブグラフの構文チェック
-
-## Mermaid構文クイックリファレンス
-
-### C4モデル
-
-```mermaid
-C4Context
-    title System Context Diagram
-
-    Person(user, "User", "エンドユーザー")
-    System(system, "System Name", "システム説明")
-    System_Ext(external, "External System", "外部システム")
-
-    Rel(user, system, "Uses", "HTTPS")
-    Rel(system, external, "Integrates", "REST/HTTPS")
-```
-
-**注意点**:
-- `C4Context` の後に改行が必要
-- `title` は必須ではないが推奨
-- `Rel()` の引数は必ず4つ（from, to, label, technology）
-
-### シーケンス図
-
-```mermaid
-sequenceDiagram
-    participant User
-    participant Frontend
-    participant Backend
-
-    User->>Frontend: リクエスト
-    Frontend->>Backend: API呼び出し
-    Backend-->>Frontend: レスポンス
-    Frontend-->>User: 表示
-```
-
-**注意点**:
-- `participant` 宣言は必須ではないが推奨
-- `->>`（同期）、`-->>`（非同期）、`-x`（破棄）を区別
-- ラベルに日本語を含む場合、引用符は不要
-
-### グラフ（フローチャート）
-
-```mermaid
-graph TB
-    A[クライアント] --> B[APIゲートウェイ]
-    B --> C[バックエンドサービス]
-    C --> D[データベース]
-    C --> E[外部API]
-```
-
-**注意点**:
-- `graph TB`（上から下）、`graph LR`（左から右）
-- ノードラベルに日本語を含む場合、`[]` で囲む
-- `subgraph` はインデント必須
-
-### ER図
-
-```mermaid
-erDiagram
-    USER ||--o{ ORDER : places
-    USER {
-        string id
-        string name
-        string email
-    }
-    ORDER {
-        string id
-        string userId
-        date createdAt
-    }
-```
-
-**注意点**:
-- リレーションシップ記法: `||--o{`（1対多）、`}o--o{`（多対多）
-- フィールド定義は `type name` の順
-
-## 検証方法
-
-### オンライン検証（推奨）
-
-```bash
-# Mermaid Live Editorで検証
-# https://mermaid.live/
-
-# または、mermaid-cliを使用
-npx @mermaid-js/mermaid-cli mmdc -i diagram.mmd -o diagram.svg
-```
-
-### 手動検証
-
-```bash
-# Markdownファイル内のMermaid図を抽出
-grep -A 50 '```mermaid' architecture.md > extracted-diagrams.txt
-
-# 構文エラーを目視確認
-cat extracted-diagrams.txt
-```
-
-## よくある構文エラーと修正方法
-
-### エラー1: C4モデルでタイトルが不正
-
-**誤り**:
-```mermaid
-C4Context
-title: System Context Diagram
-```
-
-**修正**:
-```mermaid
-C4Context
-    title System Context Diagram
-```
-
-### エラー2: シーケンス図で矢印記法が不正
-
-**誤り**:
-```mermaid
-sequenceDiagram
-    User->Frontend: リクエスト
-```
-
-**修正**:
-```mermaid
-sequenceDiagram
-    User->>Frontend: リクエスト
-```
-
-### エラー3: グラフでサブグラフのインデント不足
-
-**誤り**:
-```mermaid
-graph TB
-subgraph "Production"
-A[Pod 1]
-end
-```
-
-**修正**:
-```mermaid
-graph TB
-    subgraph "Production"
-        A[Pod 1]
-    end
-```
-
-### エラー4: ER図でリレーションシップ記法が不正
-
-**誤り**:
-```mermaid
-erDiagram
-    USER -> ORDER : places
-```
-
-**修正**:
-```mermaid
-erDiagram
-    USER ||--o{ ORDER : places
-```
-
-## 自動修正ルール
-
-### ルール1: インデント正規化
-
-- C4モデルの要素をインデント
-- サブグラフをインデント
-- ERDのフィールド定義をインデント
-
-### ルール2: 引用符の補完
-
-- 特殊文字を含むラベルに引用符を追加
-- ただし、日本語のみの場合は不要
-
-### ルール3: 矢印記法の統一
-
-- シーケンス図で `->>` に統一（同期呼び出し）
-- 非同期の場合は `-->>` を使用
-
-## CI/CDへの組み込み
-
-### GitHub Actions 例
-
-```yaml
-name: Mermaid Validation
-
-on:
-  pull_request:
-    paths:
-      - 'docs/**/*.md'
-      - '**/*.md'
-
-jobs:
-  validate-mermaid:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v2
-
-      - name: Setup Node.js
-        uses: actions/setup-node@v2
-        with:
-          node-version: '20'
-
-      - name: Validate Mermaid Diagrams
-        run: |
-          npm install -g @mermaid-js/mermaid-cli
-          find . -name "*.md" -exec sh -c '
-            grep -l "```mermaid" "$1" && {
-              echo "Validating $1"
-              mmdc -i "$1" -o /tmp/test.svg || exit 1
-            }
-          ' _ {} \;
-```
-
-## 参考資料
-
-- [Mermaid公式ドキュメント](https://mermaid.js.org/)
-- [Mermaid Live Editor](https://mermaid.live/)
-- [C4モデルガイド](https://c4model.com/)
-- [Mermaid CLI](https://github.com/mermaid-js/mermaid-cli)