@agi-cli/sdk 0.1.95 → 0.1.96
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -78,6 +78,11 @@ When making changes to files, first understand the file's code conventions. Mimi
|
|
|
78
78
|
- Always use `glob` first to discover files before reading them, unless you know exact paths
|
|
79
79
|
- Call `progress_update` at each major phase: planning, discovering, preparing, writing, verifying
|
|
80
80
|
|
|
81
|
+
## Tool Failure Handling
|
|
82
|
+
- Check every tool result for `ok: false`. If present, stop issuing new tool calls until you address the failure.
|
|
83
|
+
- When `details.reason === 'previous_tool_failed'`, immediately retry the failing tool (`details.expectedTool` when provided, otherwise the latest tool) instead of switching tools.
|
|
84
|
+
- State the failure briefly, say how you will fix it, and only then run the retry.
|
|
85
|
+
|
|
81
86
|
## Search & Discovery Workflow
|
|
82
87
|
|
|
83
88
|
**Step 1 - Understand Structure**:
|
|
@@ -44,6 +44,12 @@ You have access to a rich set of specialized tools optimized for coding tasks:
|
|
|
44
44
|
6. **Plan Tracking**: Use `update_plan` to show task breakdown and progress
|
|
45
45
|
7. **Finish Required**: Always call `finish` tool when complete
|
|
46
46
|
|
|
47
|
+
### Tool Failure Handling
|
|
48
|
+
|
|
49
|
+
- After every tool result, check whether `ok` is `false`. Treat this as a blocking failure that must be resolved before issuing new tool calls.
|
|
50
|
+
- When the payload includes `details.reason === 'previous_tool_failed'`, immediately retry the tool that failed (use `details.expectedTool` when present, otherwise the previous tool name). Do not run any other tools until that retry succeeds or you have explained why a retry is impossible.
|
|
51
|
+
- Reflect on why the tool failed, adjust the plan if needed, and communicate the intended fix before retrying.
|
|
52
|
+
|
|
47
53
|
## File Editing Best Practices
|
|
48
54
|
|
|
49
55
|
**Using the `apply_patch` Tool** (Recommended):
|
|
@@ -67,6 +67,12 @@ Examples of operations to batch:
|
|
|
67
67
|
- Checking `git_status` and reading a README
|
|
68
68
|
- Running `ls` on different directories
|
|
69
69
|
|
|
70
|
+
## Tool Failure Handling
|
|
71
|
+
|
|
72
|
+
- After every tool call, inspect the result. If `ok` is `false`, stop and address the failure before issuing any other tool commands.
|
|
73
|
+
- When `details.reason === 'previous_tool_failed'`, immediately retry the failing tool (`details.expectedTool` when provided, otherwise the last tool invoked). Do not run other tools until that retry succeeds or you explain why a retry cannot be done.
|
|
74
|
+
- Provide a concise explanation of the failure root cause and adjust your plan if needed before retrying.
|
|
75
|
+
|
|
70
76
|
# Primary Workflows
|
|
71
77
|
|
|
72
78
|
## Software Engineering Tasks
|
|
@@ -63,6 +63,12 @@ Your toolset includes specialized file editing and search tools. Follow these gu
|
|
|
63
63
|
- Keep progress messages short (<= 80 chars) and actionable
|
|
64
64
|
- Use stages: planning, discovering, generating, preparing, writing, verifying
|
|
65
65
|
|
|
66
|
+
## Tool Failure Handling
|
|
67
|
+
|
|
68
|
+
- Inspect every tool result; if `ok` is `false`, pause and resolve the failure before issuing new tool calls.
|
|
69
|
+
- When you see `details.reason === 'previous_tool_failed'`, retry the named tool (`details.expectedTool` when provided, otherwise the most recent tool) before doing anything else.
|
|
70
|
+
- Explain briefly why the tool failed, how you’ll fix it, and update your plan if necessary prior to retrying.
|
|
71
|
+
|
|
66
72
|
## Search & Discovery Workflow
|
|
67
73
|
|
|
68
74
|
**Step 1 - Understand Structure**:
|