jasonwarrenuk/linear-crit-path-to-project

Objective

Decompose Linear project $ARGUMENTS into a set of granular, dependency-ordered issues that form a critical path from the current state of the codebase to the project's stated goals.

Process

1. Gather Context

• Fetch the full details of the project matching $ARGUMENTS from Linear (include milestones and resources)
• List existing issues already in this project to understand what's been planned and what gaps remain
• Analyse the codebase to understand the current state relevant to this project's goals
• List all active Linear projects to understand the wider landscape (some work may belong elsewhere)

2. Identify Gaps

Compare the project's description/goals against:

• What the codebase already has
• What issues already exist in the project

Only create issues for work that isn't already captured. Flag any existing issues that appear redundant or stale.

3. Decompose

Break the remaining work into the smallest meaningful units. Each issue should be:

• Independently deliverable — can be completed, reviewed, and merged on its own
• Single responsibility — one clear outcome per issue
• Well-scoped — achievable in a focused session (hours, not days)

4. Classify Relationships

Apply consistent reasoning to distinguish between relationship types:

Blocking relationships (use blocks/blockedBy) when:

• One issue is a prerequisite for another
• Infrastructure or setup work that must land before dependent work can begin
• A clear temporal dependency exists

Related relationships (use relatedTo) when:

• Issues touch the same area but don't strictly depend on each other
• Changes in one might affect the other but neither blocks progress

Cross-project blockers: If a prerequisite logically belongs in a different project, create it there instead and set up the blocking relationship across projects.

5. Determine Placement

Most issues will belong to the target project. However, for each issue consider:

• Does this work serve the project's goals specifically, or is it broader infrastructure?
• If broader: place it in the more appropriate project and link it as a blocker
• If project-specific: place it in the target project

6. Build the Critical Path

Order the issues by dependency. The critical path should flow logically:

1. Foundation/infrastructure work first
2. Core implementation in the middle
3. Integration, polish, and verification last

Account for existing issues — new issues should slot into the dependency chain alongside them where appropriate.

7. Present the Plan

Before creating anything, present:

Existing issues (already in the project):

• Which ones are still relevant
• Any that appear stale or redundant
• Where new issues connect to them in the dependency chain

New issues to create — a summary table showing:

• Issue title
• Target project (most will be the target project; some may be elsewhere)
• Dependencies (blocks / blocked by, including existing issue identifiers)
• Priority (2=High, 3=Normal, 4=Low)

Wait for approval before creating issues.

8. Create Issues

Once approved, create all issues in dependency order (foundations first). For each issue:

• Assign to me
• Set project to the determined project
• Set blocks/blockedBy using identifiers of both new and existing issues
• Set priority based on critical path position
• Write a clear description in markdown including:
  • What needs to be done
  • Acceptance criteria
  • Any relevant context about the current codebase state

9. Confirm

After all issues are created, provide a summary of what was created with their identifiers and a visual representation of the full dependency graph (including existing issues).