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. 识别更改模式：
   • 新功能
   • Bug 修复
   • 重构
   • 配置更改
   • 测试新增
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