菜单
Commit remaining changes, push the branch, open a pull request, and run Codex review
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Full development cycle — plan a feature, implement it, and open a PR
Process unhandled PR review comments on the current branch's open PR — answer questions, modify code, or push back
Like /develop, but skips test-writer invocation and post-impl verification (for repos without a test suite — see ADR-014 §12)
Run deep-learning experiments as disciplined hypothesis tests — frame the question, set up a self-contained per-experiment folder, launch training/eval runs (confirming before heavy GPU jobs), track metrics, analyze results against a baseline, and write a human-readable report with tables and plots. Use this whenever the user is doing experimental ML work: launching or preparing a training/finetuning/sampling/eval run, an ablation, or a hyperparameter sweep; saying things like "let's try X and see if it helps," "does this change improve FID/accuracy/loss," "compare these two runs/checkpoints," "track this experiment," "analyze the results," or "write up what we found." Trigger even when the user doesn't say the word "experiment" but is clearly testing whether a change moves a metric, or wants results organized, compared, or reported reproducibly.
Post-merge cleanup — update main, prune the remote, and print one paste-ready block of follow-up commands
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
| name | create-pr |
| description | Commit remaining changes, push the branch, open a pull request, and run Codex review |
| allowed-tools | Bash, Read, Edit, Write, Glob, Grep |
| argument-hint | [issue-number] |
Create a pull request for the current branch. Run two rounds of Codex code review before pushing.
The issue number (if any): $ARGUMENTS
Operating principle: Only ask the user when a step explicitly requires it, or when it is strongly necessary (e.g., blocking errors, ambiguous requirements). Do not stop just to report progress — keep moving through the steps autonomously.
Run git status and git diff to understand what has changed.
If there are uncommitted changes, commit them now following the commit discipline in CLAUDE.md — group by semantic unit, one logical change per commit.
If there is nothing to commit and no unpushed commits, stop and notify the user.
Fetch the latest main and check whether it has commits not yet in this branch:
git fetch origin main
git log HEAD..origin/main --oneline
If there are new commits on main, merge them into the current branch:
git merge origin/main --no-edit
If the merge has conflicts, stop and ask the user for help.
If main is already up-to-date, proceed.
After syncing, verify that any new ADRs or specs added on this branch don't collide with number prefixes already used on origin/main. Parallel branches can independently pick the same NNN; whichever one merges first wins, and the rest need renumbering. Run the ADR check first, then the spec check; commit each rename group separately.
git ls-tree -r --name-only origin/main docs/adr/ | sed -n 's|.*/\([0-9]\{3\}\)-.*|\1|p' | sort -u
git diff origin/main...HEAD --diff-filter=A --name-only -- 'docs/adr/*.md'
git mv docs/adr/<old>.md docs/adr/<new>.md.# ADR-<old-num>: header with # ADR-<new-num>:.git diff origin/main...HEAD --name-only, then for each file, use git diff origin/main...HEAD -- <file> to identify only the added lines (lines starting with +). Search those added lines for the old filename or ADR-<old-num>, and update matches to the new filename / ADR-<new-num>. Do not modify references that existed on main before this branch.git commit -m "docs: renumber ADR(s) to avoid collision with main".git ls-tree -r --name-only origin/main docs/specs/ | sed -n 's|.*/\([0-9]\{3\}\)-.*|\1|p' | sort -u
git diff origin/main...HEAD --diff-filter=A --name-only -- 'docs/specs/*.md'
git mv docs/specs/<old>.md docs/specs/<new>.md.# Spec-<old-num>: header with # Spec-<new-num>:.docs/specs/<old>.md paths. Use git diff origin/main...HEAD --name-only to list branch-modified files, then for each, look at added lines (+-prefixed in git diff origin/main...HEAD -- <file>) and update matches to the new filename / Spec-<new-num>. Do not modify references that existed on main before this branch.git commit -m "docs: renumber spec(s) to avoid collision with main".If no new ADRs or specs exist on the branch, skip this step.
Check whether any Python code, tests, or dependency files were modified in this branch:
git diff main...HEAD --name-only | grep -E '^(tools/|tests/|pyproject\.toml|uv\.lock)' || true
If there are matches, run the test suite:
uv run pytest tests/
If no Python-related files were changed, skip this part.
If all tests pass, continue. If any fail, stop and fix, and test again. Repeat until all tests pass. Then, proceed to the next step. If after 5 attempts the tests still fail, stop and notify the user for assistance.
Run /run-codex-review review --base main --background to review all changes on this branch.
Wait for the review to complete (check with /run-codex-review status). Once done, read the results with /run-codex-review result.
Fix all issues raised by Codex unless it brings unnecessary complications. Keep it simple!
Commit fixes with fix: address codex code review round 1.
If this PR is spec-bearing (apply the spec-presence gate in /resolve-review Bucket Routing — checks branch planning-doc header AND spec file presence on branch or main), classify each Codex finding per the Bucket Routing section of /resolve-review. Apply Sanitization rules before forwarding reviewer text to the test-writer subagent. Ambiguous findings halt /create-pr — surface the finding to the user and wait for direction before pushing. For Behavior-change-bucket findings, follow the three-commit sequence per /resolve-review's Step 4d Behavior-change pattern; the (round 1) suffix attaches to the impl commit only — the docs: spec commit and test: regen commit keep their bucket-standard messages without suffix.
If the review found no issues, proceed.
Run /run-codex-review adversarial-review --base main --background with focus text:
Only flag issues that meet one of these criteria:
- The issue would likely cause a critical bug if left unresolved
- The issue would be extremely difficult to resolve once a bug occurs in production
Wait for completion, then read the results.
Evaluate each finding against the two criteria above:
fix: address codex code review round 2 (critical).Bucket routing applies to round-2 findings as well. See Step 4's bucket-routing paragraph above; substitute (critical) for (round 1) in commit messages — same rule applies, the suffix attaches to single-commit buckets and to the impl commit of Behavior-change. Ambiguous critical findings halt /create-pr and surface to the user.
Run the following to verify the branch state, then proceed straight to Step 7. Do not pause for user confirmation:
git status
git log main..HEAD --pretty=format:"%h %s (%cd)" --date=short
Run git push -u origin <current-branch>.
If the push fails, report the error and stop — do not force push, resolve the cause of the failure.
Check whether this PR closes a GitHub issue:
42-feature-name → #42). If found, use it.$ARGUMENTS is provided, use that.Also: fetch the branch-linked issue body and grep for ^Original request: #[0-9]+$. /start-dev writes this line into new development issue bodies when the branch-linked issue differs from the originally requested one. If the grep finds a different issue number, add a second Closes #<N> for that original issue to the PR body in Step 8. If the fetch fails or no line is found, proceed with just the branch-linked close.
Run gh pr create with:
Closes #N line per issue identified in Step 7 (one in the common case; two when a separate original request issue was found)Print the PR URL when done.
Wait for all CI checks to pass:
gh pr checks <PR_NUMBER> --watch --fail-fast
If any check fails, investigate the failure, fix it, commit, and push. Then re-check CI. You have a maximum of 3 attempts:
If no CI checks are configured, proceed immediately.
Check whether any settings or hook files were changed in this PR:
git diff main...HEAD --name-only | grep -E '^(\.(claude/(settings\.json|settings\.local\.json|hooks/)|githooks/)|scripts/install-hooks\.sh)'
If any matches are found, remind the user to verify that appropriate entries exist in .claude/settings.json under both permissions.deny (block Edit/Write through Claude Code) and sandbox.filesystem.denyWrite (block writes at the OS sandbox level) to protect those files from future Claude Code modification.