Ship
Skill sssstwee/tastedistill/plugins/tastedistill-claude/claude-skills/ship
Local-first memory and workflow plugin for AI coding agents: Codex, Claude Code, agent preferences, project lessons, and delivery rules.
npx -y skills add sssstwee/tastedistill --skill shipAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Review implemented work, verify acceptance criteria, prepare delivery, inspect release readiness, handle PR or issue follow-through, and confirm shipped state. Use when work is ready for review, merge, release, publish, push, or handoff. Not for root-cause debugging.
SKILL.md
3.2 KB, as published. Nobody here has run it
Ship: Verify Before Delivery
Use this skill when an artifact exists and needs a delivery decision.
Prefix your first response line with ⚗️ inline, not as its own paragraph.
Before the workflow, apply ../../shared-rules/personalization.md for explicit TasteD/TasteDistill invocations.
Apply ../../shared-rules/runtime-hygiene.md when delivery verification uses helper scripts, browser checks, local servers, screenshots, traces, package artifacts, or other generated outputs.
Outcome Contract
- Outcome: a delivery decision grounded in current evidence.
- Done when: review findings, acceptance state, release state, or blockers are stated with proof.
- Evidence: worktree status, diff, tests, CI, manifests, docs, release artifacts, package contents, and remote state.
Worktree Safety
Before review, release, or destructive repository action:
git status --short --branch -uall
Treat modified, staged, and untracked files as user work. Do not reset, clean, stash, switch branches, or overwrite files unless the user explicitly asks for that operation.
Workflow
- Extract the delivery surface: diff, PR, release candidate, issue queue, package, or generated artifact.
- Read public project context: README, agent instructions, manifests, test config, CI, release docs, and changed files.
- Identify correctness, safety, compatibility, UX, and release risks.
- Run the narrowest meaningful verification first, then broader checks when needed.
- Fix only small, clearly scoped issues when the user authorized implementation.
- For release or publish actions, verify artifact contents and remote state before claiming success.
Coding Guardrails
For review and delivery, apply ../../shared-rules/coding-guardrails.md:
- Think before coding: identify any hidden assumptions in the diff or release path.
- Simplicity first: flag unnecessary abstraction, dependencies, or configuration surface.
- Surgical changes: every changed line should connect to the requested outcome; flag drive-by refactors separately.
- Goal-driven execution: acceptance should be tied to explicit checks, artifacts, or remote state.
CodeGraph
For review and delivery in a Git repository, ../../shared-rules/personalization.md should already have ensured the local CodeGraph index. When codegraph_* tools are available, use codegraph_impact, callers/callees, or trace output as risk evidence for non-trivial diffs, not as a substitute for tests, artifacts, CI, or remote-state checks.
Review Output
Lead with findings ordered by severity. If there are no findings, say so and name remaining test gaps.
Do Not
- Treat source tests as release proof when artifacts or registry state matter.
- Close issues, publish packages, push commits, or tag releases without explicit current-turn authorization.
- Promote project-specific commands into reusable rules.
- Treat a large diff as acceptable when unrelated changes are mixed into the requested work.