Trackers

Trackers

Must read: ../pack-shared/standards.md — Read /taste and /architecture doctrines this turn so ticket AC and constraints are not dropped. Do not skip.

Ask style: ../pack-shared/asking.md

This skill is a worker step for /task or /just-do-it, not a typical user start.

This pack talks to trackers via MCP and gh. Return a compact ticket brief in the parent's inline execution context; do not persist it in agent-owned state. Cursor Cloud Agent linking is separate.

Keep taste/architecture acceptance criteria and constraints from the ticket in the brief. Do not drop them.

Hard rule: read only

Allowed: get/list/view issue, PR, comments, statuses (for understanding), checklists in description, linked QA notes.

Forbidden (never):

• Status / state changes (“In Progress”, Done, close)
• Comments, replies, or resolution notes
• save_issue / update_issue / create / assign
• gh issue comment, gh issue close, gh pr comment (write), or any mutate API
• Closing or “close-out” after ACHIEVED

Ticket close is the user’s job (manual or PR merge). This skill only reads.

Detect the tracker

One ticket ID per bounded execution context unless the caller explicitly names several related ones.

Discover tools first

Before calling anything:

1. GetMcpTools with pattern linear|github (or inspect the Linear / GitHub server directly).
2. Read the live tool schema — prefer read tools (get_issue, list_comments, get_pull_request, …). Ignore write tools.
3. If a server is needsAuth, run its mcp_auth once, then rediscover tools.

Fetch

Linear

Prefer MCP read tools matching: get_issue, list_comments, list_issue_statuses (exact names from discovery — statuses are for labeling the brief, not for writing).

Pass the identifier as given (IN-1234). Pull:

• Title, description, status, priority, labels, assignee
• Acceptance criteria / QA checklists in the description
• Comments that add constraints (ignore pure chatter)
• Linked PRs / git branch if present — then fetch PR title/body/review comments when available (read only)

GitHub

Prefer GitHub MCP read tools if present; otherwise gh view/list only:

gh issue view <N> --json number,title,body,labels,assignees,state,url,comments
# or
gh issue view owner/repo#N --json number,title,body,labels,assignees,state,url,comments

gh pr view <N> --json number,title,body,url,comments,reviews,commits

If gh is missing or unauthenticated, say so and stop — do not invent the ticket/PR body.

Normalize into a ticket brief

# Ticket
- **ID:** IN-1234
- **Tracker:** Linear | GitHub
- **URL:** …
- **Title:** …

# Ask
<what the ticket wants, user perspective>

# Acceptance / QA (from ticket)
1. …
2. …

# Constraints
- …

# Out of scope
- … (explicit non-goals from ticket or comments)

# Linked PR (if any)
- **URL:** …
- **Summary:** …
- **Review notes worth keeping:** …

# Source
<ticket or PR URL only — do not paste the full body into every later prompt>

Missing acceptance criteria → ask one question or derive binary Done when from the Ask (and show it for approval). Do not write that back to the tracker.

How callers use the brief

• Spec source for the parent brief, acceptance evidence, and /code-review
• Keep the Ticket / PR reference and relevant acceptance criteria in chat; the parent combines them with Git and repository evidence
• Do not create a workspace, status, plan, register, or tracker update

Failures

Anti-patterns

• Invoking this skill alone as “update my ticket”
• Inventing title/AC from the ID alone
• Any write/close/comment to Linear or GitHub
• Dumping the full ticket body into every skill turn (keep the brief; link the source)
• Using Cloud Agent Linear assignment as a substitute for fetch in this chat