agent-skills

Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', "상세 설계안 작성해줘", "설계안 다듬어줘", "구현 계획 짜줘", or non-trivial work where jumping to code would lock in the wrong shape.

Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it, and return one synthesized artifact. Use for /arena, 'arena this', "경쟁시켜줘", "여러 안 뽑아서 제일 나은 걸로", "여러 버전 만들어서 비교해줘", or when one attempt at a non-trivial artifact would lock in the wrong shape. For splitting work into slices and returning a report, use swarm.

Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up. Use for 'blast radius of X', 'what could this break', "이거 바꾸면 뭐가 깨져", "영향 범위 봐줘", or reviewing a small diff you don't trust.

Generate a project-local verification skill that drives your app the way a user does — any language, framework, or platform. Use for /create-verification-skill, "make a control skill for this repo", or when a project has no scripted way to prove UI/CLI/service behavior.

Use when working a ticket from the first edit to done — before multi-file work; before opening, updating or merging a PR ("PR 올려줘", "pr 작성까지 진행해줘", "머지해줘", "머지까지 진행해줘", "머지되면 이어서"); before a release that follows the merge ("릴리즈까지 진행해줘"); when answering review comments ("리뷰 코멘트 대응해줘") or getting Codex to cross-check the change ("codex 교차 검증", "적대적 리뷰", "codex 따봉"); when proving it works ("동작확인하고 머지", "동작확인 절차", "내가 확인할 거 있어?"); before declaring a ticket done ("이 티켓 끝내줘", "ship it"); or when stacking or verifying a change on its way to main.

Use when sending work to another repo, or to a side branch of this one, as a new Orca card while this session keeps going — "별도의 세션을 만들어서 ~ 해줘", "별도 세션으로 진행해줘", "현재 세션은 두고 ~", "~ 에 위임하고 너는 X 계속해", "~ repo 에 작업 지시해줘", "dispatch to <repo>". Not "끝났으니 다음" (handoff-ticket), sub-agents, or Codex.

Use when the user asks to end, close or archive this session, card or worktree — "종료해줘", "세션 종료해줘", "현재 세션 정리해줘", "아카이브해줘", "세션을 마무리짓자", "머지하고 종료하자", "티켓 정리하고 종료해줘", "종료해도 될까?", "끝낸 orca 세션·worktree 정리해줘", "end this session" — or when handoff-ticket reaches the point where this session should disappear. Not bare "정리해줘"/"마무리해줘" with no object: that means wrap up the record and keep talking.

Design an auditable playbook before any code when no narrower procedure fits: a large migration, an ambitious multi-part change, or work the human reviews after stepping away. Use for /figure-it-out, 'figure it out', "알아서 설계해서 진행해줘", "큰 마이그레이션", "자리 비운 동안 끝내줘", or when deliver-ticket's Plan finds work of that size. Several tickets run on parallel cards are orchestrate.

Use when handing tickets to fresh Orca worktree cards — "핸드오프", "다음 작업으로 넘어가자", "다음 티켓/작업 진행해줘", "남은 작업 있어?", "진행 가능한 다음 작업", "머지하고 다음 진행해줘", "새 worktree 세션 띄우고 /goal", "handoff" — and the moment this session's ticket is done (every acceptance criterion met) to decide what runs next. "병렬로 진행" belongs here only when it means same-repo ticket cards; check whether the user instead means subagents or work dispatched while this session continues. Not when the target is another repo or this session keeps working (dispatch-card).

Use for "how does X work", "X 는 어떻게 동작해", "이 구조 설명해줘", code walkthroughs before changing something, and placement / ownership / layering questions ("where should this live", "이건 어디에 둬야 해", "which package owns this", "is this the right layer"). Explains subsystem architecture, runtime flow, onboarding mental models. For motivation and history (why it is this way, why it was decided), use why.

Use for "interrogate", "adversarial review", "multi-model review", "codex 교차 검증", "적대적 리뷰", "codex 로 설계안/계획 점검", "문제없는지 codex 에게 리뷰", "challenge this", or "find blind spots" on a design, plan or diff. Multiple LLM reviewers challenge it from independent angles. A PR on its way to main goes through deliver-ticket's Codex review instead.

Periodic pass that keeps a project's verification skill and feature map honest: parallel source readers per feature, one live session driving every feature, at most one PR of proven corrections. Use for /maintain-verification-skill or "audit the verify skill".

Use when asked how a project or autonomous run actually went — "성과 측정", follow-up/derived ticket growth after the initial design, whether the backlog is converging, accepted changes, rework, escaped defects, or token cost per merged PR — and at the Close of an `orchestrate` program.

Use when this session is the top-level orchestrator above every Claude Code and Orca session ("오케스트레이터로", "모든 세션 관리해줘", "전체 태스크 현황", "이 세션도 편입해줘"), or when one session must drive a project or milestone to done through several Orca workers — "PM 겸 오케스트레이터로 끝까지", 3+ tickets in parallel with their PRs landed, follow-up tickets kept from swallowing the plan, a progress dashboard ("대시보드 갱신해줘", "전체 진행상황 몇 퍼센트") — or when taking over ("resume") a program another coordinator ran, or asked why a program's PRs are not moving.

Use when a design, refactor, verification, or delegation decision needs a named engineering principle — sizing a diff, choosing where validation goes, deciding whether work is proven, splitting work across agents, or noticing the same instruction being written a second time.

Use to cut comments in a diff down to what the code cannot say: /prune-comments, a request to clean up or remove comments ("주석 정리해줘"), and deliver-ticket's step before review. Scoped to the diff or the files the caller names; for prose in docs and PR bodies, use write-plainly.

Use when dead sessions may have left resources piling up on this machine — "방치 리소스 정리해줘", "죽은 프로세스 정리", "codex 프로세스 너무 많아", "메모리·CPU 누가 먹고 있어", leftover Codex plugin broker trees, orphaned test processes, dangling Docker volumes and untagged images, merged local branches, stale scratchpad worktrees — and for the resource steward's periodic round. Inventories first (count, RSS, CPU, age per kind), then reaps only the listed targets.

Reconstruct recent working context from past Claude Code sessions, live state, and the shared record (tracker, PRs, worklogs, reported symptoms, reverted fixes), then hand back a tight current-state brief. Use for 'recall my work on X', 'catch me up', "어디까지 했지", "X 작업 어디까지 했더라", "최근 작업 정리해줘", "이번 주에 뭐 했지", before starting or resuming work that earlier sessions touched.

Spawn three parallel review subagents over the active transcript or a finished program, surface learnings, record them in the lessons ledger, and route each to a concrete edit on an existing skill. Use when the user says reflect, "스킬에 반영해줘", "스킬이 왜 안 떴어", "스킬 갱신이 필요해", "이 세션 돌아보고 스킬 개선해줘", "개선 이력 보여줘"; at orchestrate's Close (program mode); and from end-session when the human corrected the work (session mode).

Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why, evidence, result). Local by default; commit it when a reviewer needs the trail to trust the result. Use for /show-me-your-work, autonomous or multi-phase runs, or work a human reviews after stepping away.

Fan out N parallel workers, drain them, and return one report. Use for /swarm, 'swarm this', "병렬로 훑어줘", "나눠서 동시에 확인해줘", or parallel coverage, races to a first result, gauntlets, and exploration. For competing candidates merged into one artifact, use arena.

Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.

Explain a body of work plainly so a person actually understands it, weaving what the how and why skills find into one account at the person's pace. Use for 'teach me this', "이거 제대로 이해하고 싶어", "이 변경 이해시켜줘", "이 구조 설명 좀 해줘, 처음 봐", or explaining a change or subsystem to someone new to it. A single how-it-works question is how; a single why question is why.

Use whenever working docs are read or written — "obs 에 기록해줘", "obs 에 업데이트해줘", "설계안을 obs 에", design docs, worklogs, program notes, research notes, "정본", "worklog", "노트에 적어", a vault path like Project/<name>/*.md, or showing such a doc to the user. Routes to the configured notes store (Obsidian vault or plain Markdown).

Use when doing any ticket operation — reading, listing, searching, filing, labeling, commenting on, relating, or moving tickets, in Linear or Jira — or when a skill or script needs ticket data. Routes the operation through the active tracker adapter and holds the conventions every skill shares (follow-up ticket format, state vocabulary).

Use for why code is the way it is or why something was decided: "why is this like this", "why did we do X", "why was Y picked over Z", "왜 이렇게 됐어", "이거 왜 이렇게 짰어", "이 결정 배경이 뭐야", "왜 이렇게 했지", "이 값은 어디서 나왔어", "히스토리 좀 찾아줘". Also design rationale, the history behind a regression or a revert, incident-driven or defensive code, where a threshold or magic number came from, and recovering the reasons before changing code. For what the code does or how it works, use how.

Use when drafting or revising durable prose: a ticket, PR body, commit message, design doc, note, worklog, standalone report, or skill text; when asked to edit a code comment; or when asked to fix padded, vague, translated, or machine-written prose ("문서 다듬어줘", "문장 다듬어줘", "읽기 쉽게 고쳐줘", "AI 티 안 나게", "번역투 고쳐줘", "unslop", "make this plain", "tighten this up"). Covers Korean and English. Product UI strings follow the product's own copy guidelines.

Use when asked to write, create, or file a ticket or issue ("티켓 만들어줘", "티켓 기표해줘", "Linear 티켓으로 만들어줘", "티켓으로 남겨두고 종료하자", "이슈로 남겨줘") — including a one-line ticket request mixed into another question, feedback on in-flight work that should become its own ticket, and follow-up tickets filed from a finding.