菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Diagnose failures, broken behavior, regressions, test failures, runtime errors, stale state, rendering bugs, and repeated failed fixes. Use when something does not work, used to work, crashes, fails tests, or needs root-cause proof. Not for product planning or release readiness.
Define product direction, interaction principles, UI structure, visual execution rules, and screenshot-based polish before or during frontend implementation. Use when the task involves UI, product design, interaction behavior, visual quality, or design-system consistency. Not for backend-only logic.
Extract reusable lessons from completed work, failed attempts, user corrections, logs, diffs, tests, project outcomes, local agent memory, and conversation history, then update durable skills or rules. Use when asked to learn from experience, personalize an agent from prior work, improve skills, refine agent behavior, audit skill health, or turn repeated mistakes into guidance.
Research unfamiliar domains, source materials, repositories, documents, or problem spaces and turn them into structured understanding before planning or implementation. Use when the task asks for deep research, source synthesis, domain learning, evidence mapping, or study notes. Not for one-off link fetching or simple copy editing.
Turn rough ideas, product questions, architecture choices, implementation options, and tradeoffs into decision-ready plans. Use when the user asks what to build, whether an approach is worth it, how to structure a solution, or what plan the agent should execute. Not for debugging an already broken behavior.
Diagnose failures, broken behavior, regressions, test failures, runtime errors, stale state, rendering bugs, and repeated failed fixes. Use when something does not work, used to work, crashes, fails tests, or needs root-cause proof. Not for product planning or release readiness.
| name | tasted-ship |
| description | 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. |
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.
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.
For review and delivery, apply ../../shared-rules/coding-guardrails.md:
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.
Lead with findings ordered by severity. If there are no findings, say so and name remaining test gaps.