Pr Lifecycle

3. Run /squash-commits

• Use squash-commits on unpushed commits only.
• If it needs user approval, proposes a risky rewrite, hits conflicts, fails tests, or leaves the repo dirty, stop and report.

4. Ensure Feature Branch

• Detect the default branch from origin/HEAD, then fall back to main or master if needed.
• If HEAD is detached or the current branch is still the default branch, create and switch to feature/<slug> derived from the hint.
• If already on a non-default branch, keep it.

5. Ensure Hooks And Fast Validation Ran

• Never use --no-verify.
• Inspect .githooks/, .git/hooks/, lefthook.yml, .pre-commit-config.yaml, package.json, pyproject.toml, Cargo.toml, and other obvious project files to identify the concrete validation commands behind the hooks.
• Re-run those concrete validations against the current HEAD after commit and squash.
• If you cannot determine hook coverage confidently, stop and say so rather than pretending all hooks ran.

6. Quick Local PR Review

• Review git diff --stat <base>...HEAD, git diff --check <base>...HEAD, and a skim of the patch itself.
• Look for secrets, debug prints, stale TODO/FIXME markers, missing tests for risky behavior, broken docs, or obviously noisy changes.
• Stop on glaring issues.

7. Run /readme-doctor

• Run readme-doctor after the quick local PR review and before any version decision.
• Stop if it finds glaring README, help-text, or packaging-documentation drift.
• If readme-doctor makes material doc changes, commit them normally so hooks run before continuing.

8. Check Public Package Versioning

• Detect whether the repo publishes a public package by inspecting package.json, pyproject.toml, Cargo.toml, *.gemspec, or other release metadata.
• If the repo is private or has no publish target, skip this step.
• If the repo publishes publicly, read references/version-registries.md and use the matching registry check.
• Compare the local package version with the currently published version.
• Use the PR diff to decide whether the shipped package behavior or artifact changed enough to warrant a release.
• If the local version is already published and the PR changes shipped package behavior or artifacts, make the smallest correct SemVer bump.
• If the local version has not been published yet, do not bump the version.
• If you make a version bump, commit it normally so hooks run, then rerun the quick local review and readme-doctor.

9. Push The Feature Branch

• Push the current feature branch with upstream tracking.
• Stop on any push rejection or auth failure.

10. Open The PR

• Use gh pr create.
• Prefer --fill when the existing commit history is already clean; otherwise provide an explicit title and body built from the branch diff.
• Capture the PR number and URL.

11. Wait For Build Success

• Use gh pr checks <pr-number> --watch when available, otherwise watch the corresponding GitHub Actions run.
• If CI fails, notify the user and stop.
• If CI passes, notify the user and stop. The user owns review, merge, and all follow-up after that point.

Output Contract

End with this plain-text block:

PR_LIFECYCLE_V1