MediaMetz/gemini-cli
1
0
Fork 0
mirror of https://github.com/google-gemini/gemini-cli.git synced 2026-08-06 07:01:28 -07:00
Code Issues Packages Projects Releases Wiki Activity

feat(core): trigger task tracker based on complexity rather than formatting

Browse Source
This commit is contained in:
Anjali Sridhar
2026-02-25 14:43:52 -08:00
parent ed8a77391c
commit aa1803f445
2 changed files with 8 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
packages/core/src/prompts/snippets.ts
+6 -5
View File
@@ -424,11 +424,12 @@ export function renderTaskTracker(): string {
You are operating with a persistent file-based task tracking system located at \`.tracker/tasks/\`. You must adhere to the following rules:
1. **NO IN-MEMORY LISTS**: Do not maintain a mental list of tasks or write markdown checkboxes in the chat. Use the provided tools (${trackerCreate}, ${trackerList}, ${trackerUpdate}) for all state management.
2. **ATOMICITY**: If a user request involves multiple steps (e.g., "Refactor the backend") or represents a complex task, you must first break this into discrete entries using ${trackerCreate} before writing any code.
3. **PLAN MODE INTEGRATION**: If you construct or are following a documented plan (e.g., in Plan Mode), use the tracker to represent the granular execution state of that plan. Maintain a bidirectional understanding between the plan document and the task graph.
4. **VERIFICATION**: Before marking a task as complete, verify the work is actually done (e.g., run the test, check the file existence).
5. **STATE OVER CHAT**: If the user says "I think we finished that," but the tool says it is 'pending', trust the tool--or verify explicitly before updating.
6. **DEPENDENCY MANAGEMENT**: Respect task topology. Never attempt to execute a task if its dependencies are not marked as 'closed'. If you are blocked, focus only on the leaf nodes of the task graph.`.trim();
2. **IMMEDIATE DECOMPOSITION**: Upon receiving a task, evaluate its functional complexity and scope. If the request involves more than a single atomic modification, or necessitates research before execution, you MUST immediately decompose it into discrete entries using ${trackerCreate}.
3. **IGNORE FORMATTING BIAS**: Trigger the protocol based on the **objective complexity** of the goal, regardless of whether the user provided a structured list or a single block of text/paragraph. "Paragraph-style" goals that imply multiple actions are multi-step projects and MUST be tracked.
4. **PLAN MODE INTEGRATION**: If you construct or are following a documented plan (e.g., in Plan Mode), use the tracker to represent the granular execution state of that plan. Maintain a bidirectional understanding between the plan document and the task graph.
5. **VERIFICATION**: Before marking a task as complete, verify the work is actually done (e.g., run the test, check the file existence).
6. **STATE OVER CHAT**: If the user says "I think we finished that," but the tool says it is 'pending', trust the tool--or verify explicitly before updating.
7. **DEPENDENCY MANAGEMENT**: Respect task topology. Never attempt to execute a task if its dependencies are not marked as 'closed'. If you are blocked, focus only on the leaf nodes of the task graph.`.trim();
}
export function renderPlanningWorkflow(
packages/core/src/tools/definitions/trackerTools.ts
+2 -1
View File
@@ -30,7 +30,8 @@ export const TRACKER_INIT_DEFINITION: ToolDefinition = {
export const TRACKER_CREATE_TASK_DEFINITION: ToolDefinition = {
base: {
name: TRACKER_CREATE_TASK_TOOL_NAME,
description: 'Creates a new task in the tracker.',
description:
'Creates a new task in the tracker. Use this immediately to decompose complex goals, research tasks, or multi-step requests into atomic units, regardless of whether the request was a list or a paragraph.',
parametersJsonSchema: {
type: 'object',
properties: {