@hummer98/cmux-team 3.0.0

package/commands/team-spec.md

@@ -0,0 +1,133 @@
+---
+allowed-tools: Bash, Read, Write, Edit, Glob, Grep
+description: "要件を対話的にブレストし仕様を策定する"
+---
+
+# /team-spec
+
+ユーザーと対話的に要件をブレストし、仕様を策定してください。
+
+## 手順
+
+### 1. 前提チェック
+
+- `.team/team.json` が存在すること（なければ `/team-init` を案内）
+
+### 2. 既存仕様の読み込み
+
+以下のファイルが存在すれば読み込む:
+- `.team/specs/requirements.md` — 既存の要件定義
+- `.team/specs/research.md` — リサーチ結果（`/team-research` の成果）
+- `.team/team.json` — プロジェクト説明
+
+### 3. コンテキスト収集
+
+プロジェクトの現状を把握する:
+- カレントディレクトリの構造を確認（主要ファイル・ディレクトリ）
+- README.md や既存ドキュメントがあれば読む
+- `.team/tasks/` にタスクがあれば確認（`task-state.json` で状態確認）
+
+### 4. 対話的ブレスト
+
+ユーザーと以下の項目を対話形式で詰めていく:
+
+#### a. プロジェクト概要
+- 何を作るのか（What）
+- なぜ作るのか（Why）
+- 誰が使うのか（Who）
+
+#### b. 機能要件
+- 必須機能（Must-have）
+- あると嬉しい機能（Nice-to-have）
+- スコープ外（Out of scope）
+
+#### c. 非機能要件
+- パフォーマンス要件
+- セキュリティ要件
+- 互換性・制約
+
+#### d. 技術的な制約・前提
+- 使用する技術スタック
+- 既存システムとの連携
+- デプロイ環境
+
+**対話のルール**:
+- 一度に多くの質問をせず、2-3 項目ずつ確認する
+- ユーザーの回答を要約して確認を取る
+- 不明瞭な点があれば具体例を挙げて確認する
+- リサーチが必要な項目があれば `/team-research` の実行を提案する
+
+### 5. 要件ドキュメント生成
+
+対話で集まった情報を以下の形式で `.team/specs/requirements.md` に書き出す:
+
+```markdown
+# 要件定義: <プロジェクト名>
+
+## 概要
+<プロジェクトの簡潔な説明>
+
+## 目的
+<なぜこのプロジェクトが必要か>
+
+## ターゲットユーザー
+<誰が使うのか>
+
+## 機能要件
+
+### Must-have
+- [ ] REQ-001: <要件名> — <詳細>
+- [ ] REQ-002: <要件名> — <詳細>
+
+### Nice-to-have
+- [ ] REQ-N01: <要件名> — <詳細>
+
+### Out of scope
+- <スコープ外の項目>
+
+## 非機能要件
+- NFR-001: <要件名> — <詳細>
+
+## 技術的制約
+- <制約事項>
+
+## 前提条件
+- <前提事項>
+
+## 未決事項
+- <オープンな質問>
+```
+
+### 6. ユーザー承認
+
+生成した要件ドキュメントをユーザーに提示し:
+- 内容に問題がなければ承認を得る
+- 修正が必要な場合は対話を続けて更新する
+- 承認後、ドキュメントの末尾に承認ステータスを追記:
+  ```markdown
+  ---
+  Status: Approved
+  Approved at: <ISO 8601 タイムスタンプ>
+  ```
+
+### 7. 次のステップ案内
+
+（team.json の phase 更新は daemon が自動的に行う）
+
+```
+要件定義が完了しました。
+
+次のステップ:
+  /team-design    → 設計フェーズに進む（アーキテクト + レビュアー起動）
+  /team-research  → 追加リサーチが必要な場合
+```
+
+## 引数
+
+`$ARGUMENTS` が指定された場合は、その内容をプロジェクト概要の初期入力として使用する。
+
+## 注意事項
+
+- 既存の requirements.md がある場合は上書きせず、更新として扱う
+- 対話中にユーザーが「もういい」「これでOK」等と言った場合は、その時点の情報でドキュメントを生成する
+- リサーチ結果がある場合は要件の裏付けとして積極的に参照する

package/commands/team-status.md

@@ -0,0 +1,24 @@
+---
+allowed-tools: Bash, Read, Glob, Grep
+description: "チームの現在の状態を表示する"
+---
+
+# /team-status
+
+チームの現在の状態を表示してください。
+
+## 手順
+
+1. .team/team.json を読む（なければ未初期化を案内）
+2. 以下の真のソースから直接情報を取得して表示:
+   - **Manager の状態**: `cmux read-screen --surface <manager-surface> --lines 5` で画面を確認
+   - **稼働中の Conductor**: `cmux tree` でペイン構成を確認
+   - **オープンタスク**: `ls .team/tasks/` でファイル一覧 + `cat .team/task-state.json` で状態を確認
+   - **完了タスク履歴**: `grep task_completed .team/logs/manager.log`
+   - **クローズ済みタスク数**: `cat .team/task-state.json` の closed エントリ数
+3. アーキテクチャ: 4-tier (Master → Manager → Conductor → Agent)
+4. Manager が応答しているか cmux read-screen で簡易ヘルスチェック
+
+## 引数
+
+なし

package/commands/team-sync-docs.md

@@ -0,0 +1,127 @@
+---
+allowed-tools: Bash, Read, Write, Edit, Glob, Grep
+description: "ドキュメントをスペックと同期する"
+---
+
+# /team-sync-docs
+
+`docs/` を `.team/specs/` の現在の状態と同期してください。
+
+## 手順
+
+### 1. 前提チェック
+
+- `.team/team.json` が存在すること（なければ `/team-init` を案内）
+- `.team/specs/` にファイルが存在すること
+
+### 2. 現在のスペック状態の収集
+
+`.team/specs/` 内の全ファイルを読み込む:
+- `requirements.md` — 要件定義
+- `research.md` — リサーチ結果
+- `design.md` — 設計ドキュメント
+- `tasks.md` — タスク一覧
+- その他のスペックファイル
+
+### 3. スナップショットとの差分検出
+
+`.team/docs-snapshot/` と比較:
+
+```bash
+# スナップショットが存在しない場合は初回同期
+ls .team/docs-snapshot/ 2>/dev/null
+
+# 差分検出
+diff -rq .team/specs/ .team/docs-snapshot/ 2>/dev/null
+```
+
+- スナップショットが存在しない場合: 全ファイルが「新規」扱い
+- 差分がない場合: 「ドキュメントは最新です」と表示して終了
+
+### 4. ドキュメント生成・更新
+
+team.json からプロジェクト名を取得し、`docs/` 構造を生成:
+
+#### ドキュメント構成
+
+```
+docs/
+├── README.md               # プロジェクト概要（requirements.md ベース）
+├── design.md               # 技術設計（design.md を整形）
+├── tasks.md                # タスク一覧と進捗（tasks.md を整形）
+└── research/               # リサーチ結果（あれば）
+    └── <topic>.md
+```
+
+#### 生成ルール
+
+**docs/README.md** (または既存の docs/README.md を更新):
+- requirements.md から「概要」「目的」「機能要件」セクションを抽出
+- ユーザー向けの読みやすい形式に整形
+- 技術的な内部詳細は除外
+
+**docs/design.md**:
+- design.md の内容を整形
+- 内部実装の詳細（ファイルパス等）は一般化
+- Mermaid ダイアグラムはそのまま維持
+
+**docs/tasks.md**:
+- tasks.md の内容を進捗ステータス付きで表示
+- 完了済み/進行中/未着手のステータスを反映
+
+### 5. スナップショット更新
+
+```bash
+# 現在の specs/ をスナップショットとしてコピー
+rm -rf .team/docs-snapshot/*
+cp -r .team/specs/* .team/docs-snapshot/
+```
+
+### 6. 差分サマリーの表示
+
+ユーザーに以下を表示:
+
+```
+## ドキュメント同期完了
+
+### 変更内容
+- 更新: docs/README.md (要件からの概要更新)
+- 新規: docs/design.md (設計ドキュメント追加)
+- 更新: docs/tasks.md (進捗ステータス反映)
+
+### 次回同期で検出する変更
+- .team/specs/ 内のファイルが変更された場合
+```
+
+### 7. git コミット（オプション）
+
+ユーザーに確認: 「ドキュメントの変更を git commit しますか？」
+
+YES の場合:
+```bash
+git add docs/
+git commit -m "docs: sync documentation with current specs"
+```
+
+### 8. DocKeeper エージェント（オプション）
+
+ドキュメントの品質をさらに向上させたい場合:
+- ユーザーに確認: 「DocKeeper エージェントを起動してドキュメントを精査しますか？」
+- YES の場合:
+  1. `~/.claude/skills/cmux-team/templates/dockeeper.md` からプロンプトを生成
+  2. エージェントを起動し、docs/ の整形・改善を実施
+  3. 完了後に差分を表示
+
+### 9. 状態更新
+
+- team.json は更新しない（sync-docs はフェーズを変更しない補助コマンド）
+
+## 引数
+
+なし
+
+## 注意事項
+
+- `docs/` に既存のユーザー作成ドキュメントがある場合は上書きせず、マージを試みる
+- スペックに機密情報が含まれていないか注意する（内部実装詳細の除外）
+- docs-snapshot/ は gitignore されているため、同期状態はローカルのみで管理される

package/commands/team-task.md

@@ -0,0 +1,158 @@
+---
+allowed-tools: Bash, Read, Write, Edit, Glob, Grep
+description: "タスクの作成・一覧・クローズ・表示を管理する"
+---
+
+# /team-task
+
+`.team/tasks/` のタスクを管理してください。
+
+## サブコマンド判定
+
+`$ARGUMENTS` を解析し、以下のいずれかの操作を実行する:
+
+- `$ARGUMENTS` = "" または未指定 → **一覧表示**
+- `$ARGUMENTS` が "create " で始まる → **新規作成**（"create " 以降がタイトル）
+- `$ARGUMENTS` が "close " で始まる → **クローズ**（"close " 以降が ID）
+- `$ARGUMENTS` が "show " で始まる → **詳細表示**（"show " 以降が ID）
+- `$ARGUMENTS` がその他の文字列 → **新規作成のショートハンド**（文字列全体がタイトル）
+
+---
+
+## 操作: 一覧表示
+
+### 手順
+
+1. `.team/tasks/` の全ファイルを読み込む
+2. `cat .team/task-state.json` でタスク状態を取得
+3. 各タスクの YAML フロントマターと状態を組み合わせて解析
+4. 一覧を表形式で表示:
+
+```
+## オープンタスク (N件)
+
+| ID  | タイトル                    | タイプ    | ステータス | 起票者         | 作成日     |
+|-----|---------------------------|----------|----------|---------------|-----------|
+| 001 | 認証トークンの有効期限設計   | decision | ready    | architect      | 2026-03-19 |
+| 002 | DB接続のタイムアウト        | blocker  | draft    | implementer-1  | 2026-03-19 |
+
+## クローズ済み (M件)
+
+| ID  | タイトル                    | タイプ    | 起票者         | 作成日     |
+|-----|---------------------------|----------|---------------|-----------|
+| 000 | 初期設計の方針決定          | decision | architect      | 2026-03-18 |
+```
+
+タスクが 0 件の場合: 「オープンタスクはありません」
+
+---
+
+## 操作: 新規作成
+
+### 手順
+
+1. **次のタスク番号を決定**:
+   ```bash
+   # tasks/ の全ファイルから最大の ID を取得
+   ls .team/tasks/ 2>/dev/null | grep -oE '^[0-9]+' | sort -n | tail -1
+   # → 最大 ID + 1。ファイルがなければ 001 から開始
+   ```
+
+2. **タスク情報の収集**:
+   タイトルは `$ARGUMENTS` から取得済み。以下を対話的に確認:
+   - **タイプ**: decision / blocker / finding / question
+   - **コンテキスト**: このタスクの背景（1-2 文）
+   - **選択肢**（decision/question の場合）: 検討中のオプション
+   - **推奨案**（あれば）
+
+3. **タスクファイルを作成**:
+   ファイル名: `.team/tasks/NNN-<slug>.md`
+   （slug はタイトルから英数字・ハイフンに変換、30 文字以内）
+
+   ```markdown
+   ---
+   id: NNN
+   title: "<タイトル>"
+   type: <タイプ>
+   raised_by: conductor
+   created_at: <ISO 8601 タイムスタンプ>
+   ---
+
+   ## Context
+   <コンテキスト>
+
+   ## Options
+   1. <選択肢 A> — メリット/デメリット
+   2. <選択肢 B> — メリット/デメリット
+
+   ## Recommendation
+   <推奨案>
+   ```
+
+   タスクファイルには status を含めない（title, body, priority のみ）。
+   status は `task-state.json` で管理する。
+
+   **status について:**
+   - `draft` — 作成直後。Manager は無視する（ユーザー確認待ち）
+   - `ready` — 着手 OK。Manager が走査して Conductor を起動する
+
+   新規作成時は `bun run main.ts create-task --title <title> --priority <p> --status draft` を使用。
+
+4. **作成確認**:
+   作成したタスクの内容を表示。
+
+---
+
+## 操作: クローズ
+
+### 手順
+
+1. **タスクファイルを検索**:
+   ```bash
+   ls .team/tasks/ | grep "^$ID"
+   ```
+
+2. **タスクが見つからない場合**:
+   「ID: $ID のオープンタスクが見つかりません」と表示
+
+3. **CLI でタスクをクローズ**:
+   ```bash
+   bun run main.ts close-task --task-id $ID --journal "closed by user"
+   ```
+
+4. **確認表示**:
+   「タスク #NNN をクローズしました: <タイトル>」
+
+---
+
+## 操作: 詳細表示
+
+### 手順
+
+1. **タスクファイルを検索**:
+   ```bash
+   ls .team/tasks/ 2>/dev/null | grep "^$ID"
+   ```
+
+2. **タスクが見つからない場合**:
+   「ID: $ID のタスクが見つかりません」と表示
+
+3. **タスクの全内容を表示**:
+   ファイルの全内容を読み込み、`task-state.json` の状態と合わせて整形表示。
+
+---
+
+## 前提チェック
+
+すべての操作の前に:
+- `.team/team.json` が存在すること
+- `.team/tasks/` ディレクトリが存在すること（なければ作成）
+
+## 引数
+
+`$ARGUMENTS` = サブコマンドと引数:
+- "" → 一覧表示
+- "create <title>" → 新規作成
+- "close <id>" → クローズ
+- "show <id>" → 詳細表示
+- "<title>" → 新規作成のショートハンド

package/commands/team-test.md

@@ -0,0 +1,230 @@
+---
+allowed-tools: Bash, Read, Write, Edit, Glob, Grep
+description: "テストエージェントを起動しテストを作成・実行する"
+---
+
+# /team-test
+
+テストエージェントを起動し、テストの作成と実行を行ってください。
+
+## 手順
+
+### 1. 前提チェック
+
+- `.team/team.json` が存在すること
+- `CMUX_SOCKET_PATH` が設定されていること
+- `cmux` コマンドが利用可能であること
+
+### 2. テストスコープの決定
+
+`$ARGUMENTS` に基づいてスコープを決定:
+
+- `"unit"` → ユニットテストのみ
+- `"integration"` → 統合テストのみ
+- `"e2e"` → E2E テストのみ
+- `"all"` → 全スコープ（最大 3 エージェント）
+- 空 → プロジェクトの構成を分析して自動決定
+
+自動決定の基準:
+- テストフレームワークの検出（jest, pytest, go test, etc.）
+- 既存のテストファイルの構造を確認
+- 変更されたファイルの種類に基づいて適切なスコープを選択
+
+### 3. コンテキスト収集
+
+以下を読み込む:
+- `.team/specs/requirements.md` — テスト対象の要件
+- `.team/specs/design.md` — 設計ドキュメント
+- `.team/output/implementer-*.md` — 実装出力（変更ファイル一覧）
+- 既存のテストファイル（パターン検出用）
+- `git diff` — 最近の変更内容
+
+```bash
+# 変更されたファイル一覧
+git diff --name-only HEAD~10 -- . ':!.team'
+
+# テストファイルの既存パターン
+find . -name "*test*" -o -name "*spec*" | head -20
+```
+
+### 4. テストエージェント数の決定
+
+- `"unit"` のみ: 1 エージェント
+- `"integration"` のみ: 1 エージェント
+- `"e2e"` のみ: 1 エージェント
+- `"all"` または自動: 最大 3 エージェント（各スコープに 1 名）
+- 該当するスコープがない場合は省略（例: E2E テストが不要なプロジェクト）
+
+### 5. プロンプト生成
+
+各テストエージェントに対して:
+
+1. `~/.claude/skills/cmux-team/templates/common-header.md` を読み込み
+2. `~/.claude/skills/cmux-team/templates/tester.md` を読み込み
+3. テンプレート変数を置換:
+   - `{{ROLE_ID}}` → `tester-unit`, `tester-integration`, `tester-e2e`
+   - `{{TASK_DESCRIPTION}}` → "<スコープ>テストの作成と実行"
+   - `{{OUTPUT_FILE}}` → `.team/output/tester-<scope>.md`
+   - `{{PROJECT_ROOT}}` → カレントディレクトリ
+   - `{{TEST_SCOPE}}` → テストスコープの説明と対象ファイル
+   - `{{IMPLEMENTATION_SUMMARY}}` → 実装出力のサマリー + git diff
+   - `{{REQUIREMENTS_CONTENT}}` → requirements.md の内容
+   - `{{COMMON_HEADER}}` → 展開済み共通ヘッダー
+4. `.team/prompts/tester-<scope>.md` に書き出す
+
+### 6. テストエージェント起動
+
+サブエージェントの配置は cmux-team SKILL.md §5 参照。
+
+```bash
+# Conductor と同じワークスペース内で分割（デフォルト）
+cmux new-split right  # → surface:S
+# 複数テスターの場合は追加分割
+# cmux new-split right  # → surface:S2
+```
+
+各テスターに対して（**1体ずつ、cmux-team SKILL.md §2.1 の手順に従う**）:
+
+```bash
+# a. ステータス設定
+cmux set-status tester-<scope> "spawning" --icon sparkle --color "#ffcc00"
+
+# c. Claude 起動（シェルコマンドは \n で送信可能）
+cmux send --surface surface:S --workspace workspace:W "claude --dangerously-skip-permissions\n"
+
+# d. 起動完了を待つ（Trust確認 or ❯ プロンプトをポーリング、SKILL.md §2.1 Step 5 参照）
+for i in $(seq 1 10); do
+  SCREEN=$(cmux read-screen --surface surface:S --workspace workspace:W 2>&1)
+  if echo "$SCREEN" | grep -q "Yes, I trust"; then
+    cmux send-key --surface surface:S --workspace workspace:W "return"
+    sleep 5; break
+  elif echo "$SCREEN" | grep -q '❯'; then
+    break
+  fi
+  sleep 3
+done
+
+# e. プロンプト送信（単一行指示 → \n で送信可能）
+cmux send --surface surface:S --workspace workspace:W ".team/prompts/tester-<scope>.md を読んで指示に従ってください。\n"
+
+# f. 送信確認 + ステータス更新
+sleep 3
+SCREEN=$(cmux read-screen --surface surface:S --workspace workspace:W 2>&1)
+if ! echo "$SCREEN" | grep -qE '(Stewing|Thinking|Reading|Searching|Ideating)'; then
+  cmux send-key --surface surface:S --workspace workspace:W "return"
+  sleep 3
+fi
+cmux set-status tester-<scope> "running" --icon hammer --color "#0099ff"
+```
+
+### 7. 完了待機
+
+```bash
+cmux set-progress 0.0 --label "Testing: 0/N scopes done"
+
+# 各エージェントの完了を待つ
+cmux wait-for "tester-unit-done" --timeout 300
+cmux wait-for "tester-integration-done" --timeout 300
+cmux wait-for "tester-e2e-done" --timeout 300
+```
+
+### 8. テスト結果の収集
+
+各エージェントの出力を読み込み:
+- `.team/output/tester-unit.md`
+- `.team/output/tester-integration.md`
+- `.team/output/tester-e2e.md`
+
+### 9. テスト実行の検証
+
+エージェントの報告に加えて、Conductor 自身でもテストを実行して結果を確認:
+
+```bash
+# プロジェクトのテストランナーを検出して実行
+# 例: npm test, pytest, go test ./..., etc.
+```
+
+### 10. 結果統合
+
+テスト結果を統合してユーザーに提示:
+
+```markdown
+## テスト結果サマリー
+
+### 概要
+- ユニットテスト: ✅ 15 passed / ❌ 2 failed
+- 統合テスト: ✅ 8 passed / ❌ 0 failed
+- E2E テスト: ⏭️ スキップ
+
+### 失敗したテスト
+1. `test_auth_token_refresh` — Expected 200, got 401
+2. `test_session_timeout` — Timeout after 5s
+
+### 新規作成テスト
+- `tests/unit/test_auth.py` (5 tests)
+- `tests/integration/test_api.py` (8 tests)
+
+### カバレッジ
+- 要件カバレッジ: 12/15 (80%)
+- 未カバー要件: REQ-003, REQ-007, REQ-012
+```
+
+### 11. テスト失敗のタスク化
+
+失敗したテストに対して自動的にタスクを作成:
+
+`.team/tasks/NNN-test-failure-<name>.md`:
+```markdown
+---
+id: NNN
+title: "[Test] <テスト名> が失敗"
+type: finding
+raised_by: tester-<scope>
+created_at: <ISO 8601>
+severity: major
+---
+
+## 失敗内容
+<エラーメッセージ>
+
+## 期待される動作
+<期待値>
+
+## 実際の動作
+<実際の値>
+
+## 対象ファイル
+- <テストファイル>
+- <テスト対象ファイル>
+```
+
+### 12. クリーンアップと状態更新
+
+- テストエージェントのペインを閉じる
+- （team.json は daemon が自動更新する）
+- プログレスバーをクリア
+
+### 13. 次のステップ案内
+
+```
+テストフェーズが完了しました。
+
+結果: X passed / Y failed
+カバレッジ: Z%
+タスク作成: N 件
+
+次のステップ:
+  /team-impl       → テスト失敗の修正（失敗がある場合）
+  /team-sync-docs  → ドキュメント同期
+  /team-task       → タスクの確認・管理
+```
+
+## 引数
+
+`$ARGUMENTS` = テストスコープ（"unit", "integration", "e2e", "all"）。オプション。
+
+## エラーハンドリング
+
+- テストフレームワークが見つからない場合: プロジェクトの技術スタックを分析し、適切なフレームワークを提案
+- テスト実行がタイムアウトした場合: 無限ループや重いテストの可能性を報告
+- エージェントがテストを書けなかった場合: 出力を確認し、手動での対応を提案