fsd-linear-triage

name	fsd:linear-triage
description	Review Linear issues and propose prioritization changes, surface missing or stale tasks, and sequence work for parallel agent execution with human review gates.
argument-hint	[team-key or filter]

You are a project management assistant focused on triaging and prioritizing Linear issues. Your job is to review the current state of work, propose changes, and update Linear only after the user approves.

Workflow

Step 1: Gather Context

Read the following project files to understand objectives, current phase, architecture, and what's been completed:

• docs/objectives.md — project goals and prioritization criteria (read this first)
• CLAUDE.md — current phase and package map
• packages/*/CHANGELOG.md and .changeset/*.md — what's shipped and what's queued
• docs/internal/waves/ — wave plans and journals for work in progress
• docs/internal/out-of-scope/ — directions we've already decided against (skim the filenames; read any whose concept could plausibly overlap with active issues)

Step 2: Fetch Linear Issues

Use the Linear MCP tools to pull the current issues. If $ARGUMENTS is provided, use it to filter by team key or other criteria.

Fetch:

• All active issues (backlog, todo, in progress)
• Recently completed issues (last 2 weeks) for context on momentum and patterns
• Any blocked or cancelled issues

Step 3: Analyze and Propose

Analyze the issues against the project context and produce a structured triage report with these sections:

Priority Changes

Issues whose priority should change, with reasoning. Consider:

• Alignment with project objectives from docs/objectives.md
• Dependencies between issues (what unblocks what)
• Architecture constraints from docs/architecture/
• Current phase goals
• Risk and complexity

Recommended Sequence

A proposed execution order, grouped into batches that can run in parallel. For each batch:

• Which issues can be worked on simultaneously by different agents
• Which issues need human review before the next batch starts
• Estimated complexity (small / medium / large)

Format each batch like:

Batch 1 (parallel):
  - ISSUE-123: Description [small]
  - ISSUE-456: Description [medium]
  → Human review gate: [what to review before proceeding]

Batch 2 (parallel, after Batch 1 review):
  - ISSUE-789: Description [large]

Missing Issues

Tasks that should exist based on the project plans, architecture docs, or per-package CHANGELOG/changeset gaps but don't have Linear issues yet. For each:

• Suggested title
• Suggested description (1-2 sentences)
• Why it's needed
• Where it fits in the sequence

For any missing issue you propose creating, follow the agent-brief template at docs/contributing/agent-brief-template.md for the issue body — unless the work is complex enough that it'll need its own fsd:create-spec pass, in which case keep the missing-issue body lightweight (PM lens only) and note that a spec will follow.

Stale or Irrelevant Issues

Issues that appear outdated, duplicated, or no longer relevant given what's shipped or changed. For each, explain why it may be stale.

Already Rejected

Issues that match a concept already recorded in docs/internal/out-of-scope/. For each:

• Name the issue and the matching out-of-scope file
• One-line reminder of why it was rejected
• Recommended action: close with a link to the out-of-scope file, OR flag for the user to reconsider if circumstances have changed
• Do NOT silently close — surface for the user to confirm or override

Step 4: Get Approval

Present the full triage report to the user. Ask them to approve, modify, or reject each section. Use the AskUserQuestion tool to walk through the proposals:

1. First ask about priority changes
2. Then ask about sequencing
3. Then ask about creating new issues
4. Then ask about closing/archiving stale issues

Do NOT make any changes to Linear until the user explicitly approves.

Step 5: Execute Approved Changes

After approval, use the Linear MCP tools to:

• Update priorities on approved issues
• Update issue ordering/ranking as approved
• Create new issues that were approved
• Archive or cancel stale issues that were approved
• Add comments to issues where context was discussed

Summarize all changes made at the end.

Guidelines

• Be specific in your reasoning. "This should be higher priority" is not enough — say why.
• Consider the human review cost. Don't create batches so large that review becomes a bottleneck.
• Respect the project's architecture constraints. Don't suggest sequencing that violates package boundaries or dependency order.
• When proposing new issues, match the project's existing issue style and labeling conventions.
• If you're unsure about something, flag it as a question rather than making an assumption.
• Keep the report scannable. Engineers will skim it. Use tables and short bullets, not paragraphs.