I’m growing a YouTube channel, this newsletter, and trying to get my B2B SaaS off the ground. And that makes me… very time poor.
If you’re an entrepreneur, owner-operator, or a professional that’s barely keeping up and drowning in process, you’re in good company.
We all understand the promise of AI and yet, almost everyone I talk to has no idea where or how to start leveraging AI to really unlock themselves.
Today, I’ll share with you my Claude Code (CC) + Linear system which is saving me hours every single day and helping me ship my product faster.
Solving the Right Problem with AI
I want to be clear: shipping faster isn’t my end goal, solving my customers’ problems and getting my time back are.
I could ship faster by just working more, or hiring an army of freelancers. But stretching myself even further is not sustainable and neither is the cost of employing an army.
So what I actually want is to continue to deliver value to my customers while employing AI to handle tasks/processes that don’t require my strategic input. By doing that, I get back my time, time that I can spend on higher leverage work like creating more content for my YouTube channel or Substack.
What we often see in production and in practice is that the most effective AI solutions are AI + human rather than AI alone. And you likely have a mountain of personal experience in getting bad results when you give AI a task to solve on its own.
From my own experience and from helping others solve their problems with AI, failed implementations are often due to our expectations and approach, rather than an AI’s “intelligence”.
Knowing what to outsource to AI vs what should strictly remain your responsibility, is often the key to a successful AI solution.
Don’t outsource tasks that require strategic or creative decisions. Use AI as a multiplying force, a multiplier of you.
If instead you try to throw AI at everything, you’re slowly replacing yourself. And let’s be real, your AI replacement is probably not going to do your entire job very well, otherwise we’d all be replaced by now.
No one knows your business, product vision, or problem better than you; AI included. No matter how much context you give it, AI will never have as much context as you have in your brain, right now. At least not until we’re all hooked up to Neuralinks 😅.
AI is good for researching, automating processes, compressing information, and giving you different perspectives. Those are the things I would focus on outsourcing to AI.
Now, back to solving our problem. In my case, it’s that I have to repeatedly hand-hold Claude Code (CC) through the exact same process every time I want to implement a new feature or bug fix, which takes hours out of my day.
I want to free up my time by not having to babysit Claude Code when shipping a new customer request.
Now let me walk you through my workflow which is helping me do just that.
Claude Code + Linear
The workflow I’m sharing is based on Linear, a product management app. But even if you’re not building a product, don’t worry too much about the technical details. The concepts very much apply across other types of work. For example you could be managing a content pipeline in Notion, or managing projects and workflows using some Kanban app like Trello or even in a simple to do list.
I like using Linear for product management, it’s a great user experience (no, I’m not sponsored). I also strongly prefer having AI meet me where I’m already working (augmenting), rather than trying to invent a new process or custom workflow to meet AI. This greatly reduces the friction to get started as well as the time it takes to see results.
This is my high level process for resolving a Linear issue:
This is a standardized, repeatable process that really doesn’t require my strategic input outside of the planning phase: perfect for AI.
As mentioned in the previous section, I want to be intimately involved in the planning phase where we figure out architecture decisions, consider the customer experience of the proposed changes, etc.
But besides the planning step, I want Claude Code to automatically handle this process to solve a linear issue end-to-end, without requiring me.
Creating Self-Contained Linear Issues
In Linear, the basic unit of work is an Issue. It defines the problem to solve, and that can be for example a bug, a new feature, an improvement, etc.
For the best results, Issues should be narrow in scope. The way I like to think about it now in the context of AI, is that it’s a narrow enough task that it can be accomplished within a single context window.
Within the prompts you’re about to see, I define a “narrow” scope in terms of the acceptance criteria for the issue. If there are more than 3 acceptance criteria, it should probably be split into multiple issues.
I create issues using slash commands which follow specified templates depending on the issue type. All I have to do is explain my initial problem and it’ll walk me through a quick process to refine the issue until there’s little to no ambiguity. What matters is ensuring that you've defined the problem well enough that an AI agent with zero context can pick it up and work on it to completion.
Here’s what that slash command looks like:
---
name: Create Linear Issue
description: Create a well-defined Linear issue through collaborative conversation
---
# Create Linear Issue
## Goal
Create issues that an AI coding agent can pick up and implement without needing to ask clarifying questions. Focus on **what** needs to be done and **why**, not **how** to implement it.
## Principles
- **Describe intent, not implementation** - Let the implementing agent figure out which files to modify
- **Be specific about outcomes** - Vague requirements lead to misaligned implementations
- **Define boundaries clearly** - What's in scope matters as much as what's out of scope
- **Keep issues small** - If it has >3 acceptance criteria, it should probably be split
## Workflow
1. **Understand what the user wants** - Ask clarifying questions about the problem, desired behavior, and priority
- If the issue is a bug:
- Ask about the steps to reproduce.
- You *MUST USE* the `root-cause-analyzer` agent to provide a root cause analysis.
2. **Draft the issue** - Write it up using the template below
3. **Review with user** - Present the draft and adjust based on feedback
4. **Create in Linear** - Use the MCP tool to create the issue
## Issue Template
```markdown
## Summary
[1-2 sentences: what this accomplishes and why it matters]
## Current vs Expected Behavior
**Current:** [What happens now, or "N/A" for new features]
**Expected:** [What should happen after this is implemented]
## Acceptance Criteria
- [ ] [Specific, testable outcome 1]
- [ ] [Specific, testable outcome 2]
- [ ] [Specific, testable outcome 3 - max 3, split if more needed]
## Scope
**In scope:** [What this issue covers]
**Out of scope:** [What this issue explicitly does NOT cover]
## Additional Context
[Optional: logs, screenshots, error messages, links to designs, related issues, or hints about existing patterns to follow - only include if genuinely helpful]
```
### Issue-Specific Template Sections (REQUIRED)
#### Bugs
```markdown
## Reproduction Steps
1. [Specific step 1]
2. [Specific step 2]
3. [Specific step 3]
## Root Cause Analysis
### Evidence Gathered
[Summarize what was found in Sentry, logs, code review]
### Possible Root Causes
1. **[Most likely cause]** - [Evidence supporting this]
2. **[Alternative cause]** - [Evidence supporting this]
### Relevant Code Paths
- [File/function involved]
- [File/function involved]
```
## Writing Tips
**Titles** should complete "This issue will...":
- Good: "Add Google OAuth login to signup flow"
- Bad: "Google login" or "Auth improvements"
**Acceptance criteria** should be pass/fail testable:
- Good: "User sees error message when email is already registered"
- Bad: "Handle duplicate emails gracefully"
**Scope boundaries** prevent misunderstandings:
- Good: "In scope: Add login button. Out of scope: Forgot password flow"
- Bad: Omitting the section entirely
**Reproduction steps** must be specific and repeatable:
- Good: "1. Log in as admin 2. Navigate to /settings 3. Click 'Save' without changes"
- Bad: "Sometimes the settings page doesn't work"
## Priority & Labels
**Priority** (ask user if unclear):
- **Urgent**: Production broken, security issue
- **High**: Blocking other work, significant user impact
- **Medium**: Normal feature work (default)
- **Low**: Nice-to-have, can wait
**Labels**: Feature | Improvement | Bug
## Creating the Issue
Use `mcp__linear__create_issue` with:
- **Team:** Sprout AI
- **Project:** EQL MVP
- **State:** Backlog
- **Priority:** 1=Urgent, 2=High, 3=Medium, 4=Low
- **Label:** Based on issue type
Here’s an example of an issue created using this exact slash command:
The full issue is partially truncated for clarity. Notice how well the problem is defined. There is even a root cause analysis that’s attached which summarizes the most likely root causes in the code.
This is how you can create issues from natural language prompts that are ready for an agent to pick up and implement without having to ask for additional inputs.
Creating Self-Contained Linear Projects
The next level of work organization in Linear is projects. Projects are useful for grouping multiple related issues.
Let’s say you want to implement payments into your app, you’d have to create your stripe account, create the database tables to store user subscriptions data, add a pricing page, and setup stripe integration into your frontend like the checkout page.
In this example, your project would be Setting up Payments and all of the tasks we just described would be your individual issues. You can organize issues within a project into smaller groups called milestones, but I won’t get further into the weeds for this post.
Here’s the slash command I use to create projects:
---
name: Create Linear Project
description: Create a new Linear project and associated issues
---
# Create Linear Project
## Goal
Break down complex initiatives into focused, dependency-aware issues that an AI agent can work through sequentially.
## Principles
- **One concern per project** - Unrelated tracks of work should be separate projects
- **5-7 issues maximum** - More than this means the scope is too broad
- **Issues stay small** - Max 3 acceptance criteria; split if larger
## Workflow
1. **Understand the initiative** - What problem are we solving? What's the end state?
2. **Explore the codebase** - Understand current implementation to inform structure
3. **Identify milestones** - Break work into logical phases (e.g., Foundation → Core → Integration)
4. **Draft issues per milestone** - Use the `/create-linear-issue` template for each issue
5. **Review with user** - Present structure, adjust based on feedback
6. **Create in Linear** - Project first, then issues with dependencies
## Project Template
```markdown
## Goal
[1-2 sentences: what this accomplishes when complete]
## Milestones
### 1. [Phase Name]
[What this phase accomplishes]
### 2. [Phase Name]
[What this phase accomplishes]
## Technical Context
[Relevant details about current implementation]
## Out of Scope
[What this project does NOT cover]
```
## Naming Conventions
**Project names** - noun phrases describing the initiative:
- Good: "Facebook OAuth Integration", "Order Analytics Dashboard"
- Bad: "Add Facebook login", "Auth improvements"
**Issue titles** - `[Milestone] Action phrase` format:
- Good: "[Foundation] Configure Facebook OAuth in Supabase"
- Bad: "Setup", "Fix auth"
## Dependencies
Use `blockedBy` to establish order: Foundation issues have no blockers, later phases block on earlier ones.
## Creating in Linear
**Project:** `mcp__linear__create_project` with Team: Sprout AI
**Issues:** `mcp__linear__create_issue` with:
- `project`: Link to project created above
- `blockedBy`: Array of blocking issue IDs
- `labels`: Feature | Improvement | Bug
## Common Patterns
**Research-then-implement**: Unsure about approach? Create a standalone research issue first.
**Parallel tracks**: Independent milestone tracks don't need blockers between them.
**Follow-up projects**: Scope expanding? Create a low-priority reminder issue to plan a separate project.
Notice that the create project command leverages the create issue command. Just like with the create issue command, I typically spend 5-10 minutes planning out a project with Claude.
It’s also worth noting that the method for how you plan doesn’t matter all that much. You can leverage skills like superpowers:brainstorming, something like spec-kit, or create your own prompt specific for your use case, like I did.
Whatever you use, it helps to have a back and forth with the agent. Have it ask questions, determine if there are any ambiguities, think about edge cases, etc. and really flesh out the idea.
Now almost inevitably, details will slip through the cracks sometimes and that’s okay because you can always create a follow up issue to make changes.
Here’s an example of a project created with this slash command:
The full project description is partially truncated for clarity. This one includes a deeper level of organization for issues using Milestones, which is useful for larger projects.
Resolving issues
By the way, if you’re interested in purchasing this complete system in a ready-to-use Plugin, complete with a step-by-step guide with examples, MCP configuration, commands, subagents, and skills, there will be a purchase link at the end!
Now that we have a really well-defined project and accompanying issues, we want to create the repeatable process or workflow to resolve issues. This is where the real time savings comes in.
Here’s my slash command for resolving Linear issues using Test Driven Development (TDD). I actually employ the superpowers:test-driven-development skill. No need to reinvent the wheel. We can just use a solution that’s already tested.
You’ll also notice references to a tool called mcpl that Claude is instructed to use as a backup. I had open-sourced the MCP Launchpad (mcpl) tool to efficiently load many MCP servers/tools, before Anthropic shipped Tool Search with Claude Code. If you want to use the prompt you can just remove that part and tell Claude to use the Linear MCP tools directly!
---
name: resolve-linear-issue-tdd
description: Resolve a linear issue end-to-end using Test Driven Development. This involves investigating the issue and relevant context, generating a detailed plan, implementing the plan using TDD, and deploying the changes.
---
# Resolve Linear Issue
This a workflow to resolve a Linear issue end-to-end. It is designed to be flexible and adaptable to different types of issues. Use your understanding of the issue, project context, tools, etc. to adjust the workflow as needed. You should leverage your team of agents whenever possible - see specifically the steps that call for "General", "Plan", and "test-analyzer" agents.
Start by creating a TODO list to complete all steps outlined below.
## Steps
1. Get issue details
Use your MCP tools directly to fetch the issue details. If the MCP tools are not available or fail, use the MCP Launchpad uv tool to fetch the issue details. For example:
```bash
mcpl call linear get_issue '{"id": "spr-12"}'
```
2. Generate issue branch
Create a new branch from `main` with the issue ID to automatically link it to linear (e.g. spr-123-my-feature). This automatically moves the issue to "In Progress" in Linear.
3. **Call a new Plan agent** to investigate the issue and generate a plan to implement/resolve the issue using Test Driven Development (TDD).
The following instructions are an example, modify or add as needed.
<example_prompt>
You **MUST** use the superpowers:test-driven-development skill for this task. Start by invoking the skill to understand the implementation strategy.
Use the MCP Launchpad to fetch the issue details, for example:
```bash
mcpl call linear get_issue '{"id": "spr-12"}'
```
Gather additional context if relevant, e.g.:
- See related git commit and PRs
- Explore relevant code
- Sentry for error/issue logs
- Use PSQL to explore the local dev db, or Supabase to access actual PROD data
- Render for backend logs
- etc.
</example_prompt>
4. Call a new General agent to implement the plan. After implementation, the agent must run the tests and ensure they pass. The agent must also ensure that all linters and type checkers pass, apply supabase migrations locally and ensure no errors, and that bun run build completes successfully.
5. Commit and push the changes on the issue branch, then open a PR into main for review.
6. Update the linear issue with any relevant information or findings that are important for posterity. Do not change the issue status/state, it will automatically move to "Done" when the PR is merged.
7. Start a background task to monitor the PR checks until they've all completed running. IF any checks failed, call a new General agent to read the check results, fix the failures, commit and push the changes and add a comment to the PR summarizing the changes made. You can ignore failed Vercel deployments due to permissions errors.
8. You, Claude, must read the complete PR Review. If any issues/recommendations have been raised, call a General agent to address **ALL** issues, even minor ones.
The general agent should:
- Read the full PR review
- Address **ALL** issues, even minor ones
- Re-run tests as needed
- Commit the updates and push
- Add a comment to the PR summarizing the changes made.
9. Clean up by killing any background tasks
Notice how we consistently leverage the use of subagents to preserve the main context window. This allows us to resolve an entire issue while only using around 30-70K tokens in the main context window.
Once the slash command is executed, Claude Code populates its task list with this exact process. It then systematically resolves the Linear issue end-to-end without me having to jump in at all.
What I end up with is a PR with a complete bug fix or new feature that has been tested thoroughly, completed a review process, fixed all issues in the review, passed build checks, and is ready to merge to production.
If you want to see this process happen live, see the video version of this post on YouTube:
Results
With this simple 2 step process, I spend 5-10 minutes planning the project. And then for each issue, I spend less than a minute to run /resolve-linear-issue and merge each PR.
Claude typically takes anywhere between 10 to 30 minutes to completely resolve an issue on its own, depending on the complexity.
Between my old, manual workflow and this new process, I estimate that I’m saving 3-10 minutes per issue. Which amounts to 45 min to 2 hours per day. This is a significant time savings! But more importantly…
with my old process, I couldn’t do much while Claude worked because I had to manage it throughout. Now I can step away and work uninterrupted for 10s of minutes at a time. That’s where I’ve gotten the most value.
It’s nice being able to execute one slash command and come back to a ready-to-ship PR. But we can do better.
The next step is to automate the part where I have to manually run the /resolve-linear-issue command that starts the whole process. This is obviously a repetitive task that I don’t need to be doing. If I can figure that out, I could simply review when the full project has been implemented, but that’ll have to wait for the next post. Let me know if you have any ideas on how to get Claude to complete the full project on its own!
If you’re interested in purchasing this complete system in a ready-to-use Plugin, complete with MCP configuration, commands, subagents, skills, and a step-by-step guide with examples, you can do so here!