feat(ship): rework /ship as launch task runner - #635
Merged
Conversation
added 5 commits
April 28, 2026 08:04
Transforms /ship from a single-shot readiness reviewer into a stepwise task runner that classifies risk, curates a launch task list, and walks through it one task at a time with user confirmation. - SKILL.md: SCOPE→GATE→CLASSIFY→PLAN→EXECUTE→WRAP phases - references/curation-rules.md (new): low/standard/risky classes and default task sets - references/launch-playbook.md (new): pre-launch checklist, feature flag lifecycle, staged rollout thresholds, rollback template (adapted from addyosmani/agent-skills, MIT) - references/ship-checklist.md: removed (gate-judgment content folded into SKILL.md and curation-rules.md) Validated through 5 RED-GREEN-REFACTOR cycles per superpowers:writing-skills: pressure scenarios for sunk-cost/authority, scope falsification, class-downgrade via task removal, phase backtrack, and abandonment.
baleen37
enabled auto-merge (squash)
April 28, 2026 00:17
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Ship as /ship Skill
participant Classifier as Risk Classifier
participant Planner as Task Planner
participant Executor as Task Executor
User->>Ship: Submit change for shipping
activate Ship
Ship->>Ship: SCOPE: Extract evidence
Note over Ship: Require SCOPE evidence or GATE block
Ship->>Ship: GATE: Check preconditions
alt Evidence missing
Ship-->>User: ❌ Cannot proceed - missing evidence
else Proceed
Ship->>Classifier: CLASSIFY: Analyze risk
Classifier->>Classifier: Determine class (low/standard/risky)
Classifier-->>Ship: Risk classification
Ship->>Planner: PLAN: Generate task checklist
Note over Planner: Use default checklist per risk class
Planner-->>Ship: Task list preview (not created yet)
Ship-->>User: Preview tasks & risk class
User->>User: Review & approve
alt User approves
Ship->>Executor: EXECUTE: Create & run tasks
activate Executor
loop Sequential task execution
Executor->>Executor: Run one task at a time
alt Mid-execution scope change
Executor->>Ship: Pause & backtrack
Ship->>Classifier: Re-classify
Ship->>Executor: Falsify/narrow claims, reopen/augment tasks
Executor->>Executor: Resume execution
else Normal completion
Executor->>Executor: Complete task
end
end
Executor-->>Ship: Execution complete
deactivate Executor
Ship->>Ship: WRAP: Finalize
Ship-->>User: ✅ Launch workflow complete
else User rejects
Ship-->>User: ⛔ Workflow cancelled
end
end
deactivate Ship
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~30 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
plugins/me/skills/ship/references/curation-rules.md (1)
63-91: Add canonical playbook-section mappings for each default task.
plugins/me/skills/ship/SKILL.mdLine 74 requires PLAN previews to include a section reference, but this file only lists task titles. Defining section mappings here will prevent inconsistent task rendering and drift across runs.Suggested structure
### standard (8 tasks) -1. Confirm scope from diff matches user description +1. Confirm scope from diff matches user description (section: N/A - scope validation) ... -8. Deploy to production; monitor watch window for first hour +8. Deploy to production; monitor watch window for first hour (section: Post-launch verification (first hour)) ### risky (full playbook) Use full `launch-playbook.md`. Minimum task set: -3. Pre-launch checklist (security, performance, accessibility, infra) — section by section +3. Pre-launch checklist (security, performance, accessibility, infra) — section: Pre-launch checklist ... -10. Canary 5% with rollout decision thresholds (advance/hold/rollback) +10. Canary 5% with rollout decision thresholds (advance/hold/rollback) — section: Rollout decision thresholds🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@plugins/me/skills/ship/references/curation-rules.md` around lines 63 - 91, Update this curation-rules.md to include explicit canonical playbook section mappings for each default task title under the "standard (8 tasks)" and "risky (full playbook)" blocks so PLAN previews can resolve section references required by plugins/me/skills/ship/SKILL.md; for each numbered task (e.g., "Confirm scope from diff matches user description", "/qa evidence present...", "Identify rollback path...", etc.) add a short canonical mapping like "Task Title → playbook-section: <section-id>" or similar consistent key/value entries adjacent to each task so rendering is deterministic and machine-parsable; ensure mapping keys match the exact task text and include at least one verified section id for each task used by PLAN previews.plugins/me/skills/ship/references/launch-playbook.md (1)
158-163: Avoid prescribing directgit pushin rollback template.This can bypass protected-branch/CI release policies. Prefer a policy-safe instruction (rollback PR or platform rollback mechanism).
Suggested wording update
### Rollback steps 1. Disable feature flag (if applicable) OR -1. Deploy previous version: `git revert <commit> && git push` +1. Revert to previous version using your release workflow (e.g., rollback deploy, or create rollback commit/PR per branch policy) 2. Verify rollback: health check, error monitoring 3. Communicate: notify team🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@plugins/me/skills/ship/references/launch-playbook.md` around lines 158 - 163, The "Rollback steps" section (header "### Rollback steps") currently instructs using a direct command `git revert <commit> && git push`; change this to avoid prescribing direct pushes that can bypass protected-branch/CI rules by instructing a policy-safe rollback path such as "open a rollback PR with the revert commit and follow your repo's review/merge process" or "use your platform's release/rollback mechanism (e.g., deploy rollback in CI/CD or platform console)" instead of `git push`, and update the example line to show creating a branch and opening a PR or invoking the platform rollback command.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@plugins/me/skills/ship/references/curation-rules.md`:
- Line 101: The table header contains the phrase "Rate limiting decision" which
should be hyphenated as a compound adjective; update the table cell text from
"Rate limiting decision" to "Rate-limiting decision" in the row that reads "New
public route/handler | Rate limiting decision" so the table header becomes "New
public route/handler | Rate-limiting decision".
In `@plugins/me/skills/ship/SKILL.md`:
- Around line 28-30: The fenced code block containing the phase sequence "SCOPE
→ GATE → CLASSIFY → PLAN → EXECUTE → WRAP" in SKILL.md lacks a language
identifier; update that fenced block (the triple-backtick block showing the
phase sequence) to include a language token such as "text" (e.g., ```text) so
markdownlint rule MD040 is satisfied.
- Around line 91-110: Clarify that the "call TaskCreate once" rule is the
default at approval but explicitly allow additional TaskCreate calls during
EXECUTE backtrack: when new scope is discovered mid-EXECUTE (the
backtrack/triage flow), pause the current in_progress task (do not
complete/cancel), run the backtrack triage (reclassify completed tasks as
falsified or narrow-but-true, reopen falsified ones, augment narrow ones), then
call TaskCreate to add change-specific follow-up tasks before resuming; continue
to enforce that only one task may be in_progress at a time and that any task
state changes (including batch confirmations) must use TaskUpdate per task.
---
Nitpick comments:
In `@plugins/me/skills/ship/references/curation-rules.md`:
- Around line 63-91: Update this curation-rules.md to include explicit canonical
playbook section mappings for each default task title under the "standard (8
tasks)" and "risky (full playbook)" blocks so PLAN previews can resolve section
references required by plugins/me/skills/ship/SKILL.md; for each numbered task
(e.g., "Confirm scope from diff matches user description", "/qa evidence
present...", "Identify rollback path...", etc.) add a short canonical mapping
like "Task Title → playbook-section: <section-id>" or similar consistent
key/value entries adjacent to each task so rendering is deterministic and
machine-parsable; ensure mapping keys match the exact task text and include at
least one verified section id for each task used by PLAN previews.
In `@plugins/me/skills/ship/references/launch-playbook.md`:
- Around line 158-163: The "Rollback steps" section (header "### Rollback
steps") currently instructs using a direct command `git revert <commit> && git
push`; change this to avoid prescribing direct pushes that can bypass
protected-branch/CI rules by instructing a policy-safe rollback path such as
"open a rollback PR with the revert commit and follow your repo's review/merge
process" or "use your platform's release/rollback mechanism (e.g., deploy
rollback in CI/CD or platform console)" instead of `git push`, and update the
example line to show creating a branch and opening a PR or invoking the platform
rollback command.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9865f8a0-1c83-4353-ab53-529c364f2582
📒 Files selected for processing (4)
plugins/me/skills/ship/SKILL.mdplugins/me/skills/ship/references/curation-rules.mdplugins/me/skills/ship/references/launch-playbook.mdplugins/me/skills/ship/references/ship-checklist.md
💤 Files with no reviewable changes (1)
- plugins/me/skills/ship/references/ship-checklist.md
| | New `migrations/` file | Verify migration is reversible OR document why not | | ||
| | New `process.env.X` reference | Confirm env var set in production | | ||
| | New entry in `package.json` dependencies | `npm audit` shows no high/critical | | ||
| | New public route/handler | Rate limiting decision | |
There was a problem hiding this comment.
Hyphenate the compound adjective for clarity.
Use “Rate-limiting decision” instead of “Rate limiting decision.”
🧰 Tools
🪛 LanguageTool
[uncategorized] ~101-~101: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...critical | | New public route/handler | Rate limiting decision | | Auth/session change | Sess...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@plugins/me/skills/ship/references/curation-rules.md` at line 101, The table
header contains the phrase "Rate limiting decision" which should be hyphenated
as a compound adjective; update the table cell text from "Rate limiting
decision" to "Rate-limiting decision" in the row that reads "New public
route/handler | Rate limiting decision" so the table header becomes "New public
route/handler | Rate-limiting decision".
Comment on lines
+28
to
+30
| ``` | ||
| SCOPE → GATE → CLASSIFY → PLAN → EXECUTE → WRAP | ||
| ``` |
There was a problem hiding this comment.
Add a language identifier to the fenced block (MD040).
The phase-sequence fence should specify a language (e.g., text) to satisfy markdownlint.
Suggested fix
-```
+```text
SCOPE → GATE → CLASSIFY → PLAN → EXECUTE → WRAP</details>
<!-- suggestion_start -->
<details>
<summary>📝 Committable suggestion</summary>
> ‼️ **IMPORTANT**
> Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
```suggestion
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 28-28: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@plugins/me/skills/ship/SKILL.md` around lines 28 - 30, The fenced code block
containing the phase sequence "SCOPE → GATE → CLASSIFY → PLAN → EXECUTE → WRAP"
in SKILL.md lacks a language identifier; update that fenced block (the
triple-backtick block showing the phase sequence) to include a language token
such as "text" (e.g., ```text) so markdownlint rule MD040 is satisfied.
Comment on lines
+91
to
+110
| After approval, call TaskCreate once with all tasks set to `pending`. | ||
|
|
||
| - Pre-launch: pass / weak / fail | ||
| - Rollout: pass / weak / fail | ||
| - Rollback: pass / weak / fail | ||
| - Monitoring: pass / weak / fail | ||
| Then loop: | ||
| 1. Pick the first `pending` task. Set it to `in_progress` via TaskUpdate. | ||
| 2. Show the task content and what evidence/action satisfies it. | ||
| 3. Wait for the user to confirm done OR provide evidence OR say "skip with reason". | ||
| 4. Mark `completed` (or `cancelled` with reason). Move to next. | ||
| 5. If the user reports a blocker, stop the loop and report. Do not auto-mark remaining tasks. | ||
|
|
||
| ### Next actions | ||
| Only one task is `in_progress` at a time. Even when the user batch-confirms ("tasks 1, 2, 3 done"), call TaskUpdate per task, not all at once. The pacing IS the discipline. | ||
|
|
||
| Give the smallest set of actions needed to improve readiness. | ||
| **Handling phase backtrack (mid-EXECUTE scope discovery):** | ||
|
|
||
| ## Red flags | ||
| If the user reveals new scope mid-EXECUTE ("oh wait, there's also a migration"), SCOPE evidence is now stale. Do not silently amend. Triage: | ||
|
|
||
| Do not mark a change as Ready if any of these are true: | ||
| 1. Pause the current `in_progress` task. Do not mark it completed or cancelled yet. | ||
| 2. Re-classify if the new scope changes the class (e.g., schema migration entering the picture). | ||
| 3. Per completed task, decide: *falsified* (claim is now false — e.g., "scope confirmation" against an incomplete diff) or *narrow-but-true* (claim still holds for what was checked, just incomplete coverage). Reopen falsified ones; augment narrow ones with follow-up tasks. | ||
| 4. Add change-specific tasks for the newly discovered scope. | ||
| 5. Resume EXECUTE only after the user confirms the reset shape. |
There was a problem hiding this comment.
Resolve the TaskCreate rule conflict in EXECUTE/backtrack flow.
Line 91 says “call TaskCreate once,” but Line 109 requires adding new tasks after scope expansion. Please define the explicit exception path, or agents may skip necessary task creation during backtrack.
Suggested clarification
### 5. EXECUTE
After approval, call TaskCreate once with all tasks set to `pending`.
@@
4. Add change-specific tasks for the newly discovered scope.
+ - If new tasks are needed, call TaskCreate again for only the newly added tasks, all as `pending`.
+ - Keep existing task IDs/status intact; only reopen falsified tasks via TaskUpdate.
5. Resume EXECUTE only after the user confirms the reset shape.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@plugins/me/skills/ship/SKILL.md` around lines 91 - 110, Clarify that the
"call TaskCreate once" rule is the default at approval but explicitly allow
additional TaskCreate calls during EXECUTE backtrack: when new scope is
discovered mid-EXECUTE (the backtrack/triage flow), pause the current
in_progress task (do not complete/cancel), run the backtrack triage (reclassify
completed tasks as falsified or narrow-but-true, reopen falsified ones, augment
narrow ones), then call TaskCreate to add change-specific follow-up tasks before
resuming; continue to enforce that only one task may be in_progress at a time
and that any task state changes (including batch confirmations) must use
TaskUpdate per task.
baleen-release-app Bot
pushed a commit
that referenced
this pull request
Apr 28, 2026
# [16.17.0](v16.16.0...v16.17.0) (2026-04-28) ### Features * **ship:** rework /ship as launch task runner ([#635](#635)) ([6787edb](6787edb))
This was referenced Apr 28, 2026
baleen37
added a commit
that referenced
this pull request
Apr 28, 2026
#635 reworked /ship into a phased launch task runner (SCOPE → GATE → CLASSIFY → PLAN → EXECUTE → WRAP) backed by curation-rules.md and launch-playbook.md. In practice the task list and per-task confirm loop overweight small changes, the default task set is web/API biased so batch/ETL fixes don't fit cleanly, and PLAN previews force the user to open the playbook to judge each task. Revert ship/ to the readiness-reviewer form at 5003c42 — short Ready / Conditionally ready / Not ready report against four areas (pre-launch, rollout, rollback, monitoring), no task creation, single ship-checklist.md reference. Also drop the references/curation-rules.md and references/launch-playbook.md files and update tests/me/me-specific.bats accordingly. Co-authored-by: Test User <test@example.com>
2 tasks
5 tasks
baleen37
added a commit
that referenced
this pull request
May 1, 2026
* feat(ship): adopt gstack-based ship and add land-and-deploy Split ship lifecycle into two skills along the PR-merge boundary: /ship gates readiness up to merge, /land-and-deploy owns merge through deploy. Preserve gstack core principles (Boil the Lake, idempotent re-run, adaptive gating, scope-drift detection, revert escape hatch) and delegate self-run pieces to /qa, /e2e, /create-pr, /pr-pass, semantic-release. Track progress via TaskCreate; avoid per-task confirm round-trips that sank the #635 launch task runner. Source: https://github.com/garrytan/gstack ship/ and land-and-deploy/ * feat(pickup): add /pickup skill paired with /handoff Reads the most recent handoff file from ~/.claude/handoff/, quotes the Resume Prompt verbatim, surfaces Failed Approaches, and warns on worktree/branch mismatch before continuing. Pair to /handoff so the next session can resume without the user pasting a path. Tested via RED-GREEN-REFACTOR with subagents under pressure scenarios: closed loopholes around auto-picking by topic match, summarizing the Resume Prompt, and nudging the user past worktree mismatch. --------- Co-authored-by: Test User <test@example.com>
This was referenced May 10, 2026
This was referenced Aug 1, 2026
baleen37
added a commit
that referenced
this pull request
Aug 4, 2026
* feat(ship): adopt gstack-based ship and add land-and-deploy Split ship lifecycle into two skills along the PR-merge boundary: /ship gates readiness up to merge, /land-and-deploy owns merge through deploy. Preserve gstack core principles (Boil the Lake, idempotent re-run, adaptive gating, scope-drift detection, revert escape hatch) and delegate self-run pieces to /qa, /e2e, /create-pr, /pr-pass, semantic-release. Track progress via TaskCreate; avoid per-task confirm round-trips that sank the #635 launch task runner. Source: https://github.com/garrytan/gstack ship/ and land-and-deploy/ * feat(pickup): add /pickup skill paired with /handoff Reads the most recent handoff file from ~/.claude/handoff/, quotes the Resume Prompt verbatim, surfaces Failed Approaches, and warns on worktree/branch mismatch before continuing. Pair to /handoff so the next session can resume without the user pasting a path. Tested via RED-GREEN-REFACTOR with subagents under pressure scenarios: closed loopholes around auto-picking by topic match, summarizing the Resume Prompt, and nudging the user past worktree mismatch. * fix(me): make ship follow project release routes --------- Co-authored-by: Test User <test@example.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
/shipfrom single-shot readiness reviewer into a stepwise launch task runnershipping-and-launchcontent as launch playbook referenceChanges
plugins/me/skills/ship/SKILL.md— phased workflow: SCOPE → GATE → CLASSIFY → PLAN → EXECUTE → WRAP. Includes red flags, rationalization table, and explicit rules for SCOPE bypass refusal, PLAN-edit triage, batch-confirm pacing, and phase backtrack handling.plugins/me/skills/ship/references/curation-rules.md(new) — risk class criteria and default task sets per class.plugins/me/skills/ship/references/launch-playbook.md(new) — pre-launch checklist, feature flag lifecycle, staged rollout thresholds, rollback template. Adapted from addyosmani/agent-skills (MIT).plugins/me/skills/ship/references/ship-checklist.md(removed) — gate-judgment content folded into SKILL.md and curation-rules.md.Validation
Followed superpowers:writing-skills RED-GREEN-REFACTOR. 5 cycles with pressure scenarios:
All scenarios verified: no single-shot regression, one-task-at-a-time discipline held, GATE pressure rejection symmetric (sunk cost AND abandonment).
Test plan
bats tests/passespre-commit run --all-filespasses/shipinvocation produces phased walk-through (not single-shot report)Summary by CodeRabbit
Release Notes
New Features
/shipskill now operates as a phased launch task runner with explicit phase control and gating rules.Documentation