create-feature-pr

Create Feature PR

Contract

Prereqs:

• Run inside the target git repo with a clean working tree (or stash unrelated changes).
• git and gh available on PATH, and gh auth status succeeds.
• $CODEX_HOME points at the repo root (or tools are otherwise available).

Inputs:

• Feature summary + acceptance criteria (preferred) or inferred from the latest commit subject.
• Optional: related progress file path under docs/progress/ to link in the PR body.

Outputs:

• A new branch feat/<slug>, one or more commits, and a GitHub PR created via gh.
• PR body populated from references/PR_TEMPLATE.md (include a full GitHub URL to the progress file when provided).

Exit codes:

• N/A (multi-command workflow; failures surfaced from underlying git/gh commands)

Failure modes:

• Dirty working tree or wrong base branch.
• Missing gh auth or insufficient permissions to push/create PR.
• PR body missing required sections; if using a progress file, missing/invalid progress link.

Inputs

• Prefer explicit user feature description and acceptance criteria.
• If missing, read the latest commit message: git log -1 --pretty=%B.
• If still unclear, ask for a 1-2 sentence feature summary and expected behavior.

Branch naming

• Prefix: feat/.
• Build the slug from the feature summary or latest commit subject.
• Slug rules: lowercase; replace non-alphanumeric with hyphens; collapse hyphens; trim to 3-6 words.
• If a ticket ID like ABC-123 appears, prefix it: feat/abc-123-<slug>.

Workflow

1. Confirm the working tree is clean; stash or commit if needed.
2. Determine the base branch (default origin/HEAD); ask if unclear.
3. Create the branch: git checkout -b feat/<slug>.
4. Implement the feature with minimal scope; avoid unrelated refactors.
5. Add or update tests when reasonable; run available lint/test/build commands.
6. Commit using semantic-commit-autostage by default; use semantic-commit only when the user has explicitly staged a reviewed subset.
7. Push the branch and open a PR with gh pr create using references/PR_TEMPLATE.md.

PR rules

• Title: capitalize the first word; reflect the feature outcome; do not reuse the commit subject verbatim.
• Replace the first H1 line in references/PR_TEMPLATE.md with the PR title.
• Progress (optional):
  • If a progress file exists, include a full GitHub URL (e.g. https://github.com/<owner>/<repo>/blob/<branch>/docs/progress/...) because PR bodies resolve relative links under /pull/.
  • If no progress file, write None under ## Progress.
• Planning PR (optional):
  • If this feature work follows a planning PR, add ## Planning PR and reference it as - #<number> (no extra text/URL).
  • If no planning PR, write None under ## Planning PR.
• Always include Summary, Changes, Testing, and Risk/Notes sections.
• If tests are not run, state "not run (reason)".
• Use $CODEX_HOME/skills/workflows/pr/feature/create-feature-pr/scripts/render_feature_pr.sh --pr to generate the PR template quickly.

Output

• Use references/ASSISTANT_RESPONSE_TEMPLATE.md as the response format.
• Use $CODEX_HOME/skills/workflows/pr/feature/create-feature-pr/scripts/render_feature_pr.sh --output to generate the output template quickly.