pm-pivot

What this skill does

# PM Pivot — Direction Change Handler

When work diverges from the original Linear issue, surface the decision clearly and recommend a path.

## Usage

```
/pm-pivot
```

Natural-language / workflow-driven — no flags. Triggered by the user describing a direction change (e.g. "let's change direction", "pivot", "this isn't right"). Operates on the active tracked issue and the user's chosen path. Inputs it needs:

- `active issue` *(issue key, required)* — the Linear/GitHub issue work has diverged from.
- `original approach` *(string, required)* — what the issue was planned to do.
- `new approach` *(string, required)* — the changed direction / scope.
- `chosen path` *(enum `A|B|C`, required at execution)* — update existing issue (A), new issue + cancel old (B), or split into two (C); confirmed by the user before any tracker writes.

## Detecting a Pivot

A pivot has occurred when ANY of these are true:
- The user describes a solution significantly different from the issue's description
- The scope expanded or contracted materially
- The original acceptance criteria can no longer be met as written
- The user explicitly says they're taking a different approach

## Step 1: Surface the Divergence

Clearly state what changed:
> "The current approach differs from ENG-42 (Auth middleware refactor). Originally we were planning [original approach], but now we're [new approach]."

## Step 2: Recommend a Path

Evaluate and recommend ONE of these options — don't just list them, pick the most appropriate one and explain why:

### Option A: Update the existing issue
**When to recommend:** The core goal is the same, only the implementation approach changed.
- Update the issue description with the new approach
- Keep the same issue ID (branch name stays valid)
- Add a note explaining the pivot: "Pivoted from X to Y because..."

### Option B: Create a new issue, cancel the old one
**When to recommend:** The scope, goal, or acceptance criteria fundamentally changed.
- Create a new issue with the updated goal and fresh acceptance criteria
- Cancel or mark the original issue as "Won't Do" with a note
- Create a new branch: `<type>/<NEW-ID>-<description>`
- The original branch/PR should either be closed or retargeted

### Option C: Split into two issues
**When to recommend:** The pivot revealed additional work that should be tracked separately.
- Keep the original issue for what was already built
- Create a new issue for the new direction
- Update acceptance criteria on the original to match what was actually built

## Step 3: Execute the Chosen Path

After the user confirms:

**For Option A — Update existing:**
```
save_issue { id: "<issue_id>", description: "<updated>", title: "<updated if needed>" }
```

**For Option B — New issue + cancel old:**
```
save_issue { team: "<team_key>", title: "...", description: "..." }  // new issue
save_issue { id: "<old_id>", state: "cancelled" }
```
To find the cancelled state name: `list_issue_statuses { team: "<team_key>" }`
Then use `pm-branches` to create a new branch with the new issue ID.

**For Option C — Split:**
```
save_issue { team: "<team_key>", title: "...", description: "..." }  // new direction
save_issue { id: "<old_id>", description: "<narrowed scope>" }
```

## Step 4: Update Cache

Write the updated issue context to `~/.claude/project-manager/cache/<slug>/context.json`.