| name | create-pr |
| description | Commit changes and open a pull request with safe metadata |
| disable-model-invocation | true |
Important: Steps 2 and 3 require required_permissions: ['all'] because:
gh CLI has TLS certificate issues in sandboxed modeNEVER include PII (Personally Identifiable Information) in:
PII includes: names, email addresses, phone numbers, physical addresses, usernames, account IDs, API keys, tokens, passwords, or any other sensitive personal data.
git branch --show-current && git status -s && git diff HEAD --stat
main OR if the current branch doesn't match the work you're committing: create a branch using the appropriate prefix:
feat/<description> - new featuresfix/<description> - bug fixeschore/<description> - maintenance, refactoring, etc.git checkout -b feat/<description>
Note: git checkout -b requires required_permissions: ['git_write']
required_permissions: ['all'])If uncommitted changes exist:
If staged files exist (respect user's selection):
git commit -m "<msg>" && git push
If unstaged files exist (add specific files, NOT git add .):
git add <file1> <file2> ... && git commit -m "<msg>" && git push
required_permissions: ['all'])Format:
<feature_area>: <Title> (80 chars max)
<TLDR> (1-2 sentences)
- bullet 1
- bullet 2
Without skip-review:
gh pr create --title "<title>" --body "<body>"
With skip-review (user says "skip review", "#skipreview", etc.):
gh pr create --title "<title>" --body "<body>" && gh pr comment $(gh pr view --json number -q .number) --body "#skipreview"
Display the returned PR URL as a markdown link on its own line, formatted as: [PR #<number>](<url>) so it's clickable.
Display the name of the branch you created.
In the final response, include a concise performance impact note for the PR, covering added runtime work, database/network calls, and hot-path risk when relevant.
Guidelines for testing the application with Vitest, including unit tests, integration tests (emulator), AI tests, and eval suites for LLM features
Cursor Cloud VM setup and service startup instructions for local development
Simplify and refine recently modified code for clarity, consistency, and maintainability while preserving exact behavior. Use when asked to simplify, polish, refactor lightly, or clean up current-session changes before review or PR.
Review prompt and tool-description changes in a branch or PR. Use when asked to audit system prompts, prompt builders, tool descriptions, prompt inputs, or nearby evals/tests; summarize what changed; identify guidance that feels eval-shaped or too heavy for product use; and find repeated instructions between the main prompt and tool descriptions.
Add a new changelog entry to docs/changelog-entries/
Update workspace packages while respecting the repo's pinned package list in .ncurc.cjs. Use when the user asks to update dependencies or refresh package versions.