@sk8metal/michi-cli 0.13.0 → 0.14.1

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

@@ -1,198 +0,0 @@
----
-description: Multi-Repoプロジェクトの要件定義書をAI支援で生成
-allowed-tools: Bash, Glob, Grep, LS, Read, Write, Edit, MultiEdit, Update, WebSearch, WebFetch
-argument-hint: <project-name>
----
-
-# Multi-Repo Requirements Generation
-
-<background_information>
-- **Mission**: Multi-Repoプロジェクトの包括的な要件定義書をEARS形式で生成
-- **Success Criteria**:
-  - 登録された全リポジトリの情報を反映
-  - リポジトリ間の依存関係とインターフェースを明記
-  - EARS形式の受入基準を含む
-  - サービス構成図（Mermaid）を含む
-</background_information>
-
-<instructions>
-## Core Task
-Multi-Repoプロジェクト **$1** の要件定義書を生成します。
-
-## Execution Steps
-
-### Step 1: プロジェクト情報の取得
-1. `.michi/config.json` を読み込み、プロジェクト `$1` の情報を取得
-2. プロジェクトが登録されていない場合は、`michi multi-repo:init` の実行を促す
-3. 登録されたリポジトリ一覧を確認
-4. リポジトリ数が0の場合は警告を出し、基本構造のみ生成
-
-### Step 2: コンテキスト収集
-1. **EARS形式ルール**: `.kiro/settings/rules/ears-format.md` を読み込み
-   - EARS形式（Event-Action-Response-System）の構文を理解
-2. **既存要件テンプレート**: `templates/multi-repo/overview/requirements.md` を確認
-3. **各リポジトリの情報収集**:
-   - リポジトリ名、URL、ブランチ
-   - 技術スタック（package.json、build.gradle、composer.json等から推測）
-   - 主要機能（README.mdから抽出）
-   - 注: ローカルクローンがない場合は、設定情報から推測
-
-### Step 3: 要件定義書生成
-以下のセクションを含む要件定義書を生成します：
-
-1. **プロジェクト概要**
-   - プロジェクト名、JIRAキー、Confluenceスペース
-   - 複数リポジトリを統合したシステムの概要
-   - ビジネス価値
-
-2. **サービス構成**
-   - 登録リポジトリ一覧（表形式）
-   - サービス間依存関係（Mermaidダイアグラム）
-   - 各サービスの役割説明
-
-3. **インターフェース要件**
-   - サービス間API契約（エンドポイント一覧）
-   - イベント契約（Pub/Sub、メッセージキュー等）
-   - データフォーマット
-
-4. **機能要件**
-   - 各サービスの機能要件をEARS形式で記述
-   - サービス横断的な機能要件（認証、ログ集約等）
-
-5. **非機能要件**
-   - パフォーマンス要件（レスポンスタイム、スループット）
-   - セキュリティ要件（認証・認可、通信暗号化）
-   - 可用性要件（SLA、冗長化）
-   - 保守性要件（モニタリング、ログ）
-
-### Step 4: ファイル保存
-- 出力先: `docs/michi/$1/overview/requirements.md`
-- 既存ファイルがある場合は、上書き確認を実施
-- ファイル保存後、完了メッセージを表示
-
-### Step 5: メタデータ更新（spec.json）
-- `docs/michi/$1/spec.json` を読み込み
-- phase を `"requirements-generated"` に更新
-- `approvals.requirements.generated` を `true` に更新
-- `updated_at` を現在のISO 8601タイムスタンプに更新
-- spec.json を保存
-
-## Multi-Repo固有セクション
-要件定義書に以下のセクションを必ず含めること：
-
-```markdown
-## サービス構成
-
-### 登録リポジトリ一覧
-
-| サービス名 | リポジトリURL | ブランチ | 役割 | 技術スタック |
-|-----------|---------------|---------|------|-------------|
-| frontend | https://github.com/org/frontend | main | ユーザーインターフェース | React, TypeScript |
-| backend | https://github.com/org/backend | main | APIサーバー | Node.js, Express |
-
-### サービス間依存関係
-
-\`\`\`mermaid
-graph TB
-    A[Frontend] -->|REST API| B[API Gateway]
-    B -->|HTTP| C[Auth Service]
-    B -->|HTTP| D[User Service]
-    C -->|gRPC| E[Database]
-    D -->|gRPC| E
-\`\`\`
-
-## インターフェース要件
-
-### API契約
-
-**Auth Service → User Service**
-- エンドポイント: `POST /api/v1/auth/verify`
-- プロトコル: HTTP/REST
-- データ形式: JSON
-
-### イベント契約
-
-**User Service → Notification Service**
-- イベント: `user.created`
-- プロトコル: Kafka
-- スキーマ: { userId, email, createdAt }
-```
-
-## Important Constraints
-- EARS形式を厳守（When/If/While/Where/The system shall）
-- サービス名を明確にする（例: The Frontend Service shall...）
-- 要件はテスト可能であること
-- 実装詳細は含めない（WHAT、not HOW）
-
-</instructions>
-
-## Tool Guidance
-- **Read first**: プロジェクト設定、EARS形式ルール、テンプレートを読み込み
-- **Write last**: 要件定義書を最後に保存
-- **WebSearch/WebFetch**: 外部ドメイン知識が必要な場合のみ使用
-
-## Output Description
-以下の情報を出力してください：
-
-1. **生成された要件定義書のパス**: `docs/michi/{project}/overview/requirements.md`
-2. **含まれるリポジトリ/サービスの一覧**: サービス名と役割の要約
-3. **次のステップ**:
-   - `/michi-multi-repo:spec-design $1` で設計書を生成
-   - `michi multi-repo:confluence-sync $1 --doc-type requirements` でConfluenceに同期
-
-**出力形式**:
-```markdown
-## 要件定義書生成完了
-
-### 出力ファイル
-`docs/michi/{project}/overview/requirements.md`
-
-### 含まれるサービス
-- **Frontend**: ユーザーインターフェース（React）
-- **Backend**: APIサーバー（Node.js）
-- **Database**: データ永続化（PostgreSQL）
-
-### 次のステップ
-1. 要件定義書を確認: `docs/michi/{project}/overview/requirements.md`
-2. 設計書を生成: `/michi-multi-repo:spec-design {project}`
-3. Confluenceに同期: `michi multi-repo:confluence-sync {project} --doc-type requirements`
-```
-
-## Safety & Fallback
-
-### Error Scenarios
-- **プロジェクト未登録**:
-  ```
-  エラー: プロジェクト '{project}' が見つかりません。
-
-  次のコマンドでプロジェクトを初期化してください：
-  michi multi-repo:init {project} --jira {JIRA_KEY} --confluence-space {SPACE}
-  ```
-
-- **リポジトリ未登録**:
-  ```
-  警告: プロジェクト '{project}' にリポジトリが登録されていません。
-
-  基本的な要件定義書の骨格を生成しますが、サービス固有の情報は含まれません。
-
-  次のコマンドでリポジトリを登録してください：
-  michi multi-repo:add-repo {project} --name {name} --url {url} --branch {branch}
-  ```
-
-- **既存ファイル存在**:
-  ```
-  警告: 既存の要件定義書が存在します: `docs/michi/{project}/overview/requirements.md`
-
-  上書きしてもよろしいですか？ (y/n)
-  ```
-
-- **EARS形式ルール未取得**:
-  - `.kiro/settings/rules/ears-format.md` が存在しない場合、基本的なEARS形式を使用
-  - 警告メッセージを表示
-
-### Fallback Strategy
-- ローカルクローンがないリポジトリ: 設定情報（名前、URL）のみから推測
-- 技術スタック不明: "未指定" として記載
-- 依存関係不明: 基本的なクライアント-サーバー構成を仮定
-
-think hard

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

@@ -1,261 +0,0 @@
----
-description: Multi-Repoプロジェクトのクロスリポジトリ仕様レビューを実行
-allowed-tools: Task, Bash, Read, Write, Edit, Glob, Grep
-argument-hint: <project-name> [--focus api|data|event|deps|test|all]
----
-
-# Multi-Repo Cross-Repository Review
-
-<background_information>
-- **Mission**: 複数リポジトリにまたがる仕様の整合性を検証
-- **Success Criteria**:
-  - 全リポジトリの仕様を収集・分析
-  - API契約、データモデル、イベントスキーマの整合性を検証
-  - 品質ゲート判定を実行
-  - 修正が必要な箇所を明確に報告
-</background_information>
-
-<instructions>
-## Core Task
-Multi-Repoプロジェクト **$1** の全リポジトリを対象に、クロスリポジトリレビューを実行します。
-
-## 引数解析
-
-引数の形式:
-```
-/michi-multi-repo:spec-review <project-name> [--focus <focus>]
-```
-
-パラメータ:
-- **$1**: プロジェクト名（必須）
-- **--focus**: レビュー観点（オプション、デフォルト: all）
-  - `api`: API契約整合性のみ
-  - `data`: データモデル整合性のみ
-  - `event`: イベントスキーマ整合性のみ
-  - `deps`: 依存関係整合性のみ
-  - `test`: テスト仕様整合性のみ
-  - `all`: 全観点（デフォルト）
-
-## Execution Steps
-
-### Step 1: コンテキスト読み込み
-
-1. `.michi/config.json` からプロジェクト情報取得
-   - プロジェクト名
-   - 登録リポジトリ一覧
-
-2. 各リポジトリの `localPath` を取得
-
-3. 親プロジェクトの仕様を読み込み
-   - `docs/michi/$1/overview/requirements.md`
-   - `docs/michi/$1/overview/architecture.md`
-
-### Step 2: localPath 検証
-
-各リポジトリについて以下を確認:
-- localPathが設定されているか
-- ディレクトリが存在するか
-- Gitリポジトリか (`.git/`ディレクトリ確認)
-- Michiがセットアップ済みか (`.kiro/project.json`確認)
-- 仕様ファイルが存在するか
-
-**検証失敗時の対応**:
-- localPath未設定: 警告を出力し、スキップ
-- ディレクトリ不存在: エラーを出力し、スキップ
-- Michi未セットアップ: 警告を出力し、スキップ
-- 仕様ファイル不存在: 警告を出力し、利用可能情報でレビュー続行
-
-### Step 3: サブエージェント起動
-
-cross-repo-reviewerサブエージェントを使用して、以下のプロジェクトをレビューしてください：
-
-- PROJECT_NAME: $1
-- REPOSITORIES:
-  - {repo1.name}: {repo1.localPath}
-  - {repo2.name}: {repo2.localPath}
-  - ...
-- REVIEW_FOCUS: {指定されたfocus}
-
-品質ゲート判定結果をレポートしてください。
-
-### Step 4: レビューレポート出力
-
-出力先: `docs/michi/$1/reviews/cross-repo-review-{timestamp}.md`
-
-レポート形式:
-
-```markdown
-## Multi-Repo Cross-Repository Review Report
-
-**プロジェクト**: $1
-**レビュー日時**: {timestamp}
-**対象リポジトリ**: {count}件
-**レビュー観点**: {focus}
-
----
-
-### サマリー
-
-| カテゴリ | ステータス | 問題件数 |
-|---------|----------|---------|
-| API契約整合性 | ✅/⚠️/❌ | N件 |
-| データモデル整合性 | ✅/⚠️/❌ | N件 |
-| イベントスキーマ整合性 | ✅/⚠️/❌ | N件 |
-| 依存関係整合性 | ✅/⚠️/❌ | N件 |
-| テスト仕様整合性 | ✅/⚠️/❌ | N件 |
-
----
-
-### 検出された問題
-
-#### 🔴 BLOCK (修正必須)
-
-（cross-repo-reviewerが検出した重大な不整合）
-
-#### 🟡 WARN (修正推奨)
-
-（cross-repo-reviewerが検出した軽微な不整合）
-
----
-
-### 品質ゲート判定
-
-**判定**: ❌ 不合格 / ⚠️ 条件付き合格 / ✅ 合格
-
-**理由**: {判定理由}
-
----
-
-### 次のアクション
-
-1. BLOCK問題の修正
-2. `/michi-multi-repo:spec-review $1` を再実行
-3. 合格後、各リポジトリで実装を開始
-```
-
-### Step 5: 判定結果の表示
-
-**合格時（✅ PASS）**:
-```markdown
-🎉 品質ゲート合格
-
-全リポジトリの仕様が整合性基準を満たしています。
-
-### 次のステップ
-
-1. 各リポジトリでタスク生成:
-   各リポジトリで `/michi:spec-tasks {feature}` を実行
-
-2. 全リポジトリで実装を開始:
-   `/michi-multi-repo:impl-all $1`
-
-3. CI/CD設定:
-   `michi multi-repo:ci-status $1` でCI結果を監視
-```
-
-**条件付き合格時（⚠️ WARN）**:
-```markdown
-⚠️ 品質ゲート条件付き合格
-
-WARN問題が検出されましたが、修正は任意です。
-
-### 検出された問題
-- {WARN問題のリスト}
-
-### 次のステップ（選択可能）
-
-A) WARN問題を修正してから実装開始（推奨）
-   - 各リポジトリのdesign.mdを修正
-   - `/michi-multi-repo:spec-review $1` を再実行
-
-B) そのまま実装開始
-   - `/michi-multi-repo:impl-all $1`
-```
-
-**不合格時（❌ BLOCK）**:
-```markdown
-❌ 品質ゲート不合格
-
-BLOCK問題が検出されました。修正が必須です。
-
-### BLOCK問題
-- {BLOCK問題のリスト}
-
-### 対処方法
-
-1. 該当リポジトリのdesign.mdを修正
-2. `/michi-multi-repo:spec-review $1` を再実行
-3. 合格後に実装を開始
-
-**注意**: BLOCK問題を未解決のまま実装を開始すると、サービス間通信が失敗する可能性があります。
-```
-
-## Important Constraints
-- 読み取り操作のみ（各リポジトリへの書き込みは行わない）
-- localPath未設定のリポジトリはスキップ（警告を出力）
-- 大規模リポジトリの場合は主要ファイルのみ分析
-
-</instructions>
-
-## Tool Guidance
-- **Task**: cross-repo-reviewerサブエージェント起動に使用
-- **Read**: プロジェクト仕様、各リポジトリ仕様の読み込み
-- **Write**: レビューレポートの出力
-- **Glob/Grep**: 仕様ファイルの検索
-
-## Output Description
-
-日本語で以下の情報を出力してください:
-
-1. **レビュー対象リポジトリ一覧**: 各リポジトリのlocalPathと仕様状態
-2. **検出された問題**: BLOCK/WARN分類と詳細
-3. **品質ゲート判定結果**: 合格/不合格と理由
-4. **次のアクション**: 修正が必要な場合の具体的な手順
-
-## Safety & Fallback
-
-### Error Scenarios
-
-- **プロジェクト未登録**:
-  ```
-  エラー: プロジェクト '$1' が見つかりません。
-  ```
-
-- **親プロジェクト仕様未作成**:
-  ```
-  エラー: 親プロジェクトの設計書が見つかりません: docs/michi/$1/overview/architecture.md
-
-  先に親プロジェクトの設計を作成してください:
-  /michi-multi-repo:spec-design $1
-  ```
-
-- **localPath未設定**:
-  ```
-  警告: リポジトリ '{name}' の localPath が未設定です。スキップします。
-  ```
-
-- **Michi未セットアップ**:
-  ```
-  ⚠️ リポジトリ '{name}' にMichiがセットアップされていません。スキップします。
-
-  セットアップコマンド:
-  cd {localPath} && npx @sk8metal/michi-cli@latest init
-
-  セットアップ完了後、このコマンドを再実行してください。
-  ```
-
-- **仕様ファイル不存在**:
-  ```
-  警告: リポジトリ '{name}' に仕様ファイルがありません。
-
-  仕様を展開してください:
-  /michi-multi-repo:propagate-specs $1
-  ```
-
-### Fallback Strategy
-- localPath未設定: 該当リポジトリをスキップし、他のリポジトリでレビュー続行
-- Michi未セットアップ: 該当リポジトリをスキップし、他のリポジトリでレビュー続行
-- 仕様ファイル不存在: 警告を出力し、利用可能な情報でレビュー
-- 通信エラー: リトライ後、該当リポジトリをスキップ
-
-think hard

package/templates/claude/rules/atlassian-integration.md

@@ -1,35 +0,0 @@
----
-title: Atlassian Integration
-description: Integration rules for Confluence and JIRA via MCP
----
-
-# Atlassian Integration
-
-## Development Guidelines
-{{DEV_GUIDELINES}}
-
-## Language
-All generated documents should be in: **{{LANG_CODE}}**
-
-## MCP Integration
-
-### Confluence Sync
-- Sync specifications from {{KIRO_DIR}}/specs/ to Confluence
-- Use MCP server for Confluence operations
-- Project labels: Check {{KIRO_DIR}}/project.json
-
-### JIRA Sync
-- Create Epic and Stories from {{KIRO_DIR}}/specs/{{FEATURE_NAME}}/tasks.md
-- Use JIRA project key: {{PROJECT_ID}}
-- Link Confluence pages automatically
-
-## Project Metadata
-- Project ID: {{PROJECT_ID}}
-- Kiro directory: {{KIRO_DIR}}
-- Agent directory: {{AGENT_DIR}}
-
-## Workflow
-1. Create spec in {{KIRO_DIR}}/specs/{{FEATURE_NAME}}/
-2. Sync to Confluence via MCP
-3. Create JIRA Epic/Stories
-4. Link Confluence pages to JIRA

package/templates/claude/rules/michi-core.md

@@ -1,54 +0,0 @@
----
-title: Michi Core Principles
-description: Core principles for GitHub SSoT and multi-project management
----
-
-# Michi Core Principles
-
-## Development Guidelines
-{{DEV_GUIDELINES}}
-
-## Language
-All generated documents should be in: **{{LANG_CODE}}**
-
-Reference the language field in {{KIRO_DIR}}/project.json.
-
-## Single Source of Truth (SSoT)
-
-### GitHub as SSoT
-- **All specifications are managed in GitHub** ({{KIRO_DIR}}/specs/)
-- Confluence is **reference and approval only** (editing is GitHub only)
-- Avoid duplicate management
-
-### Data Flow
-```
-GitHub ({{KIRO_DIR}}/specs/)  ← Source of truth (editable)
-    ↓ sync
-Confluence ← Display and approval (read-only)
-```
-
-## Multi-Project Management
-
-### Project Identification
-- All operations reference {{KIRO_DIR}}/project.json
-- Dynamically use project ID, JIRA key, Confluence labels
-- Project ID: {{PROJECT_ID}}
-
-### Naming Conventions
-
-#### Confluence Pages
-- Format: `[{projectName}] {document_type}`
-- Example: `[{{PROJECT_ID}}] Requirements`
-
-#### JIRA Epic/Story
-- Format: `[{JIRA_KEY}] {title}`
-- Use project metadata from {{KIRO_DIR}}/project.json
-
-## Agent Directory
-- Agent configuration: {{AGENT_DIR}}
-- Rules location: {{AGENT_DIR}}/rules/
-- Commands location: {{AGENT_DIR}}/commands/
-
-## Feature Development
-- Feature name: {{FEATURE_NAME}}
-- Spec location: {{KIRO_DIR}}/specs/{{FEATURE_NAME}}/