@sk8metal/michi-cli 0.13.0 → 0.14.1

package/templates/claude/commands/michi-multi-repo/spec-design.md

@@ -1,359 +0,0 @@
----
-description: Multi-Repoプロジェクトの設計書をAI支援で生成
-allowed-tools: Bash, Glob, Grep, LS, Read, Write, Edit, MultiEdit, Update, WebSearch, WebFetch
-argument-hint: <project-name> [-y]
----
-
-# Multi-Repo Design Generator
-
-<background_information>
-- **Mission**: Multi-Repoプロジェクトの包括的な技術設計書を生成
-- **Success Criteria**:
-  - 全サービスのアーキテクチャを統合
-  - サービス間通信の設計を明確化
-  - 各サービスの技術スタックを反映
-  - C4モデルに基づいた視覚的な設計図を含む
-</background_information>
-
-<instructions>
-## Core Task
-Multi-Repoプロジェクト **$1** の技術設計書を生成します。
-
-## Execution Steps
-
-### Step 1: コンテキスト読み込み
-1. `.michi/config.json` からプロジェクト情報取得
-   - プロジェクト名、JIRAキー、Confluenceスペース
-   - 登録リポジトリ一覧
-2. `docs/michi/$1/overview/requirements.md` から要件読み込み
-   - 要件定義書が存在しない場合は、先に `/michi-multi-repo:spec-requirements $1` の実行を促す
-3. `.kiro/settings/rules/design-principles.md` から設計原則取得（存在する場合）
-4. `.kiro/settings/templates/specs/design.md` から構造参照（存在する場合）
-
-### Step 2: Discovery & Analysis
-
-**Multi-Repo固有の分析**:
-
-1. **各リポジトリの技術スタック調査**
-   - package.json / build.gradle / composer.json / requirements.txt
-   - 使用フレームワーク、ライブラリバージョン
-   - 依存関係の分析
-
-2. **サービス間通信パターンの特定**
-   - REST API / GraphQL / gRPC
-   - メッセージキュー / イベントバス（Kafka、RabbitMQ等）
-   - 同期通信 vs 非同期通信
-
-3. **共有コンポーネントの識別**
-   - 共通ライブラリ
-   - 共有データモデル
-   - 共通インフラストラクチャ（ログ、監視、認証等）
-
-4. **データフローの分析**
-   - サービス間のデータ連携
-   - データの永続化方式
-   - キャッシュ戦略
-
-### Step 3: 設計書生成
-
-以下のセクションを含む設計書を生成します：
-
-1. **システム全体図**
-   - C4モデル - システムコンテキスト図（Mermaid）
-   - 全サービスの配置とフロー
-   - 外部システムとの連携
-
-2. **サービス横断アーキテクチャ**
-   - マイクロサービス構成図（C4モデル推奨）
-   - サービス間API契約定義
-   - イベントスキーマ定義
-   - データフロー図
-
-3. **各サービスの設計**
-   - コンポーネント図
-   - インターフェース定義
-   - データモデル
-   - 主要クラス/モジュール構造
-
-4. **セキュリティ設計**
-   - 認証・認可の連携（OAuth2、JWT等）
-   - 通信暗号化（TLS、mTLS）
-   - シークレット管理
-
-5. **デプロイメントアーキテクチャ**
-   - インフラストラクチャ構成（Kubernetes、Docker等）
-   - ネットワーク設計
-   - スケーリング戦略
-
-6. **データモデル**
-   - サービス横断のデータフロー
-   - データベーススキーマ（サービスごと）
-   - データ整合性の保証方法
-
-### Step 4: ファイル保存
-- 出力先: `docs/michi/$1/overview/architecture.md`
-- 既存ファイルがある場合は、上書き確認（`-y` フラグで自動承認）
-
-### Step 4.5: 品質検証（PROACTIVE）
-
-**architecture.md生成後、以下の検証を自動実行**:
-
-#### 4.5.1 Mermaid図の構文検証
-
-`mermaid-validator` エージェントを使用してMermaid図を検証:
-
-```
-IMPORTANT: architecture.mdにMermaid図が含まれる場合、mermaid-validatorエージェントを自動実行してください。
-- 検出: Mermaid図を含むかどうかを確認
-- 検証: 構文エラーを検出
-- 修正: 自動修正可能なエラーを修正
-- 報告: 修正内容をユーザーに通知
-```
-
-**実行タイミング**: architecture.md保存直後
-
-**エージェント呼び出し**:
-```
-Task(subagent_type='mermaid-validator', prompt='docs/michi/$1/overview/architecture.md のMermaid図を検証し、構文エラーを自動修正してください')
-```
-
-#### 4.5.2 技術スタックバージョン監査
-
-`stable-version-auditor` エージェントを使用して技術スタックを監査:
-
-```
-IMPORTANT: architecture.mdに技術スタック（Node.js、Java、Python、PHP等）が記載されている場合、
-stable-version-auditorエージェントを自動実行してください。
-- 検出: バージョン指定を抽出
-- 監査: EOLリスクを評価
-- 推奨: 最新LTS/安定版を提案
-- 報告: アップグレード推奨をユーザーに通知
-```
-
-**実行タイミング**: architecture.md保存直後
-
-**エージェント呼び出し**:
-```
-Task(subagent_type='stable-version-auditor', prompt='docs/michi/$1/overview/architecture.md に記載された技術スタックのバージョンを監査し、EOLリスクを評価してください')
-```
-
-### Step 5: メタデータ更新（spec.json）
-- `docs/michi/$1/spec.json` を読み込み
-- phase を `"design-generated"` に更新
-- `approvals.design.generated` を `true` に更新
-- `updated_at` を現在のISO 8601タイムスタンプに更新
-- spec.json を保存
-
-## Multi-Repo固有セクション
-
-設計書に以下のセクションを必ず含めること：
-
-```markdown
-## サービス横断アーキテクチャ
-
-### C4モデル - システムコンテキスト図
-
-\`\`\`mermaid
-C4Context
-    title System Context Diagram
-
-    Person(user, "User", "エンドユーザー")
-    System(frontend, "Frontend Service", "Webアプリケーション")
-    System(backend, "Backend Service", "APIサーバー")
-    System_Ext(external_api, "External API", "外部サービス")
-
-    Rel(user, frontend, "Uses", "HTTPS")
-    Rel(frontend, backend, "API calls", "REST/HTTPS")
-    Rel(backend, external_api, "Integrates", "REST/HTTPS")
-\`\`\`
-
-### サービス間通信
-
-| 呼び出し元 | 呼び出し先 | 方式 | プロトコル | 用途 |
-|-----------|-----------|------|-----------|------|
-| Frontend | API Gateway | 同期 | REST/HTTPS | ユーザーリクエスト処理 |
-| API Gateway | Auth Service | 同期 | gRPC | 認証・認可 |
-| User Service | Notification Service | 非同期 | Kafka | ユーザー作成イベント通知 |
-
-### 共有コンポーネント
-
-**共通ライブラリ**:
-- `@org/shared-types`: TypeScript型定義（全サービスで共有）
-- `@org/logger`: 統一ログライブラリ
-
-**共通インフラ**:
-- Elasticsearch: ログ集約
-- Prometheus + Grafana: メトリクス監視
-- Keycloak: 統合認証基盤
-
-### デプロイメントアーキテクチャ
-
-\`\`\`mermaid
-graph TB
-    subgraph "Production Kubernetes Cluster"
-        LB[Load Balancer]
-        FE1[Frontend Pod 1]
-        FE2[Frontend Pod 2]
-        BE1[Backend Pod 1]
-        BE2[Backend Pod 2]
-        DB[(PostgreSQL)]
-
-        LB --> FE1
-        LB --> FE2
-        FE1 --> BE1
-        FE2 --> BE2
-        BE1 --> DB
-        BE2 --> DB
-    end
-\`\`\`
-
-### データフロー
-
-\`\`\`mermaid
-sequenceDiagram
-    participant User
-    participant Frontend
-    participant API Gateway
-    participant Auth Service
-    participant User Service
-    participant Database
-
-    User->>Frontend: リクエスト
-    Frontend->>API Gateway: API呼び出し
-    API Gateway->>Auth Service: トークン検証
-    Auth Service-->>API Gateway: 検証成功
-    API Gateway->>User Service: ユーザー情報取得
-    User Service->>Database: クエリ実行
-    Database-->>User Service: データ返却
-    User Service-->>API Gateway: レスポンス
-    API Gateway-->>Frontend: レスポンス
-    Frontend-->>User: 表示
-\`\`\`
-```
-
-## Important Constraints
-- 実装詳細ではなく、アーキテクチャ設計に焦点を当てる
-- サービス間の境界とインターフェースを明確にする
-- 技術選定の理由を記述する
-- スケーラビリティとパフォーマンスを考慮
-- セキュリティ要件を設計に反映
-
-</instructions>
-
-## Tool Guidance
-- **Read first**: プロジェクト設定、要件定義書、設計原則、テンプレートを読み込み
-- **Glob/Grep**: 各リポジトリの技術スタック調査（ローカルクローンがある場合）
-- **Write last**: 設計書を最後に保存
-- **WebSearch/WebFetch**: 最新の設計パターンやベストプラクティスが必要な場合のみ使用
-
-## Output Description
-以下の情報を出力してください：
-
-1. **生成された設計書のパス**: `docs/michi/{project}/overview/architecture.md`
-2. **分析したリポジトリの一覧**: サービス名と技術スタックの要約
-3. **品質検証結果**:
-   - Mermaid図の検証結果
-   - 技術スタックバージョン監査結果
-4. **次のステップ**:
-   - 設計書の確認
-   - Confluence同期
-   - 各リポジトリでの個別実装
-
-**出力形式**:
-```markdown
-## 設計書生成完了
-
-### 出力ファイル
-`docs/michi/{project}/overview/architecture.md`
-
-### 分析したサービス
-- **Frontend**: React + TypeScript（3リポジトリ依存）
-- **Backend**: Node.js + Express（2リポジトリ依存）
-- **Auth Service**: Go + gRPC（独立）
-
-### アーキテクチャ概要
-- **通信方式**: REST API（同期）、Kafka（非同期イベント）
-- **データベース**: PostgreSQL（サービスごとにDB分離）
-- **デプロイ**: Kubernetes（Pod自動スケーリング）
-
-### 品質検証結果
-
-#### Mermaid図検証
-✅ 検証完了 - 構文エラーなし
-または
-⚠️ 2件の構文エラーを自動修正しました:
-- L15: C4モデルのタイトル記法エラー → 修正済み
-- L45: シーケンス図の矢印記法エラー → 修正済み
-
-#### 技術スタックバージョン監査
-✅ すべて最新LTS/安定版を使用
-または
-⚠️ バージョン更新を推奨:
-- Node.js 16.x → 20.x (LTS) - EOL: 2023-09-11（EOL済み）
-- Python 3.9 → 3.11 - EOL 6ヶ月以内
-
-### 次のステップ
-1. 設計書を確認: `docs/michi/{project}/overview/architecture.md`
-2. 技術スタック更新（必要に応じて）
-3. Confluenceに同期: `michi multi-repo:confluence-sync {project} --doc-type architecture`
-4. 各リポジトリで実装を開始:
-   - `/kiro:spec-init` で個別仕様を作成
-   - または直接実装を開始
-```
-
-## Safety & Fallback
-
-### Error Scenarios
-- **要件定義書未作成**:
-  ```
-  エラー: 要件定義書が見つかりません: `docs/michi/{project}/overview/requirements.md`
-
-  先に要件定義書を生成してください：
-  /michi-multi-repo:spec-requirements {project}
-  ```
-
-- **プロジェクト未登録**:
-  ```
-  エラー: プロジェクト '{project}' が見つかりません。
-
-  次のコマンドでプロジェクトを初期化してください：
-  michi multi-repo:init {project} --jira {JIRA_KEY} --confluence-space {SPACE}
-  ```
-
-- **リポジトリアクセス不可**:
-  ```
-  警告: 一部のリポジトリのローカルクローンがありません。
-
-  設定情報（URL、ブランチ）から推測して設計書を生成します。
-  より詳細な設計が必要な場合は、リポジトリをクローンしてから再実行してください。
-  ```
-
-- **既存ファイル存在（`-y` フラグなし）**:
-  ```
-  警告: 既存の設計書が存在します: `docs/michi/{project}/overview/architecture.md`
-
-  上書きしてもよろしいですか？ (y/n)
-  または `-y` フラグを使用して自動承認できます。
-  ```
-
-### Fallback Strategy
-- **設計原則ファイル不在**: 基本的な設計原則（SOLID、DRY等）を適用
-- **技術スタック不明**: README や設定ファイルから推測、または "未指定" として記載
-- **依存関係不明**: 基本的なクライアント-サーバー構成を仮定
-- **テンプレート不在**: インラインで基本構造を使用
-
-### Next Phase: Implementation
-
-**設計書承認後**:
-1. 設計書を確認: `docs/michi/{project}/overview/architecture.md`
-2. Confluenceに同期: `michi multi-repo:confluence-sync {project} --doc-type architecture`
-3. **各リポジトリで個別実装**:
-   - リポジトリごとに `/kiro:spec-init` で仕様作成
-   - または直接実装を開始
-4. **CI/CD設定**: `michi multi-repo:ci-status {project}` でCI結果を監視
-
-**修正が必要な場合**:
-- フィードバックを提供し、`/michi-multi-repo:spec-design $1` を再実行
-- `-y` フラグで自動上書き可能
-
-think hard

package/templates/claude/commands/michi-multi-repo/spec-init.md

@@ -1,228 +0,0 @@
----
-description: Multi-Repoプロジェクトを初期化し、プロジェクト説明とメタデータを設定
-allowed-tools: Bash, Glob, Read, Write, Edit
-argument-hint: "<project-description>" --jira <JIRA_KEY> --confluence-space <SPACE>
----
-
-# Multi-Repo Specification Initialization
-
-<background_information>
-- **Mission**: Multi-Repoプロジェクトの初期化（`michi multi-repo:init` の代替）
-- **Success Criteria**:
-  - プロジェクト説明からfeature-name形式のプロジェクト名を生成
-  - ディレクトリ構造を作成
-  - spec.jsonでメタデータ管理を開始
-  - `.michi/config.json` のmultiRepoProjectsに登録
-  - 次のステップ（リポジトリ登録、要件定義）への明確な誘導
-</background_information>
-
-<instructions>
-## Core Task
-プロジェクト説明 **$1** から Multi-Repoプロジェクトを初期化し、`michi multi-repo:init` と同等の機能をAIコマンドとして提供します。
-
-## 引数解析
-
-引数の形式:
-```
-/michi-multi-repo:spec-init "<プロジェクト説明>" --jira <JIRA_KEY> --confluence-space <SPACE>
-```
-
-パラメータ:
-- **$1**: プロジェクト説明（必須） - 例: "マイクロサービスアーキテクチャでECサイトを構築"
-- **--jira**: JIRAプロジェクトキー（必須） - 例: MSV
-- **--confluence-space**: Confluenceスペースキー（必須） - 例: MSV
-
-## Execution Steps
-
-### Step 1: 引数解析とバリデーション
-
-1. **プロジェクト説明の取得**: $1 からプロジェクト説明を抽出
-2. **JIRA/Confluenceキーの取得**:
-   - `--jira` オプションの値を取得（なければエラー）
-   - `--confluence-space` オプションの値を取得（なければエラー）
-3. **バリデーション**:
-   - JIRAキー: 2-10文字の大文字英字のみ（正規表現: `^[A-Z]{2,10}$`）
-   - Confluenceスペースキー: 空でない文字列
-
-### Step 2: プロジェクト名の生成
-
-1. **feature-name形式に変換**:
-   - プロジェクト説明から簡潔なプロジェクト名を生成
-   - 形式: 小文字英数字とハイフン（例: `my-microservices`, `ec-platform`）
-   - 日本語説明の場合は英語に変換
-
-2. **一意性チェック**:
-   - `.michi/config.json` の `multiRepoProjects` を確認
-   - 重複する場合は数値サフィックスを追加（例: `my-project-2`）
-
-### Step 3: ディレクトリ構造の作成
-
-以下のディレクトリとファイルを作成:
-
-```
-docs/michi/{project-name}/
-├── spec.json                    # メタデータファイル（NEW）
-├── overview/
-│   ├── requirements.md          # 要件定義書（プロジェクト説明を含む）
-│   ├── architecture.md          # アーキテクチャ設計書（テンプレート）
-│   └── sequence.md              # シーケンス図（テンプレート）
-├── steering/
-│   └── multi-repo.md            # ステアリングドキュメント（テンプレート）
-├── tests/
-│   ├── scripts/                 # テストスクリプト配置用
-│   ├── results/                 # テスト結果保存用
-│   ├── unit/
-│   ├── integration/
-│   ├── e2e/
-│   └── performance/
-└── docs/
-    ├── ci-status.md             # CI結果サマリー（テンプレート）
-    └── release-notes.md         # リリースノート（テンプレート）
-```
-
-### Step 4: メタデータ初期化
-
-1. **spec.jsonの生成**:
-   - テンプレート: `templates/multi-repo/spec.json`
-   - プレースホルダー置換:
-     - `{{PROJECT_NAME}}` → 生成されたプロジェクト名
-     - `{{CREATED_AT}}` → 現在のISO 8601タイムスタンプ
-     - `{{JIRA_KEY}}` → JIRAキー
-     - `{{CONFLUENCE_SPACE}}` → Confluenceスペースキー
-   - 出力先: `docs/michi/{project-name}/spec.json`
-
-2. **requirements.mdの初期化**:
-   - テンプレート: `templates/multi-repo/overview/requirements.md`
-   - 「概要」セクションにプロジェクト説明を記載
-   - プレースホルダー置換
-   - 出力先: `docs/michi/{project-name}/overview/requirements.md`
-
-3. **その他テンプレートファイルのレンダリング**:
-   - `templates/multi-repo/overview/architecture.md` → `docs/michi/{project-name}/overview/architecture.md`
-   - `templates/multi-repo/overview/sequence.md` → `docs/michi/{project-name}/overview/sequence.md`
-   - `templates/multi-repo/steering/multi-repo.md` → `docs/michi/{project-name}/steering/multi-repo.md`
-   - `templates/multi-repo/tests/strategy.md` → `docs/michi/{project-name}/tests/strategy.md`
-   - `templates/multi-repo/docs/ci-status.md` → `docs/michi/{project-name}/docs/ci-status.md`
-   - `templates/multi-repo/docs/release-notes.md` → `docs/michi/{project-name}/docs/release-notes.md`
-
-### Step 5: .michi/config.json の更新
-
-1. **config.jsonの読み込み**: `.michi/config.json` を読み込む
-2. **multiRepoProjects に追加**:
-   ```json
-   {
-     "name": "{project-name}",
-     "jiraKey": "{JIRA_KEY}",
-     "confluenceSpace": "{CONFLUENCE_SPACE}",
-     "createdAt": "{ISO 8601 timestamp}",
-     "repositories": []
-   }
-   ```
-3. **保存**: `.michi/config.json` を保存
-
-## Important Constraints
-- プロジェクト名は1-100文字、パストラバーサル文字（`/`, `\`, `..`）、制御文字は禁止
-- JIRAキーは2-10文字の大文字英字のみ
-- Confluenceスペースキーは空でない文字列
-- 既存プロジェクト名と重複する場合は数値サフィックスを自動追加
-- DO NOT generate requirements/design at this stage（要件・設計は後続コマンドで生成）
-
-</instructions>
-
-## Tool Guidance
-- **Glob**: `.michi/config.json` 存在確認、プロジェクト名の一意性チェック
-- **Read**: テンプレートファイル読み込み、config.json 読み込み
-- **Write**: spec.json、requirements.md、config.json、その他テンプレート出力
-- **Edit**: config.json の multiRepoProjects 配列に追加（必要に応じて）
-
-## Output Description
-日本語で以下の情報を出力してください:
-
-1. **生成されたプロジェクト名**: `{project-name}` 形式（1-2文で理由を説明）
-2. **プロジェクト概要**: プロジェクト説明の要約（1文）
-3. **作成されたファイル**: 箇条書きで主要ファイルのパス
-4. **次のステップ**: 次に実行すべきコマンド（リポジトリ登録、要件定義）
-
-**出力形式**:
-```markdown
-## Multi-Repoプロジェクト初期化完了
-
-### プロジェクト名
-`{project-name}`
-
-プロジェクト説明「{description}」から生成しました。
-
-### プロジェクト概要
-{プロジェクト説明の要約}
-
-### 作成されたファイル
-- `docs/michi/{project}/spec.json` - メタデータ（phase: initialized）
-- `docs/michi/{project}/overview/requirements.md` - 要件定義書（初期化済み）
-- `docs/michi/{project}/overview/architecture.md` - 設計書（テンプレート）
-- `.michi/config.json` - multiRepoProjects に登録
-
-### 次のステップ
-
-1. **リポジトリを登録**:
-   \`\`\`bash
-   michi multi-repo:add-repo {project} --name frontend --url https://github.com/org/frontend --branch main
-   michi multi-repo:add-repo {project} --name backend --url https://github.com/org/backend --branch main
-   \`\`\`
-
-2. **AI要件定義書を生成**:
-   \`\`\`bash
-   /michi-multi-repo:spec-requirements {project}
-   \`\`\`
-
-3. **AI設計書を生成**:
-   \`\`\`bash
-   /michi-multi-repo:spec-design {project}
-   \`\`\`
-
-4. **Confluenceに同期**:
-   \`\`\`bash
-   michi multi-repo:confluence-sync {project}
-   \`\`\`
-```
-
-## Safety & Fallback
-
-### Error Scenarios
-
-- **引数不足**:
-  ```
-  エラー: 必須パラメータが不足しています。
-
-  使用方法:
-  /michi-multi-repo:spec-init "<プロジェクト説明>" --jira <JIRA_KEY> --confluence-space <SPACE>
-
-  例:
-  /michi-multi-repo:spec-init "マイクロサービスでECサイト構築" --jira MSV --confluence-space MSV
-  ```
-
-- **JIRAキーが不正**:
-  ```
-  エラー: JIRAキーは2-10文字の大文字英字のみです（例: MSV, PROJ）
-  ```
-
-- **プロジェクト名重複**:
-  ```
-  警告: プロジェクト名 '{project-name}' は既に存在します。
-  自動的に '{project-name-2}' として作成しました。
-  ```
-
-- **config.json が存在しない**:
-  ```
-  エラー: .michi/config.json が見つかりません。
-
-  Michiプロジェクトのルートディレクトリで実行してください。
-  または、次のコマンドで初期設定を行ってください:
-  michi init
-  ```
-
-### Fallback Strategy
-- プロジェクト名生成が曖昧な場合: 2-3の候補を提示し、ユーザーに選択を求める
-- テンプレートファイル不在: エラーメッセージと対処方法を表示
-- ディレクトリ作成失敗: パーミッションまたはディスク容量の確認を促す
-
-think hard