name	create-pr
description	Run /verify-pr checks, then create a GitHub PR if all pass. Automates the full flow from quality checks to PR creation.
argument-hint	[--base <branch>]

Create PR

Run all quality checks and create a GitHub PR if everything passes.

Steps

Ensure on a feature branch with the right cwd:
- git branch --show-current — check current branch
- Multi-worktree pre-flight: if the current branch is main (or master), also run git worktree list --porcelain and check whether any other worktree is on a non-main branch. If yes, surface that explicitly:
```
git worktree list --porcelain | awk '/^worktree /{wt=$2} /^branch refs\/heads\//{b=substr($0,index($0,"refs/heads/")+11); if (b!="main" && b!="master") print wt " on branch " b}'
```
  The user almost certainly intended to run /create-pr from that worktree's path — every subsequent git / gh pr view call defaults to cwd, so running from the parent worktree on main produces "no PR found for branch 'main'" even when a feature branch with commits is sitting in another worktree. Stop and ask the user whether to proceed in the listed worktree (offering cd <path> as the next step) before falling through to "create a new branch".
- If on main and no other worktrees have non-main branches, ask the user for a branch name and create it: git checkout -b <branch-name>.
- Branch naming convention: feat/, fix/, refactor/, docs/, chore/ prefix.
- Subsequent steps assume cwd is the worktree of the feature branch being PR'd. If the user defers the cd, abort instead of guessing.
Run /verify-pr — typecheck, lint, build, tests, CI, docs consistency, leftover resources. If any check fails, stop and report.
Ensure changes are committed and pushed:
- git status — if uncommitted changes exist, ask the user whether to commit them
- git push -u origin <branch> — ensure remote is up to date
Check if PR already exists for the current branch:
- gh pr view --json number,url -q '.url' 2>/dev/null
- If PR exists, report the URL and ask if the user wants to update it
Gather PR context:
- git log main...HEAD --oneline — all commits in this branch
- git diff main...HEAD --stat — changed files summary
- Determine base branch (default: main, overridable with --base)
Draft PR title and body:
- Title: concise, under 70 characters
- Base the title and body on the actual diff (git diff main...HEAD), not just commit messages — commit messages may reflect intermediate iterations that were later reverted
- Always write the PR title and body in English
- Body format:
```
## Summary
- bullet points of what changed and why

## Test plan
- [ ] Unit tests pass (N files, M tests)
- [ ] Integration test: <which ones were run, if any>
- [ ] Documentation updated
```

Create PR:

gh pr create --title "..." --body "$(cat <<'EOF'
...
EOF
)"

Report the PR URL.

Important

Do NOT create a PR if any /verify-pr check fails
Always push before creating the PR
If the branch has no commits ahead of main, warn and stop
gh pr edit may fail silently (e.g., Projects Classic deprecation). After updating a PR, verify the result with gh pr view. If gh pr edit fails, fall back to gh api repos/{owner}/{repo}/pulls/{number} -X PATCH

Más de este repositorio

mismo repositorio

cleanup

go-to-k/cdkd

Detect and delete leftover AWS resources from cdkd integration tests. Only targets resources matching known cdkd stack name patterns.

2026-07-0858

hunt-bugs

go-to-k/cdkd

Proactively hunt for cdkd bugs by deploying real CDK apps that exercise common-but-untested AWS resources, configs, and CloudFormation notations against real AWS, then fix what breaks. Use for a periodic "find latent bugs" sweep, not for verifying a specific change.

2026-07-0858

work-issues

go-to-k/cdkd

Work through already-filed GitHub issues (typically the bug-hunt's output) end to end — triage safely, pick a few FILE-DISJOINT issues to fix in parallel, claim each on the issue before starting (collision-safe with other agents), verify against real AWS, then carry each through merge → pull → release → rebuild the linked binary → worktree cleanup. Use when asked to "handle/address filed issues", not to hunt for new bugs (that is /hunt-bugs).

2026-07-0858

pick-integ

go-to-k/cdkd

Recommend which integration tests to run, based on the integ ledger (staleness / last result) plus the code areas touched by recent commits. Outputs a prioritized list of `/run-integ <name>` commands. Use before a release, after a batch of merges, or when unsure what integ coverage a change needs.

2026-07-0258

new-integ

go-to-k/cdkd

Scaffold a new integration test for cdkd. Creates a minimal CDK app with the specified AWS resources for deploy/destroy E2E testing.

2026-06-2058

run-integ

go-to-k/cdkd

Run integration tests (deploy + destroy) against real AWS. Use when you need to verify cdkd works end-to-end with actual AWS resources.

2026-06-0158

Create PR

Run all quality checks and create a GitHub PR if everything passes.

Steps

Ensure on a feature branch with the right cwd:

git branch --show-current — check current branch
Multi-worktree pre-flight: if the current branch is main (or master), also run git worktree list --porcelain and check whether any other worktree is on a non-main branch. If yes, surface that explicitly:
```
git worktree list --porcelain | awk '/^worktree /{wt=$2} /^branch refs\/heads\//{b=substr($0,index($0,"refs/heads/")+11); if (b!="main" && b!="master") print wt " on branch " b}'
```
The user almost certainly intended to run /create-pr from that worktree's path — every subsequent git / gh pr view call defaults to cwd, so running from the parent worktree on main produces "no PR found for branch 'main'" even when a feature branch with commits is sitting in another worktree. Stop and ask the user whether to proceed in the listed worktree (offering cd <path> as the next step) before falling through to "create a new branch".
If on main and no other worktrees have non-main branches, ask the user for a branch name and create it: git checkout -b <branch-name>.
Branch naming convention: feat/, fix/, refactor/, docs/, chore/ prefix.
Subsequent steps assume cwd is the worktree of the feature branch being PR'd. If the user defers the cd, abort instead of guessing.

Run /verify-pr — typecheck, lint, build, tests, CI, docs consistency, leftover resources. If any check fails, stop and report.

Ensure changes are committed and pushed:

git status — if uncommitted changes exist, ask the user whether to commit them
git push -u origin <branch> — ensure remote is up to date

Check if PR already exists for the current branch:

gh pr view --json number,url -q '.url' 2>/dev/null
If PR exists, report the URL and ask if the user wants to update it

Gather PR context:

git log main...HEAD --oneline — all commits in this branch
git diff main...HEAD --stat — changed files summary
Determine base branch (default: main, overridable with --base)

Draft PR title and body:

Title: concise, under 70 characters
Base the title and body on the actual diff (git diff main...HEAD), not just commit messages — commit messages may reflect intermediate iterations that were later reverted
Always write the PR title and body in English

Body format:

## Summary
- bullet points of what changed and why

## Test plan
- [ ] Unit tests pass (N files, M tests)
- [ ] Integration test: <which ones were run, if any>
- [ ] Documentation updated

Create PR:

gh pr create --title "..." --body "$(cat <<'EOF'
...
EOF
)"

Report the PR URL.

Important

Do NOT create a PR if any /verify-pr check fails

Always push before creating the PR

If the branch has no commits ahead of main, warn and stop

gh pr edit may fail silently (e.g., Projects Classic deprecation). After updating a PR, verify the result with gh pr view. If gh pr edit fails, fall back to gh api repos/{owner}/{repo}/pulls/{number} -X PATCH