template:'Review this pull request #{{pr_number}} using the provided PR context',
},
{
id:'github.pr.review.instructions',
title:'PR Review Instructions',
group:'GitHub',
description:'Hidden instructions attached when generating a PR review response.',
template:`Before reporting issues:
- First identify the PR intent (what it's trying to achieve) from title/body/diff, then evaluate whether the implementation matches that intent; call out missing pieces, incorrect behavior vs intent, and scope creep.
- Gather any needed repository context (code, config, docs) to validate assumptions.
- No speculation: if something is unclear or cannot be verified, say what's missing and ask for it instead of guessing.
Output rules:
- Start with a 1-2 sentence summary.
- Provide a single concise PR review comment.
- No emojis. No code snippets. No fenced blocks.
- Short inline code identifiers allowed, but no snippets or fenced blocks.
- Reference evidence with file paths and line ranges (e.g., path/to/file.ts:120-138). If exact lines aren't available, cite the file and say "approx" + why.
- Keep the entire comment under ~300 words.
Report:
- Must-fix issues (blocking)-brief why and a one-line action each.
- Nice-to-have improvements (optional)-brief why and a one-line action each.
Quality & safety (general):
- Call out correctness risks, edge cases, performance regressions, security/privacy concerns, and backwards-compatibility risks.
- Call out missing tests/verification steps and suggest the minimal validation needed.
- Note readability/maintainability issues when they materially affect future changes.
Applicability (only if relevant):
- If changes affect multiple components/targets/environments (e.g., client/server, OSs, deployments), state what is affected vs not, and why.
Architecture:
- Call out breakages, missing implementations across modules/targets, boundary violations, and cross-cutting concerns (errors, logging/observability, accessibility).
Precedence:
- If local precedent conflicts with best practices, state it and suggest a follow-up task.
Do not implement changes until I confirm; end with a short "Next actions" sentence describing the recommended plan.
description:'Visible user message when creating issue review requests from GitHub context.',
placeholders:[
{key:'issue_number',description:'Issue number.'},
],
template:'Review this issue #{{issue_number}} using the provided issue context',
},
{
id:'github.issue.review.instructions',
title:'Issue Review Instructions',
group:'GitHub',
description:'Hidden instructions attached when generating an issue review response.',
template:`Review this issue using the provided issue context.
Process:
- First classify the issue type (bug / feature request / question/support / refactor / ops) and state it as: Type: <one label>.
- Gather any needed repository context (code, config, docs) to validate assumptions.
- After gathering, if anything is still unclear or cannot be verified, do not speculate-state what's missing and ask targeted questions.
Output rules:
- Compact output; pick ONE template below and omit the others.
- No emojis. No code snippets. No fenced blocks.
- Short inline code identifiers allowed.
- Reference evidence with file paths and line ranges when applicable; if exact lines are not available, cite the file and say "approx" + why.
- Keep the entire response under ~300 words.
Templates (choose one):
Bug:
- Summary (1-2 sentences)
- Likely cause (max 2)
- Repro/diagnostics needed (max 3)
- Fix approach (max 4 steps)
- Verification (max 3)
Feature:
- Summary (1-2 sentences)
- Requirements (max 4)
- Unknowns/questions (max 4)
- Proposed plan (max 5 steps)
- Verification (max 3)
Question/Support:
- Summary (1-2 sentences)
- Answer/guidance (max 6 lines)
- Missing info (max 4)
Do not implement changes until I confirm; end with: "Next actions: <1 sentence>".`,
},
{
id:'github.pr.checks.review.visible',
title:'PR Failed Checks Visible Prompt',
group:'GitHub',
description:'Visible user message for PR failed checks analysis.',
template:'Review these PR failed checks and propose likely fixes. Do not implement until I confirm.',
},
{
id:'github.pr.checks.review.instructions',
title:'PR Failed Checks Instructions',
group:'GitHub',
description:'Hidden instructions for PR failed checks analysis.',
template:`Use the attached checks payload.
- Summarize what is failing.
- Prioritize check annotations/errors over generic status text.
- Identify likely root cause(s).
- Propose a minimal fix plan and verification steps.
- No speculation: ask for missing info if needed.`,
},
{
id:'github.pr.comments.review.visible',
title:'PR Comments Review Visible Prompt',
group:'GitHub',
description:'Visible user message for PR comments analysis.',
template:'Review these PR comments and propose the required changes and next actions. Do not implement until I confirm.',
},
{
id:'github.pr.comments.review.instructions',
title:'PR Comments Review Instructions',
group:'GitHub',
description:'Hidden instructions for PR comments analysis.',
template:`Use the attached comments payload.
- Identify required vs optional changes.
- Call out intent/implementation mismatch if present.
- Propose a minimal plan and verification steps.
- No speculation: ask for missing info if needed.`,
},
{
id:'github.pr.comment.single.visible',
title:'Single PR Comment Visible Prompt',
group:'GitHub',
description:'Visible user message for single PR comment analysis.',
template:'Address this comment from PR and propose required changes. Do not implement until I confirm.',
},
{
id:'github.pr.comment.single.instructions',
title:'Single PR Comment Instructions',
group:'GitHub',
description:'Hidden instructions for single PR comment analysis.',
template:`Use the attached single-comment payload.
- Explain what the reviewer is asking for.
- Identify exact code areas likely impacted.
- Propose a minimal implementation plan and verification steps.
- Call out ambiguity and ask focused follow-up questions if needed.`,
},
{
id:'git.conflict.resolve.visible',
title:'Merge/Rebase Conflict Visible Prompt',
group:'Git',
description:'Visible user message for merge/rebase conflict resolution help.',
placeholders:[
{key:'operation_label',description:'Operation label in lower-case (merge/rebase).'},
{key:'head_ref',description:'Head reference for preserving intent.'},
],
template:'Resolve {{operation_label}} conflicts, stage the resolved files, and complete the {{operation_label}}. Preserve the intent of changes from {{head_ref}}.',
},
{
id:'git.conflict.resolve.instructions',
title:'Merge/Rebase Conflict Instructions',
group:'Git',
description:'Hidden instructions for merge/rebase conflict resolution help.',
placeholders:[
{key:'operation_label',description:'Operation label in lower-case (merge/rebase).'},
template:'Resolve cherry-pick conflicts, stage the resolved files, and continue the cherry-pick. Keep intent of commit {{current_commit}} onto branch {{target_branch}}.',
description:'Visible user message when sending a todo into a new planning session.',
placeholders:[
{key:'todo_text',description:'Todo text selected by the user.'},
],
template:'{{todo_text}}',
},
{
id:'plan.todo.instructions',
title:'Todo Planning Instructions',
group:'Planning',
description:'Hidden instructions for sending a project todo into a new planning session.',
placeholders:[
{key:'todo_text',description:'Todo text selected by the user.'},
],
template:`You are starting from a project todo item.
Todo: {{todo_text}}
Your job right now is to produce an implementation plan for this todo, not to implement it yet.
Before writing the plan, inspect the repository and gather the necessary context from relevant files, module docs, existing patterns, and nearby code.
Identify the affected areas, constraints, dependencies, likely risks, and validation steps based on the actual repo state.
Then provide a concrete implementation plan grounded in that repo context. Make assumptions and missing context explicit.`,
},
{
id:'plan.improve.visible',
title:'Improve Plan Visible Prompt',
group:'Planning',
description:'Visible user message when sending a saved plan into an improve flow.',
placeholders:[
{key:'plan_title',description:'Current plan title.'},
],
template:'Improve this plan: {{plan_title}}',
},
{
id:'plan.improve.instructions',
title:'Improve Plan Instructions',
group:'Planning',
description:'Hidden instructions for improving a saved plan from project context.',
placeholders:[
{key:'plan_title',description:'Current plan title.'},
{key:'plan_path',description:'Absolute path to the saved plan file.'},
],
template:`You are starting from an existing implementation plan.
Plan title: {{plan_title}}
This plan is stored in the file: {{plan_path}}
Read that file first and treat its current contents as the source of truth for the plan.
First inspect the repository and gather the necessary context from relevant files, module docs, existing patterns, and nearby code.
Your main goal in this task is to improve the plan so it is better grounded in the actual repo state.
Do not implement yet. Produce an improved implementation plan, call out assumptions, missing context, risks, and validation steps.
Discuss important plan decisions, tradeoffs, gaps, or risks with the user in a concise and understandable way.
Keep the response short and to the point. Do not dump a long wall of text.
Prefer a short summary of proposed changes, open questions, and recommendations over rewriting the whole plan inline.
Do not return the full plan as a markdown code block or fenced block.
If useful, quote only small targeted snippets or describe the exact sections that should change.
After you finish researching, propose the improved plan and explicitly offer to edit this same file with those plan changes.`,
},
{
id:'plan.implement.visible',
title:'Implement Plan Visible Prompt',
group:'Planning',
description:'Visible user message when sending a saved plan into an implement flow.',
placeholders:[
{key:'plan_title',description:'Current plan title.'},
],
template:'Implement this plan: {{plan_title}}',
},
{
id:'plan.implement.instructions',
title:'Implement Plan Instructions',
group:'Planning',
description:'Hidden instructions for implementing a saved plan from project context.',
placeholders:[
{key:'plan_title',description:'Current plan title.'},
{key:'plan_path',description:'Absolute path to the saved plan file.'},
],
template:`You are starting from an existing implementation plan.
Plan title: {{plan_title}}
This plan is stored in the file: {{plan_path}}
Read that file first and treat its current contents as the source of truth for the plan.
Use this plan as task context and begin implementing it.
Before and during implementation, inspect the repository and gather the necessary context from relevant files, module docs, existing patterns, and nearby code.
Do the implementation work. If you discover mismatches between the plan and the repo reality, make those adjustments explicit and continue with implementation using the corrected understanding.
If implementation reveals plan adjustments, explicitly tell the user those plan changes should be saved back into this same file.`,
