shiplisted

Use when completed work is being prepared for merge, release, deployment, rollback, or user-facing handoff. Run a proportional live readiness checklist using the current diff, verification, review, docs, risks, and rollback needs. Do not create a readiness artifact; publishing, deploying, tagging, pushing, or destructive rollback actions always require explicit user approval.
danielleit241/forge · ★ 1 · Code & Development · score 70

Install: claude install-skill danielleit241/forge

# ship Provide a live readiness decision, not another report file. ## Checklist 1. Confirm the diff matches the accepted plan, fix, or stated intent. Use `scout --review` only when the mapping is unclear or stale. 2. Confirm relevant verification is fresh for the current diff. 3. Reuse an existing review; request independent review only when it is absent, stale, high-risk, or explicitly requested. 4. Check required docs, migration/rollback implications, release versioning, and accepted residual risk in proportion to the change. 5. Return a concise verdict: `READY`, `BLOCKED`, or `READY WITH ACCEPTED RISK`, with evidence, blockers, and next action. For release, deployment, tagging, pushing, or rollback, present the exact actions and wait for explicit approval. Do not create `readiness.md` or a standalone ship work item.