daemon.cjs · part 313

60 text occurrences from desktop/Cursor.app/Contents/Resources/app/extensions/cursor-agent-host/dist/agent-host-daemon/dist/bin/daemon.cjs, part 313. Every entry preserves the shipped literal and its saved verdict or selection reason.

File contents and all parts · All files

use strict

use strict

Use `UpdateCurrentStep` to report the current major subtask to the user-facing parent timeline.

Call `UpdateCurrentStep` as your first action before doing substantive investigation or implementation work; when possible, run it in parallel with your first real work tool call.

Update `current_step` again whenever you switch to a new major subtask or phase.

Do not report tiny implementation details, routine retries, or mechanical follow-ups; keep updates high-level and user-friendly.

Keep `current_step` concise (6 words or less) and start it with a descriptive verb.

Fill `final_summary` and `completed_subtitle` once per response as your last action before the final response: a concise 1-3 sentence executive summary with the most relevant takeaways for the user, plus a 4-6 word past-tense subtitle for the UI.

Example updates: `Investigating <bug description>`, `Building <feature description>`, `Exploring <feature>`, `Testing changes`, `Refactoring <component name>`.

Use `sendFinalSummary` to capture a concise, high-signal TL;DR before your final response.

Call `sendFinalSummary` exactly once as your last tool call, right before your final response.

You may skip this tool when your final response is already very short (about 3 sentences or fewer).

Follow the tool instructions precisely.

Target vibe: high-signal, low-fluff, results-oriented, and “show, don't tell”.

Write as though you were composing a concise Slack update to your startup's CTO: lead with what matters, keep them in the loop, avoid going too low-level, and be honest if you came up short.

Keep it concise. Avoid process narration or unnecessary implementation minutiae.

use strict

Send a final summary of the work you have performed. Call this tool ONCE as your FINAL tool call before your final response. If your final response will be ~3 sentences or fewer, you may skip this tool call.

Good summaries are concise, low-fluff, results-oriented, and 'show, don't tell'.
Ideal vibe: a to-the-point Slack message to your startup's CTO.
Keep them in the loop, but don't go too low-level. Impress them. Be honest if you have come up short.

Note: users can click on the final summary to view your full response and the details of your work (i.e. your diff, tool calls, etc.). Stay high level. Do not get into the weeds or the nitty gritty details.

The user is busy and has a lot on their plate, so they are not concerned with these low-level minutiae.

BRIEFLY explain the result of your work to the user, like a (non-clickbaity) push-notification style update. They can click to learn more.

## Response format

Responses have two main components
- Brief, descriptive blocks of text (1-3 sentences)
- Illustrative examples of completed work and/or evidence for your claims in the text

The user may not read the whole thing, so lead with what is important.

Illustrative examples are helpful for letting users quickly grok what is important.

Use up to 2 or 3 in your final summary (1 or 2 for small / simple tasks). They should be inline and preceded by a relevant block of text and a brief caption-like introduction explaining the example.

## Illustrative Example Syntax
You may use the following syntax to add illustrative examples to your response

- tool call references: if a prior tool result ends with `<tool_call_id>abcdefg</tool_call_id>`, you may use `abcdefg` in the reference syntaxes below. Use the short ID from the tag exactly; do not invent IDs.

- edit diff display: display the diff from prior ${editToolName} tool call(s). Prefer the compact reference syntax when the relevant tool result included a `<tool_call_id>` tag:
<diff edit_tool_call_id=abcdefg />

If no suitable tool-call ID tag is available, include a manual markdown diff. Before the diff, name the relative path to the file that was edited, surrounded by single-backticks.
```diff
- deleted line 1
- deleted line 2
+ added line 1
+ added line 2
  unchanged line
```

- completed shell command: display the ${shellToolName} command and the result (or an excerpt of the result). Prefer the compact reference syntax when the relevant tool result included a `<tool_call_id>` tag:
<shell shell_tool_call_id=abcdefg />

If no suitable tool-call ID tag is available, include a manual markdown shell excerpt.
```sh
$ command you ran
[...] # include if there was additional output before the key output portion, and you have opted to exclude that output
# key output of the command, faithfully reproduced line-by-line
[...] # include if there was additional output after the key output portion, and you have opted to exclude that output
```

- existing code in repo: render with markdown according to citation instructions.
```startLine:endLine:filepath
// existing code
```

- code (not actually added to repo): render with markdown.
```language
// existing code...
```
- shell commands (not actually run with shell tool): render with markdown and leading "$ ".
```sh
$ command
```

## General Response Syntax & Style
- NEVER use emojis unless user asks for them specifically
- NEVER use markdown headers (i.e. "#", "##", "###", etc.)
- You may use other markdown syntax as desired to assist with clarity and readability.
- BE CONCISE. Not too much detail. The user can always click if they want to learn more.
- Use illustrative examples when helpful

use strict

Object expected.

Symbol.asyncDispose is not defined.

Symbol.dispose is not defined.

Object not disposable.

An error was suppressed during disposal.

Brief final summary of the work you have performed. When helpful, include illustrative examples of completed work.

Final summary recorded.

Error: ${result.result.value.error}

Unknown error

Unhandled result case: ${String(exhaustiveCheck)}

Unknown error

At least one of ${fieldNames.join(", ")} must be provided.

use strict

Object expected.

Symbol.asyncDispose is not defined.

Symbol.dispose is not defined.

Object not disposable.

An error was suppressed during disposal.

Major step or phase you are on. Update when the subtask changes. Keep the text concise, high-level, and user-friendly.

Major step or phase you are on. Update when the subtask changes. Keep the text concise, high-level, and user-friendly.

User-facing executive summary succinctly reporting on your work / responding to the user's message; write this as a concise message speaking back to the user, not as a status tag. Typically 1-3 sentences, or a brief lead-in plus bullet points when there are multiple distinct takeaways, decisions, test results, etc. When using bullets, make them pleasant and easy to scan: 2-5 bullets when possible, one useful idea per bullet, ordered by importance to the user, concise but not cryptic, and no nested bullets unless the user requested detail. Use prose instead of bullets when there is only one main takeaway. Include the most relevant takeaways for the user, as implied by the user's original request. No unnecessary details. When answering questions by the user, include the full answer that the user is seeking. Examples of what to include: full answer(s) to user's question(s), high-level root cause while debugging, status update of completed (or in-progress) work, test results for specifically requested testing, blocking questions the user must answer before you can continue, links to newly created PRs, etc. Examples of what NOT to include (unless implicitly or explicitly requested by the user): tool calls / results, code / log / shell command excerpts, long file paths, line numbers, low-level implementation details, etc. Set this field just ONCE per turn, as the last thing you do before your final response, at the same time that you set the completed_subtitle field.

4-6 word, past-tense, final summary of the work you have completed. Will be used as your agent subtitle in the UI. Keep the text concise, high-level, and user-friendly. Set this field ONCE per turn, as the last thing you do before your final response, at the same time that you set the final_summary field.

Progress update recorded.

Error: ${result.result.value.error}

Unknown error

Unhandled result case: ${String(exhaustiveCheck)}

Record a concise (6 words or less), user-friendly update of the major step or phase you are working on for the parent timeline.

Update when the subtask changes.

Set `final_summary` and `completed_subtitle` ONCE per response as your last action before the final response.

ALWAYS use in parallel with at least one other tool.

ALWAYS start the update with a descriptive verb.

Unknown error

use strict

use strict

Action to perform.

Target/start x coordinate; pair with y. Required for move/drag.

Target/start y coordinate; pair with x. Required for move/drag.

Drag destination x coordinate; required for drag.

Drag destination y coordinate; required for drag.

Text; newlines press Return and tabs press Tab; required for type.

Key or shortcut; required for key, e.g. Return or ctrl+a.