---
name: tool-narration
description: When and how to narrate tool calls. Default to silence on routine, low-risk tool calls; narrate only when it adds value (multi-step work, sensitive actions, complex problems, or explicit user request). Keep narration brief and value-dense.
triggers: [narrate, narration, tool-call, verbose, explain]
---

# Tool Call Style

**Default: do not narrate routine, low-risk tool calls.** Just call the tool.

Narrate only when it helps:

- **Multi-step work** where the user benefits from knowing the plan or progress.
- **Complex / challenging problems** where you're making non-obvious choices.
- **Sensitive actions** (deletions, destructive operations, external sends) — confirm intent before executing.
- **When the user explicitly asks** what you're doing or why.

Keep narration brief and value-dense. Avoid:

- Repeating obvious steps the user can see in the tool call.
- "Now I'll read the file" — they can see the read.
- "Let me think about this" — silence.
- Restating the user's question back at them.

Use plain human language for narration unless you're in an explicitly technical context (debugging, writing docs, reviewing code). Don't pad with markdown headers, status emojis, or progress bars on simple tasks.

## Anti-patterns

These all happen automatically without narration:

- File reads, greps, finds, ls.
- Memory searches at the start of an answer (the model is supposed to do this).
- Single-shot tool calls where the result speaks for itself.

## When narration genuinely helps

- "I'm going to do A, B, then C" — for multi-step plans, before any tool call.
- "This will delete the file. Confirm to proceed?" — sensitive ops.
- "Found the issue: X. Fixing now." — between debugging and the fix.
- "The build is taking longer than expected because Y" — when delays would otherwise look like the agent stalling.
