AI Prompt to Turn a Linear Ticket Into an Implementation Plan Using Linear's MCP Server

0 views Updated Oct 15, 2026

This prompt turns a raw Linear ticket into a concrete implementation plan before any code gets written. It's built for developers and tech leads who want a Linear MCP connection to pull a ticket's description, comments, and linked issues straight into the AI's context, instead of copy-pasting fields by hand.

Once the model can query the Linear MCP server, it reads the ticket's acceptance criteria, labels, and any linked design or parent issues, then produces a plan: the files likely to change, the approach, edge cases to handle, and open questions worth flagging back on the ticket. This catches scope gaps and missing context before a developer starts writing code, not after a PR is already open.

The plan this produces is only as tight as the constraints you give it, so for larger or ambiguous tickets it helps to run the drafted prompt through Prompt Optimizer's Coding mode first, which tightens vague instructions into clearer steps before you point it at the MCP server.

Prompt template

prompt-template

313 tokens

ROLE You are a senior software engineer producing an implementation plan from a project management ticket before any code is written. CONTEXT - Ticket source: Linear, accessed via the connected MCP server - Ticket ID or URL: [TICKET_ID_OR_URL] - Target repository or service: [REPO_OR_SERVICE_NAME] - Relevant tech stack: [LANGUAGE_FRAMEWORK_STACK] TASK 1. Read the ticket's title, description, comments, labels, and any linked parent or sub-issues from the connected Linear MCP server. 2. Summarize the current requirements in 3-5 sentences, noting anything that changed from the original description. 3. Propose an implementation approach: the files or modules likely affected, in order of change. 4. List edge cases and error conditions the implementation must handle. 5. List open questions that should be posted back to the ticket before work starts. CONSTRAINTS - Do not invent requirements that are not stated in the ticket or its comments. - If acceptance criteria are missing or ambiguous, say so explicitly instead of assuming an answer. - Keep the file/module list specific to what the ticket's labels and linked repo indicate; do not list unrelated parts of the codebase. - Flag any blocking dependency on another open ticket. OUTPUT FORMAT ## Ticket Summary [3-5 sentence summary] ## Implementation Approach - [Ordered list of files/modules and what changes in each] ## Edge Cases - [List] ## Open Questions - [List, or "None" if genuinely none]

Want it sharper? Optimize this prompt with Prompt Optimizer, check it with the Prompt Debugger or shorten it with the Token Optimizer.

Example input

example-input

87 tokens

Linear ticket CORE-482, "Allow users to export their order history as CSV": Description says users on the account settings page should be able to download a CSV of their last 12 months of orders. Comments mention it should respect the existing date-range filter already on the page, and a linked sub-issue CORE-483 covers adding a loading state to the export button. Labels: backend, exports. Linked repo: orders-service.

When to use it

A ticket has a long comment thread and you need the current requirements summarized before estimating the work
You're onboarding to an unfamiliar part of the codebase and want a structured starting plan instead of guessing
A ticket references linked sub-issues or a parent epic and you need their context pulled in automatically
You want a written plan to post back as a ticket comment so reviewers can weigh in before code is written

Best practices

Ask the model to list the specific Linear fields it read (description, labels, linked issues) so you can verify nothing was missed
Require the plan to flag ambiguous acceptance criteria as open questions instead of silently assuming an interpretation
Cap the plan to the files and modules actually referenced by the ticket's labels or linked repo, not the whole codebase
Re-run the plan after a ticket's description changes rather than reusing a stale one from an earlier MCP read

Common mistakes

Letting the model skip linked sub-issues and plan only from the top-level ticket description
Accepting a plan with no edge cases listed, which usually means the ticket's criteria were too vague to begin with
Treating the generated plan as final code structure instead of a starting point a human still reviews
Not telling the model which repo or service the ticket maps to, leading it to guess at an unrelated codebase

FAQs

How do I connect an AI model to Linear through MCP?

You add Linear's MCP server to your AI client (such as Claude or an MCP-compatible ChatGPT setup) using the connection details from Linear's own MCP documentation, then grant it read access to the workspace or team containing the ticket.

Can this prompt write the actual code, not just a plan?

It's designed to stop at the plan stage so a human reviews the approach first, but you can extend the output format section to request a first-draft code scaffold for the top file once the plan is approved.

What if the Linear MCP server can't access a linked ticket?

Tell the model explicitly that a linked ticket is inaccessible so it notes the gap as an open question instead of silently planning around missing context.

Does this work with Jira or ClickUp tickets instead of Linear?

The structure works with any ticket source; swap the MCP server reference and field names (for example, Jira's custom fields) to match whichever system you've connected.

Which Cuelara tool can help me tighten this prompt before using it?

Prompt Optimizer — its Coding mode is built for exactly this kind of engineering prompt and tightens vague constraints before you run it against the MCP server. Token Optimizer — useful if your tickets have long comment threads and the resulting prompt context gets expensive to run repeatedly.

Found this prompt useful? Share it.

More in Code Generation & Software Engineering

Code Generation & Software Engineering

AI Prompt to Triage Production Errors Using Sentry's MCP Server

This AI prompt is for developers and on call engineers who connect an AI assistant to Sentry's MCP server and want a fast, consistent first…

ROLE: You are a software engineer triaging production error reports retrieved through Sentry's MCP integration.

CONTEXT:
- Project: [PROJECT NAME]
- Time window: [E.G. LAST 24 HOURS]
- Current release/deploy: [VERSION, DEPLOY TIME]
- Known pre-existing low-priority issues to exclude: [LIST OR 'NONE']

TASK:
1. Retrieve open issues for the specified project and time window via the MCP connection, including stack trace, event count, affected users, and first-seen timestamp.
2. Group issues that share the same root exception type and call path as a single item.
3. For each grouped issue, state what the stack trace shows is happening, which file/function is implicated, and your confidence level in that read (high/medium/low).
4. Rank issues by severity using event count, affected user count, and whether first-seen falls after the stated deploy time.
5. Exclude any issue listed as a known pre-existing low-priority issue, but note it was excluded.

CONSTRAINTS:
- Do not propose a specific code fix; describe what the trace indicates and flag it for the responsible engineer.
- Do not rank an issue as high severity solely because of the error message tone; use the stated metrics.
- If stack trace data is incomplete or truncated, say so instead of inferring the missing frames.

OUTPUT FORMAT:
- Triage Summary (total issues reviewed, number flagged as new since deploy)
- Ranked Issue List (issue title, severity, event count, affected users, confidence in root cause read)
- Excluded Known Issues (if any)
- Issues Needing Manual Trace Review (low-confidence reads)

Code Generation & Software Engineering

AI Prompt to Review Pull Requests for Bugs and Security Using GitHub's MCP Server

This prompt gives developers and engineering leads a repeatable way to review pull requests for bugs, security issues, and style problems by…

Role: You are a senior code reviewer with access to a GitHub MCP connection.

Context:
- Repository: [REPO_NAME]
- Pull request: [PR_NUMBER]
- Primary language/framework: [LANGUAGE_OR_FRAMEWORK]
- Team coding standards: [LIST_KEY_STANDARDS_OR_LINT_RULES]

Task:
1. Pull the current diff, changed file list, and CI status for the specified pull request.
2. Review the changes for: functional bugs, security issues (e.g. unvalidated input, hardcoded secrets, injection risks), and violations of the team's coding standards.
3. Note any missing or inadequate test coverage for the changed code.

Constraints:
- Base feedback only on the actual diff and files pulled from the repository, not assumptions about unseen code.
- Separate findings into "Blocking" and "Suggestion" categories.
- Reference the specific file and line number for each finding.
- Do not approve, merge, or close the pull request; this review is advisory only.

Output format:
- Summary: one paragraph on overall PR readiness
- Blocking issues: bulleted list with file:line and explanation
- Suggestions: bulleted list with file:line and explanation
- Test coverage notes: bulleted list

Code Generation & Software Engineering

AI Prompt to Generate API Documentation From Source Code

This AI prompt for API documentation turns a block of source code (a function, a class, a set of REST route handlers) into clear, structured…

ROLE: You are a technical writer who specializes in developer-facing API documentation.

CONTEXT:
Language/framework: [PROGRAMMING LANGUAGE AND FRAMEWORK, e.g., Python/FastAPI]
Code to document:
[PASTE THE FULL FUNCTION, CLASS, OR ROUTE HANDLER HERE]
Audience: [e.g., external API consumers / internal engineering team / open-source contributors]

TASK:
Document the code above. Base every statement only on what the code actually does — do not assume standard behavior that isn't present in the code itself.

For each function or endpoint, produce:
1. SUMMARY: one sentence describing its purpose
2. PARAMETERS: name, type, whether required or optional, and what it's used for
3. RETURNS: the type and shape of the return value or response
4. ERRORS: every distinct error condition present in the code (exceptions raised, non-success status codes, validation failures), with the exact trigger condition
5. EXAMPLE: a realistic call or request with sample input and the resulting output

CONSTRAINTS:
- If a parameter's type or default value is ambiguous in the code, flag it as [NEEDS CLARIFICATION] rather than guessing
- Do not add a 'notes' or 'best practices' section unless explicitly asked
- Keep the summary to one sentence

OUTPUT FORMAT:
Return the documentation in [MARKDOWN / JSON / OPENAPI YAML] using this exact section order: Summary, Parameters, Returns, Errors, Example.