main.js · part 203

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

File contents and all parts · All files

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

${ah(t,{...$y(e.modelInfo),mcpAuthInstruction:Ap})}

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.

Object expected.

Symbol.asyncDispose is not defined.

Symbol.dispose is not defined.

Object not disposable.

An error was suppressed during disposal.

Failed to get request context

Failed to get request context

omitSkillsToFit: loop ended without returning

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.

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.

Available persistent agent stores:

- ${(e=>{const t=e.readOnly?" (read-only)":"",r=void 0!==e.alias&&e.alias.length>0?` "${e.alias}"`:"";switch(e.kind){case po.$q.SELF:return void 0===e.inheritedFromPath?`Current agent's store: ${e.path}${t}`:`Current agent's store: ${e.path}${t} (inherited from the parent agent; a symlink to ${e.inheritedFromPath})`;case po.$q.PRINCIPAL:switch(e.alias){case lo._l:return`User's personal store: ${e.path}${t}`;case lo.WA:return`Current team's shared store: ${e.path}${t}`;case lo.SN:return`Current automation's shared store: ${e.path}${t}`;case lo.wd:return`Current named agent's shared home store: ${e.path}${t}`;default:return`${e.path}${t}`}case po.$q.PEER:return`Peer agent store${r}: ${e.path}${t}`;case po.$q.SHARE:return`Shared store${r}: ${e.path}${t}`;default:return`${e.path}${t}`}})(e)}

 "${e.alias}"

Current agent's store: ${e.path}${t}

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

User's personal store: ${e.path}${t}

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

Current automation's shared store: ${e.path}${t}

Current named agent's shared home store: ${e.path}${t}

Peer agent store${r}: ${e.path}${t}

Shared store${r}: ${e.path}${t}

Use normal file tools with these absolute paths. Stores marked (read-only) must not be written to; all other stores support reads and writes. 

Use normal file tools with these absolute paths to read or write store contents. 

When the user says "my user store" or "my personal store," use ${t.path}. 

Only use stores listed here; omitted stores are unavailable.

You are operating in a Cursor worktree, do not edit files outside of it unless explicitly asked to do so by the user.

If editing a git workspace within your current directory, do not search or edit non-primary worktrees unless the user explicitly requests you to do so.

This applies especially to Cursor-managed worktrees in ~/.cursor/worktrees.

${s} ${o} ${Number.parseInt(i,10).toString()}, ${a}

${t}

... (git status truncated)

${Ge(e.content??"")}, glob pattern(s) for applicable files: ${t}

${Ge(e.content??"")}, applicable for all files within ${t}

at:
${o.map(e=>`- ${e.path}`).join("\n")}

- ${e.path}

at ${o[0].path}

Yes (potentially incomplete while git repository detection is still warming), currently found ${g}

Unknown (git repository detection still warming)

Yes, ${g}

OS Version: 

Workspace Paths:

Workspace Path: 

Workspace Path: unknown

Is directory a git repo: 

Terminals folder: 

Today's date: 

Agent shared notes folder: 

Meta-agent notes folder: ${l}

Agent conversation notes folder: ${u}