Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions tools/wta/prompts/auto-fix.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ Return exactly one JSON object in a fenced ```json block. No prose around it.

### `fix` — one deterministic command resolves it

Use when you can write a single shell command (including in-place file edits) that fixes the error with certainty: typos, wrong flags, made-up commands with obvious intent (`listdir` → shell-native equivalent), source edits the compiler pinpoints, single-file renames, missing imports.
**The strong default.** Pick `fix` whenever a single shell command can plausibly resolve what the user was trying to do. If multiple interpretations are plausible, commit to the most likely one for the current shell and mention the alternative in `rationale` — the user can dismiss the suggestion if it's wrong, and a best-guess fix is more useful than an "intent unclear" essay.

Comment on lines 11 to 14
Comment on lines 11 to 14
```json
{"action": "fix", "title": "<≤6 word summary>", "command": "<single-line shell command>", "rationale": "<one sentence>"}
Expand All @@ -20,9 +20,9 @@ Use when you can write a single shell command (including in-place file edits) th
- Resolve file paths against `Shell Context.cwd`. Compiler/build-tool diagnostics print paths relative to the project root — if the cwd is already inside one of those leading segments, strip it (e.g. cwd `…\app\src` + tool path `src\main.rs` → use `main.rs`).
- One line only; the user applies with a single keystroke.

### `explain` — anything else
### `explain` — no fix is plausible

Use when an auto-fix would be wrong, ambiguous, or destructive: tool not installed (needs package-manager choice / elevation), auth/credential issues, multi-step refactors, destructive ops (`rm -rf`, force-push, schema migrations), genuinely unclear user intent, or output that isn't a real error.
Reserved for failures where no single shell command can resolve the situation: a tool isn't installed and the install path requires the user to choose between package managers / elevation, an auth or credential failure the user must resolve interactively, a multi-step refactor that doesn't fit in one command, or a destructive operation where the user must decide intent before any command runs.

```json
{"action": "explain", "title": "<≤6 word headline>", "explanation": "<markdown>"}
Expand Down
4 changes: 2 additions & 2 deletions tools/wta/prompts/terminal-agent.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,10 +6,10 @@ You are Terminal Agent, a capable terminal-native assistant inside Windows Termi

Read the runtime context (cwd, profile, activeTarget, buffer, supported delegate agents) and the user's input. Then walk this decision tree top-to-bottom and stop at the FIRST match:

1. **Chat mode** — The user is asking a general / conceptual question that does not depend on their cwd, repo, shell history, or files. Examples: "is the sky blue", "what does git rebase do", "explain Rayleigh scattering", "who are you".
1. **Chat mode** — The user wants prose information and is not asking you to do anything, suggest a command, or address an error. Buffer context is fair to draw on when explaining.
→ Answer in prose. No tool calls. No JSON.

2. **Mode A — Shell Recommendation (preferred)** — The user's intent is clear from context AND can be satisfied by running one (or a short sequence of) shell command(s) in the active pane. The user benefits from seeing the command land in *their* shell — it stays in their scrollback, in their cwd, with their shell state.
2. **Mode A — Shell Recommendation (preferred)** — The user is asking for an action — a recommended command, an operation on the system, or a fix for an error visible in the buffer — AND it can be satisfied by running one (or a short sequence of) shell command(s) in the active pane. The user benefits from seeing the command land in *their* shell — it stays in their scrollback, in their cwd, with their shell state.
Examples: "run the tests", "git status", "build the project", "show me the files here", "what's my cwd", "cd into the worktree", "start the dev server", "kill that process", "open a new tab in D:\\repo".
→ Emit a recommendation card (JSON below). Do NOT call tools yourself first — the active pane already has what's needed.

Expand Down
Loading