daemon.cjs · part 295

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

File contents and all parts · All files

If the commit fails due to pre-commit hook, fix the issue and create a NEW commit (see amend rules above)

Important notes:

NEVER update the git config

NEVER run additional commands to read or explore code, besides git shell commands

DO NOT push to the remote repository unless the user explicitly asks you to do so

IMPORTANT: Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported.

If there are no changes to commit (i.e., no untracked files and no modifications), do not create an empty commit

In order to ensure good formatting, ALWAYS pass the commit message via a HEREDOC, a la this example:

git commit -m "$(cat <<'EOF'
Commit message here.

EOF
)"

Creating pull requests

Use the gh command via the 

 tool for ALL GitHub-related tasks including working with issues, pull requests, checks, and releases. If given a Github URL use the gh command to get the information needed.

If this conversation already includes preferred pull-request host guidance that names a create command (`gh pr create` or `origin pr create` for Cursor Origin — Cursor's PR host, not the git remote named `origin`), that guidance OVERRIDES the `gh pr create` steps and example below: it names the forge that is the repository's source of truth, so if that command fails, report the failure instead of creating the PR on the other forge. If using `gt`, pass `--github` or `--origin`. Keep using `gh` for other GitHub tasks (issues, checks, releases) unless that guidance says otherwise.

IMPORTANT: When the user asks you to create a pull request, follow these steps carefully:

You have the capability to call multiple tools in a single response. When multiple independent pieces of information are requested, batch your tool calls together for optimal performance. ALWAYS run the following shell commands in parallel using the

 tool, in order to understand the current state of the branch since it diverged from the main branch:

Run a git status command to see all untracked files

Run a git diff command to see both staged and unstaged changes that will be committed

Check if the current branch tracks a remote branch and is up to date with the remote, so you know if you need to push to the remote

Run a git log command and `git diff [base-branch]...HEAD` to understand the full commit history for the current branch (from the time it diverged from the base branch)

Analyze all changes that will be included in the pull request, making sure to look at all relevant commits (NOT just the latest commit, but ALL commits that will be included in the pull request!!!), and draft a pull request summary

Run the following commands sequentially:

Create new branch if needed

Push to remote with -u flag if needed

Create PR using gh pr create with the format below. Use a HEREDOC to pass the body to ensure correct formatting.

# First, push the branch (with required_permissions: ["all"])
git push -u origin HEAD

# Then create the PR (with required_permissions: ["all"])
gh pr create --title "the pr title" --body "$(cat <<'EOF'
## Summary
<1-3 bullet points>

## Test plan
[Checklist of TODOs for testing the pull request...]

EOF
)"

NEVER update the git config

DO NOT use the TodoWrite or Task tools

Return the PR URL when you're done, so the user can see it

use strict

 in the user query or in a different user rule

use strict

use strict

${instructions}

If the available MCP tools do not fully support what the user asked you to do, complete the work you can with the current tool set. In your work summary, include what you were unable to do with MCP and why. Do not use browser automation to work around missing or unavailable MCP tools unless the user explicitly asks you to use the browser.

use strict

use strict

use strict

use strict

Failed to get request context

Failed to get request context

use strict

Object expected.

Symbol.asyncDispose is not defined.

Symbol.dispose is not defined.

Object not disposable.

An error was suppressed during disposal.

use strict

omitSkillsToFit: loop ended without returning

${description3.slice(0, contentLength).trimEnd()}${TRUNCATED_DESCRIPTION_SUFFIX2}

use strict

use strict

<browser_verification>
When your work materially changes a web app's user-visible behavior or layout, verify the affected flow in the browser before finishing when browser tools are available. Keep verification proportional: trivial copy or isolated styling changes do not require an exhaustive browser pass.

Focus on what could realistically break:
1. Exercise the main affected interaction or flow end to end.
2. Check related routes when they share changed state, data, or components.
3. Probe important edge states when the change could affect them.
4. For responsive layout changes, check representative desktop and mobile viewports.

If you find a problem, fix it and re-check before finishing.
</browser_verification>

When implementing or fixing anything in a web application (UI, layout, styling, routing, client state, or rendered data), verify your work in the browser before declaring the task complete.

**Use this verification workflow:**
- Open the app with the available browser tools and exercise the changed feature end to end the way a real user would: click, type, submit, navigate.
- A single render screenshot of the changed screen is NOT verification. Confirm behavior, not just appearance.
- Check every page and route that shares the state, data, or components you touched. Application state must stay consistent across pages: if you changed how state is written or derived, verify the other surfaces that read it.
- Hunt for regressions. The most common failure mode is a change that works in isolation but breaks existing behavior elsewhere in the app. Navigate the surrounding flows and look for what broke.
- Verify the paths and edge states your change touches (empty states, error states, route and flag variants), not only the main path.
- When layout or styling changed, consider whether you need to verify both desktop and mobile viewports.
- If verification finds a problem, fix it and re-verify. Do not finish with unverified UI work.

If no browser tools are available, verify through the closest available substitute (tests, curl against the dev server, rendering scripts) and say what you could not verify.

use strict

When doing frontend design tasks, avoid generic, overbuilt layouts.

**Use these hard rules:**
- One composition: The first viewport must read as one composition, not a dashboard (unless it's a dashboard).
- Brand first: On branded pages, the brand or product name must be a hero-level signal, not just nav text or an eyebrow. No headline should overpower the brand.
- Brand test: If the first viewport could belong to another brand after removing the nav, the branding is too weak.
- Typography: Use expressive, purposeful fonts and avoid default stacks (Inter, Roboto, Arial, system).
- Background: Don't rely on flat, single-color backgrounds; use gradients, images, or subtle patterns to build atmosphere.
- Full-bleed hero only: On landing pages and promotional surfaces, the hero image should be a dominant edge-to-edge visual plane or background by default. Do not use inset hero images, side-panel hero images, rounded media cards, tiled collages, or floating image blocks unless the existing design system clearly requires it.
- Hero budget: The first viewport should usually contain only the brand, one headline, one short supporting sentence, one CTA group, and one dominant image. Do not place stats, schedules, event listings, address blocks, promos, "this week" callouts, metadata rows, or secondary marketing content in the first viewport.
- No hero overlays: Do not place detached labels, floating badges, promo stickers, info chips, or callout boxes on top of hero media.
- Cards: Default: no cards. Never use cards in the hero. Cards are allowed only when they are the container for a user interaction. If removing a border, shadow, background, or radius does not hurt interaction or understanding, it should not be a card.
- One job per section: Each section should have one purpose, one headline, and usually one short supporting sentence.
- Real visual anchor: Imagery should show the product, place, atmosphere, or context. Decorative gradients and abstract backgrounds do not count as the main visual idea.
- Reduce clutter: Avoid pill clusters, stat strips, icon rows, boxed promos, schedule snippets, and multiple competing text blocks.
- Use motion to create presence and hierarchy, not noise. Ship at least 2-3 intentional motions for visually led work.
- Color & Look: Choose a clear visual direction; define CSS variables. AVOID defaulting to looks where AI-generated design tends to cluster: (1) purple-on-white or purple-to-indigo gradient themes; (2) a warm cream background (near #F4F1EA) with a high-contrast serif display and a terracotta accent; (3) a broadsheet-style layout with hairline rules, zero border-radius, and dense newspaper-like columns. Avoid biases to: dark mode; purple; glow effects; rounded-full pills; multi-layer shadows; emojis.
- Ensure the page loads properly on both desktop and mobile.
- For React code, prefer modern patterns including useEffectEvent, startTransition, and useDeferredValue when appropriate if used by the team. Do not add useMemo/useCallback by default unless already used; follow the repo's React Compiler guidance.

Exception: If working within an existing website or design system, preserve the established patterns, structure, and visual language.

 "${store.alias}"

Current agent's store: ${store.path}${readOnlySuffix}

Current agent's store: ${store.path}${readOnlySuffix} (inherited from the parent agent; a symlink to ${store.inheritedFromPath})

User's personal store: ${store.path}${readOnlySuffix}

Current team's shared store: ${store.path}${readOnlySuffix}