Skill: ivangdavila/cursor (version 1.0.0)

--- name: Cursor slug: cursor version: 1.0.0 homepage: https://clawic.com/skills/cursor description: Use Cursor safely across editor, CLI, rules, background agents, Bugbot, and MCP workflows with repo-aware context and reviewable execution. changelog: Initial release with editor and CLI guidance, rules and context control, background agent and Bugbot guardrails, privacy notes, and recovery workflows. metadata: {"clawdbot":{"emoji":"⌨️","requires":{"bins":["cursor-agent"],"bins.optional":["cursor","git","rg"],"config":["~/cursor/"]},"os":["linux","darwin","win32"],"configPaths":["~/cursor/"]}} --- ## When to Use User wants to operate Cursor as a real coding environment instead of a vague AI editor: choose the right surface, shape repo context, set rules correctly, use `cursor-agent`, run Background Agents, review with Bugbot, or decide whether MCP and remote execution are acceptable. Use this skill when the hard part is not "write code" but "make Cursor behave predictably" across editor chat, Agent or Ask flows, CLI runs, project rules, repo indexing, remote agents, GitHub integration, and privacy-sensitive work. ## Architecture Memory lives in `~/cursor/`. If `~/cursor/` does not exist, run `setup.md`. See `memory-template.md` for structure. ```text ~/cursor/ |-- memory.md # Durable activation boundaries and workflow defaults |-- repo-profiles.md # Per-repo conventions, trust posture, and verification expectations |-- rules-notes.md # Project-rule strategy, legacy rule cleanup, and instruction hierarchy notes |-- privacy.md # Indexing, ignore, remote execution, and data-handling defaults |-- remote-workflows.md # Background Agent, Bugbot, and GitHub integration decisions `-- incidents.md # Repeated failures, wrong-surface runs, and recovery patterns ``` ## Quick Reference Load only the smallest file needed for the current blocker. | Topic | File | |-------|------| | Setup guide | `setup.md` | | Memory template | `memory-template.md` | | Install and choose the right Cursor surface | `install-and-surfaces.md` | | Rules, context hierarchy, and mode choice | `rules-and-context.md` | | `cursor-agent`, non-interactive runs, and MCP boundaries | `cli-and-mcp.md` | | Background Agents, Bugbot, and GitHub-connected workflows | `background-agents-and-bugbot.md` | | Privacy mode, indexing, and ignore files | `privacy-and-indexing.md` | | Recovery playbooks for auth, bad context, and remote-run mistakes | `troubleshooting.md` | ## Requirements - Cursor installed and usable on the target machine, or permission to guide installation. - `cursor-agent` available when the task depends on CLI or automation workflows. - `git` available for repo-aware work, diff review, branch handling, Background Agents, or Bugbot. - Explicit user approval before enabling Background Agents, granting GitHub app write access, using remote MCP servers, or running high-trust non-interactive commands. - Treat model names, mode behavior, CLI flags, and remote-workflow features as live product surface: verify against official Cursor docs or current CLI help instead of assuming stale behavior. ## Operating Coverage This skill treats Cursor as an operational coding system, not as generic editor advice. It covers: - editor-side usage across Agent, Ask, Manual, and custom mode patterns - project rules through `.cursor/rules`, user rules, and repo-level agent guidance, with `.cursorrules` treated as legacy - context shaping through repo boundaries, indexing, and ignore files - local and non-interactive `cursor-agent` workflows, including resume and MCP-aware execution - Background Agents and Bugbot when work shifts from local interaction to remote GitHub-connected execution - privacy, data exposure, and review discipline when Cursor features move code or prompts off the local machine ## Data Storage Keep only durable Cursor operating context in `~/cursor/`: - which repos, teams, or task types are approved for Cursor use - preferred surface by task type: editor, CLI, Background Agent, or Bugbot - rule hierarchy decisions and recurring `.cursor/rules` patterns that worked - privacy and trust defaults around indexing, ignore files, GitHub integration, and remote MCP - repeated failures such as wrong repo scope, ignored rules, unsafe non-interactive runs, or remote review noise ## Core Rules ### 1. Lock the Cursor Surface First - Name the active surface before doing anything else: editor Agent, Ask, Manual, custom mode, `cursor-agent`, Background Agent, or Bugbot. - Each surface changes permissions, context loading, and review expectations. - Advice that ignores the surface usually causes the wrong workflow or trust level. ### 2. Establish the Instruction Hierarchy Before Prompting - Check for project rules in `.cursor/rules`, repo agent guidance, and any team-level user rules before asking Cursor to act. - Treat `.cursorrules` as a legacy format that may still exist but should not be your default design target. - If rules conflict or are too broad, fix the rule layout before expanding the prompt. ### 3. Shape Context Deliberately - Control what Cursor sees through repo selection, indexing posture, and ignore files instead of assuming it "just knows the repo." - Use `.cursorignore` and `.cursorindexingignore` for context control, but never treat them as perfect secret barriers. - When a task is narrow, reduce context first instead of adding more instructions later. ### 4. Separate Local Work From Remote Work - Editor Agent and local CLI use are different from Background Agents and Bugbot. - Remote GitHub-connected runs can execute commands, fetch code, and generate review output outside the local machine. - Escalate to remote workflows only when the value is clear and the trust story is explicit. ### 5. Treat Non-Interactive CLI and MCP as High-Trust Modes - `cursor-agent` is powerful, and non-interactive usage does not deserve casual assumptions about safety. - Review MCP server scope, host, and side effects before turning it on. - If a workflow depends on unattended writes, record the exact repo, command goal, and verification path first. ### 6. Make Privacy and Data Flow Explicit - Cursor requests, indexing, and remote workflows may send code or prompts to Cursor services, GitHub, or user-approved MCP hosts. - Privacy Mode changes expectations, but it does not make remote features equivalent to local-only execution. - The user should know what leaves the machine before you enable higher-trust features. ### 7. End With Reviewable Evidence - A good Cursor run ends with a diff, a check result, or a clear checkpoint, not just "the agent handled it." - For Background Agents and Bugbot, inspect the output before merging or applying anything locally. - Leave a concise handoff trail so the next operator can resume without guessing which surface ran what. ## Cursor Traps - Treating every Cursor feature as local-only -> remote execution and GitHub-connected workflows get approved without real review. - Dumping instructions into chat before checking `.cursor/rules` or repo agent guidance -> the repo's own guidance loses to prompt churn. - Assuming `.cursorignore` blocks every possible data path -> terminal and MCP tool calls can still touch things you did not intend. - Using Background Agents because they are convenient -> remote command execution happens before the trust boundary is discussed. - Treating `cursor-agent` automation as if it had interactive approvals -> non-interactive runs can widen scope quickly. - Mixing Bugbot, editor Agent, and local git state without naming ownership -> review noise and duplicated work pile up. - Assuming an API key means direct provider execution -> Cursor still mediates product behavior and trust boundaries. ## External Endpoints Only these endpoint categories are allowed unless the user explicitly approves more: | Endpoint | Data Sent | Purpose | |----------|-----------|---------| | https://cursor.com/* | prompts, selected repo context, diffs, integration metadata, and remote-workflow payloads needed by Cursor features | Cursor editor, agent, indexing, Background Agent, and review workflows | | https://docs.cursor.com/* | doc queries only | Verify current Cursor behavior, feature scope, and integration details | | https://github.com/* | repository metadata, code, pull-request context, and review actions approved by the user | Background Agents, Bugbot, and GitHub-connected Cursor workflows | | https://api.github.com/* | repository, branch, PR, and review metadata approved by the user | GitHub API access used by Cursor-connected review and remote execution flows | | https://{user-approved-mcp-host} | request payloads required by the approved MCP server | Optional MCP tool access beyond the local machine | No other data is sent externally unless the user explicitly approves more hosts or integrations. ## Security & Privacy Data that leaves your machine: - prompts and selected code context sent to Cursor services - indexing-related code chunks or metadata needed for Cursor codebase features - optional repo, branch, and PR context when Background Agents or Bugbot use GitHub-connected flows - optional MCP payloads only for user-approved MCP servers Data that stays local: - durable operating notes under `~/cursor/` - local repo state, local rules, and diffs unless the user enables remote features - any ignored or unshared files that never enter a Cursor request or approved tool call This skill does NOT: - treat `.cursorignore` as a perfect protection layer for secrets - enable Background Agents, Bugbot, or remote MCP without explicit approval - claim Cursor requests stay entirely local by default - assume legacy `.cursorrules` is still the right target for new setups - modify its own skill files ## Trust By using this skill, prompts and selected code context may be sent to Cursor services, plus optional GitHub and user-approved MCP hosts. Only install if you trust those services with that data. ## Scope This skill ONLY: - helps operate Cursor safely across editor, CLI, rules, indexing, remote agents, and review workflows - structures repo work into the right local or remote execution surface - keeps durable notes for approved repos, rule strategy, privacy posture, and recurring failure fixes This skill NEVER: - blur the line between local editor help and remote Background Agent execution - claim ignore files solve every privacy or access problem - recommend unattended high-trust Cursor runs as a default - treat Cursor as just another generic chat wrapper ## Related Skills Install with `clawhub install <slug>` if user confirms: - `agentic-engineering` - Strengthen multi-agent workflow design, review discipline, and blast-radius thinking around Cursor usage. - `coding` - Improve implementation quality once Cursor is operating inside the right repo boundaries. - `git` - Handle branches, diffs, stashes, and non-destructive repo recovery around Cursor-driven changes. - `api` - Reuse request-debugging and integration patterns when Cursor work touches external services. - `workflow` - Turn recurring Cursor tasks into cleaner, repeatable operating procedures. ## Feedback - If useful: `clawhub star cursor` - Stay updated: `clawhub sync`

path: background-agents-and-bugbot.md
content: # Background Agents And Bugbot - Cursor

Use this file when the user is considering remote execution or GitHub-connected review workflows.

## Background Agents

Treat Background Agents as remote execution, not as "Cursor but later."
Operationally they change several things at once:
- code can be cloned or fetched through GitHub-connected flows
- commands can run outside the local machine
- network access and remote compute become part of the trust boundary

Use them only when:
- the task is long-running enough to justify remote execution
- GitHub integration is acceptable
- the user agrees to the remote trust and review model

## Bugbot

Treat Bugbot as a review surface, not as automatic truth.
It is useful when:
- the unit of work is a pull request
- the goal is finding bugs or regressions before merge
- the user wants structured review comments instead of another implementation pass

Use repo guidance such as `.cursor/BUGBOT.md` only when it exists and is actually maintained.

## Review Discipline

- inspect Background Agent output before merging or applying follow-up changes locally
- inspect Bugbot findings before acting on them
- separate "helpful signal" from "approved change"
- if remote work touched the repo, compare the result against local expectations before continuing

## Red Flags

- enabling Background Agents just to avoid local setup work
- treating GitHub app access as a harmless toggle
- letting review comments trigger more remote work without clarifying ownership
- assuming privacy-sensitive repos are safe just because the feature is official


path: cli-and-mcp.md
content: # CLI And MCP - Cursor

Use this file when the user wants repeatable terminal execution, unattended runs, or tool access through MCP.

## `cursor-agent` Posture

Treat `cursor-agent` as a real execution surface, not a thin wrapper around editor chat.
Good fits:
- bounded repo tasks
- reproducible automation
- explicit terminal-first workflows
- session resume and checkpointed work

## Non-Interactive Risk

- Non-interactive usage should be treated as high trust.
- Do not assume interactive approval behavior will save you in unattended runs.
- Before launching, lock the repo, objective, allowed files, and verification path.

## MCP Boundaries

Cursor supports MCP, but the question is not "can it connect?"
The question is:
- which host is involved
- what data it can read
- what side effects it can trigger
- whether local-only assumptions still hold once MCP is enabled

## Default Policy

- prefer no MCP unless the workflow materially benefits
- prefer local or tightly scoped servers over broad remote ones
- require explicit approval before remote MCP
- document what each approved server is allowed to touch

## Failure Signs

- the run uses the wrong repo because CLI context was never pinned
- the task widens after launch because the prompt stayed vague
- MCP was enabled to "help" before its scope was reviewed
- the user expected local-only work but the workflow now depends on remote tools


path: install-and-surfaces.md
content: # Install And Surfaces - Cursor

Use this file when the user needs to choose the right Cursor operating surface before solving the actual coding problem.

## Surface Map

### Editor
Use the editor when:
- the user is already inside Cursor
- the work benefits from direct codebase context, inline edits, and local iteration
- you need to inspect how rules and context actually apply inside the repo

### `cursor-agent`
Use the CLI when:
- the task needs repeatable terminal execution
- the user wants automation or non-interactive runs
- you need a clean, explicit repo and command boundary

### Background Agent
Use it when:
- the task is longer-running and GitHub-connected execution is acceptable
- remote command execution is worth the trust tradeoff
- the user wants work to continue outside the local editor session

### Bugbot
Use it when:
- the job is review-first and tied to pull requests
- the user wants a separate review surface instead of another implementation pass
- GitHub-connected review output is acceptable

## Choosing Quickly

Ask only the questions that change the answer:
- Does this need to stay local?
- Does it need unattended execution?
- Is the goal implementation or review?
- Is the repo already open in Cursor?

## Practical Rule

Prefer the smallest surface that can solve the problem:
1. editor for local interactive work
2. `cursor-agent` for bounded automation
3. Background Agent for explicitly approved remote execution
4. Bugbot for review-specific GitHub workflows


path: memory-template.md
content: # Memory Template - Cursor

Create `~/cursor/memory.md` with this structure:

```markdown
# Cursor Memory

## Status
status: ongoing
version: 1.0.0
last: YYYY-MM-DD
integration: pending | done | declined

## Context
<!-- What the user uses Cursor for and why -->
<!-- Example: repo-aware implementation and review with local CLI only, no Background Agents -->

## Activation Boundaries
<!-- When this skill should activate automatically and when it should stay quiet -->

## Repo Defaults
<!-- Approved repos, verification expectations, and git-safety posture -->

## Rules Strategy
<!-- Preferred use of .cursor/rules, repo agent guidance, and legacy cleanup decisions -->

## Privacy and Remote Work
<!-- Indexing, Background Agent, GitHub, Bugbot, and MCP boundaries -->

## Surface Preferences
<!-- Editor Agent, Ask, Manual, custom modes, CLI, Background Agent, Bugbot -->

## Notes
<!-- Durable operational observations worth reusing -->

---
*Updated: YYYY-MM-DD*
```

## Status Values

| Value | Meaning | Behavior |
|-------|---------|----------|
| `ongoing` | Default learning state | Keep refining durable Cursor defaults |
| `complete` | Stable surfaces and trust posture are clear | Reuse defaults unless the environment changes |
| `paused` | User wants less overhead | Save only critical changes |
| `never_ask` | User rejected persistence | Operate statelessly |

## Key Principles

- Store workflow boundaries, not full prompts, full diffs, or private transcripts.
- Keep repo approvals, remote-workflow approvals, and MCP approvals explicit.
- Record which Cursor surfaces are preferred and which are prohibited.
- Update `last` on each meaningful Cursor session.


path: privacy-and-indexing.md
content: # Privacy And Indexing - Cursor

Use this file when the user cares about where code goes, what indexing really means, or whether ignore files provide enough protection.

## Core Reality

Cursor features can send prompts and code context to Cursor services.
That remains true even when the user supplies their own model provider key for some flows.
Do not describe Cursor as local-only unless the exact workflow truly is.

## Indexing

Codebase indexing improves retrieval, but it is also a data-flow decision.
Treat indexing as a separate approval question for privacy-sensitive repos.

## Ignore Files

### `.cursorignore`
Use it to reduce what Cursor should index or reference.
It helps, but it is not a perfect barrier.
Do not assume it blocks every possible tool path or terminal action.

### `.cursorindexingignore`
Use it when the goal is narrower indexing control specifically.
Do not confuse "not indexed" with "impossible to reach."

## Important Boundary

Ignore controls do not guarantee protection against everything an agent can reach through terminal commands or MCP tool calls.
If a file must never be exposed, solve that at the repo, filesystem, or integration boundary, not only with Cursor ignore settings.

## Practical Policy

- for sensitive repos, ask whether indexing is acceptable before enabling rich context features
- keep secrets and production credentials out of repo paths the agent can touch
- treat Background Agents, Bugbot, GitHub integration, and MCP as additional privacy layers to review separately


path: rules-and-context.md
content: # Rules And Context - Cursor

Use this file when Cursor seems inconsistent, over-general, or blind to repo conventions.

## Rule Hierarchy

Current Cursor setups should prefer:
1. `.cursor/rules` for project rules
2. repo-level agent guidance when it already exists
3. user rules only for durable personal defaults
4. `.cursorrules` only as legacy material that may need migration

## `.cursor/rules` Strategy

Treat rules as scoped tools, not as one giant policy dump.
Useful rule categories:
- repo conventions
- framework-specific constraints
- dangerous-action guardrails
- review and verification expectations

Keep rules short enough to load intentionally and specific enough to change behavior.

## Attachment Modes

Cursor supports different rule attachment patterns. Treat them as separate tools:
- always-on rules for universal repo safety
- auto-attached rules for specific file or context triggers
- agent-requested rules for optional deep guidance
- manual rules for operator-controlled loading

If too many rules attach at once, Cursor becomes noisy and less predictable.

## Context Hygiene

- Start with the smallest relevant folder or file set.
- Use indexing and references deliberately instead of assuming the full repo should always load.
- If Cursor is ignoring conventions, inspect the rule layout before rewriting the prompt.

## Legacy Cleanup

- `.cursorrules` is legacy, not the target design for new setups.
- Migrate only when the repo is ready and you can preserve intent.
- Do not leave duplicate instructions spread across `.cursorrules`, `.cursor/rules`, and repo-level agent guidance unless the overlap is deliberate.


path: setup.md
content: # Setup - Cursor

Read this when `~/cursor/` is missing or empty. Start naturally and stay operational.

## Your Attitude

Act like a careful Cursor operator, not a hype-driven editor fan.
Be explicit about trust boundaries, repo scope, and which Cursor surface is in play.
Get the user to a working Cursor workflow in the same session without hiding tradeoffs.

## Priority Order

### 1. Integration First
Within the first exchanges, clarify activation boundaries:
- Should this skill activate whenever Cursor, `cursor-agent`, Background Agents, Bugbot, `.cursor/rules`, or MCP comes up?
- Should it jump in proactively for rule hygiene, context control, and reviewability, or only on request?
- Are there situations where this skill should stay inactive?

Before creating local memory files, ask for permission and explain that only durable Cursor operating preferences will be kept.
If the user declines persistence, continue in stateless mode.

### 2. Lock the Active Surface Fast
Capture only the facts that change behavior:
- editor, CLI, Background Agent, or Bugbot
- local-only versus GitHub-connected or remote execution
- current blocker: install, rules, context, automation, privacy, or review noise
- whether MCP or custom modes are in scope at all

Ask minimally, then move into the live task.

### 3. Set the Defaults That Prevent Drift
Align on the practical defaults that matter:
- which repos or orgs are approved for Cursor use
- whether remote workflows are acceptable or local-only is preferred
- whether rules should live in `.cursor/rules`, repo agent guidance, or both
- how much verification is required before the user considers the run complete

If uncertain, default to local editor or CLI work, explicit rules, no remote MCP, and review before any remote execution path.

## What To Store

Save only durable context:
- approved repos, teams, and no-go areas
- preferred Cursor surface by task type
- rule hierarchy and context-shaping defaults
- privacy, GitHub, Background Agent, and MCP boundaries worth reusing

Store data only in `~/cursor/` after user consent.

## Golden Rule

Answer the live Cursor workflow problem in the same session while building just enough durable context to make future runs safer, faster, and easier to review.


path: troubleshooting.md
content: # Troubleshooting - Cursor

Use this file when Cursor is behaving inconsistently, reading the wrong context, or producing work that does not match repo intent.

## Fast Triage

Check these in order:
1. active surface
2. repo and folder scope
3. rule hierarchy
4. indexing and ignore posture
5. remote versus local execution
6. verification evidence

## Common Failure Patterns

### Cursor ignores repo conventions
- inspect `.cursor/rules` and repo agent guidance before rewriting prompts
- remove duplicate or conflicting guidance
- narrow context to the files that actually matter

### CLI run widens scope
- confirm the repo path and task boundary
- restate the objective in one sentence
- avoid rerunning vague non-interactive prompts

### Background Agent results feel off
- verify which repo, branch, and integration path the remote run actually used
- separate command failure from bad task framing
- inspect remote output before applying local fixes

### Bugbot noise overwhelms signal
- check whether the PR is too broad
- refine review guidance if `.cursor/BUGBOT.md` exists
- triage findings by severity before changing code

### Privacy assumptions were wrong
- check whether indexing, GitHub integration, or MCP changed the trust boundary
- stop remote workflows until the data path is clear
- move to a smaller local surface if the repo is more sensitive than expected

## Recovery Rule

When in doubt, fall back to the smallest local Cursor surface that can reproduce the issue, confirm repo context and rules, and only then reintroduce automation, indexing, or remote execution.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)