@sk8metal/michi-cli 0.0.4 → 0.0.6

package/docs/multi-project.md

@@ -1,233 +0,0 @@
-# マルチプロジェクト管理ガイド
-
-> **凡例について**: `<feature>` などの記号の意味は [README.md#凡例の記号説明](../README.md#凡例の記号説明) を参照してください。
-
-## 概要
-
-Michiは、複数プロジェクト（3-5案件）を同時並行で管理できるように設計されています。
-
-## アーキテクチャ
-
-### マイクロサービス構成
-
-```
-organization/
-├── customer-a-service-1/  ← A社 サービス1
-│   └── .kiro/
-│       ├── project.json
-│       └── specs/
-├── customer-a-service-2/  ← A社 サービス2
-│   └── .kiro/
-├── customer-b-api/        ← B社 API
-│   └── .kiro/
-└── michi/                 ← 統合ハブ（本プロジェクト）
-    └── .kiro/
-```
-
-### 統合管理
-
-**Confluence**: 共有スペース（PRD, QA, RELEASE）
-- ラベルでプロジェクトを識別
-- プロジェクト横断ダッシュボード
-
-**JIRA**: プロジェクトキー別
-- PRJA（A社案件）
-- PRJB（B社案件）
-- MICHI（統合ハブ）
-
-## プロジェクトのセットアップ
-
-### 新規プロジェクト追加
-
-詳細な手順は [新規プロジェクトセットアップガイド](./new-project-setup.md) を参照してください。
-
-**クイックスタート**:
-1. 既存リポジトリに追加: `bash /path/to/michi/scripts/setup-existing.sh`
-2. 新規リポジトリ作成: `npm run create-project -- --name <id> --project-name <name> --jira-key <key>`
-
-**マルチプロジェクト特有の注意点**:
-- 各プロジェクトは独立したリポジトリで管理
-- `.kiro/project.json`でプロジェクトを識別
-- Confluenceラベルでプロジェクト横断検索が可能
-
-### 環境変数設定
-
-各プロジェクトで`.env`ファイルを設定します。詳細は [新規プロジェクトセットアップガイド](./new-project-setup.md#step-5-環境変数設定) を参照してください。
-
-### 動作確認
-
-セットアップ完了後、プロジェクト情報を確認します：
-
-```bash
-# プロジェクト情報を表示
-cat .kiro/project.json
-
-# テスト機能で確認（オプション）
-/kiro:spec-init テスト機能
-/kiro:spec-requirements test-feature
-npx @michi/cli phase:run test-feature requirements
-```
-
-## プロジェクト切り替え
-
-### Cursorで切り替え
-
-```
-/kiro:project-switch customer-a-service-1
-```
-
-### ターミナルで切り替え
-
-```bash
-cd ~/work/projects/customer-a-service-1
-cat .kiro/project.json
-```
-
-## プロジェクト横断操作
-
-### すべてのプロジェクトを一覧表示
-
-```bash
-npm run project:list
-```
-
-出力例：
-```
-📋 プロジェクト一覧:
-
-| プロジェクト | ID | ステータス | JIRA | チーム |
-|------------|-------|----------|------|--------|
-| Michi | michi | active | MICHI | @developer1 |
-| A社 サービス1 | customer-a-service-1 | active | PRJA | @dev1, @dev2 |
-| B社 API | customer-b-api | active | PRJB | @dev3 |
-
-合計: 3 プロジェクト
-```
-
-### リソースダッシュボード生成
-
-```bash
-npm run project:dashboard
-```
-
-Confluenceに「プロジェクトリソースダッシュボード」ページを作成します。
-
-### プロジェクト横断見積もり集計
-
-```bash
-npm run multi-estimate
-```
-
-すべてのプロジェクトの見積もりを集計し、Excelファイルに出力します。
-
-## Confluenceダッシュボード
-
-### プロジェクト一覧ページ
-
-Confluenceで作成：
-
-**ページタイトル**: プロジェクト一覧
-
-**コンテンツ**:
-```
-{report-table:space=PRD|label=requirements|columns=title,labels,status}
-```
-
-**フィルタ例**:
-- A社案件のみ: `label = "project:a"`
-- レビュー待ち: `status = "レビュー待ち"`
-- 設計フェーズ: `label = "design"`
-
-### JIRAダッシュボード
-
-**フィルタ**:
-```
-project IN (MICHI, PRJA, PRJB) AND status IN ("In Progress", "In Review")
-```
-
-**グルーピング**: プロジェクトキー別
-
-**集計**: ストーリーポイント合計
-
-## プロジェクト間の依存関係
-
-プロジェクトは基本的に独立していますが、共通基盤がある場合：
-
-### 共通ライブラリプロジェクト
-
-```
-shared-infrastructure/
-└── .kiro/
-    └── project.json
-        {
-          "projectId": "shared-infra",
-          "projectName": "共通基盤",
-          "jiraProjectKey": "INFRA",
-          ...
-        }
-```
-
-### 依存関係の記述
-
-各プロジェクトの `.kiro/project.json` に追加：
-```json
-{
-  "dependencies": ["shared-infra"],
-  "dependents": ["customer-a-service-1", "customer-b-api"]
-}
-```
-
-## ベストプラクティス
-
-### 命名規則の統一
-
-**プロジェクトID**: `customer-{id}-{service}`
-- 例: `customer-a-service-1`, `customer-b-api`
-
-**JIRA プロジェクトキー**: 3-4文字
-- 例: `PRJA`, `PRJB`, `MICHI`
-
-**Confluenceラベル**: `project:{projectId}, service:{service}`
-- 例: `project:customer-a-service-1, service:s1`
-
-**ラベル生成ロジック**: 詳細は [新規プロジェクトセットアップガイド](./new-project-setup.md#ラベル生成ロジック) を参照してください。
-### チーム構成の明確化
-
-各プロジェクトの `team` フィールドに担当者を記載：
-```json
-{
-  "team": ["@tech-lead", "@frontend-dev", "@backend-dev"]
-}
-```
-
-### ステータス管理
-
-プロジェクトのステータスを適切に更新：
-- `active`: 開発中
-- `maintenance`: 保守フェーズ
-- `completed`: 完了
-- `inactive`: 休止中
-
-## トラブルシューティング
-
-### プロジェクトが一覧に表示されない
-
-`.kiro/project.json` が正しく作成されているか確認：
-```bash
-cat .kiro/project.json
-```
-
-### Confluenceで他のプロジェクトが見える
-
-ラベルでフィルタリング：
-```
-label = "project:michi"
-```
-
-### JIRA チケットが混在
-
-プロジェクトキーでフィルタリング：
-```
-project = MICHI
-```
-

package/docs/testing.md

@@ -1,202 +0,0 @@
-# テスト・検証ガイド
-
-> **凡例について**: `<feature>` などの記号の意味は [README.md#凡例の記号説明](../README.md#凡例の記号説明) を参照してください。
-
-## E2Eテストシナリオ
-
-### シナリオ1: 単一機能の完全フロー
-
-新機能「ユーザー認証」を要件定義からリリースまで実行：
-
-#### Step 1: 要件定義
-```bash
-# 凡例
-/kiro:spec-init <機能説明>
-/kiro:spec-requirements <feature>
-jj commit -m "docs: <feature> 要件定義"
-jj git push
-npm run confluence:sync <feature> requirements
-
-# 具体例
-/kiro:spec-init OAuth 2.0を使ったユーザー認証機能
-/kiro:spec-requirements user-auth
-jj commit -m "docs: ユーザー認証 要件定義"
-jj git push
-npm run confluence:sync user-auth requirements
-```
-
-**確認ポイント**:
-- [ ] `.kiro/specs/user-auth/requirements.md` が生成された
-- [ ] Confluenceページが作成された
-- [ ] ラベル `project:michi, requirements, user-auth` が付与された
-- [ ] 企画・部長にメンション通知が届いた
-
-#### Step 2: 設計
-```bash
-# 凡例
-/kiro:spec-design <feature>
-jj commit -m "docs: <feature> 設計"
-jj git push
-npm run confluence:sync <feature> design
-npm run excel:sync <feature>
-
-# 具体例
-/kiro:spec-design user-auth
-jj commit -m "docs: ユーザー認証 設計"
-jj git push
-npm run confluence:sync user-auth design
-npm run excel:sync user-auth
-```
-
-**確認ポイント**:
-- [ ] `.kiro/specs/user-auth/design.md` が生成された
-- [ ] 見積もりセクションが含まれている
-- [ ] Confluenceページが作成された（親: 要件定義）
-- [ ] Excelファイルが出力された
-
-#### Step 3: タスク分割
-```bash
-# 凡例
-/kiro:spec-tasks <feature>
-jj commit -m "docs: <feature> タスク分割"
-jj git push
-npm run jira:sync <feature>
-
-# 具体例
-/kiro:spec-tasks user-auth
-jj commit -m "docs: ユーザー認証 タスク分割"
-jj git push
-npm run jira:sync user-auth
-```
-
-**確認ポイント**:
-- [ ] `.kiro/specs/user-auth/tasks.md` が生成された
-- [ ] JIRA Epicが作成された
-- [ ] JIRA Storyが作成された（複数）
-- [ ] Epic-Storyリンクが設定された
-
-#### Step 4: 実装
-```
-/kiro:spec-impl user-auth FE-1,BE-1
-jj commit -m "feat: ユーザー認証実装 [MICHI-123]"
-jj bookmark create michi/feature/user-auth -r '@-'
-jj git push --bookmark michi/feature/user-auth --allow-new
-npm run github:create-pr michi/feature/user-auth
-```
-
-**確認ポイント**:
-- [ ] テストが先に書かれた（TDD）
-- [ ] コードが実装された
-- [ ] PRが作成された
-- [ ] JIRA ステータスが "In Review" に更新された
-
-### シナリオ2: マルチプロジェクト横断テスト
-
-3つのプロジェクトで同時に要件定義を実施：
-
-```bash
-# プロジェクトA
-cd customer-a-service-1
-/kiro:spec-requirements payment-feature
-npm run confluence:sync payment-feature
-
-# プロジェクトB
-cd ../customer-b-api
-/kiro:spec-requirements user-api
-npm run confluence:sync user-api
-
-# プロジェクトC（Michi）
-cd ../michi
-/kiro:spec-requirements integration-hub
-npm run confluence:sync integration-hub
-
-# 横断確認
-npm run project:list
-npm run project:dashboard
-```
-
-**確認ポイント**:
-- [ ] 3つのプロジェクトすべてでページ作成成功
-- [ ] Confluenceダッシュボードに3プロジェクト表示
-- [ ] ラベルでフィルタリング可能
-- [ ] JIRAダッシュボードに3プロジェクト表示
-
-## チームフィードバック収集
-
-### フィードバック項目
-
-#### 使いやすさ
-- [ ] Cursorコマンドは直感的か？
-- [ ] ドキュメントは理解しやすいか？
-- [ ] エラーメッセージは明確か？
-
-#### 効率性
-- [ ] 要件定義の時間短縮できたか？
-- [ ] Confluence/JIRA連携は手間を減らしたか？
-- [ ] 全体の開発スピードは向上したか？
-
-#### 品質
-- [ ] AIが生成する仕様書の品質は十分か？
-- [ ] テンプレートは実務に適しているか？
-- [ ] 見積もりの精度は妥当か？
-
-### フィードバック方法
-
-GitHub Issuesで収集：
-```bash
-gh issue create --title "フィードバック: <内容>" --body "<詳細>"
-```
-
-ラベル:
-- `feedback:usability`: 使いやすさ
-- `feedback:efficiency`: 効率性
-- `feedback:quality`: 品質
-
-## 継続的改善
-
-### Week 1-2: パイロット運用
-- 1プロジェクトで全フロー実行
-- 問題点を記録
-- フィードバック収集
-
-### Week 3-4: 改善
-- テンプレート調整
-- スクリプト改善
-- ドキュメント更新
-
-### Week 5-6: 横展開
-- 2-3プロジェクトに展開
-- チーム全体でフィードバック
-
-### Week 7-8: 最適化
-- ベストプラクティス確立
-- 自動化範囲の拡大
-- ツールの安定化
-
-## メトリクス
-
-### 効率化指標
-
-| 指標 | 導入前 | 導入後 | 改善率 |
-|------|--------|--------|--------|
-| 要件定義時間 | 3日 | 0.5日 | 83% |
-| 設計時間 | 5日 | 1日 | 80% |
-| タスク分割時間 | 2日 | 0.5日 | 75% |
-| ドキュメント作成 | 2日 | 0.2日 | 90% |
-
-### 品質指標
-
-| 指標 | 目標値 | 測定方法 |
-|------|--------|---------|
-| 仕様書の完成度 | 90%以上 | レビュースコア |
-| 見積もり精度 | ±20%以内 | 実績との比較 |
-| テストカバレッジ | 95%以上 | 自動測定 |
-
-## 次のステップ
-
-1. パイロットプロジェクトでE2Eテスト実行
-2. フィードバック収集
-3. 改善実施
-4. 他プロジェクトに横展開
-5. ベストプラクティス確立
-