ship

What this skill does

# Ship

Commit, push, create a pull request, then auto-register the immediately-actionable test plan checklist items as tasks. Deferred items (`ci`, `post-merge`) are summarized, not tracked.

## Purpose

Extends the standard commit-push-pr workflow with task registration: after PR creation, extract `- [ ]` items from the PR body, classify each by type, and automatically create tasks for the immediately-actionable items with metadata linking back to the PR. Deferred items (`ci`, `post-merge`) are reported in the closing summary only — not tracked as tasks, because linking a task to a later session requires belatedly wiring up `CLAUDE_CODE_TASK_LIST_ID`, which defeats the purpose of leaving only here-and-now work in the task list.

## Workflow

### Phase 1: Commit, Push, PR

Follow the standard commit-push-pr flow:

1. Read current git status, diff, and branch
2. Create a new branch if on main
3. Create a single commit with an appropriate message
4. Push the branch to origin
5. Create a pull request using `gh pr create`

All git operations should be done in a single message with parallel tool calls where possible, exactly as commit-push-pr does.

### Phase 2: Extract Checklist Items

After PR creation:

1. Run `gh pr view --json number,body,url` to read the created PR
2. Parse the PR body for the `## Test plan` section
3. Extract all top-level `- [ ]` (unchecked) items from that section. Ignore indented (nested) checklist items — only lines starting with `- [ ]` at the section's base indentation level.
4. Stop at the "Generated with" footer line or end of body
5. Ignore `- [x]` items (already completed)

**Guard**: If no `## Test plan` section exists or no `- [ ]` items found, inform the user and stop. Do not create tasks.

### Phase 3: Classify Items

Classify each extracted item into one of four types, applying rules in priority order. The type determines the outcome: **immediate** types (`executable`, `manual`) become tracked tasks; **deferred** types (`ci`, `post-merge`) appear in the closing summary only.

**Priority 1 — `executable`**: Item contains a command in backticks that Claude can run.
Detection: backtick-wrapped content matching executable patterns — shell commands (`lua`, `node`, `python`, `grep`, `echo`), slash commands (`/verify`), or CLI invocations.
Outcome: **tracked task** — surfaced in ClaudePanel for execution in the current or a later session.

**Priority 2 — `ci`**: Item depends on CI pipeline results.
Detection: contains "CI", "pipeline", "workflow", "review pass", "GitHub Actions" AND no backtick-wrapped executable command matching Priority 1 patterns.
Outcome: **summary only** — never created as a task. CI results are auto-verifiable via `gh pr checks` / `gh run list`; listed in the closing summary for transparency.

**Priority 3 — `post-merge`**: Item requires merge or a separate session to verify.
Detection: no executable command (Priority 1) AND no CI keywords (Priority 2) AND contains keywords indicating post-merge context — new session, reload, restart, next session, after merge, plugin reload, routing, deploy (in any language matching the PR body).
Outcome: **summary only** — never created as a task. Verifying it would require a separate/later session and after-the-fact `CLAUDE_CODE_TASK_LIST_ID` wiring; listed in the closing summary instead.

**Priority 4 — `manual`** (default): Item requires human interaction or visual confirmation.
Detection: none of the above patterns match. Typically UI checks, visual verification, keyboard interaction.
Outcome: **tracked task** — surfaced in ClaudePanel and actionable in the current session: resolvable by Claude via browser-use / computer-use, or checked off manually by the user.

### Phase 4: Create Tasks & Summarize

For each `executable` and `manual` item, call `TaskCreate`. Creation is automatic — there is no user confirmation step. The classification fully determines the outcome, so no choice needs to be presented. `ci` and `post-merge` items are never created as tasks; they appear in the closing summary only.

| Field | Value |
|-------|-------|
| **subject** | Checklist text (cleaned, without leading `- [ ]`) |
| **description** | `pr: N\ncheckbox_text: [original text]\ntype: [executable|manual]` |
| **metadata** | `{"source": "pr-checklist", "pr": N, "type": "[type]", "checkbox_text": "[text]"}` |

**Ordering and dependencies**:
- Create `executable` tasks first (lowest IDs), then `manual`
- No blockedBy relationships between items (they are independent checklist items)

**Batch creation**: TaskCreate calls for independent tasks can be made in parallel.

**Failure handling**: If any TaskCreate call fails during batch creation, report partial results:
- List successfully registered items with their task IDs
- List failed items with error reason
- Do not silently continue — the user must know which items were not tracked

After task creation, output a summary:
- **Created tasks** — count, with a handling note per type (executable: run now; manual: resolve via browser-use / computer-use, or user check in ClaudePanel)
- **Not tracked** — list the `ci` and `post-merge` items as informational only, with how to verify each (ci: `gh pr checks`; post-merge: re-check in a later session)

## Input

- `$ARGUMENTS`: None expected. The skill reads git state directly.

## Rules

- Always create a PR first, then register tasks. Never create tasks without a successful PR.
- Only `executable` and `manual` items become tasks; `ci` and `post-merge` are summarized, never tracked.
- Task creation is automatic — do not present a confirmation gate. The classification is deterministic, so there is no choice to confirm; if a misclassification surfaces later, the user can adjust the task directly.
- If `gh` CLI is not available, complete the git workflow but skip task registration with a warning.
- Do not modify PR body or add task IDs back to the PR. Tasks reference the PR, not vice versa.
- PR body language follows the repository's conventions (check recent PR history for language preference).