Start Linear Project

Plan and create a new Linear project for a feature or initiative.

Prerequisites

Recommended: Activate a role first (e.g., /roles/techlead) to load relevant codebase rules.

If you haven't loaded rules yet, read the appropriate ones:

• Backend work: .claude/rules/backend/*.md and .claude/rules/dataclasses/laravel-data.md
• Frontend work: .claude/rules/frontend/*.md
• Full-stack work: Both backend and frontend rules

Workflow

1. Understand the Feature

Ensure you thoroughly understand what needs to be built:

• If they provided a description, confirm your understanding
• If not, ask them to describe the feature/task
• Ask clarifying questions about scope, requirements, and acceptance criteria
• Identify any technical constraints, dependencies, or integration points

2. Identify Git Branch

Determine which branch this feature will be developed on:

• Use Bash: git branch --show-current
• Ask the user: "I see you're on branch [branch-name]. Is this the correct branch for this feature, or would you like to specify a different one?"
• Store the branch name to include in the project description

3. Create Linear Project

Create a new Linear project:

• Use mcp__linear-server__create_project with comprehensive details
• Use a clear, descriptive name for the project
• Include a detailed description in Markdown format:

## Branch
`[branch-name]`

## Purpose
[What problem this solves or what value it provides]

## Scope
[What's included and what's explicitly out of scope]

## Technical Approach
[High-level architecture or approach - reference patterns from rules]

## Dependencies
[Any related systems, APIs, or services]

• Set the appropriate team (ask user if unclear)
• Set target date if the user provides one

4. Break Down into Issues

Use the linear-issue-writer skill to create detailed issues:

• Activate the skill: Skill tool with command: "linear-issue-writer"
• Break the feature down into logical, implementable tasks
• Write issues assuming someone else will implement them - include full context
• Each issue should contain:
  • Clear title describing what needs to be done
  • Detailed description with background context
  • Specific acceptance criteria
  • Technical guidance (files to modify, patterns to follow, services to use)
  • Links to relevant documentation or related code
  • Any gotchas or important considerations
• Order issues logically (dependencies first)
• Assign appropriate labels and priorities
• Reference codebase conventions from the rules (e.g., "Create a Data class per form-data-classes.md")

5. Ask About Next Steps

After planning is complete, ask the user:

"I've created the Linear project '[Project Name]' with [X] issues for implementation. What would you like to do next?"

• Start implementing now (use /linear/work-on-issue to begin)
• Stop here and continue later (you can resume with /linear/work-on-issue [issue-id])
• Review the plan first (I can walk through the issues)

Provide them with the Linear project ID/URL for reference.

Notes

• Plan thoroughly - assume handoff to another person/session
• Write issues with full context, not just task names
• Keep the user informed at each step
• Ask for approval before creating multiple Linear issues
• Reference specific codebase patterns in issues
• Good planning makes implementation smoother for anyone