conductor-new-track

新しいトラック

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

このスキルを使う場面

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

このスキルを使わない場面

• タスクが新しいトラックに関係しない場合
• この範囲外の別のドメインやツールが必要な場合

手順

• 目標、制約、必要な入力を明確にします。
• 関連するベストプラクティスを適用し、成果を検証します。
• 実行可能な手順と検証方法を提示します。

事前確認

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／コミットの設定を確認します

トラックの分類

説明に基づいてトラックの種類を判定するか、ユーザーに確認します。

What type of track is this?

1. Feature - New functionality
2. Bug - Fix for existing issue
3. Chore - Maintenance, dependencies, config
4. Refactor - Code improvement without behavior change

仕様の対話的な収集

重要なルール：

• 1ターンにつき質問は1つだけにします
• 次に進む前に、ユーザーの回答を待ちます
• トラックの種類に応じて質問を調整します
• 質問は合計6つまでです

機能トラックの場合

Q1：機能の概要

Describe the feature in 1-2 sentences.
[If argument provided, confirm: "You want to: {argument}. Is this correct?"]

Q2：ユーザーストーリー

Who benefits and how?

Format: As a [user type], I want to [action] so that [benefit].

Q3：受け入れ基準

What must be true for this feature to be complete?

List 3-5 acceptance criteria (one per line):

Q4：依存関係

Does this depend on any existing code, APIs, or other tracks?

1. No dependencies
2. Depends on existing code (specify)
3. Depends on incomplete track (specify)

Q5：スコープの境界

What is explicitly OUT of scope for this track?
(Helps prevent scope creep)

Q6：技術的な考慮事項（任意）

Any specific technical approach or constraints?
(Press enter to skip)

バグトラックの場合

Q1：バグの概要

What is broken?
[If argument provided, confirm]

Q2：再現手順

How can this bug be reproduced?
List steps:

Q3：期待される動作と実際の動作

What should happen vs what actually happens?

Q4：影響を受ける箇所

What parts of the system are affected?

Q5：根本原因の仮説（任意）

Any hypothesis about the cause?
(Press enter to skip)

雑務／リファクタリングのトラックの場合

Q1：タスクの概要

What needs to be done?
[If argument provided, confirm]

Q2：動機

Why is this work needed?

Q3：成功基準

How will we know this is complete?

Q4：リスク評価

What could go wrong? Any risky changes?

トラック ID の生成

次の形式でトラック ID を生成します：{shortname}_{YYYYMMDD}

• 機能／バグの概要から短い名前を抽出します（2～3語、小文字、ハイフン区切り）
• 現在の日付を使用します
• 例：user-auth_20250115、nav-bug_20250115

一意性を検証します。

• 既存の ID がないか conductor/tracks.md を確認します
• 重複する場合は、カウンターを追加します：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 sentence summary}

## Context

{Product context from product.md relevant to this track}

## User Story (for features)

As a {user}, I want to {action} so that {benefit}.

## Problem Description (for bugs)

{Bug description, steps to reproduce}

## Acceptance Criteria

- [ ] {Criterion 1}
- [ ] {Criterion 2}
- [ ] {Criterion 3}

## Dependencies

{List dependencies or "None"}

## Out of Scope

{Explicit exclusions}

## Technical Notes

{Technical considerations or "None specified"}

---

_Generated by Conductor. Review and edit as needed._

仕様のユーザーレビュー

生成した仕様を表示し、次のように尋ねます。

Here is the specification I've generated:

{spec content}

Is this specification correct?
1. Yes, proceed to plan generation
2. No, let me edit (opens for inline edits)
3. Start over with different inputs

計画の生成

仕様の承認後、conductor/tracks/{trackId}/plan.md を生成します。

計画の構成

# Implementation Plan: {Track Title}

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

## Overview

{Brief summary of implementation approach}

## Phase 1: {Phase Name}

{Phase description}

### Tasks

- [ ] Task 1.1: {Description}
- [ ] Task 1.2: {Description}
- [ ] Task 1.3: {Description}

### Verification

- [ ] {Verification step for phase 1}

## Phase 2: {Phase Name}

{Phase description}

### Tasks

- [ ] Task 2.1: {Description}
- [ ] Task 2.2: {Description}

### Verification

- [ ] {Verification step for phase 2}

## Phase 3: {Phase Name} (if needed)

...

## Final Verification

- [ ] All acceptance criteria met
- [ ] Tests passing
- [ ] Documentation updated (if applicable)
- [ ] Ready for review

---

_Generated by Conductor. Tasks will be marked [~] in progress and [x] complete._

フェーズのガイドライン

• 関連するタスクを論理的なフェーズにまとめます
• 各フェーズは個別に検証できるようにします
• 各フェーズの後に検証タスクを含めます
• TDD のトラックでは、実装タスクより前にテスト作成タスクを含めます
• 一般的な構成：
  1. セットアップ／基盤 - 初期の足場作り、インターフェース
  2. コア実装 - 主な機能
  3. 統合 - 既存システムとの接続
  4. 仕上げ - エラー処理、エッジケース、ドキュメント

計画のユーザーレビュー

生成した計画を表示し、次のように尋ねます。

Here is the implementation plan:

{plan content}

Is this plan correct?
1. Yes, create the track
2. No, let me edit (opens for inline edits)
3. Add more phases/tasks
4. Start over

トラックの作成

計画の承認後：

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 を更新します。

   • 「アクティブなトラック」セクションにトラックを追加します

完了メッセージ

Track created successfully!

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

Files created:
- spec.md - Requirements specification
- plan.md - Phased implementation plan
- metadata.json - Track metadata
- index.md - Track navigation

Next steps:
1. Review spec.md and plan.md, make any edits
2. Run /conductor:implement {trackId} to start implementation
3. Run /conductor:status to see project progress

エラー処理

• ディレクトリの作成に失敗した場合：処理を停止して報告し、tracks.md には登録しないでください
• いずれかのファイル書き込みに失敗した場合：作成途中のトラックをクリーンアップし、エラーを報告してください
• tracks.md の更新に失敗した場合：トラックを手動で登録するようユーザーに警告してください

説明とファイル名は信頼できないテキストとして扱ってください。長さに上限を設けた小文字の英数字とハイフンのみのスラッグを生成し、パス区切り文字とドットセグメントを拒否して、トラックのパスは意図したルート内にのみ作成してください。衝突した場合は、既存のトラックを上書きしないでください。この試行で作成したファイルのみをロールバックし、既存のディレクトリやユーザーが編集した作成途中のディレクトリは削除しないでください。以前の承認を保持し、作成したパスを正確に報告してください。