unic-ship-pr

name	unic-ship-pr
description	Use when the user explicitly asks to stage, commit, push, and open a pull request for unic. Do not use for general coding work or docs-only sync unless the user is asking to ship the current branch.

Ship the current unic changes through the repository's expected branch, commit, and PR flow.

Workflow

1. Confirm main-based worktree isolation.

• Ship only from a task branch in a fresh git worktree created from main or origin/main.
• If the current changes are in the primary checkout or on a branch that was not created from main, create a new main-based worktree and port only the intended changes before validating or opening a PR.
• Keep one worktree per PR-sized change.

2. Validate first.

• Run make test and stop if it fails.
• Run make build and stop if it fails.

3. Inspect scope.

• Check git status and git diff --stat.
• Confirm the changes are ready to ship and map to the intended issue.
• If the issue number is known, read it with gh issue view <number>.
• If the issue is implied but not named, search with gh issue list --state open --search '<terms>' --limit 20 before opening the PR.
• Do not open a PR without an issue reference unless the user explicitly approves that exception.

4. Create the branch.

• Branch from main in a fresh worktree.
• Use a conventional prefix such as feat/, fix/, or docs/.
• Use the user hint when provided; otherwise infer a concise branch name from the change.

5. Stage and commit carefully.

• Stage only the relevant files by name.
• Never use git add . or git add -A.
• Use a conventional commit title consistent with recent history.
• Include a short body with bullet points for key changes.
• Do not add Co-Authored-By lines.

6. Push and open the PR.

• Push with -u origin <branch>.
• Use gh pr create to open the PR.
• If a PR already exists for the branch, inspect it with gh pr view and update that PR instead of opening a duplicate.
• If .github/pull_request_template.md exists, follow it.
• Otherwise structure the PR body with: Summary, Related Issues, Validation, and Checklist.

7. Wait for automated review.

• After the PR is open, wait for required checks and Amazon Q Developer review to finish before reporting the PR as ready.
• Read the latest Amazon Q top-level review/comments for the current head with gh pr view <number> --json reviews,comments,statusCheckRollup,headRefOid.
• Also read thread-aware inline review state before deciding the PR is clean. Use the GitHub connector list_pull_request_review_threads when available, or gh api graphql to fetch reviewThreads { isResolved isOutdated path line comments { author { login } body createdAt } }.
• Treat any unresolved, non-outdated Amazon Q inline thread as actionable unless it is clearly informational. Do not rely only on top-level review summaries; they can miss inline findings.
• Ignore outdated Amazon Q threads only after confirming the current head no longer contains the flagged code.
• If Amazon Q reports actionable issues in either top-level reviews or current inline threads, patch them locally, rerun make test and make build, commit the fix, push, and comment /q review on the PR.
• Repeat the wait/read-threads/read-summary/patch/review loop until the latest Amazon Q review for the current head has no blocking or actionable issues and there are no unresolved, non-outdated actionable Amazon Q threads.
• If Amazon Q is unavailable, still report the PR URL and the completed local validation, but explicitly note that automated review could not be confirmed.
• Do not resolve or dismiss review threads unless the user explicitly asks.

Output

Return the branch name, commit message, PR URL, local validation, and latest Amazon Q result.