|
|
|
|
@@ -14,7 +14,7 @@ import { GrepTool } from '../tools/grep.js';
|
|
|
|
|
import { ReadFileTool } from '../tools/read-file.js';
|
|
|
|
|
import { ReadManyFilesTool } from '../tools/read-many-files.js';
|
|
|
|
|
import { ShellTool } from '../tools/shell.js';
|
|
|
|
|
import { WriteFileTool } from '../tools/write-file.js';
|
|
|
|
|
import { WRITE_FILE_TOOL_NAME } from '../tools/tool-names.js';
|
|
|
|
|
import process from 'node:process';
|
|
|
|
|
import { isGitRepository } from '../utils/gitUtils.js';
|
|
|
|
|
import { MemoryTool, GEMINI_CONFIG_DIR } from '../tools/memoryTool.js';
|
|
|
|
|
@@ -118,7 +118,7 @@ export function getCoreSystemPrompt(
|
|
|
|
|
- **Proactiveness:** Fulfill the user's request thoroughly. When adding features or fixing bugs, this includes adding tests to ensure quality. Consider all created files, especially tests, to be permanent artifacts unless the user says otherwise.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Path Construction:** Before using any file system tool (e.g., ${ReadFileTool.Name}' or '${WriteFileTool.Name}'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.
|
|
|
|
|
- **Path Construction:** Before using any file system tool (e.g., ${ReadFileTool.Name}' or '${WRITE_FILE_TOOL_NAME}'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@@ -136,14 +136,14 @@ ${(function () {
|
|
|
|
|
1. **Understand:** Think about the user's request and the relevant codebase context. Use '${GrepTool.Name}' and '${GlobTool.Name}' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use '${ReadFileTool.Name}' and '${ReadManyFilesTool.Name}' to understand context and validate any assumptions you may have.
|
|
|
|
|
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.`;
|
|
|
|
|
})()}
|
|
|
|
|
3. **Implement:** Use the available tools (e.g., '${EditTool.Name}', '${WriteFileTool.Name}' '${ShellTool.Name}' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
|
|
|
|
|
3. **Implement:** Use the available tools (e.g., '${EditTool.Name}', '${WRITE_FILE_TOOL_NAME}' '${ShellTool.Name}' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
|
|
|
|
|
4. **Verify (Tests):** If applicable and feasible, verify the changes using the project's testing procedures. Identify the correct test commands and frameworks by examining 'README' files, build/package configuration (e.g., 'package.json'), or existing test execution patterns. NEVER assume standard test commands.
|
|
|
|
|
5. **Verify (Standards):** VERY IMPORTANT: 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 (or obtained from the user). This ensures code quality and adherence to standards. If unsure about these commands, you can ask the user if they'd like you to run them and if so how to.
|
|
|
|
|
6. **Finalize:** After all verification passes, consider the task complete. Do not remove or revert any changes or created files (like tests). Await the user's next instruction.
|
|
|
|
|
|
|
|
|
|
## New Applications
|
|
|
|
|
|
|
|
|
|
**Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype. Utilize all tools at your disposal to implement the application. Some tools you may especially find useful are '${WriteFileTool.Name}', '${EditTool.Name}' and '${ShellTool.Name}'.
|
|
|
|
|
**Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype. Utilize all tools at your disposal to implement the application. Some tools you may especially find useful are '${WRITE_FILE_TOOL_NAME}', '${EditTool.Name}' and '${ShellTool.Name}'.
|
|
|
|
|
|
|
|
|
|
1. **Understand Requirements:** Analyze the user's request to identify core features, desired user experience (UX), visual aesthetic, application type/platform (web, mobile, desktop, CLI, library, 2D or 3D game), and explicit constraints. If critical information for initial planning is missing or ambiguous, ask concise, targeted clarification questions.
|
|
|
|
|
2. **Propose Plan:** Formulate an internal development plan. Present a clear, concise, high-level summary to the user. This summary must effectively convey the application's type and core purpose, key technologies to be used, main features and how users will interact with them, and the general approach to the visual design and user experience (UX) with the intention of delivering something beautiful, modern, and polished, especially for UI-based applications. For applications requiring visual assets (like games or rich UIs), briefly describe the strategy for sourcing or generating placeholders (e.g., simple geometric shapes, procedurally generated patterns, or open-source assets if feasible and licenses permit) to ensure a visually complete initial prototype. Ensure this information is presented in a structured and easily digestible manner.
|
|
|
|
|
@@ -176,7 +176,7 @@ ${(function () {
|
|
|
|
|
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
|
|
|
|
|
|
|
|
|
|
## Tool Usage
|
|
|
|
|
- **File Paths:** Always use absolute paths when referring to files with tools like '${ReadFileTool.Name}' or '${WriteFileTool.Name}'. Relative paths are not supported. You must provide an absolute path.
|
|
|
|
|
- **File Paths:** Always use absolute paths when referring to files with tools like '${ReadFileTool.Name}' or '${WRITE_FILE_TOOL_NAME}'. Relative paths are not supported. You must provide an absolute path.
|
|
|
|
|
- **Parallelism:** Execute multiple independent tool calls in parallel when feasible (i.e. searching the codebase).
|
|
|
|
|
- **Command Execution:** Use the '${ShellTool.Name}' tool for running shell commands, remembering the safety rule to explain modifying commands first.
|
|
|
|
|
- **Background Processes:** Use background processes (via \`&\`) for commands that are unlikely to stop on their own, e.g. \`node server.js &\`. If unsure, ask the user.
|
|
|
|
|
@@ -274,7 +274,7 @@ Here's the plan:
|
|
|
|
|
Should I proceed?
|
|
|
|
|
user: Yes
|
|
|
|
|
model:
|
|
|
|
|
[tool_call: ${WriteFileTool.Name} or ${EditTool.Name} to apply the refactoring to 'src/auth.py']
|
|
|
|
|
[tool_call: ${WRITE_FILE_TOOL_NAME} or ${EditTool.Name} to apply the refactoring to 'src/auth.py']
|
|
|
|
|
Refactoring complete. Running verification...
|
|
|
|
|
[tool_call: ${ShellTool.Name} for 'ruff check src/auth.py && pytest']
|
|
|
|
|
(After verification passes)
|
|
|
|
|
@@ -311,7 +311,7 @@ Here's the plan:
|
|
|
|
|
Should I proceed?
|
|
|
|
|
user: Yes
|
|
|
|
|
model:
|
|
|
|
|
[tool_call: ${WriteFileTool.Name} or ${EditTool.Name} to apply the refactoring to 'src/auth.py']
|
|
|
|
|
[tool_call: ${WRITE_FILE_TOOL_NAME} or ${EditTool.Name} to apply the refactoring to 'src/auth.py']
|
|
|
|
|
Refactoring complete. Running verification...
|
|
|
|
|
[tool_call: ${ShellTool.Name} for 'ruff check src/auth.py && pytest']
|
|
|
|
|
(After verification passes)
|
|
|
|
|
@@ -340,7 +340,7 @@ Okay, I can write those tests. First, I'll read \`someFile.ts\` to understand it
|
|
|
|
|
Now I'll look for existing or related test files to understand current testing conventions and dependencies.
|
|
|
|
|
[tool_call: ${ReadManyFilesTool.Name} for paths ['**/*.test.ts', 'src/**/*.spec.ts'] assuming someFile.ts is in the src directory]
|
|
|
|
|
(After reviewing existing tests and the file content)
|
|
|
|
|
[tool_call: ${WriteFileTool.Name} to create /path/to/someFile.test.ts with the test code]
|
|
|
|
|
[tool_call: ${WRITE_FILE_TOOL_NAME} to create /path/to/someFile.test.ts with the test code]
|
|
|
|
|
I've written the tests. Now I'll run the project's test command to verify them.
|
|
|
|
|
[tool_call: ${ShellTool.Name} for 'npm run test']
|
|
|
|
|
</example>
|
|
|
|
|
|
Abhi