create-pr
Open a PR
Important: Steps 2 and 3 require required_permissions: ['all'] because:
- Pre-commit hooks need access to global npm/node paths outside the workspace
ghCLI has TLS certificate issues in sandboxed mode
Critical Rules
NEVER include PII (Personally Identifiable Information) in:
- Commit messages
- PR titles or descriptions
- Branch names
- File paths or names mentioned in commits/PRs
- Any text that will be publicly visible
PII includes: names, email addresses, phone numbers, physical addresses, usernames, account IDs, API keys, tokens, passwords, or any other sensitive personal data.
Step 1: Check state (ONE command)
git branch --show-current && git status -s && git diff HEAD --stat
- Always create a new branch for each PR unless you're already on the correct branch for the current changes.
- If on
mainOR 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']
Step 2: Commit + Push (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
Step 3: Create PR (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.
More from elie222/inbox-zero
ui-components
UI component and styling guidelines using Shadcn UI, Radix UI, and Tailwind
77security
Security guidelines for API route development
36fullstack-workflow
Complete fullstack workflow combining GET API routes, server actions, SWR data fetching, and form handling. Use when building features that need both data fetching and mutations from API to UI.
23test-feature
End-to-end feature testing — browser QA, API verification, eval tests, or any combination. Covers browser interactions (via agent-browser CLI), Google Workspace operations (gws CLI), API calls, and LLM eval tests. Can also persist tests as reusable QA flows or eval files.
21testing
Guidelines for testing the application with Vitest, including unit tests, integration tests (emulator), AI tests, and eval suites for LLM features
21project-structure
Project structure and file organization guidelines
21