New Track

仕様書と段階的な実装計画を備えた新しいトラック（機能、バグ修正、雑務、またはリファクタリング）を作成します。

このスキルを使用する場合

• 新しいトラックタスクまたはワークフローに取り組む場合
• 新しいトラックのガイダンス、ベストプラクティス、またはチェックリストが必要な場合

このスキルを使用しない場合

• タスクが新しいトラックと関係がない場合
• このスコープの外にある別のドメインまたはツールが必要な場合

指示

• 目標、制約、必要な入力を明確にします。
• 関連するベストプラクティスを適用し、結果を検証します。
• 実行可能なステップと検証を提供します。
• 詳細な例が必要な場合は、resources/implementation-playbook.md を開きます。

プリフライトチェック

1. Conductor が初期化されていることを確認：

   • conductor/product.md が存在することを確認
   • conductor/tech-stack.md が存在することを確認
   • conductor/workflow.md が存在することを確認
   • 不足している場合：エラーを表示し、最初に /conductor:setup を実行することをお勧めします

2. コンテキストファイルを読み込み：

   • conductor/product.md からプロダクトコンテキストを読み込み
   • conductor/tech-stack.md から技術コンテキストを読み込み
   • conductor/workflow.md から TDD/コミット設定を読み込み

トラック分類

説明に基づいてトラックタイプを判定するか、ユーザーに確認：

このトラックはどのタイプですか？

1. Feature - 新しい機能
2. Bug - 既存の問題の修正
3. Chore - メンテナンス、依存関係、設定
4. Refactor - 動作を変えないコード改善

インタラクティブな仕様書の収集

重要なルール：

• 1ターンにつき1つの質問をする
• ユーザーの応答を待ってから進める
• トラックタイプに基づいて質問をカスタマイズ
• 最大6つの質問

機能トラック用

Q1: 機能の要約

機能を1～2文で説明してください。
[引数が提供されている場合、確認：「{引数} を実装したいということですね。正しいですか?」]

Q2: ユーザーストーリー

誰が、どのようなメリットを得ますか？

形式: As a [ユーザータイプ], I want to [アクション] so that [メリット].

Q3: 受け入れ基準

この機能が完成するには何が必要ですか？

3～5個の受け入れ基準をリストアップしてください（1行に1つ）：

Q4: 依存関係

これは既存のコード、API、または他のトラックに依存していますか？

1. 依存関係なし
2. 既存のコードに依存（詳細を指定）
3. 不完全なトラックに依存（詳細を指定）

Q5: スコープ境界

このトラックの範囲外で明確に何がありますか？
（スコープ拡大を防ぐのに役立ちます）

Q6: 技術的検討（オプション）

特定の技術アプローチまたは制約がありますか？
（スキップするにはEnterキーを押します）

バグトラック用

Q1: バグの要約

何が壊れていますか？
[引数が提供されている場合、確認]

Q2: 再現手順

このバグはどうしたら再現できますか？
ステップをリストアップしてください：

Q3: 期待動作 vs 実際の動作

何が起きるべきか、実際に何が起きているのか？

Q4: 影響を受ける領域

システムのどの部分が影響を受けていますか？

**Q5: 根本原因の仮説（オプション）

原因について何か仮説がありますか？
（スキップするにはEnterキーを押します）

雑務/リファクタリングトラック用

Q1: タスクの要約

何をする必要がありますか？
[引数が提供されている場合、確認]

Q2: 動機

このタスクがなぜ必要なのか？

Q3: 成功基準

これが完了したことはどうしたらわかりますか？

Q4: リスク評価

何が悪くなる可能性がありますか？危険な変更がありますか？

トラック ID の生成

トラック ID を {shortname}_{YYYYMMDD} 形式で生成：

• 機能/バグの要約から shortname を抽出（2～3単語、小文字、ハイフン区切り）
• 現在の日付を使用
• 例：user-auth_20250115、nav-bug_20250115

一意性を検証：

• conductor/tracks.md で既存の ID を確認
• 衝突がある場合、カウンターを追加：user-auth_20250115_2

仕様書の生成

conductor/tracks/{trackId}/spec.md を作成：

# Specification: {Track Title}

**Track ID:** {trackId}
**Type:** {Feature|Bug|Chore|Refactor}
**Created:** {YYYY-MM-DD}
**Status:** Draft

## Summary

{1～2文の要約}

## Context

{このトラックに関連する product.md のプロダクトコンテキスト}

## User Story（機能の場合）

As a {ユーザー}, I want to {アクション} so that {メリット}.

## Problem Description（バグの場合）

{バグの説明、再現手順}

## Acceptance Criteria

- [ ] {基準 1}
- [ ] {基準 2}
- [ ] {基準 3}

## Dependencies

{依存関係のリストまたは「なし」}

## Out of Scope

{明確な除外項目}

## Technical Notes

{技術的検討または「指定なし」}

---

_Conductor により生成されました。必要に応じて確認と編集をしてください。_

仕様書のユーザーレビュー

生成された仕様書を表示し、ユーザーに確認：

生成した仕様書は以下の通りです：

{仕様書の内容}

この仕様書は正しいですか？
1. はい、計画生成に進みます
2. いいえ、編集させてください（インライン編集が開きます）
3. 異なる入力で最初からやり直します

計画生成

仕様書が承認された後、conductor/tracks/{trackId}/plan.md を生成：

計画構造

# Implementation Plan: {Track Title}

**Track ID:** {trackId}
**Spec:** spec.md
**Created:** {YYYY-MM-DD}
**Status:** [ ] Not Started

## Overview

{実装アプローチの簡単な要約}

## Phase 1: {フェーズ名}

{フェーズの説明}

### Tasks

- [ ] Task 1.1: {説明}
- [ ] Task 1.2: {説明}
- [ ] Task 1.3: {説明}

### Verification

- [ ] {フェーズ 1 の検証ステップ}

## Phase 2: {フェーズ名}

{フェーズの説明}

### Tasks

- [ ] Task 2.1: {説明}
- [ ] Task 2.2: {説明}

### Verification

- [ ] {フェーズ 2 の検証ステップ}

## Phase 3: {フェーズ名}（必要に応じて）

...

## Final Verification

- [ ] すべての受け入れ基準を満たしている
- [ ] テストが成功している
- [ ] ドキュメントが更新されている（該当する場合）
- [ ] レビュー準備完了

---

_Conductor により生成されました。タスクは進行中は [~] で、完了時は [x] でマークされます。_

フェーズガイドライン

• 関連するタスクを論理的なフェーズにグループ化
• 各フェーズは個別に検証可能である必要があります
• 各フェーズ後に検証タスクを含める
• TDD トラック：実装タスクの前にテスト作成タスクを含める
• 典型的な構造：
  1. Setup/Foundation - 初期スキャフォルディング、インターフェース
  2. Core Implementation - メイン機能
  3. Integration - 既存システムとの接続
  4. Polish - エラーハンドリング、エッジケース、ドキュメント

計画のユーザーレビュー

生成された計画を表示し、ユーザーに確認：

実装計画は以下の通りです：

{計画の内容}

この計画は正しいですか？
1. はい、トラックを作成します
2. いいえ、編集させてください（インライン編集が開きます）
3. フェーズ/タスクを追加します
4. 最初からやり直します

トラック作成

計画が承認された後：

1. ディレクトリ構造を作成：

   conductor/tracks/{trackId}/
   ├── spec.md
   ├── plan.md
   ├── metadata.json
   └── index.md
   

2. metadata.json を作成：

   {
     "id": "{trackId}",
     "title": "{Track Title}",
     "type": "feature|bug|chore|refactor",
     "status": "pending",
     "created": "ISO_TIMESTAMP",
     "updated": "ISO_TIMESTAMP",
     "phases": {
       "total": N,
       "completed": 0
     },
     "tasks": {
       "total": M,
       "completed": 0
     }
   }
   

3. index.md を作成：

   # Track: {Track Title}
   
   **ID:** {trackId}
   **Status:** Pending
   
   ## Documents
   
   - Specification
   - Implementation Plan
   
   ## Progress
   
   - Phases: 0/{N} complete
   - Tasks: 0/{M} complete
   
   ## Quick Links
   
   - Back to Tracks
   - Product Context
   

4. conductor/tracks.md に登録：

   • トラックテーブルに行を追加
   • 形式：| [ ] | {trackId} | {title} | {created} | {created} |

5. conductor/index.md を更新：

   • 「Active Tracks」セクションにトラックを追加

完了メッセージ

トラックが正常に作成されました！

Track ID: {trackId}
Location: conductor/tracks/{trackId}/

作成されたファイル：
- spec.md - 要件仕様書
- plan.md - 段階的実装計画
- metadata.json - トラックメタデータ
- index.md - トラックナビゲーション

次のステップ：
1. spec.md と plan.md を確認し、必要に応じて編集
2. /conductor:implement {trackId} を実行して実装を開始
3. /conductor:status を実行してプロジェクトの進捗を確認

エラーハンドリング

• ディレクトリ作成が失敗した場合：停止してレポートし、tracks.md に登録しない
• ファイル書き込みが失敗した場合：部分的なトラックをクリーンアップしてエラーをレポート
• tracks.md の更新が失敗した場合：ユーザーに手動でトラックを登録するよう警告