linear-implement

What this skill does

# Linear Issue Implementation

## Overview

This skill provides a comprehensive workflow for implementing Linear issues with professional software engineering practices. It automates the entire development lifecycle from issue analysis through PR creation, ensuring quality through test-driven development, parallel code reviews, and systematic validation.

## When to Use This Skill

Use this skill when:
- User provides a Linear issue ID (format: `TRA-9`, `DEV-123`, etc.)
- User requests implementation of a Linear issue
- User wants a structured TDD approach with code review
- User needs automated workflow from issue to PR

Examples:
- "Implement TRA-142"
- "Help me build the feature in DEV-89"
- "Work on Linear issue ABC-456"

## Core Workflow

The skill follows a 14-step process:

1. **Fetch Linear Issue** - Retrieve complete issue details via Linear MCP
2. **Gather Additional Context** - Search Obsidian, Sentry, and GitHub for related information
3. **Move to In Progress** - Update issue status to indicate active work
4. **Create Feature Branch** - Use Linear's suggested git branch naming
5. **Analyze & Plan** - Break down requirements and create implementation plan
6. **Save to Memory** - Store plan in memory graph for tracking
7. **Review Plan** - Present plan for user confirmation
8. **TDD Implementation** - Invoke `tdd-workflow` skill for test-driven development
9. **Parallel Code Reviews** - Invoke `parallel-code-review` skill for comprehensive analysis
10. **Address Feedback** - Invoke `code-review-implementer` skill to systematically fix issues
11. **Validation** - Ensure all tests and linters pass
12. **Logical Commits** - Create meaningful commit history
13. **Create PR** - Generate comprehensive pull request with Linear linking
14. **Final Verification** - Confirm CI/CD pipeline and Linear integration

## Workflow Implementation Details

### Step 1: Fetch Linear Issue Details

Retrieve the complete issue using Linear MCP tools:

```
mcp__linear__get_issue(id: <issue-id>)
```

Extract key information:
- Title and description
- Current status and priority
- Suggested git branch name (`branchName` field)
- Team and project context
- Attachments or related work
- Labels and assigned team members

### Step 2: Gather Additional Context

Before planning, gather related context from multiple sources to inform the implementation approach.

#### Search Obsidian Vault

Search for any existing notes that might be related to this issue:

```
# Search by issue ID
Search Obsidian vault for: "TRA-142"

# Search by issue summary/keywords
Search Obsidian vault for: "<keywords from issue title/description>"
```

Look for:
- Previous meeting notes discussing this feature
- Architecture decisions or technical notes
- Related implementation notes from similar work
- User research or requirements documentation

#### Fetch Sentry Context (if referenced)

If the Linear issue references any Sentry issues or error tracking:

```
mcp__sentry__get_issue(issue_id: <sentry-issue-id>)
```

Extract from Sentry:
- Error stack traces and frequency
- Affected users and environments
- Related events and breadcrumbs
- Any existing comments or assignments

This context helps understand:
- The root cause of bugs
- Which code paths are affected
- How frequently the issue occurs
- Environmental factors to consider

#### Fetch GitHub Context (if referenced)

If the Linear issue references GitHub pull requests, issues, or discussions:

```bash
# View PR details and discussion
gh pr view <pr-number>

# View PR comments and review threads
gh pr view <pr-number> --comments

# View issue details
gh issue view <issue-number>

# View issue comments
gh issue view <issue-number> --comments
```

Extract from GitHub:
- Previous implementation attempts
- Review feedback and concerns raised
- Design discussions and decisions
- Related code changes or context

**Context Summary:**

After gathering context, summarize:
- Relevant information found in Obsidian
- Sentry error details (if applicable)
- GitHub discussion insights (if applicable)
- How this context affects the implementation approach

### Step 3: Move Issue to In Progress

Update the issue status to reflect active development:

1. Identify the team ID from the issue
2. Retrieve "In Progress" state using `mcp__linear__list_issue_statuses(team: <team-id>)`
3. Update issue using `mcp__linear__update_issue(id: <issue-id>, state: <in-progress-state-id>)`

This provides visibility to team members that work has begun.

### Step 4: Create Feature Branch

Use Linear's suggested branch name for consistency:

```bash
# Ensure on main and up-to-date
git checkout main
git pull origin main

# Get branch name from Linear's branchName field
BRANCH_NAME="<from Linear branchName field>"

# Create branch if new, or checkout if exists (idempotent)
git checkout -b "$BRANCH_NAME" 2>/dev/null || git checkout "$BRANCH_NAME"

# Verify correct branch
git branch --show-current
```

This pattern ensures:
- Reuse of existing branches
- Consistent Linear-suggested naming
- Idempotent operations (safe to re-run)
- Always working from latest main

### Step 5: Analyze and Plan Solution

Break down the issue into an actionable implementation plan:

**Analysis Process:**
1. Extract specific requirements from issue description
2. Identify affected components and systems
3. Determine testing strategy (unit → integration → system)
4. Plan implementation approach following project patterns
5. Identify potential risks and dependencies

**Planning Output:**
- **Goal**: Clear statement of implementation objective
- **Requirements**: Specific functional and technical requirements
- **Architecture**: How solution fits existing codebase (models, services, controllers)
- **Test Strategy**: Comprehensive testing including system specs
- **Implementation Steps**: Ordered list of development tasks
- **Acceptance Criteria**: Definition of done

### Step 6: Save Plan to Memory

Store the implementation plan using memory MCP tools:

```
mcp__memory__create_entities(entities: [
  {
    name: "Linear Issue <issue-id>",
    entityType: "implementation-plan",
    observations: [
      "Requirements: <requirements>",
      "Architecture: <architecture-decisions>",
      "Test Strategy: <test-approach>",
      "Status: planning-complete"
    ]
  }
])
```

This creates permanent tracking of:
- Issue context and requirements
- Implementation approach and reasoning
- Progress throughout development
- Lessons learned for future work

### Step 7: Review Plan with User

Present the complete plan for confirmation:

**Plan Presentation:**
- Summary of what will be implemented
- Key technical decisions and rationale
- Testing strategy and expected coverage
- Estimated complexity and identified risks
- Explicit confirmation request

**User Options:**
- Approve to proceed with implementation
- Request modifications to approach
- Add requirements or constraints
- Ask clarifying questions

### Step 8: Test-Driven Development Implementation

Upon approval, invoke the TDD workflow skill:

```
Invoke the Skill tool with: tdd-workflow
```

The TDD workflow skill enforces:
- Red-Green-Refactor cycles
- Test pyramid strategy (unit → integration → system)
- Writing tests before implementation
- Comprehensive test coverage including system specs

**Expected Outcomes:**
- Complete test coverage for new functionality
- Implementation following project POODR principles
- Result pattern for operations that can fail
- Clean, maintainable code structure

### Step 9: Parallel Subagent Code Reviews

After implementation, invoke the parallel code review skill:

```
Invoke the Skill tool with: parallel-code-review
```

This launches specialized review subagents in parallel:

**Security Review:**
- OWASP Top 10 vulnerabilities
- Multi-tenant security (ActsAsTenant verification)
- XSS, CSRF, SQL injection prevention
- Authentication and authorization checks
- Sensitive data handling

**Rails Best Practices Review:**
- POO