mirror of
https://github.com/google-gemini/gemini-cli.git
synced 2026-05-03 16:34:31 -07:00
chore: strengthen validation guidance in system prompt (#18544)
This commit is contained in:
@@ -176,12 +176,18 @@ export class PromptProvider {
|
||||
() => ({ interactive: interactiveMode }),
|
||||
isGitRepository(process.cwd()) ? true : false,
|
||||
),
|
||||
finalReminder: this.withSection('finalReminder', () => ({
|
||||
readFileToolName: READ_FILE_TOOL_NAME,
|
||||
})),
|
||||
};
|
||||
finalReminder: isGemini3
|
||||
? undefined
|
||||
: this.withSection('finalReminder', () => ({
|
||||
readFileToolName: READ_FILE_TOOL_NAME,
|
||||
})),
|
||||
} as snippets.SystemPromptOptions;
|
||||
|
||||
basePrompt = activeSnippets.getCoreSystemPrompt(options);
|
||||
basePrompt = (
|
||||
activeSnippets.getCoreSystemPrompt as (
|
||||
options: snippets.SystemPromptOptions,
|
||||
) => string
|
||||
)(options);
|
||||
}
|
||||
|
||||
// --- Finalization (Shell) ---
|
||||
|
||||
@@ -32,7 +32,6 @@ export interface SystemPromptOptions {
|
||||
operationalGuidelines?: OperationalGuidelinesOptions;
|
||||
sandbox?: SandboxMode;
|
||||
gitRepo?: GitRepoOptions;
|
||||
finalReminder?: FinalReminderOptions;
|
||||
}
|
||||
|
||||
export interface PreambleOptions {
|
||||
@@ -66,10 +65,6 @@ export interface GitRepoOptions {
|
||||
interactive: boolean;
|
||||
}
|
||||
|
||||
export interface FinalReminderOptions {
|
||||
readFileToolName: string;
|
||||
}
|
||||
|
||||
export interface PlanningWorkflowOptions {
|
||||
planModeToolsList: string;
|
||||
plansDir: string;
|
||||
@@ -116,8 +111,6 @@ ${renderOperationalGuidelines(options.operationalGuidelines)}
|
||||
${renderSandbox(options.sandbox)}
|
||||
|
||||
${renderGitRepo(options.gitRepo)}
|
||||
|
||||
${renderFinalReminder(options.finalReminder)}
|
||||
`.trim();
|
||||
}
|
||||
|
||||
@@ -158,7 +151,7 @@ export function renderCoreMandates(options?: CoreMandatesOptions): string {
|
||||
- **Contextual Precedence:** Instructions found in \`GEMINI.md\` files are foundational mandates. They take absolute precedence over the general workflows and tool defaults described in this system prompt.
|
||||
- **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
|
||||
- **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
|
||||
- **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
|
||||
- **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
|
||||
- **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. ${options.interactive ? 'For Directives, only clarify if critically underspecified; otherwise, work autonomously.' : 'For Directives, you must work autonomously as no further user input is available.'} You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
|
||||
- **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
|
||||
- ${mandateConfirm(options.interactive)}
|
||||
@@ -249,7 +242,7 @@ ${workflowStepStrategy(options)}
|
||||
- **Act:** Apply targeted, surgical changes strictly related to the sub-task. Use the available tools (e.g., '${EDIT_TOOL_NAME}', '${WRITE_FILE_TOOL_NAME}', '${SHELL_TOOL_NAME}'). Ensure changes are idiomatically complete and follow all workspace standards, even if it requires multiple tool calls. **Include necessary automated tests; a change is incomplete without verification logic.** Avoid unrelated refactoring or "cleanup" of outside code. Before making manual code changes, check if an ecosystem tool (like 'eslint --fix', 'prettier --write', 'go fmt', 'cargo fmt') is available in the project to perform the task automatically.
|
||||
- **Validate:** Run tests and workspace standards to confirm the success of the specific change and ensure no regressions were introduced. After making code changes, execute the project-specific build, linting and type-checking commands (e.g., 'tsc', 'npm run lint', 'ruff check .') that you have identified for this project.${workflowVerifyStandardsSuffix(options.interactive)}
|
||||
|
||||
**Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and it is confirmed that no regressions or structural side-effects were introduced. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead.
|
||||
**Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
|
||||
|
||||
## New Applications
|
||||
|
||||
@@ -309,12 +302,8 @@ export function renderSandbox(mode?: SandboxMode): string {
|
||||
# Sandbox
|
||||
|
||||
You are running in a sandbox container with limited access to files outside the project directory or system temp directory, and with limited access to host system resources such as ports. If you encounter failures that could be due to sandboxing (e.g. if a command fails with 'Operation not permitted' or similar error), when you report the error to the user, also explain why you think it could be due to sandboxing, and how the user may need to adjust their sandbox configuration.`.trim();
|
||||
} else {
|
||||
return `
|
||||
# Outside of Sandbox
|
||||
|
||||
You are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.`.trim();
|
||||
}
|
||||
return '';
|
||||
}
|
||||
|
||||
export function renderGitRepo(options?: GitRepoOptions): string {
|
||||
@@ -339,14 +328,6 @@ export function renderGitRepo(options?: GitRepoOptions): string {
|
||||
- Never push changes to a remote repository without being asked explicitly by the user.`.trim();
|
||||
}
|
||||
|
||||
export function renderFinalReminder(options?: FinalReminderOptions): string {
|
||||
if (!options) return '';
|
||||
return `
|
||||
# Final Reminder
|
||||
|
||||
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use '${options.readFileToolName}' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved.`.trim();
|
||||
}
|
||||
|
||||
export function renderUserMemory(memory?: string): string {
|
||||
if (!memory || memory.trim().length === 0) return '';
|
||||
return `
|
||||
|
||||
Reference in New Issue
Block a user