Recover Branch Context

You are tasked with understanding the intent and current state of an existing branch so you can resume or continue work effectively. The code state is your primary source of truth - it may have drifted from any associated Linear ticket.

Initial Response

When this command is invoked, respond with:

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)

Then wait briefly for the user's response. If they provide a ticket, fetch it. If they say no or don't respond quickly, proceed with the analysis.

Process Steps

Step 1: Determine the Base Branch

Check common base branch names:

bash

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

Find the merge base:

bash

# 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

Get current branch name:
bash
```
git branch --show-current
```

Step 2: Gather Commit History Since Divergence

Get all commits since diverging from base:

bash

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

Get detailed commit messages for understanding intent:

bash

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

Get files changed across all commits:

bash

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

Step 3: Gather Uncommitted Changes

Get staged changes:
bash
```
git diff --name-status --cached
```
Get unstaged changes:
bash
```
git diff --name-status
```

Get untracked files:

bash

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

Full working tree status:
bash
```
git status --short
```

Step 4: Fetch Linear Ticket (If Provided)

If the user provides a Linear ticket:

Use the
```
mcp__linear__get_issue
```
tool to fetch the ticket details
Note: The ticket represents the original requirements but the code may have evolved

Step 5: Analyze and Group Changes by Intent

CRITICAL: Do not just list files. Group them by logical feature area or intent.

Read key changed files to understand what they do
Identify patterns in the changes:
- New feature additions
- Bug fixes
- Refactoring
- Configuration changes
- Test additions
Group files by their purpose, not by directory

Step 6: Output Summary

Present findings in this structure:

markdown

# 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]

Important Guidelines

Code is the source of truth: The branch's commits and changes represent what's actually being built, which may differ from the original ticket description.
Group by intent, not structure: Don't just list files by directory. Understand what each change accomplishes and group related changes together.
Include file:line references: When describing changes, point to specific locations in files so the user can quickly navigate.
Identify work-in-progress: Distinguish between completed (committed) work and in-progress (uncommitted) work.
Note drift from ticket: If a Linear ticket was provided, explicitly call out where the implementation has evolved beyond or differs from the ticket description.
Be concise but complete: The summary should give someone enough context to immediately start working, without overwhelming them with every detail.

Example Output

markdown

# 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

recover-branch-context

NPX Install

Tags

SKILL.md Content

Recover Branch Context

Initial Response

Process Steps

Step 1: Determine the Base Branch

Step 2: Gather Commit History Since Divergence

Step 3: Gather Uncommitted Changes

Step 4: Fetch Linear Ticket (If Provided)

Step 5: Analyze and Group Changes by Intent

Step 6: Output Summary

Important Guidelines

Example Output