Menu
Issue tracking and project management with Linear MCP. Use when creating issues, managing tasks, updating status, or working with Linear projects. Provides conventions for sizing, status, comments, and labels.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when working with mise - creating/editing mise.toml or .mise.toml files, defining tasks with usage field arguments, managing dev tools and environments, configuring hooks, or when user mentions mise configuration.
Prisma 7 ORM with PostgreSQL — schema design, migrations, seeding, and Railway deployment patterns. This skill should be used when setting up Prisma in a new project, writing migrations, managing database schemas, or deploying Prisma-backed services to Railway.
Railway deployment and infrastructure management skill. This skill should be used when deploying applications to Railway, managing Railway services, checking deployment status, viewing logs, configuring environment variables, or troubleshooting Railway deployments.
NestJS 11 backend patterns with Fastify, modular architecture, guards, pipes, and Railway deployment. This skill should be used when building NestJS APIs, setting up backend services, or creating REST/GraphQL endpoints with NestJS.
shadcn/studio component library with MCP integration, theme generation, and block patterns. This skill should be used when building UI with shadcn components, selecting dashboard layouts, or generating landing pages. Canonical source for all shadcn-based work.
Theme generation with tweakcn for shadcn/ui and Magic UI animations. Use when setting up project themes, customizing color schemes, adding dark mode, or integrating animated components.
| name | tools-linear |
| description | Issue tracking and project management with Linear MCP. Use when creating issues, managing tasks, updating status, or working with Linear projects. Provides conventions for sizing, status, comments, and labels. |
Conventions and patterns for using the Linear MCP server effectively.
Use the Linear MCP server tools:
| Tool | Purpose |
|---|---|
linear_create_issue | Create new issues |
linear_update_issue | Update existing issues |
linear_search_issues | Find issues by query |
linear_get_issue | Get issue details |
linear_add_comment | Add comments to issues |
linear_get_teams | List available teams |
linear_get_projects | List projects |
Format: <type>: <brief description>
Types:
feat - New feature or enhancementfix - Bug fixchore - Maintenance, refactoring, dependenciesdocs - Documentationperf - Performance improvementExamples:
feat: Add user authentication flow
fix: Resolve null pointer in checkout
chore: Upgrade React to v19
docs: Update API documentation
Structure descriptions consistently:
## Context
[Why this issue exists - background and motivation]
## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3
## Technical Notes
[Optional: implementation hints, constraints, dependencies]
Use fibonacci-style story points:
| Points | Meaning | Rough Time |
|---|---|---|
| 0 | Trivial | < 30 min |
| 1 | Small | 1-2 hours |
| 2 | Medium-small | Half day |
| 3 | Medium | 1 day |
| 5 | Medium-large | 2-3 days |
| 8 | Large | 1 week |
| 13 | Very large | Consider splitting |
Default to smaller estimates. If unsure between 3 and 5, pick 3.
| Priority | When to Use |
|---|---|
| Urgent | Production down, security issue, blocking release |
| High | Current sprint commitment, customer-facing bugs |
| Medium | Planned work, improvements (default) |
| Low | Nice-to-have, tech debt, future consideration |
Standard workflow states:
Backlog → Todo → In Progress → In Review → Done
↓
Blocked
Status conventions:
Use labels sparingly. Recommended categories:
| Category | Examples |
|---|---|
| Area | frontend, backend, api, infra |
| Type | bug, enhancement, tech-debt |
| Effort | quick-win, spike |
Add comments for:
**[Status Update]**
Blocked waiting on API credentials from vendor. ETA tomorrow.
---
**[Technical Note]**
Found that the existing auth middleware can be reused. See `src/middleware/auth.ts`.
---
**[Decision]**
Going with approach A because of X. Considered B but rejected due to Y.
When a PR is created, add a comment:
**[PR Submitted]**
https://github.com/org/repo/pull/123
Ready for review.
1. Use linear_get_teams to find team ID
2. Create issue with:
- Descriptive title (type: description)
- Structured description with acceptance criteria
- Appropriate estimate (default to smaller)
- Priority (default: Medium)
- Status: Backlog or Todo
1. Move issue to "In Progress"
2. Begin implementation
3. Add comments for significant findings
1. Create PR (see Git conventions)
2. Add comment linking PR to issue
3. Move issue to "In Review"
1. Merge PR
2. Move issue to "Done"
3. Add final comment if needed (lessons learned, follow-up items)
Do NOT use Linear's git branch integration. We manage branches manually.
When working on an issue:
Search: assignee:me is:open
Search: status:Blocked
Search: priority:High label:bug
Search: estimate:none project:"Current Sprint"
| Action | Approach |
|---|---|
| Create issue | Title with type prefix, structured description |
| Size issue | Fibonacci points, default smaller |
| Update status | Move through workflow, add context comments |
| Link PR | Comment with PR URL when submitted |
| Close issue | Move to Done after PR merged and verified |