--- name: cursor-cloud-auto-engineer description: Drive one vibix issue-to-PR cycle inside Cursor Cloud — pick an unblocked issue, plan the change, implement it, validate it, push a branch, and open or update a PR. Use when the user says "auto-engineer", "auto-pilot", "go run the loop", or invokes `/cursor-cloud-auto-engineer`. compatibility: Cursor Cloud agent with git push access, `ManagePullRequest`, and read-only `gh`. disable-model-invocation: true metadata: runtime: cursor-cloud source_skill: .claude/skills/auto-engineer/SKILL.md --- # cursor-cloud-auto-engineer Read these shared playbooks first: - `docs/agent-playbooks/sdlc.md` - `docs/agent-playbooks/build-run.md` - `docs/agent-playbooks/testing.md` - `docs/agent-playbooks/pr-review.md` - `docs/agent-playbooks/prioritization.md` This is the Cursor Cloud companion to `.claude/skills/auto-engineer/SKILL.md`. Keep the same core loop — pick work, plan, implement, validate, push, and open a PR — but adapt it to Cursor Cloud's actual tool surface: - use Cursor-native tools such as `TodoWrite`, `Subagent`, and `ManagePullRequest` - use `gh` only for read-only inspection of issues, PRs, CI, and review comments - do not assume Claude-only primitives such as `ScheduleWakeup`, `/compact`, `/usage`, or GitHub write MCPs are available - keep any wait loop bounded to the current turn instead of trying to self-reschedule ## When to invoke - User explicitly asks to "auto-engineer", "auto-pilot", "run the loop", or similar in Cursor. - User invokes `/cursor-cloud-auto-engineer`. - User points at a specific issue (`#NN` or URL) and wants the agent to take it from branch to PR. Because this workflow is broad and potentially expensive, keep it explicit. Do not trigger it implicitly for ordinary coding requests. ## Success state One invocation is successful when all of these are true: 1. A single cohesive issue or task is selected. 2. The change is implemented on its own topic branch from `main`. 3. The highest-signal checks for the scope have passed. 4. The branch is pushed. 5. A PR targeting `main` exists and includes a concise summary plus the exact checks that ran. Unlike the Claude version, Cursor Cloud should normally stop at the PR handoff unless the user explicitly asks for more follow-up. ## Cycle ### 1. Pick one unblocked issue If the user already named an issue, use it. Otherwise inspect open issues with `gh issue list` and choose one that is not obviously blocked. Suggested query: ```sh gh issue list --search 'no:assignee' --state open \ --json number,title,labels,body,assignees,url ``` Filter out issues labeled `blocked`, `needs-discussion`, `question`, or `wontfix`, plus issues whose body clearly references an unresolved dependency. Apply the pick-order policy from `docs/agent-playbooks/prioritization.md`: sort `priority:P0` → `P1` → `P2` → `P3`, preferring `track:userspace` / `track:filesystem` / `track:terminal` / `track:posix` in that order within a priority bucket, and only fall back to lowest-numbered first inside a (priority, track) bucket. Issues missing a `priority:*` label rank after `priority:P3`. Cursor Cloud's `gh` access is read-only in this repo, so do not try to assign the issue. If issue assignment matters, note that limitation in the final handoff or PR body. ### 2. Plan with Cursor tools Gather context before editing: - use `Subagent` with `explore` for broad readonly codebase discovery - use `Subagent` with `generalPurpose` when you want a deeper implementation plan - use `TodoWrite` to track the active cycle Turn the result into a concrete implementation plan: - files to change - symbols to add or edit - tests or validation steps to run - risks and out-of-scope follow-ups If the chosen issue is too broad for one coherent PR, narrow it before editing and state the reduced scope in the PR. ### 3. Implement on a topic branch Start from `main` on a dedicated branch. Follow the active environment's branch naming rules; in Cursor Cloud that usually means a `cursor/` branch, possibly with a required suffix injected by the environment. While editing: - keep commits coherent - do not touch unrelated dirty-worktree changes - prefer the shared playbooks over improvised build or test commands - use `cargo xtask` entry points instead of raw kernel build commands ### 4. Validate according to scope Use the narrowest high-signal checks that match the change, then escalate if risk justifies it. - Kernel or behavior changes: run `cargo xtask test` and `cargo xtask smoke` - Build-system or tooling changes: run the most relevant `cargo xtask` or `cargo clippy` command - Docs/process/skill-only changes: run a targeted validation step appropriate to the edit; a low-cost repo sanity check such as `cargo xtask build` is optional, not mandatory Cursor Cloud runtime notes for this repo: - trust `cargo clippy -p xtask --all-targets -- -D warnings` as the Cloud lint command - when manually booting the kernel, prefer `timeout 6 cargo xtask run` or a tmux-backed session Do not claim success based only on compilation or branch creation if the change merits stronger validation. ### 5. Commit, push, and open the PR Before the final handoff: 1. Stage the intended changes only. 2. Create coherent commits with a short imperative subject and a body explaining why. 3. Push with `git push -u origin `. 4. Open or update the PR with `ManagePullRequest` against `main`. Use the repo's standard PR body shape: ```markdown ## Summary - - ## Test plan - [x] ``` If the work maps cleanly to a GitHub issue, include `Closes #` near the top of the PR body so the issue closes when a human merges the PR. Never use `gh` for write operations such as creating or editing PRs. ### 6. Handle follow-up within the current turn only If the current turn still has room and the user asked for CI follow-up, run a bounded review round against the PR using read-only GitHub commands such as: ```sh gh pr view gh pr checks gh api "repos/{owner}/{repo}/issues//comments" ``` Use this cadence: 1. Inspect immediately after opening or updating the PR. 2. If checks or review-bot feedback are still pending, sleep `180` seconds. 3. Re-check. 4. Repeat until everything reaches a terminal state or the round has spent `900` seconds total waiting. Treat one such bounded poll window as a single review round. Within that round: - fix actionable bugs or cheap in-scope nits as follow-up commits - never amend or force-push reviewed history - update the PR after each follow-up push If checks are still pending after `900` seconds, a review bot has not posted yet, or manual approval is required, stop with a concise status instead of trying to emulate Claude's wake-up loop across turns. ## Cursor Cloud differences from Claude auto-engineer - No self-rescheduling. One invocation handles one issue-to-PR cycle. - Review polling is bounded: sleep 3 minutes between checks, for up to 15 minutes per review round. - No `/compact` or `/usage` quota gate unless the active environment adds equivalents. - No GitHub write MCPs for issue assignment, issue filing, issue comments, or merge. - No self-merge. Leave the PR ready for a human reviewer unless the user explicitly grants a merge workflow and the environment provides a supported merge tool. ## Never - Commit directly to `main`. - Force-push or rewrite reviewed commits. - Use `gh` for write actions. - Claim checks passed without running them. - Wait indefinitely on CI or review bots inside one Cursor Cloud turn.