feat: expand magic prompts coverage and split generation prompts (#835)
- Add configurable visible/instructions prompt families for commit/PR generation, PR checks/comments flows, and git conflict resolution helpers. - Refactor prompt sending to explicit visible + synthetic parts instead of newline-based splitting, with legacy override migration for old keys. - Polish Magic Prompts settings UX with grouped sidebar entries, tooltip-based descriptions, AI icon, and validation that visible prompts cannot be empty across web and VS Code runtimes.
This commit is contained in:
Bohdan Triapitsyn
committed by
GitHub
GitHub
parent
2e5b02e753
commit
5f0d1623ae
@@ -29,6 +29,7 @@ import { useContextStore } from '@/stores/contextStore';
|
||||
import { useUIStore } from '@/stores/useUIStore';
|
||||
import { useGitHubAuthStore } from '@/stores/useGitHubAuthStore';
|
||||
import { opencodeClient } from '@/lib/opencode/client';
|
||||
import { renderMagicPrompt } from '@/lib/magicPrompts';
|
||||
import { createWorktreeSessionForNewBranch } from '@/lib/worktreeSessionCreator';
|
||||
import { generateBranchSlug } from '@/lib/git/branchNameGenerator';
|
||||
import type { GitHubIssue, GitHubIssueComment, GitHubIssuesListResult, GitHubIssueSummary } from '@/lib/api/types';
|
||||
@@ -450,42 +451,10 @@ export function GitHubIssuePickerDialog({
|
||||
}
|
||||
}
|
||||
|
||||
const visiblePromptText = 'Review this issue using the provided issue context: title, body, labels, assignees, comments, metadata.';
|
||||
const instructionsText = `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 aren’t 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>”.`;
|
||||
const visiblePromptText = await renderMagicPrompt('github.issue.review.visible', {
|
||||
issue_number: String(issue.number),
|
||||
});
|
||||
const instructionsText = await renderMagicPrompt('github.issue.review.instructions');
|
||||
const contextText = buildIssueContextText({ repo: issueRes.repo, issue, comments });
|
||||
|
||||
void opencodeClient.sendMessage({
|
||||
|
||||
@@ -22,6 +22,7 @@ import { useRuntimeAPIs } from '@/hooks/useRuntimeAPIs';
|
||||
import { useProjectsStore } from '@/stores/useProjectsStore';
|
||||
import { useUIStore } from '@/stores/useUIStore';
|
||||
import { useGitHubAuthStore } from '@/stores/useGitHubAuthStore';
|
||||
import { renderMagicPrompt } from '@/lib/magicPrompts';
|
||||
import type { GitHubPullRequestContextResult, GitHubPullRequestSummary, GitHubPullRequestsListResult } from '@/lib/api/types';
|
||||
|
||||
const parsePrNumber = (value: string): number | null => {
|
||||
@@ -47,50 +48,6 @@ const buildPullRequestContextText = (payload: GitHubPullRequestContextResult) =>
|
||||
return `GitHub pull request context (JSON)\n${JSON.stringify(payload, null, 2)}`;
|
||||
};
|
||||
|
||||
const PR_REVIEW_INSTRUCTIONS = `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.
|
||||
|
||||
Format exactly:
|
||||
Must-fix:
|
||||
- <issue> - <brief why> - <file:line-range> - Action: <one-line action>
|
||||
Nice-to-have:
|
||||
- <issue> - <brief why> - <file:line-range> - Action: <one-line action>
|
||||
If no issues, write:
|
||||
Must-fix:
|
||||
- None
|
||||
Nice-to-have:
|
||||
- None`;
|
||||
|
||||
export function GitHubPrPickerDialog({
|
||||
open,
|
||||
onOpenChange,
|
||||
@@ -272,6 +229,7 @@ export function GitHubPrPickerDialog({
|
||||
}
|
||||
|
||||
if (onSelect) {
|
||||
const instructionsText = await renderMagicPrompt('github.pr.review.instructions');
|
||||
onSelect({
|
||||
number: context.pr.number,
|
||||
title: context.pr.title,
|
||||
@@ -279,7 +237,7 @@ export function GitHubPrPickerDialog({
|
||||
head: context.pr.head,
|
||||
base: context.pr.base,
|
||||
includeDiff,
|
||||
instructionsText: PR_REVIEW_INSTRUCTIONS,
|
||||
instructionsText,
|
||||
contextText: buildPullRequestContextText(context),
|
||||
author: context.pr.author
|
||||
? {
|
||||
|
||||
@@ -50,6 +50,7 @@ import { getWorktreeSetupCommands } from '@/lib/openchamberConfig';
|
||||
import { getRootBranch } from '@/lib/worktrees/worktreeStatus';
|
||||
import { generateBranchSlug } from '@/lib/git/branchNameGenerator';
|
||||
import { opencodeClient } from '@/lib/opencode/client';
|
||||
import { renderMagicPrompt } from '@/lib/magicPrompts';
|
||||
import { rankBranchesForQuery } from '@/lib/worktrees/branchSearch';
|
||||
import { useRuntimeAPIs } from '@/hooks/useRuntimeAPIs';
|
||||
import { useGitBranches, useGitStore, useGitLoadingBranches } from '@/stores/useGitStore';
|
||||
@@ -547,42 +548,10 @@ export function NewWorktreeDialog({
|
||||
throw new Error('Failed to load issue comments');
|
||||
}
|
||||
|
||||
const visiblePromptText = `Review this issue #${args.issue.number} using the provided issue context`;
|
||||
const instructionsText = `Review this issue using the provided issue context: title, body, labels, assignees, comments, metadata.
|
||||
|
||||
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 aren't 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>".`;
|
||||
const visiblePromptText = await renderMagicPrompt('github.issue.review.visible', {
|
||||
issue_number: String(args.issue.number),
|
||||
});
|
||||
const instructionsText = await renderMagicPrompt('github.issue.review.instructions');
|
||||
const contextText = buildIssueContextText({
|
||||
repo: issueRes.repo,
|
||||
issue: issueRes.issue,
|
||||
@@ -619,50 +588,10 @@ Do not implement changes until I confirm; end with: "Next actions: <1 sentence>"
|
||||
throw new Error('Failed to load PR context');
|
||||
}
|
||||
|
||||
const visiblePromptText = `Review this pull request #${args.pr.number} using the provided PR context`;
|
||||
const instructionsText = `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.
|
||||
|
||||
Format exactly:
|
||||
Must-fix:
|
||||
- <issue> - <brief why> - <file:line-range> - Action: <one-line action>
|
||||
Nice-to-have:
|
||||
- <issue> - <brief why> - <file:line-range> - Action: <one-line action>
|
||||
If no issues, write:
|
||||
Must-fix:
|
||||
- None
|
||||
Nice-to-have:
|
||||
- None`;
|
||||
const visiblePromptText = await renderMagicPrompt('github.pr.review.visible', {
|
||||
pr_number: String(args.pr.number),
|
||||
});
|
||||
const instructionsText = await renderMagicPrompt('github.pr.review.instructions');
|
||||
const contextText = buildPullRequestContextText(prContext);
|
||||
|
||||
await opencodeClient.sendMessage({
|
||||
|
||||
Reference in New Issue
Block a user