shawn-sandy/ship-autonomous

Autonomously branch, commit, and open a PR, then subscribe to the PR's activity events and autofix failures as they arrive — keeping the user posted throughout.

Run Steps 0–5 in strict order. Step 5 subscribes to PR events and ends the turn. Steps 6–7 are the standing policy the session follows each time a PR event wakes it; they are not a synchronous loop you run inside one turn.

---

Step 0: Exit Plan Mode

Call ExitPlanMode immediately and silently — always, unconditionally, before any other action. Do not prompt the user. Committing, pushing, and opening a PR are mutations that cannot proceed inside plan mode.

ExitPlanMode is a deferred tool. Use ToolSearch with select:ExitPlanMode first to load its schema, then call ExitPlanMode. Both steps run silently with no user-visible output.

Error handling: If ExitPlanMode returns the exact error "You are not in plan mode", treat that as success — plan mode was already off. Do not abort or surface the error to the user; continue to the next step.

---

Step 1: Pre-flight Guards

Run all checks before any mutation.

Clean working tree:

git status --porcelain

If empty, output: "Nothing to ship — working tree is clean." and STOP.

Uncommitted plan files:

git ls-files --others --modified --exclude-standard docs/plans/

If any plan files are listed, output them and ask:

Uncommitted plan files detected. How would you like to proceed?

• include — stage them with the rest of the changes
• stash — git stash them before branching (you can restore after)
• abort — stop here; commit or clean up plan files first

Use AskUserQuestion with those three options. On abort, STOP.

Detached HEAD:

git branch --show-current

If empty, output: "Cannot ship: repository is in detached HEAD state. Checkout a branch first." and STOP.

GitHub CLI auth:

gh auth status

If not installed or not authenticated, output:

GitHub CLI is required. Install from https://cli.github.com/ and run `gh auth login`.

and STOP.

---

Step 2: Branch

Check current branch:

git branch --show-current

Detect the default branch:

git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||'

If the current branch is the default branch (or main/master as fallback), invoke the existing git-agent:branch-agent skill with no arguments. It will auto-generate a <type>/<scope>-<desc> slug from the working tree and branch from origin/HEAD --no-track.

If already on a feature branch, continue without creating a new branch.

---

Step 3: Commit

Invoke the existing git-agent:commit-agent skill. It stages all changes, analyzes the diff, writes a conventional commit message, and commits.

If commit-agent stops due to a pre-commit hook failure: propagate the failure message verbatim and STOP. Do not retry. Do not use --no-verify.

---

Step 4: Open PR

Invoke the existing git-agent:pr-agent skill. It:

• Pushes the branch (sets upstream if needed)
• Checks for an existing open PR (skips creation if OPEN; creates if MERGED/CLOSED/missing — v3.3.2 fix)
• Generates a Summary/Changes PR body from git log base..HEAD
• Opens the PR via gh pr create

Capture the PR URL from pr-agent's final output — look for the line containing https://github.com/.*/pull/\d+.

---

Step 5: Subscribe to PR Activity (preferred) or Poll CI (fallback)

Parse the PR URL captured in Step 4 into owner, repo, and pullNumber (https://github.com/<owner>/<repo>/pull/<number>).

Preferred: subscribe to PR events

mcp__github__subscribe_pr_activity is a deferred tool available only in remote execution environments (Claude Code on the web, GitHub Actions). Load it with ToolSearch using select:mcp__github__subscribe_pr_activity,mcp__github__unsubscribe_pr_activity.

If the tools load, do the following and then end the turn:

1. Call mcp__github__subscribe_pr_activity with owner, repo, pullNumber.
2. Seed a TodoWrite status checklist: CI green, review comments resolved.
3. Post one status update to the user, e.g.: "Watching PR #<n> — I'll autofix CI failures and respond to review comments as they land, and keep you posted."
4. End your turn. Do not poll, sleep, or run gh pr checks --watch. PR events arrive as <github-webhook-activity> messages that wake the session; handle each per Steps 6–7. After a fix is pushed, the new CI run emits fresh events — never manually re-poll in subscription mode.

Fallback: poll CI

If ToolSearch returns no match for the subscribe tool (a local environment without the GitHub MCP server), poll synchronously instead:

gh pr checks <pr-url> --watch --fail-fast=false
gh pr checks <pr-url> --json name,state,conclusion,workflowName

Parse with jq. If all conclusions are SUCCESS/SKIPPED, go to Step 7. If any is FAILURE, handle it via Step 6 then re-poll (max 3 fix attempts per check). If any is CANCELLED/TIMED_OUT, escalate via AskUserQuestion.

---

Step 6: Handle Each PR Event

Each time a <github-webhook-activity> event arrives (or, in fallback mode, after a poll returns), investigate and act. Refresh the TodoWrite checklist on every event so the thread shows live state, and post a concise status update on each meaningful change (fix pushed, escalation, all-green). Do not narrate routine investigation, and skip duplicate or no-op events silently.

Cap autofix at 3 attempts per failing check (track each check's count in TodoWrite). On the 4th recurrence of the same check, stop fixing it and escalate via AskUserQuestion.

6a: Triage

• A check run / CI job failed → classify and fix (6b).
• A review, review comment, or change request → address (6c).
• All checks green (SUCCESS/SKIPPED) → go to Step 7.
• Informational comment, duplicate, or no action needed → skip silently.

6b: CI failures — classify, then autofix the allow-listed classes

Fetch the failing log:

gh run list --json databaseId,conclusion,workflowName --jq '.[] | select(.conclusion=="failure") | .databaseId' | head -1
gh run view <run-id> --log-failed

Classify on log content:

| Class | Signature in log | Allowed action | |---|---|---| | lint | eslint, lint error, rule violation names | Run the project's lint-fix command | | typecheck | TS, TypeScript, error TS, tsc | Apply minimal TS fixes | | peer-deps | peer dep, ERESOLVE, incompatible peer | Reinstall lockfile | | anything else | any other content | Ask the user — do not guess |

lint: Detect the lint-fix command:

jq -r '.scripts | to_entries[] | select(.key | test("lint")) | "\(.key): \(.value)"' package.json 2>/dev/null

Run the script that includes --fix (or add --fix if the lint script calls eslint directly). If no lint script exists, ask the user.

typecheck: Read the reported errors from the log and apply minimal fixes (add missing imports, use correct existing types). Never introduce any, as unknown, // @ts-ignore, or // @ts-expect-error, and never loosen an existing type. If the fix requires type loosening, ask the user.

peer-deps: Detect the package manager and reinstall:

test -f pnpm-lock.yaml && echo pnpm || test -f yarn.lock && echo yarn || echo npm

Run pnpm install / yarn install / npm install, then confirm the diff is lockfile-only (git diff --name-only). If anything else changed, ask the user.

Outside the allowlist (or attempt cap reached): use AskUserQuestion. Summarize the failing check and the first ~20 lines of its log, and offer options such as "attempt a fix", "skip this check", or "stop watching the PR". Do not guess a fix for an unrecognized failure.

6c: Review comments

If the requested change is clear, safe, and in scope: apply it with Edit, commit via git-agent:commit-agent, git push, then reply to the comment via gh noting the commit that addresses it.

If the comment is ambiguous, architecturally significant, or open to multiple interpretations: use AskUserQuestion with enough context that the user can answer without scrolling back. Do not guess.

6d: Commit and let the next event drive

After any fix: commit via git-agent:commit-agent, then git push. In subscription mode the push triggers a new CI run whose events wake the session again — stop here and wait. In fallback mode, return to the Step 5 poll.

---

Step 7: Green / Done

When all checks are green (all conclusions SUCCESS or SKIPPED):

1. Mark the PR ready if it was opened as draft: gh pr ready <pr-url>.
2. Comment: gh pr comment <pr-url> --body "CI is green — ready for review."
3. Update the TodoWrite checklist and post a final status update to the user with the PR URL.

In fallback (polling) mode, you are done — STOP.

In subscription mode, keep the subscription active so later review comments are still handled per Step 6. Call mcp__github__unsubscribe_pr_activity (with owner, repo, pullNumber) and stop pushing changes only when the PR merges or closes, or when the user asks you to stop watching.

---

Beyond this policy, do not analyze unrelated code, run extra tests, or suggest follow-up tasks. Act only on the PR events you receive.