@juspay/yama 2.4.2 → 2.5.0

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

@@ -8,14 +8,22 @@
 import { YamaConfig } from "../types/config.types.js";
 import { LocalReviewRequest, ReviewRequest } from "../types/v2.types.js";
 import type { LocalDiffContext } from "../core/LocalDiffSource.js";
+import { type VCSProviderName } from "../providers/ProviderToolset.js";
 export declare class PromptBuilder {
     private langfuseManager;
     constructor();
+    /**
+     * Build the provider-agnostic params object the ProviderToolset consumes.
+     * Carries both Bitbucket (workspace/repository/pullRequestId) and GitHub
+     * (owner/repo/prNumber) identifiers plus the shared branch; each toolset
+     * reads only the fields it needs.
+     */
+    private toToolsetParams;
     /**
      * Build complete review instructions for AI
      * Combines generic base prompt + project-specific config
      */
-    buildReviewInstructions(request: ReviewRequest, config: YamaConfig, bootstrapStandards?: string | null): Promise<string>;
+    buildReviewInstructions(request: ReviewRequest, config: YamaConfig, bootstrapStandards: string | null | undefined, provider: VCSProviderName): 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.
@@ -54,7 +62,7 @@ export declare class PromptBuilder {
     /**
      * Build description enhancement prompt separately (for description-only operations)
      */
-    buildDescriptionEnhancementInstructions(request: ReviewRequest, config: YamaConfig): Promise<string>;
+    buildDescriptionEnhancementInstructions(request: ReviewRequest, config: YamaConfig, provider: VCSProviderName): Promise<string>;
     /**
      * Build local SDK review instructions.
      * Produces strict JSON output for local diff quality analysis.

package/dist/v2/prompts/PromptBuilder.js

@@ -9,19 +9,73 @@ import { readFile } from "fs/promises";
 import { existsSync } from "fs";
 import { join } from "path";
 import { LangfusePromptManager } from "./LangfusePromptManager.js";
+import { buildReviewSystemPrompt } from "./ReviewSystemPrompt.js";
 import { KnowledgeBaseManager } from "../learning/KnowledgeBaseManager.js";
+import { getProviderToolset, } from "../providers/ProviderToolset.js";
 export class PromptBuilder {
     langfuseManager;
     constructor() {
         this.langfuseManager = new LangfusePromptManager();
     }
+    /**
+     * Build the provider-agnostic params object the ProviderToolset consumes.
+     * Carries both Bitbucket (workspace/repository/pullRequestId) and GitHub
+     * (owner/repo/prNumber) identifiers plus the shared branch; each toolset
+     * reads only the fields it needs.
+     */
+    toToolsetParams(request) {
+        const params = {};
+        const workspace = (request.workspace || "").trim();
+        const repository = (request.repository || "").trim();
+        const branch = (request.branch || "N/A").trim();
+        params.workspace = workspace;
+        params.repository = repository;
+        params.branch = branch;
+        // Coalesce the PR identifier across both field names so the toolset always
+        // receives the PR number regardless of which one the caller populated.
+        // GitHub's identifierXml reads params.prNumber while Bitbucket's reads
+        // params.pullRequestId; CLI callers set request.pullRequestId even for
+        // GitHub, so without this a GitHub run would lose the PR number and fall
+        // back to 'find-by-branch'. No-op for existing Bitbucket behavior.
+        const resolvedPrNumber = request.prNumber ??
+            (typeof request.pullRequestId === "number"
+                ? request.pullRequestId
+                : undefined);
+        const resolvedPullRequestId = request.pullRequestId ?? request.prNumber;
+        if (resolvedPullRequestId !== undefined) {
+            params.pullRequestId = resolvedPullRequestId;
+        }
+        if (request.owner !== undefined) {
+            params.owner = request.owner.trim();
+        }
+        // Coalesce the repo name across the GitHub-specific 'repo' field and the
+        // shared 'repository' field, mirroring the prNumber<->pullRequestId
+        // coalescing above. A GitHub caller may populate the shared 'repository'
+        // field instead of 'repo'; without this the toolset would receive GitHub
+        // identifiers with no repo name. No-op for existing Bitbucket behavior,
+        // which never sets request.repo.
+        const resolvedRepo = request.repo ?? request.repository;
+        if (resolvedRepo !== undefined) {
+            params.repo = resolvedRepo.trim();
+        }
+        if (resolvedPrNumber !== undefined) {
+            params.prNumber = resolvedPrNumber;
+        }
+        return params;
+    }
     /**
      * Build complete review instructions for AI
      * Combines generic base prompt + project-specific config
      */
-    async buildReviewInstructions(request, config, bootstrapStandards) {
-        // Base system prompt - fetched from Langfuse or local fallback
-        const basePromptRaw = await this.langfuseManager.getReviewPrompt();
+    async buildReviewInstructions(request, config, bootstrapStandards, provider) {
+        const toolset = getProviderToolset(provider);
+        // Base system prompt. Prefer a Langfuse-managed prompt when one is
+        // configured (provider-agnostic remote override); otherwise fall back to
+        // the provider-aware local prompt so the <tool-usage> section matches the
+        // active provider's tool idiom.
+        const basePromptRaw = this.langfuseManager.isEnabled()
+            ? await this.langfuseManager.getReviewPrompt()
+            : buildReviewSystemPrompt(toolset);
         // Project-specific configuration in XML format
         const projectConfig = this.buildProjectConfigXML(config, request);
         // Project-specific standards (if available)
@@ -31,7 +85,8 @@ export class PromptBuilder {
         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 toolsetParams = this.toToolsetParams(request);
+        const workflowBlock = PromptBuilder.stripDisabledSections(this.buildReviewWorkflow(request, toolset, toolsetParams), exploreEnabled);
         const bootstrapBlock = bootstrapStandards && bootstrapStandards.trim().length > 0
             ? `<bootstrapped-standards>
 <!--
@@ -59,10 +114,7 @@ ${bootstrapBlock}
 ${knowledgeBase ? `<learned-knowledge>\n${knowledgeBase}\n</learned-knowledge>` : ""}
 
 <review-task>
-  <workspace>${this.escapeXML(request.workspace)}</workspace>
-  <repository>${this.escapeXML(request.repository)}</repository>
-  <pull_request_id>${request.pullRequestId || "find-by-branch"}</pull_request_id>
-  <branch>${this.escapeXML(request.branch || "N/A")}</branch>
+${toolset.identifierXml(toolsetParams)}
   <mode>${request.dryRun ? "dry-run" : "live"}</mode>
 
 ${workflowBlock}
@@ -73,47 +125,18 @@ ${workflowBlock}
      * 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) {
+    buildReviewWorkflow(request, toolset, params) {
         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)}`
             : "";
+        // The numbered review steps (tool names + workflow prose) come from the
+        // provider toolset; the <instructions> wrapper and the dynamic mode/
+        // additional tail stay here so they apply to every provider unchanged.
         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.
+${toolset.reviewWorkflowInstructions(params)}
 
     ${modeLine}${additional}
   </instructions>`;
@@ -298,7 +321,9 @@ ${loadedStandards.join("\n\n---\n\n")}
     /**
      * Build description enhancement prompt separately (for description-only operations)
      */
-    async buildDescriptionEnhancementInstructions(request, config) {
+    async buildDescriptionEnhancementInstructions(request, config, provider) {
+        const toolset = getProviderToolset(provider);
+        const toolsetParams = this.toToolsetParams(request);
         // Base enhancement prompt - fetched from Langfuse or local fallback
         const basePrompt = await this.langfuseManager.getEnhancementPrompt();
         // Project-specific enhancement configuration
@@ -311,25 +336,11 @@ ${enhancementConfigXML}
 </project-configuration>
 
 <enhancement-task>
-  <workspace>${this.escapeXML(request.workspace)}</workspace>
-  <repository>${this.escapeXML(request.repository)}</repository>
-  <pull_request_id>${request.pullRequestId || "find-by-branch"}</pull_request_id>
-  <branch>${this.escapeXML(request.branch || "N/A")}</branch>
+${toolset.identifierXml(toolsetParams)}
   <mode>${request.dryRun ? "dry-run" : "live"}</mode>
 
   <instructions>
-    Enhance the PR description now.
-
-    1. Call get_pull_request() to read current PR and description
-    2. Call get_pull_request_diff() to analyze code changes
-    3. Use search_code() to find configuration patterns, API changes
-    4. Extract information for each required section
-    5. Build enhanced description following section structure
-    6. Call update_pull_request() with enhanced description
-
-    CRITICAL: Return ONLY the enhanced description markdown.
-    Do NOT include meta-commentary or explanations.
-    Start directly with section content.
+${toolset.descriptionEnhancementInstructions(toolsetParams)}
 
     ${request.dryRun ? "DRY RUN MODE: Simulate only, do not actually update PR." : "LIVE MODE: Update the actual PR description."}
     ${request.prompt ? `ADDITIONAL INSTRUCTIONS: ${this.escapeXML(request.prompt)}` : ""}

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

@@ -7,7 +7,35 @@
  *
  * Sections wrapped in <!-- EXPLORE_BEGIN --> ... <!-- EXPLORE_END --> markers
  * are stripped by PromptBuilder when config.ai.explore.enabled is false.
+ *
+ * The <tool-usage> section is the ONLY provider-specific part of this prompt.
+ * It is supplied by the ProviderToolset so the same review philosophy, severity
+ * rules and anti-patterns drive both Bitbucket and GitHub. For
+ * provider === "bitbucket" the rendered output is byte-identical to the
+ * historical hardcoded prompt (the toolset's Bitbucket strings were copied
+ * verbatim).
+ */
+import { type ProviderToolset, type VCSProviderName } from "../providers/ProviderToolset.js";
+/**
+ * Render the base review system prompt for a given provider.
+ *
+ * Accepts either a provider name (the common case) or an already-resolved
+ * ProviderToolset. Only the <tool-usage> section varies by provider; every
+ * other block (identity, core rules, severity levels, anti-patterns) is shared
+ * verbatim.
+ */
+export declare function buildReviewSystemPrompt(provider: VCSProviderName | ProviderToolset): string;
+/**
+ * Provider-aware alias matching the pinned signature `build(provider)`.
+ */
+export declare const build: typeof buildReviewSystemPrompt;
+/**
+ * Bitbucket-rendered base review system prompt.
+ *
+ * Kept as a named constant for backward compatibility with consumers that
+ * expect a static fallback (e.g. LangfusePromptManager's Bitbucket fallback).
+ * This is byte-identical to the historical hardcoded prompt.
  */
-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 declare const REVIEW_SYSTEM_PROMPT: string;
 export default REVIEW_SYSTEM_PROMPT;
 //# sourceMappingURL=ReviewSystemPrompt.d.ts.map

package/dist/v2/prompts/ReviewSystemPrompt.js

@@ -7,8 +7,27 @@
  *
  * Sections wrapped in <!-- EXPLORE_BEGIN --> ... <!-- EXPLORE_END --> markers
  * are stripped by PromptBuilder when config.ai.explore.enabled is false.
+ *
+ * The <tool-usage> section is the ONLY provider-specific part of this prompt.
+ * It is supplied by the ProviderToolset so the same review philosophy, severity
+ * rules and anti-patterns drive both Bitbucket and GitHub. For
+ * provider === "bitbucket" the rendered output is byte-identical to the
+ * historical hardcoded prompt (the toolset's Bitbucket strings were copied
+ * verbatim).
+ */
+import { getProviderToolset, } from "../providers/ProviderToolset.js";
+/**
+ * Render the base review system prompt for a given provider.
+ *
+ * Accepts either a provider name (the common case) or an already-resolved
+ * ProviderToolset. Only the <tool-usage> section varies by provider; every
+ * other block (identity, core rules, severity levels, anti-patterns) is shared
+ * verbatim.
  */
-export const REVIEW_SYSTEM_PROMPT = `
+export function buildReviewSystemPrompt(provider) {
+    const toolset = typeof provider === "string" ? getProviderToolset(provider) : provider;
+    const toolUsageSection = toolset.systemPromptToolsSection();
+    return `
 <yama-review-system>
   <identity>
     <role>Autonomous Code Review Agent</role>
@@ -24,48 +43,7 @@ export const REVIEW_SYSTEM_PROMPT = `
     <rule id="avoid-duplicates">Check existing comments before posting. If a developer's reply is wrong, reply to it instead of duplicating.</rule>
   </core-rules>
 
-  <tool-usage>
-    <tool name="get_pull_request">
-      <use-when>Once at the start, to read PR metadata and existing comments.</use-when>
-    </tool>
-
-    <tool name="get_pull_request_diff">
-      <use-when>For ONE file at a time, immediately before reviewing it.</use-when>
-      <do-not-use-when>Never call this without a file_path argument. Never request the full PR diff.</do-not-use-when>
-    </tool>
-
-    <tool name="search_code">
-      <use-when>A single direct lookup answers your question (function definition, single file).</use-when>
-      <do-not-use-when>The investigation needs more than one call or spans multiple files — delegate to explore_context instead.</do-not-use-when>
-    </tool>
-
-    <tool name="get_file_content">
-      <use-when>You already know the path and need the file's contents.</use-when>
-    </tool>
-
-    <!-- EXPLORE_BEGIN -->
-    <tool name="explore_context">
-      <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>
-      <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>
-      <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>
-      <example positive>Diff adds a retry guard in PaymentProcessor → 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>
-      <example negative>Don't: explore_context(task="What does validatePayment do?"). Do: search_code(search_query="function validatePayment").</example>
-    </tool>
-    <!-- EXPLORE_END -->
-
-    <tool name="add_comment">
-      <fields>file_path, line_number, line_type (ADDED|REMOVED|CONTEXT), comment_text, and suggestion (required for CRITICAL and MAJOR — must be real, executable code).</fields>
-      <do-not-use-when>You only have a code_snippet but no line_number/line_type from the diff JSON.</do-not-use-when>
-    </tool>
-
-    <tool name="set_pr_approval">
-      <use-when>No blocking issues found. Pass approved=true.</use-when>
-    </tool>
-
-    <tool name="set_review_status">
-      <use-when>Blocking criteria met. Pass request_changes=true.</use-when>
-    </tool>
-  </tool-usage>
+${toolUsageSection}
 
   <severity-levels>
     <level name="CRITICAL" emoji="🔒">Blocks the PR. MUST include a real-code suggestion. Security, data loss, auth flaws, hardcoded secrets.</level>
@@ -84,5 +62,18 @@ export const REVIEW_SYSTEM_PROMPT = `
   </anti-patterns>
 </yama-review-system>
 `;
+}
+/**
+ * Provider-aware alias matching the pinned signature `build(provider)`.
+ */
+export const build = buildReviewSystemPrompt;
+/**
+ * Bitbucket-rendered base review system prompt.
+ *
+ * Kept as a named constant for backward compatibility with consumers that
+ * expect a static fallback (e.g. LangfusePromptManager's Bitbucket fallback).
+ * This is byte-identical to the historical hardcoded prompt.
+ */
+export const REVIEW_SYSTEM_PROMPT = buildReviewSystemPrompt("bitbucket");
 export default REVIEW_SYSTEM_PROMPT;
 //# sourceMappingURL=ReviewSystemPrompt.js.map

package/dist/v2/providers/ProviderToolset.d.ts

@@ -0,0 +1,54 @@
+/**
+ * ProviderToolset — the single source of truth for everything that differs
+ * between VCS providers (Bitbucket vs GitHub) when Yama drives an AI review.
+ *
+ * Every provider-specific string the AI sees (the <available_tools> section,
+ * the numbered review workflow, the PR-context identifier block, the
+ * description-enhancement steps) and every provider-specific signal Yama reads
+ * back (which tool call is a comment, a diff fetch, a repo mutation, or an
+ * approve/block decision) lives behind this interface.
+ *
+ * The Bitbucket toolset reproduces the CURRENT prompt wording verbatim, so
+ * behaviour for Bitbucket stays byte-identical. The GitHub toolset teaches the
+ * official github/github-mcp-server consolidated API and pending-review flow,
+ * keeping the same review philosophy and severity rules.
+ */
+export type VCSProviderName = "github" | "bitbucket";
+export interface ReviewPromptParams {
+    workspace?: string;
+    repository?: string;
+    pullRequestId?: number | string;
+    owner?: string;
+    repo?: string;
+    prNumber?: number;
+    branch?: string;
+}
+export interface ProviderToolCall {
+    toolName?: string;
+    args?: Record<string, unknown>;
+}
+export interface ProviderToolset {
+    readonly provider: VCSProviderName;
+    /** Tool name the AI calls to read a PR's metadata/comments
+     *  (Bitbucket: get_pull_request; GitHub: pull_request_read). */
+    readonly prReadToolName: string;
+    /** <pr_context> identifier block injected into review/enhancement prompts */
+    identifierXml(params: ReviewPromptParams): string;
+    /** The <available_tools> section listing the tools the AI may call (provider idiom) */
+    systemPromptToolsSection(): string;
+    /** Provider-specific numbered review workflow instructions (prose the AI follows) */
+    reviewWorkflowInstructions(params: ReviewPromptParams): string;
+    /** Provider-specific PR-description-enhancement workflow instructions */
+    descriptionEnhancementInstructions(params: ReviewPromptParams): string;
+    /** Tool names whose calls represent an inline/PR comment (statistics counting) */
+    readonly commentToolNames: string[];
+    /** Tool names representing diff/file retrieval (statistics counting) */
+    readonly diffToolNames: string[];
+    /** Plain tool names that mutate PR/repo state (explore_context block list) */
+    readonly mutationToolNames: string[];
+    /** Interpret a single tool call as an approve/block decision signal, else null.
+     *  Bitbucket: set_pr_approval/set_review_status (+ args). GitHub: pull_request_review_write with args.event. */
+    interpretDecision(call: ProviderToolCall): "APPROVED" | "BLOCKED" | null;
+}
+export declare function getProviderToolset(provider: VCSProviderName): ProviderToolset;
+//# sourceMappingURL=ProviderToolset.d.ts.map