neon-sprawl/.cursor/rules/story-end.md

3.4 KiB
Raw Blame History

description alwaysApply
When a Linear-tracked story is finished (merged or abandoned locally), return to main, pull, delete the local story branch true

Story end (Linear)

When the user ends story work on a ticketed branch—phrases like “end story”, “story is merged”, “clean up branch after NEO-…”, or they confirm the PR is merged to main—run this git sequence so local state matches the remote default branch.

1. Preconditions

  • Merged: Prefer deleting the local branch only after main on the remote includes the story (PR merged). If the PR is not merged, git branch -d will refuse; use git branch -D only when the user explicitly wants to drop unmerged work.
  • Uncommitted changes: Stash, commit, or discard before switching branches; do not leave a dirty tree without the users choice.

2. Steps (run in order)

  1. git checkout main
  2. git pull origin main (or git pull if main already tracks origin/main and that is correct for this repo)
  3. git branch -d <story-branch> — use the branch that was used for the issue (first path segment should be the Linear issue id, e.g. NEO-10-move-validation). If Git reports “not fully merged”, confirm whether origin/main already contains the story (e.g. squash merge or follow-up commits only cherry-picked to main). If yes, git branch -D <story-branch> is OK only with user confirmation so local unpushed tip is not lost by mistake.

2a. When main is push-protected

If the user asks to push changes that sit on main and git push origin main fails (required PR / status checks), create a branch from current main (e.g. chore/…), git push -u origin that branch, give them the PR link, then git reset --hard origin/main if you had temporarily advanced local main so local main matches remote until the PR merges.

3. What not to do

  • Do not delete main or origin/*.
  • Do not assume the remote story branch should be deleted unless the user asks (many teams keep origin/NEO-… for history or delete via GitHub UI).

4. Linear issue status

  • Do not call Linear save_issue to change state until the user has explicitly chosen the target status. Typical names here are In Test or Done; use list_issue_statuses (Linear MCP, server plugin-linear-linear) if names differ on your team.
  • If the user only says “end story” / “merge cleanup” / similar without naming a target status: run the git steps in §2, then ask which Linear state to set (e.g. In Test vs Done) and wait for their answer before updating the issue. Never assume Done without that confirmation.
  • Exception: If the same user message already names the status (e.g. “end story, move NEO-18 to Done”), you may update Linear after git cleanup without a second ask.
  • When Linear MCP is available, perform the update with save_issue (id = issue identifier, state = chosen status).
  • If MCP is unavailable or the update fails, tell the user and ask them to update Linear manually.