Make tool prompts explicit-request driven and scope rule headings

CHANGELOG.md

@@ -2,6 +2,7 @@
 
 ## Unreleased
 
+- Tool prompts: push, git config, shell search/read and sub-agents run on explicit request; rule headings are tool-scoped.
 - Recover Anthropic streaming responses interrupted by transient TLS `bad_record_mac` failures.
 - BREAKING: `plugins.install` now appends across config layers. Set `plugins.installMode` to `replace` beside the list to exclude inherited plugins as before.
 

resources/prompts/tools/git.md

@@ -38,10 +38,9 @@ EOF
 
 4. Return the PR URL.
 
-# Rules
-- Never use interactive flags (`-i`, `--interactive`)
-- Never update git config
-- Do not push unless creating a PR
+# Rules when using this tool
+- Never use interactive flags (`-i`, `--interactive`): no interactive terminal, so they hang; use a non-interactive equivalent and say why
+- Push and git config changes only on explicit request; when asked, do it without re-asking
 - Do not create empty commits
 - Always pass multi-line messages via stdin HEREDOC (`-F -`, `--body-file -`) with a quoted delimiter (`<<'EOF'`); never embed heredocs inside `$(...)`, some shells fail to parse them
 - Use `gh` for all GitHub API interactions (issues, PRs, checks, releases)

resources/prompts/tools/shell_command.md

@@ -26,8 +26,8 @@ Usage notes:
   - The `command` argument is required.
   - It is very helpful if you write a clear, concise description of what this command does in 5-10 words.
   - When issuing multiple commands, use the ';' or '&&' operator to separate them. DO NOT use newlines (newlines are ok in quoted strings).
-  - VERY IMPORTANT: You MUST avoid using search command `grep`. Instead use eca__grep to search. You MUST avoid read tools like `cat`, `head`, `tail`, and `ls`, and use eca__read_file or eca__directory_tree.
-  - Try to maintain your current working directory throughout the session by using absolute paths and avoiding usage of `cd`. You my use `cd` if the User explicitly requests it.
+  - For search and reading, default to `eca__grep`, `eca__read_file`, and `eca__directory_tree` (bounded, line-numbered output) over shell `grep`, `cat`, `head`, `tail`, `ls`. If the user explicitly asks for the shell command (e.g. to pipe), run it as asked.
+  - Commands start in the workspace root (or `working_directory`); `cd` does not persist between them, so prefer absolute paths.
     <good-example>
     pytest /foo/bar/tests
     </good-example>

resources/prompts/tools/spawn_agent.md

@@ -2,7 +2,7 @@ Spawn an isolated sub-agent to handle complex, multi-step tasks without pollutin
 
 Use for: Codebase exploration, codebase editing and refactoring, focused research, or delegating specialized tasks.
 Proactive use: If the specific agent's description suggests proactive use, use it whenever the task complexity justifies delegation.
-Restrictions: Avoid sub-agents for simple tasks, file reading, or basic lookups. Delegate ONLY if the task is complex, requires multi-step processing, or benefits from summarization and token saving.
+Restrictions: Avoid sub-agents for simple tasks, file reading, or basic lookups, unless the user explicitly asks. Delegate ONLY if the task is complex, requires multi-step processing, or benefits from summarization and token saving.
 Agent Limits: Sub-agents cannot spawn other agents (no nesting) and have access only to their configured tools.
 
 Strict rules for arguments:

resources/prompts/tools/task.md

@@ -29,7 +29,7 @@ Task Creation Guidance:
 - Order tasks by expected execution flow. Put prerequisite tasks before tasks that depend on them, and use `blocked_by` to record those dependencies explicitly.
 - Create tasks as independently executable units with concise, outcome-focused subjects. Keep steps separate if one can be completed before the next begins. If several planned steps will be carried out in the same unit of work, combine them into one task and put the substeps in the description.
 
-Workflow & Strict Execution Rules:
+Workflow rules for this tool:
 1. PLAN: Use 'plan' to create the task list with initial tasks. You MUST wait for the tool to return the generated task ids before doing anything else. Do NOT execute any work or call other tools in the same step as 'plan'.
 2. START & SYNC: Use 'start' immediately before beginning work on a task. Start ONLY tasks you are about to work on. Do not start tasks preemptively. You are FORBIDDEN to execute any work on a task unless its status is explicitly `in_progress`.
 3. DO THE WORK FIRST: After calling 'start', you MUST actually perform the work (write code, use tools, etc.). NEVER call 'complete' preemptively; only call 'complete' after the work has been done and objectively verified against the task's `description` acceptance criteria since the corresponding 'start'.