recover-branch-context

ブランチのコンテキストを把握する

既存のブランチの意図と現在の状態を把握し、作業を効果的に再開または継続することが求められています。コードの状態を最も信頼できる情報源としてください。関連する Linear チケットの内容から乖離している可能性があります。

初回の応答

このコマンドが呼び出されたら、次のように応答します。

I'll help you understand the context of this branch. Let me analyze the commits and changes.

Do you have a Linear ticket ID or URL for this work? (optional - I can proceed without it)

その後、ユーザーの応答を少し待ちます。チケットが提示された場合は取得してください。ユーザーが「いいえ」と答えた場合、またはすぐに応答がない場合は、分析を進めてください。

手順

ステップ 1：ベースブランチを特定する

1. 一般的なベースブランチ名を確認する：

   git branch -a | grep -E "(main|master|dev|develop)" | head -5
   

2. マージベースを特定する：

   # Try dev first (common in this repo), then main/master
   git merge-base HEAD dev 2>/dev/null || git merge-base HEAD main 2>/dev/null || git merge-base HEAD master
   

3. 現在のブランチ名を取得する：

   git branch --show-current
   

ステップ 2：分岐後のコミット履歴を収集する

1. ベースから分岐して以降のすべてのコミットを取得する：

   git log --oneline $(git merge-base HEAD dev)..HEAD
   

2. 意図を把握するため、詳細なコミットメッセージを取得する：

   git log --format="%h %s%n%b" $(git merge-base HEAD dev)..HEAD
   

3. すべてのコミットで変更されたファイルを取得する：

   git diff --name-status $(git merge-base HEAD dev)..HEAD
   

ステップ 3：未コミットの変更を収集する

1. ステージ済みの変更を取得する：

   git diff --name-status --cached
   

2. 未ステージの変更を取得する：

   git diff --name-status
   

3. 未追跡ファイルを取得する：

   git ls-files --others --exclude-standard
   

4. 作業ツリー全体の状態を取得する：

   git status --short
   

ステップ 4：Linear チケットを取得する（提示された場合）

ユーザーが Linear チケットを提示した場合：

1. mcp__linear__get_issue ツールを使ってチケットの詳細を取得します
2. 注意：チケットは当初の要件を示しますが、コードはその後進化している可能性があります

ステップ 5：変更を分析し、意図ごとにグループ化する

重要：ファイルを列挙するだけではいけません。変更を論理的な機能領域や意図ごとにグループ化してください。

1. 主要な変更ファイルを読み、それらの役割を把握します
2. 変更のパターンを特定します：
   • 新機能の追加
   • バグ修正
   • リファクタリング
   • 設定変更
   • テストの追加
3. ディレクトリではなく、目的ごとにファイルをグループ化します

ステップ 6：概要を出力する

次の構成で調査結果を提示します。

# Branch Context: [branch-name]

**Base branch**: [dev/main]
**Commits since divergence**: [count]
**Linear ticket**: [ID if provided, or "None provided"]

## Intent Summary

[1-3 sentences describing the overall goal of this branch based on commits and changes]

## Feature Areas

### [Feature/Intent Area 1]
**Purpose**: [What this group of changes accomplishes]
**Status**: [Complete/In Progress/Not Started]

**Committed changes**:
- `path/to/file.ext:lines` - [brief description]
- `path/to/another.ext` - [brief description]

**Uncommitted changes**:
- `path/to/wip.ext` - [brief description]

### [Feature/Intent Area 2]
...

## Uncommitted Work

**Staged** (ready to commit):
- [files]

**Modified** (not staged):
- [files]

**Untracked** (new files):
- [files]

## Code vs Ticket Drift

[If a Linear ticket was provided, note any discrepancies between what the ticket describes and what the code actually implements. The code is the source of truth.]

## Suggested Next Steps

[Based on the analysis, what appears to be remaining work or natural next actions]

重要なガイドライン

1. コードを信頼できる情報源とする：ブランチのコミットと変更は、実際に開発されている内容を表します。元のチケットの説明とは異なる場合があります。

2. 構成ではなく意図ごとにグループ化する：ディレクトリごとにファイルを列挙するだけではいけません。それぞれの変更が何を実現するのかを把握し、関連する変更をまとめてください。

3. ファイルと行番号を含める：変更を説明するときは、ユーザーがすぐに確認できるよう、ファイル内の具体的な場所を示してください。

4. 作業中の変更を明確にする：完了済みの変更（コミット済み）と作業中の変更（未コミット）を区別してください。

5. チケットとの乖離を記載する：Linear チケットが提示された場合は、実装がチケットの説明からどのように発展したか、または異なるかを明示してください。

6. 簡潔かつ漏れなくまとめる：詳細を詰め込みすぎず、すぐに作業を始められるだけの情報を概要に含めてください。

出力例

# Branch Context: feat/comment-threads

**Base branch**: main
**Commits since divergence**: 3
**Linear ticket**: TASK-142

## Intent Summary

This branch adds threaded comments to tasks, allowing users to start discussion threads on individual tasks and reply to existing comments. The implementation includes a new database table, API routes for CRUD operations, and a collapsible thread UI in the task detail view.

## Feature Areas

### Comments Data Layer
**Purpose**: Database schema and API routes for storing and retrieving comment threads
**Status**: Complete

**Committed changes**:
- `src/db/schema/comments.ts` - New comments table with parent_id for threading
- `src/db/migrations/0012_add_comments.sql` - Migration file
- `src/api/routes/comments.ts` - CRUD endpoints for comments

### Thread UI Components
**Purpose**: Components for displaying and composing threaded comments on tasks
**Status**: In Progress

**Committed changes**:
- `src/components/tasks/CommentThread.tsx` - Recursive thread display component

**Uncommitted changes**:
- `src/components/tasks/CommentComposer.tsx` - Reply/new comment input box
- `src/hooks/useCommentThread.ts` - Data fetching hook for thread state

## Code vs Ticket Drift

The ticket scoped comments as flat (non-threaded), but the implementation adds full threading support with nested replies via a parent_id column.

## Suggested Next Steps

1. Complete the CommentComposer component and wire it into CommentThread
2. Add optimistic updates to useCommentThread for snappy UX
3. Add tests for the comment API routes