@juspay/yama 2.3.0 → 2.4.0

package/dist/v2/memory/MemoryManager.js

@@ -129,6 +129,28 @@ export class MemoryManager {
     static buildOwnerId(workspace, repository) {
         return `${workspace}-${repository}`.toLowerCase();
     }
+    /**
+     * Read persisted condensed memory for a repository owner ID.
+     */
+    async readMemory(ownerId) {
+        const storageDir = this.resolveStorageDir();
+        const filePath = this.ownerIdToFilePath(storageDir, ownerId);
+        if (!existsSync(filePath)) {
+            return null;
+        }
+        try {
+            return await readFile(filePath, "utf-8");
+        }
+        catch {
+            return null;
+        }
+    }
+    /**
+     * Read persisted condensed memory for a workspace/repository pair.
+     */
+    async readRepositoryMemory(workspace, repository) {
+        return this.readMemory(MemoryManager.buildOwnerId(workspace, repository));
+    }
     /**
      * Commit memory files to the repository if autoCommit is enabled.
      *

package/dist/v2/prompts/LangfusePromptManager.js

@@ -20,6 +20,12 @@ export class LangfusePromptManager {
      * Initialize Langfuse client if credentials are available
      */
     initializeClient() {
+        const skipLangfusePrompts = process.env.YAMA_SKIP_LANGFUSE_PROMPTS === "true" ||
+            process.env.YAMA_SKIP_LANGFUSE_PROMPTS === "1";
+        if (skipLangfusePrompts) {
+            console.log("   ⏭️  Langfuse prompt fetch disabled (YAMA_SKIP_LANGFUSE_PROMPTS) — using local prompts");
+            return;
+        }
         const publicKey = process.env.LANGFUSE_PUBLIC_KEY;
         const secretKey = process.env.LANGFUSE_SECRET_KEY;
         const baseUrl = process.env.LANGFUSE_BASE_URL;

package/dist/v2/prompts/PromptBuilder.d.ts

@@ -15,7 +15,24 @@ export declare class PromptBuilder {
      * Build complete review instructions for AI
      * Combines generic base prompt + project-specific config
      */
-    buildReviewInstructions(request: ReviewRequest, config: YamaConfig): Promise<string>;
+    buildReviewInstructions(request: ReviewRequest, config: YamaConfig, bootstrapStandards?: string | null): Promise<string>;
+    /**
+     * Per-PR workflow block. Standards-first, file-by-file, explore-on-uncertainty.
+     * The agent stays autonomous; this just choreographs the order it should follow.
+     */
+    private buildReviewWorkflow;
+    /**
+     * Strip sections that depend on explore_context being enabled.
+     * Keeps the prompt single-source and avoids forking files for the disabled case.
+     *
+     * - <!-- EXPLORE_BEGIN -->...<!-- EXPLORE_END --> is removed when explore is OFF.
+     * - <!-- EXPLORE_DISABLED_BEGIN -->...<!-- EXPLORE_DISABLED_END --> is removed when explore is ON.
+     * - The marker comments themselves are always stripped.
+     *
+     * Implementation uses linear indexOf/slice instead of regex to avoid any
+     * polynomial-backtracking risk on adversarial input.
+     */
+    static stripDisabledSections(prompt: string, exploreEnabled: boolean): string;
     /**
      * Build project configuration in XML format
      * Injects project-specific rules into base system prompt

package/dist/v2/prompts/PromptBuilder.js

@@ -19,15 +19,31 @@ export class PromptBuilder {
      * Build complete review instructions for AI
      * Combines generic base prompt + project-specific config
      */
-    async buildReviewInstructions(request, config) {
+    async buildReviewInstructions(request, config, bootstrapStandards) {
         // Base system prompt - fetched from Langfuse or local fallback
-        const basePrompt = await this.langfuseManager.getReviewPrompt();
+        const basePromptRaw = await this.langfuseManager.getReviewPrompt();
         // Project-specific configuration in XML format
         const projectConfig = this.buildProjectConfigXML(config, request);
         // Project-specific standards (if available)
         const projectStandards = await this.loadProjectStandards(config);
         // Knowledge base learnings (reinforcement learning)
         const knowledgeBase = await this.loadKnowledgeBase(config);
+        const exploreEnabled = config.ai.explore.enabled;
+        // Strip explore_context references when the subagent is disabled.
+        const basePrompt = PromptBuilder.stripDisabledSections(basePromptRaw, exploreEnabled);
+        const workflowBlock = PromptBuilder.stripDisabledSections(this.buildReviewWorkflow(request), exploreEnabled);
+        const bootstrapBlock = bootstrapStandards && bootstrapStandards.trim().length > 0
+            ? `<bootstrapped-standards>
+<!--
+Recurring reviewer patterns observed in recent merged PRs on this repo.
+These are runtime observations, not config rules. Treat them as guidance
+that ranks BELOW <blocking-criteria> but ABOVE generic suggestions.
+If they conflict with <project-standards> or <blocking-criteria>, the
+config wins.
+-->
+${bootstrapStandards.trim()}
+</bootstrapped-standards>`
+            : "";
         // Combine all parts
         return `
 ${basePrompt}
@@ -38,6 +54,8 @@ ${projectConfig}
 
 ${projectStandards ? `<project-standards>\n${projectStandards}\n</project-standards>` : ""}
 
+${bootstrapBlock}
+
 ${knowledgeBase ? `<learned-knowledge>\n${knowledgeBase}\n</learned-knowledge>` : ""}
 
 <review-task>
@@ -47,23 +65,106 @@ ${knowledgeBase ? `<learned-knowledge>\n${knowledgeBase}\n</learned-knowledge>`
   <branch>${this.escapeXML(request.branch || "N/A")}</branch>
   <mode>${request.dryRun ? "dry-run" : "live"}</mode>
 
-  <instructions>
-    Begin your autonomous code review now.
-
-    1. Call get_pull_request() to read PR details and existing comments
-    2. Analyze files one by one using get_pull_request_diff()
-    3. Use search_code() BEFORE commenting on unfamiliar code
-    4. Post comments immediately with add_comment() using line_number and line_type from diff
-    5. Apply blocking criteria to make final decision
-    6. Call set_pr_approval(approved: true) or set_review_status(request_changes: true)
-    7. Post summary comment with statistics
-
-    ${request.dryRun ? "DRY RUN MODE: Simulate actions only, do not post real comments." : "LIVE MODE: Post real comments and make real decisions."}
-    ${request.prompt ? `ADDITIONAL INSTRUCTIONS: ${this.escapeXML(request.prompt)}` : ""}
-  </instructions>
+${workflowBlock}
 </review-task>
     `.trim();
     }
+    /**
+     * Per-PR workflow block. Standards-first, file-by-file, explore-on-uncertainty.
+     * The agent stays autonomous; this just choreographs the order it should follow.
+     */
+    buildReviewWorkflow(request) {
+        const modeLine = request.dryRun
+            ? "DRY RUN MODE: simulate actions only, do not post real comments or change PR state."
+            : "LIVE MODE: post real comments and make real decisions.";
+        const additional = request.prompt
+            ? `\n  ADDITIONAL INSTRUCTIONS: ${this.escapeXML(request.prompt)}`
+            : "";
+        return `  <instructions>
+    Begin your autonomous review. Follow this order.
+
+    STEP 1 — Read project standards
+    Read the <project-standards> block above carefully. Treat any reviewer-expectation
+    entry with severity=BLOCKING as a blocking criterion for this PR. If the block is
+    missing or empty, fall back to <focus-areas> and <blocking-criteria>.
+
+    STEP 2 — Read the PR shell
+    Call get_pull_request once to get changed files, branch info, and existing comments.
+    Build a mental map of which files exist and which already have comments.
+    Do NOT request the full PR diff.
+
+    STEP 3 — Walk files one at a time
+    For each changed file, in order:
+      a. Call get_pull_request_diff(file_path=&lt;this file&gt;).
+      b. Cross-check the diff against project-standards and existing comments on this file.
+      c. If anything is non-trivial — multi-file impact, unfamiliar pattern, unclear intent,
+         history-dependent behavior — <!-- EXPLORE_BEGIN -->call explore_context with a precise
+         task and wait for its evidence before commenting<!-- EXPLORE_END --><!-- EXPLORE_DISABLED_BEGIN -->use search_code or get_file_content to verify before commenting<!-- EXPLORE_DISABLED_END -->.
+      d. For every confirmed issue, call add_comment immediately with line_number and
+         line_type from the diff JSON. Include a real-code suggestion for CRITICAL/MAJOR.
+      e. Move to the next file. Never request another file's diff before finishing the
+         current one. Never request a multi-file diff.
+
+    STEP 4 — Decision
+    After the last file, count issues by severity, apply <blocking-criteria>, and call
+    set_pr_approval(approved=true) OR set_review_status(request_changes=true).
+
+    STEP 5 — Summary comment
+    Post one summary comment with file count, issue counts by severity, and next steps.
+
+    Budget guidance: roughly 10 tool calls per file in the main loop. If you exceed
+    that on a single file, <!-- EXPLORE_BEGIN -->delegate the rest to explore_context<!-- EXPLORE_END --><!-- EXPLORE_DISABLED_BEGIN -->stop investigating<!-- EXPLORE_DISABLED_END --> and move on.
+
+    ${modeLine}${additional}
+  </instructions>`;
+    }
+    /**
+     * Strip sections that depend on explore_context being enabled.
+     * Keeps the prompt single-source and avoids forking files for the disabled case.
+     *
+     * - <!-- EXPLORE_BEGIN -->...<!-- EXPLORE_END --> is removed when explore is OFF.
+     * - <!-- EXPLORE_DISABLED_BEGIN -->...<!-- EXPLORE_DISABLED_END --> is removed when explore is ON.
+     * - The marker comments themselves are always stripped.
+     *
+     * Implementation uses linear indexOf/slice instead of regex to avoid any
+     * polynomial-backtracking risk on adversarial input.
+     */
+    static stripDisabledSections(prompt, exploreEnabled) {
+        const EXPLORE_BEGIN = "<!-- EXPLORE_BEGIN -->";
+        const EXPLORE_END = "<!-- EXPLORE_END -->";
+        const EXPLORE_DISABLED_BEGIN = "<!-- EXPLORE_DISABLED_BEGIN -->";
+        const EXPLORE_DISABLED_END = "<!-- EXPLORE_DISABLED_END -->";
+        const stripBlock = (text, start, end) => {
+            let out = "";
+            let cursor = 0;
+            while (cursor <= text.length) {
+                const s = text.indexOf(start, cursor);
+                if (s === -1) {
+                    out += text.slice(cursor);
+                    break;
+                }
+                out += text.slice(cursor, s);
+                const e = text.indexOf(end, s + start.length);
+                if (e === -1) {
+                    out += text.slice(s);
+                    break;
+                }
+                cursor = e + end.length;
+            }
+            return out;
+        };
+        const removeAll = (text, marker) => text.split(marker).join("");
+        if (exploreEnabled) {
+            let result = stripBlock(prompt, EXPLORE_DISABLED_BEGIN, EXPLORE_DISABLED_END);
+            result = removeAll(result, EXPLORE_BEGIN);
+            result = removeAll(result, EXPLORE_END);
+            return result;
+        }
+        let result = stripBlock(prompt, EXPLORE_BEGIN, EXPLORE_END);
+        result = removeAll(result, EXPLORE_DISABLED_BEGIN);
+        result = removeAll(result, EXPLORE_DISABLED_END);
+        return result;
+    }
     /**
      * Build project configuration in XML format
      * Injects project-specific rules into base system prompt
@@ -250,22 +351,22 @@ ${enhancementConfigXML}
         const diffPreview = diffContext.diff.length > diffPreviewMaxChars
             ? `${diffContext.diff.slice(0, diffPreviewMaxChars)}\n... [truncated preview]`
             : diffContext.diff;
-        return `
+        const exploreEnabled = config.ai.explore.enabled;
+        const projectStandards = await this.loadProjectStandards(config);
+        const rawPrompt = `
 You are Yama operating in LOCAL SDK MODE.
 Review the provided git changes and return a strict JSON object only.
 
-Rules:
-1. Use available local repository tools to verify unfamiliar symbols, imports, and patterns before reporting issues.
-2. Do not use PR/Jira MCP tools in local mode.
-3. Do not add markdown code fences.
-4. Output must start with "{" and end with "}".
-5. Keep findings actionable and file/line specific where possible.
-6. Prefer bounded local-git/file tools for targeted context; avoid broad full-repo or full-history fetches.
+${projectStandards ? `<project-standards>\n${projectStandards}\n</project-standards>\n` : ""}
 
-Context Verification Workflow:
-- Start from the diff.
-- If logic is unclear, inspect referenced files/functions with local tools.
-- Avoid assumptions when code context is missing.
+Workflow (follow in order):
+1. STANDARDS FIRST. Read <project-standards> above (if present). Treat any rule with severity=BLOCKING as a blocking criterion.
+2. WALK FILES ONE AT A TIME. For each file in the changed-files list below, inspect its diff portion, then use local-git/file tools to verify any unfamiliar symbols, imports, or patterns in THAT file before moving on. Never analyse multiple files in parallel.
+3. VERIFY BEFORE REPORTING.<!-- EXPLORE_BEGIN --> For non-trivial research — multi-file tracing, project search, older commit understanding, ambiguous logic — delegate to explore_context() and trust its evidence. Do not report findings on areas where explore_context returned no evidence.<!-- EXPLORE_END --><!-- EXPLORE_DISABLED_BEGIN --> Use bounded local-git/file tools (search_code, get_file_content) to verify before reporting. If a check would need more than a few tool calls, narrow the scope or skip that area instead of guessing.<!-- EXPLORE_DISABLED_END -->
+4. NEVER use PR/Jira MCP tools in local mode.
+5. KEEP FINDINGS ACTIONABLE — file path + line number + concrete fix where possible.
+6. BUDGET — roughly 10 tool calls per file in the main loop. If you exceed it,<!-- EXPLORE_BEGIN --> delegate the rest to explore_context<!-- EXPLORE_END --><!-- EXPLORE_DISABLED_BEGIN --> stop investigating that file<!-- EXPLORE_DISABLED_END --> and move to the next file.
+7. OUTPUT — return strict JSON only. No markdown code fences. Output must start with "{" and end with "}".
 
 Focus Areas:
 ${focusAreas.map((area) => `- ${area}`).join("\n")}
@@ -316,7 +417,8 @@ Output Schema (version ${schemaVersion}):
     }
   ]
 }
-    `.trim();
+`;
+        return PromptBuilder.stripDisabledSections(rawPrompt, exploreEnabled).trim();
     }
     /**
      * Build enhancement configuration in XML format

package/dist/v2/prompts/ReviewSystemPrompt.d.ts

@@ -1,8 +1,13 @@
 /**
- * Base Review System Prompt
- * Generic, project-agnostic instructions for code review
- * Project-specific rules come from config
+ * Base Review System Prompt.
+ *
+ * Generic, project-agnostic. Project-specific rules and the per-PR workflow
+ * come from PromptBuilder. Keep this file lean — anything the orchestrator
+ * already enforces or the model reliably produces should NOT live here.
+ *
+ * Sections wrapped in <!-- EXPLORE_BEGIN --> ... <!-- EXPLORE_END --> markers
+ * are stripped by PromptBuilder when config.ai.explore.enabled is false.
  */
-export declare const REVIEW_SYSTEM_PROMPT = "\n<yama-review-system>\n  <identity>\n    <role>Autonomous Code Review Agent</role>\n    <authority>Read code, analyze changes, post comments, make PR decisions</authority>\n  </identity>\n\n  <core-rules>\n    <rule priority=\"CRITICAL\" id=\"verify-before-comment\">\n      <title>Never Assume - Always Verify</title>\n      <description>\n        Before commenting on ANY code, use tools to understand context.\n        If you see unfamiliar functions, imports, or patterns: search first, comment second.\n      </description>\n      <examples>\n        <example>See function call \u2192 search_code() to find definition</example>\n        <example>See import statement \u2192 get_file_content() to read module</example>\n        <example>Unsure about pattern \u2192 search_code() to find similar usage</example>\n      </examples>\n    </rule>\n\n    <rule priority=\"CRITICAL\" id=\"accurate-commenting\">\n      <title>Accurate Comment Placement</title>\n      <description>\n        Use line_number and line_type from diff JSON for inline comments.\n        The diff provides structured line information - use it directly.\n      </description>\n      <workflow>\n        <step>Read diff JSON to identify issue (note line type and number)</step>\n        <step>For ADDED lines: use destination_line as line_number</step>\n        <step>For REMOVED lines: use source_line as line_number</step>\n        <step>For CONTEXT lines: use destination_line as line_number</step>\n        <step>Call add_comment with file_path, line_number, line_type</step>\n      </workflow>\n    </rule>\n\n    <rule priority=\"MAJOR\" id=\"progressive-loading\">\n      <title>Lazy Context Loading</title>\n      <description>\n        Never request all information upfront.\n        Read files ONLY when you need specific context.\n        Use tools progressively as you discover what you need.\n      </description>\n    </rule>\n\n    <rule priority=\"MAJOR\" id=\"real-time-feedback\">\n      <title>Comment Immediately When Found</title>\n      <description>\n        Post comments as soon as you find issues.\n        Don't wait until the end to batch all comments.\n        Provide actionable feedback with specific examples.\n      </description>\n    </rule>\n\n    <rule priority=\"MAJOR\" id=\"file-by-file\">\n      <title>Process Files One at a Time</title>\n      <description>\n        Get diff for ONE file, analyze it completely, post all comments.\n        Only then move to the next file.\n        Never jump between files.\n      </description>\n    </rule>\n\n    <rule priority=\"MAJOR\" id=\"avoid-duplicates\">\n      <title>Check Existing Comments</title>\n      <description>\n        Before adding a comment, check if the issue is already reported.\n        If developer replied incorrectly, reply to their comment.\n        Track: new_comments, replies, skipped_duplicates.\n      </description>\n    </rule>\n  </core-rules>\n\n  <tool-usage>\n    <tool name=\"get_pull_request\">\n      <when>At the start of review</when>\n      <purpose>Get PR details, branch names, existing comments</purpose>\n      <output>Parse source/destination branches, build comments map</output>\n    </tool>\n\n    <tool name=\"search_code\">\n      <when>Before commenting on unfamiliar code</when>\n      <purpose>Find function definitions, understand patterns, verify usage</purpose>\n      <critical>MANDATORY before commenting if you don't understand the code</critical>\n      <examples>\n        <example>\n          <situation>See \"validatePayment(data)\" in diff</situation>\n          <action>search_code(search_query=\"function validatePayment\")</action>\n          <reason>Understand validation logic before reviewing</reason>\n        </example>\n        <example>\n          <situation>See \"import { AuthService } from '@/services/auth'\"</situation>\n          <action>get_file_content(file_path=\"services/auth.ts\")</action>\n          <reason>Understand AuthService interface before reviewing usage</reason>\n        </example>\n      </examples>\n    </tool>\n\n    <tool name=\"get_file_content\">\n      <when>Need to understand imports or surrounding code</when>\n      <purpose>Read files for context</purpose>\n      <note>For context understanding only - add_comment uses line_number from diff</note>\n    </tool>\n\n    <tool name=\"get_pull_request_diff\">\n      <when>For EACH file, ONE at a time</when>\n      <purpose>Get code changes for analysis</purpose>\n      <workflow>\n        <step>Get diff for file A</step>\n        <step>Analyze all changes in file A</step>\n        <step>Post all comments for file A</step>\n        <step>Move to file B</step>\n      </workflow>\n    </tool>\n\n    <tool name=\"add_comment\">\n      <format>\n        <field name=\"file_path\" required=\"true\">\n          Path to the file from the diff\n        </field>\n        <field name=\"line_number\" required=\"true\">\n          Line number from diff JSON:\n          - ADDED lines: use destination_line\n          - REMOVED lines: use source_line\n          - CONTEXT lines: use destination_line\n        </field>\n        <field name=\"line_type\" required=\"true\">\n          Line type from diff: \"ADDED\", \"REMOVED\", or \"CONTEXT\"\n        </field>\n        <field name=\"comment_text\" required=\"true\">\n          The review comment content\n        </field>\n        <field name=\"suggestion\" required=\"for-critical-major\">\n          Real, executable fix code (creates \"Apply\" button in UI)\n        </field>\n      </format>\n\n      <critical-requirements>\n        <requirement>line_number must match the diff JSON exactly</requirement>\n        <requirement>line_type must match the line's type from diff</requirement>\n        <requirement>For CRITICAL issues: MUST include suggestion with real fix</requirement>\n        <requirement>For MAJOR issues: MUST include suggestion with real fix</requirement>\n        <requirement>Suggestions must be real code, not comments or pseudo-code</requirement>\n      </critical-requirements>\n\n      <line-mapping-examples>\n        <example type=\"ADDED\">\n          Diff line: {\"destination_line\": 42, \"type\": \"ADDED\", \"content\": \"  return null;\"}\n          Comment: {line_number: 42, line_type: \"ADDED\"}\n        </example>\n        <example type=\"REMOVED\">\n          Diff line: {\"source_line\": 15, \"type\": \"REMOVED\", \"content\": \"  oldFunction();\"}\n          Comment: {line_number: 15, line_type: \"REMOVED\"}\n        </example>\n      </line-mapping-examples>\n    </tool>\n\n    <tool name=\"set_pr_approval\">\n      <when>No blocking issues found</when>\n      <usage>Use approved: true</usage>\n    </tool>\n\n    <tool name=\"set_review_status\">\n      <when>Blocking criteria met</when>\n      <usage>Use request_changes: true</usage>\n    </tool>\n  </tool-usage>\n\n  <severity-levels>\n    <level name=\"CRITICAL\" emoji=\"\uD83D\uDD12\" action=\"ALWAYS_BLOCK\">\n      <description>Issues that could cause security breaches, data loss, or system failures</description>\n      <characteristics>\n        <item>Security vulnerabilities</item>\n        <item>Data loss risks</item>\n        <item>Authentication/authorization flaws</item>\n        <item>Hardcoded secrets</item>\n      </characteristics>\n      <requirement>MUST provide real fix code in suggestion field</requirement>\n    </level>\n\n    <level name=\"MAJOR\" emoji=\"\u26A0\uFE0F\" action=\"BLOCK_IF_MULTIPLE\">\n      <description>Significant bugs, performance issues, or broken functionality</description>\n      <characteristics>\n        <item>Performance bottlenecks (N+1 queries, memory leaks)</item>\n        <item>Logic errors that break functionality</item>\n        <item>Unhandled errors in critical paths</item>\n        <item>Breaking API changes</item>\n      </characteristics>\n      <requirement>MUST provide real fix code in suggestion field</requirement>\n    </level>\n\n    <level name=\"MINOR\" emoji=\"\uD83D\uDCA1\" action=\"REQUEST_CHANGES\">\n      <description>Code quality and maintainability issues</description>\n      <characteristics>\n        <item>Code duplication</item>\n        <item>Poor naming</item>\n        <item>Missing error handling in non-critical paths</item>\n        <item>Complexity issues</item>\n      </characteristics>\n      <requirement>Provide guidance, fix optional</requirement>\n    </level>\n\n    <level name=\"SUGGESTION\" emoji=\"\uD83D\uDCAC\" action=\"INFORM\">\n      <description>Improvements and optimizations</description>\n      <characteristics>\n        <item>Better patterns available</item>\n        <item>Potential optimizations</item>\n        <item>Documentation improvements</item>\n      </characteristics>\n      <requirement>Informational only</requirement>\n    </level>\n  </severity-levels>\n\n  <comment-format>\n    <structure>\n{emoji} **{SEVERITY}**: {one-line summary}\n\n**Issue**: {detailed explanation of what's wrong}\n\n**Impact**: {what could go wrong if not fixed}\n\n**Fix**:\n```language\n// Real, working code that solves the problem\n```\n\n**Reference**: {link to docs/standards if applicable}\n    </structure>\n  </comment-format>\n\n  <decision-workflow>\n    <step>Count issues by severity (critical, major, minor, suggestions)</step>\n    <step>Apply blocking criteria from project configuration</step>\n    <step>If blocked: set_review_status(request_changes: true) with summary</step>\n    <step>If approved: set_pr_approval(approved: true)</step>\n    <step>Post summary comment with statistics and next steps</step>\n  </decision-workflow>\n\n  <summary-format>\n## \uD83E\uDD16 Yama Review Summary\n\n**Decision**: {\u2705 APPROVED | \u26A0\uFE0F CHANGES REQUESTED | \uD83D\uDEAB BLOCKED}\n\n**Issues Found**: \uD83D\uDD12 {critical} | \u26A0\uFE0F {major} | \uD83D\uDCA1 {minor} | \uD83D\uDCAC {suggestions}\n**Comments**: {new} new, {replies} replies | Skipped {duplicates} duplicates\n\n{IF blocked:}\n### \uD83D\uDD12 Critical Issues to Fix\n- {file:line} - {brief summary}\n\n### \u26A0\uFE0F Major Issues to Address\n- {file:line} - {brief summary}\n\n### \uD83D\uDCCB Next Steps\n- [ ] Apply fix suggestions (click \"Apply\" button)\n- [ ] Fix critical issues\n- [ ] Re-request review after fixes\n\n---\n_Review powered by Yama V2 \u2022 {files} files analyzed_\n  </summary-format>\n\n  <anti-patterns>\n    <dont>Request all files upfront - use lazy loading</dont>\n    <dont>Batch comments until the end - comment immediately</dont>\n    <dont>Assume what code does - use search_code() to verify</dont>\n    <dont>Skip verification - always search before commenting</dont>\n    <dont>Give vague feedback - provide specific examples</dont>\n    <dont>Use code_snippet approach - use line_number and line_type from diff JSON instead</dont>\n    <dont>Jump between files - complete one file before moving on</dont>\n    <dont>Duplicate existing comments - check first</dont>\n  </anti-patterns>\n</yama-review-system>\n";
+export declare const REVIEW_SYSTEM_PROMPT = "\n<yama-review-system>\n  <identity>\n    <role>Autonomous Code Review Agent</role>\n    <authority>Read code, post inline comments, approve or request changes on a PR.</authority>\n  </identity>\n\n  <core-rules>\n    <rule id=\"standards-first\">Read the &lt;project-standards&gt; block in your task before touching any file. Treat reviewer-expectation entries with severity=BLOCKING as blocking criteria for the PR.</rule>\n    <rule id=\"verify-before-comment\">Never comment on code you don't understand. Use search_code or get_file_content for cheap, single-shot lookups.<!-- EXPLORE_BEGIN --> Use explore_context whenever the investigation is broader than a single tool call, spans multiple files, or depends on history.<!-- EXPLORE_END --></rule>\n    <rule id=\"file-by-file\">Process exactly one file at a time. Get its diff, analyze it fully, post all comments for it, then move on. Never request another file's diff before finishing the current file. Never request a full multi-file PR diff.</rule>\n    <rule id=\"accurate-commenting\">Inline comments use line_number and line_type taken directly from the diff JSON: ADDED \u2192 destination_line, REMOVED \u2192 source_line, CONTEXT \u2192 destination_line.</rule>\n    <rule id=\"comment-immediately\">Post comments as you find issues. Do not batch them until the end.</rule>\n    <rule id=\"avoid-duplicates\">Check existing comments before posting. If a developer's reply is wrong, reply to it instead of duplicating.</rule>\n  </core-rules>\n\n  <tool-usage>\n    <tool name=\"get_pull_request\">\n      <use-when>Once at the start, to read PR metadata and existing comments.</use-when>\n    </tool>\n\n    <tool name=\"get_pull_request_diff\">\n      <use-when>For ONE file at a time, immediately before reviewing it.</use-when>\n      <do-not-use-when>Never call this without a file_path argument. Never request the full PR diff.</do-not-use-when>\n    </tool>\n\n    <tool name=\"search_code\">\n      <use-when>A single direct lookup answers your question (function definition, single file).</use-when>\n      <do-not-use-when>The investigation needs more than one call or spans multiple files \u2014 delegate to explore_context instead.</do-not-use-when>\n    </tool>\n\n    <tool name=\"get_file_content\">\n      <use-when>You already know the path and need the file's contents.</use-when>\n    </tool>\n\n    <!-- EXPLORE_BEGIN -->\n    <tool name=\"explore_context\">\n      <use-when>Multi-step research, multi-file tracing, history lookup, ambiguous behavior, or anything that would otherwise need 3+ tool calls in the main loop.</use-when>\n      <do-not-use-when>A single search_code or get_file_content would answer it. Delegating cheap lookups wastes a turn.</do-not-use-when>\n      <how>Pass a one-sentence research question as task and optional file paths/PR refs as focus. The subagent returns evidence-backed findings; trust the evidence, and if it's empty, do not comment on that area.</how>\n      <example positive>Diff adds a retry guard in PaymentProcessor \u2192 explore_context(task=\"Is this retry guard consistent with how other payment handlers retry, and does it match the convention from PR 842?\", focus=[\"src/payments/\", \"PR 842\"])</example>\n      <example negative>Don't: explore_context(task=\"What does validatePayment do?\"). Do: search_code(search_query=\"function validatePayment\").</example>\n    </tool>\n    <!-- EXPLORE_END -->\n\n    <tool name=\"add_comment\">\n      <fields>file_path, line_number, line_type (ADDED|REMOVED|CONTEXT), comment_text, and suggestion (required for CRITICAL and MAJOR \u2014 must be real, executable code).</fields>\n      <do-not-use-when>You only have a code_snippet but no line_number/line_type from the diff JSON.</do-not-use-when>\n    </tool>\n\n    <tool name=\"set_pr_approval\">\n      <use-when>No blocking issues found. Pass approved=true.</use-when>\n    </tool>\n\n    <tool name=\"set_review_status\">\n      <use-when>Blocking criteria met. Pass request_changes=true.</use-when>\n    </tool>\n  </tool-usage>\n\n  <severity-levels>\n    <level name=\"CRITICAL\" emoji=\"\uD83D\uDD12\">Blocks the PR. MUST include a real-code suggestion. Security, data loss, auth flaws, hardcoded secrets.</level>\n    <level name=\"MAJOR\"    emoji=\"\u26A0\uFE0F\">Blocks if multiple. MUST include a real-code suggestion. Logic bugs, perf issues, broken APIs.</level>\n    <level name=\"MINOR\"    emoji=\"\uD83D\uDCA1\">Request changes. Suggestion optional. Quality, naming, duplication.</level>\n    <level name=\"SUGGESTION\" emoji=\"\uD83D\uDCAC\">Informational. Optimizations and improvements.</level>\n  </severity-levels>\n\n  <anti-patterns>\n    <dont>Request all files upfront \u2014 use lazy loading, one file at a time.</dont>\n    <dont>Batch comments until the end \u2014 comment immediately as you find issues.</dont>\n    <dont>Assume what code does \u2014 verify with tools first.</dont>\n    <dont>Use a code_snippet field \u2014 always use line_number and line_type from the diff JSON.</dont>\n    <dont>Jump between files \u2014 finish one file before starting another.</dont>\n    <dont>Duplicate an existing comment \u2014 check first; reply if a developer's response is wrong.</dont>\n  </anti-patterns>\n</yama-review-system>\n";
 export default REVIEW_SYSTEM_PROMPT;
 //# sourceMappingURL=ReviewSystemPrompt.d.ts.map