Press n or j to go to the next uncovered block, b, p or k for the previous block.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 | 21x 21x 21x 18x 6x 8x 5x 21x 14x | import { existsSync } from 'node:fs';
import { join } from 'node:path';
import type { SkillDefinition } from '../config/schema.js';
import { formatHunkForAnalysis, type HunkWithContext } from '../diff/index.js';
import {
buildChangedFilesSection,
buildJsonOutputSection,
buildPullRequestContextSection,
joinPromptSections,
type PromptPRContext,
} from './prompt-sections.js';
export type PRPromptContext = PromptPRContext;
/**
* Builds the system prompt for hunk-based analysis.
*
* Future enhancement: Could have the agent output a structured `contextAssessment`
* (applicationType, trustBoundaries, filesChecked) to cache across hunks, allow
* user overrides, or build analytics. Not implemented since we don't consume it yet.
*/
export function buildHunkSystemPrompt(skill: SkillDefinition): string {
const sections = [
`<role>
You are a code analysis agent for Warden. You evaluate code changes against specific skill criteria and report findings ONLY when the code violates or conflicts with those criteria. You do not perform general code review or report issues outside the skill's scope.
</role>`,
`<verification>
Before reporting a finding:
1. Read the relevant source code to understand the full context
2. Trace through the code path — follow imports, base classes, and indirect references, not just the immediate file
3. Verify your assumptions — confirm the issue exists, don't infer from incomplete information
4. Ensure the finding references lines within the hunk being analyzed
5. Document your verification in the 'verification' field of each finding
</verification>`,
`<skill_instructions>
The following defines the ONLY criteria you should evaluate. Do not report findings outside this scope:
${skill.prompt}
</skill_instructions>`,
buildJsonOutputSection(`
Example response format:
{"findings": [{"id": "example-1", "severity": "medium", "confidence": "high", "title": "Issue title", "description": "Description", "location": {"path": "file.ts", "startLine": 10}}]}
Full schema:
{
"findings": [
{
"id": "unique-identifier",
"severity": "high|medium|low",
"confidence": "high|medium|low",
"title": "Short, specific title naming the broken behavior or risk (e.g. 'wasFailFastAborted never detects fail-fast abort')",
"description": "Visible inline PR comment. Use one short, direct sentence whenever possible; two only if needed for the fix or impact.",
"location": {
"path": "path/to/file.ts",
"startLine": 10,
"endLine": 15
},
"verification": "Required. Detailed evidence for the collapsible verification block: files/functions checked, trigger conditions, expected vs actual behavior, and why mitigations do not apply.",
"suggestedFix": {
"description": "How to fix this issue",
"diff": "unified diff format"
}
}
]
}
Requirements:
- Return valid JSON starting with {"findings":
- "findings" array can be empty if no issues found
- "location.path" is auto-filled from context - just provide startLine (and optionally endLine). Omit location entirely for general findings not about a specific line.
- "location.startLine" MUST be within the hunk line range (shown in the "## Hunk" header). If the issue originates in surrounding code, anchor to the nearest changed line in the hunk and note the actual location in the description.
- "confidence" reflects how certain you are this is a real issue given the codebase context
- "suggestedFix" is optional - only include when you can provide a complete, correct fix **to the file being analyzed**. Omit suggestedFix if:
- The fix would be incomplete or you're uncertain about the correct solution
- The fix requires changes to a different file or a new file (briefly name the fix in the description field instead)
- "description" is rendered directly in GitHub inline comments. Keep it brief and actionable, usually one sentence.
- Put proof, trace notes, checked files, and expected/actual breakdowns in "verification", not "description".
- Do not include severity, confidence, finding ID, skill name, or generic review framing in "description".
- Focus your analysis on the code changes in the hunk. Surrounding context and tool results are for understanding only -- all findings must reference lines within the hunk range.
`),
];
const { rootDir } = skill;
if (rootDir) {
const resourceDirs = ['scripts', 'references', 'assets'].filter((dir) =>
existsSync(join(rootDir, dir))
);
if (resourceDirs.length > 0) {
const dirList = resourceDirs.map((d) => `${d}/`).join(', ');
sections.push(`<skill_resources>
This skill is located at: ${rootDir}
You can read files from ${dirList} subdirectories using the Read tool with the full path.
</skill_resources>`);
}
}
return sections.join('\n\n');
}
/**
* Builds the user prompt for a single hunk.
*/
export function buildHunkUserPrompt(
skill: SkillDefinition,
hunkCtx: HunkWithContext,
prContext?: PRPromptContext
): string {
return joinPromptSections([
`<task>
Analyze this code change according to the "${skill.name}" skill criteria.
</task>`,
buildPullRequestContextSection(prContext),
buildChangedFilesSection(prContext, hunkCtx.filename),
formatHunkForAnalysis(hunkCtx),
`<scope_reminder>
Only report findings that are explicitly covered by the skill instructions. Do not report general code quality issues, bugs, or improvements unless the skill specifically asks for them. Return an empty findings array if no issues match the skill's criteria.
</scope_reminder>`,
]);
}
|