|
61 | 61 | **Instructions:** |
62 | 62 |
|
63 | 63 | 1. Carefully read and interpret the user's request, identifying any references to files, modules, submodules, or code elements—either explicit or implied. |
64 | | -2. **Prioritize returning fully qualified code identifiers** (such as functions, classes, methods, variables, or attributes) that are directly related to the user's request or are elements of interest. The identifier format must use dot notation to represent the path-like structure, e.g., `module.submodule.Class.method` or `module.function`, without file extensions. |
65 | | -3. Only include full file paths (relative to the repository root) if: |
| 64 | +2. **Segregate identifiers into two categories:** |
| 65 | + - **Context Identifiers:** Code elements (functions, classes, methods, variables, attributes, or file paths) that are required to understand, reference, or provide context for the requested change, but are not themselves expected to be modified. |
| 66 | + - **Modify Identifiers:** Code elements (functions, classes, methods, variables, attributes, or file paths) that are likely to require direct modification to fulfill the user's request. |
| 67 | +3. **Prioritize returning fully qualified code identifiers** (using dot notation, e.g., `module.submodule.Class.method`), without file extensions. Only include file paths (relative to the repository root) if: |
66 | 68 | - The user explicitly requests file-level operations (such as adding, deleting, or renaming files), or |
67 | 69 | - No valid or relevant code identifiers can be determined for the request. |
68 | 70 | 4. If the user refers to a file by name or path and the request is about code elements within that file, extract and include the relevant code identifiers from that file instead of the file path, unless the user specifically asks for the file path. |
69 | | -5. If fulfilling the request would likely depend on additional symbols or files—based on naming, structure, required context from other files/modules, or conventional design patterns—include those code identifiers as well. |
| 71 | +5. If fulfilling the request would likely depend on additional symbols or files—based on naming, structure, required context from other files/modules, or conventional design patterns—include those code identifiers as context identifiers. |
70 | 72 | 6. Only include identifiers or paths that are present in the provided tree structure. Never fabricate or guess paths or names that do not exist. |
71 | | -7. If no relevant code identifiers or file paths can be confidently identified, return an empty list. |
| 73 | +7. If no relevant code identifiers or file paths can be confidently identified, leave the relevant section(s) empty - without any contents or lines, not even the word empty. |
72 | 74 |
|
73 | 75 | --- |
74 | 76 |
|
75 | | -**Output Format (Strict JSON Only):** |
| 77 | +**Output Format:** |
76 | 78 |
|
77 | | -Return a JSON array of strings. Each string must be: |
78 | | -- A fully qualified code identifier using dot notation (e.g., `module.submodule.Class.method`), without file extensions, or |
79 | | -- A valid file path relative to the repository root (only if explicitly required or no code identifiers are available). |
| 79 | +Your response must include: |
80 | 80 |
|
81 | | -Your output must be a pure JSON list of strings. Do **not** include any explanation, comments, or formatting outside the JSON block. |
| 81 | +1. A brief explanation (1-3 sentences) describing your reasoning and search process for selecting the identifiers. |
| 82 | +2. The following delimited sections, each containing a newline-separated list of identifiers (or left empty if none): |
| 83 | +
|
| 84 | +*** Begin Context Identifiers |
| 85 | +<one per line, or empty> |
| 86 | +*** End Context Identifiers |
| 87 | +
|
| 88 | +*** Begin Modify Identifiers |
| 89 | +<one per line, or empty> |
| 90 | +*** End Modify Identifiers |
| 91 | +
|
| 92 | +Do **not** include any additional commentary, formatting, or output outside these sections. |
82 | 93 |
|
83 | 94 | --- |
84 | 95 |
|
85 | 96 | **Evaluation Criteria:** |
86 | 97 |
|
87 | | -- You must identify all code identifiers directly referenced or implied in the user request, prioritizing them over file paths. |
| 98 | +- You must identify all code identifiers directly referenced or implied in the user request, and correctly categorize them as context or modify identifiers. |
88 | 99 | - You must include any internal code elements that are clearly involved or required for the task. |
89 | 100 | - You must consider logical dependencies that may need to be modified together (e.g., helper modules, config files, related class methods). |
90 | 101 | - You must consider files that can be relevant as context to complete the user request, but only include their paths if code identifiers are not available or explicitly requested. |
91 | | -- You must return a clean and complete list of all relevant code identifiers and, if necessary, file paths. |
| 102 | +- You must return a clean and complete list of all relevant code identifiers and, if necessary, file paths, in the correct section. |
92 | 103 | - Do not over-include; be minimal but thorough. Return only what is truly required. |
93 | 104 |
|
94 | 105 | """ |
|
288 | 299 | 1. **step_description** |
289 | 300 | **instructions**: precise instructions of the task to be implemented in this step |
290 | 301 | **context_identifiers**: |
291 | | - - fully qualified code identifiers or file paths (as taken from the repo_tree) that this step touches, depends on, or must update |
| 302 | + - fully qualified code identifiers or file paths (as taken from the repo_tree) that this step depends on for context (read/reference only) |
| 303 | + **modify_identifiers**: |
| 304 | + - fully qualified code identifiers or file paths (as taken from the repo_tree) that this step will directly modify or update |
292 | 305 | --- |
293 | 306 | 2. **next_step_description** |
294 | 307 | **instructions**: ... |
295 | 308 | **context_identifiers**: |
296 | 309 | - ... |
| 310 | + **modify_identifiers**: |
| 311 | + - ... |
297 | 312 | --- |
298 | 313 | ... |
299 | 314 | *** End Steps |
|
308 | 323 |
|
309 | 324 | 4. **Granularity:** Break complex requirements into logical sub-steps. Order them so dependencies are respected (e.g., setup → implementation → validation → integration). |
310 | 325 |
|
311 | | -5. **Traceability:** Each step’s `context_identifiers` must clearly tie that step to specific code areas; this enables downstream mapping to actual implementation targets. |
| 326 | +5. **Traceability:** Each step's `context_identifiers` and `modify_identifiers` must clearly tie that step to specific code areas; this enables downstream mapping to actual implementation targets. |
312 | 327 |
|
313 | 328 | 6. **Single-Responsibility per Step:** Aim for each numbered step to encapsulate a coherent unit of work. Avoid mixing unrelated concerns in one step. |
314 | 329 |
|
315 | 330 | 7. **Decision Points:** If a step involves a choice or alternative, surface the options in the instructions and, if necessary, flag which you assume unless the user directs otherwise. |
316 | 331 |
|
317 | 332 | 8. **Testing & Validation:** Where appropriate, include in steps the need for testing, how to validate success, and any edge cases to cover. |
318 | 333 |
|
319 | | -9. **Failure Modes & Corrections:** If the user’s request implies potential pitfalls (e.g., backward compatibility, race conditions, security), surface those in early steps or in the comments and include remediation as part of the plan. |
| 334 | +9. **Failure Modes & Corrections:** If the use's request implies potential pitfalls (e.g., backward compatibility, race conditions, security), surface those in early steps or in the comments and include remediation as part of the plan. |
320 | 335 |
|
321 | 336 | 10. **Succinctness of Format:** Strictly adhere to the step formatting with separators (`---`) and the beginning/end markers. Do not add extraneous numbering or narrative outside the prescribed structure. |
322 | | -
|
323 | | ---- |
324 | | -
|
325 | | -`repo_tree` |
326 | | -{REPO_TREE} |
327 | 337 | """ |
328 | 338 |
|
329 | 339 | CMD_TRIGGER_PLANNING_STEPS = """ |
|
343 | 353 |
|
344 | 354 | CMD_COMMIT_PROMPT = """ |
345 | 355 | Generate a conventional commit message that summarizes the work done since the previous commit. |
346 | | -The message should have a clear subject line and a body explaining the problem solved and the implementation approach. |
347 | | -
|
348 | | -Important Instructions: |
349 | 356 |
|
350 | | -Place the commit message inside exactly this format: |
351 | | -*** Begin Commit |
352 | | -[commit message] |
353 | | -*** End Commit |
354 | | -
|
355 | | -You may include additional comments about the changes made outside of this block |
| 357 | +**Instructions:** |
356 | 358 |
|
357 | | -If no diffs for staged files are provided in the context, reply that there's nothing to commit |
| 359 | +1. First, write a body (before the commit block) that explains the problem solved and the implementation approach. This should be clear, concise, and provide context for the change. |
| 360 | +2. Then, place the commit subject line (only) inside the commit block, using this format: |
| 361 | + *** Begin Commit |
| 362 | + [subject line only, up to 3 lines, straight to the point and descriptive of the broad changes] |
| 363 | + *** End Commit |
| 364 | +3. The subject line should follow the conventional commit format with a clear type/scope prefix, and summarize the broad changes made. Do not include the body or any explanation inside the commit block—only the subject line. |
| 365 | +4. You may include additional comments about the changes made outside of this block, if needed. |
| 366 | +5. If no diffs for staged files are provided in the context, reply that there's nothing to commit.context, reply that there's nothing to commit |
358 | 367 |
|
359 | 368 | The commit message should follow conventional commit format with a clear type/scope prefix |
360 | 369 | """ |
|
0 commit comments