메뉴
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.
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.
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.
| name | 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.