메뉴
Use only as an internal dependency after another workflow has selected an agent-backed step and explicitly routes here for shared runtime gates. Do not use as a user-facing entry workflow.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when non-trivial software engineering or an engineering completion claim involves implementation, debugging, refactoring, migration, architecture, technical planning, code review, material assumptions, scope pressure, or unverified evidence. Skip for trivial mechanical edits and pure factual explanation.
Use only when the user explicitly invokes $agent-debate, or when a loaded workflow routes here, and same-topic shared material needs adversarial product tradeoffs, requirement convergence, scope pruning, or decision clarity. Do not use for lanes, returned-lane review, code review, or single-agent brainstorming.
Use only when the user explicitly invokes $agent-eval, or when an active workflow routes here, to convert locked Spec behavior into acceptance evidence, automated/manual checks, failure conditions, fixtures, risk coverage, and implementation evidence requirements before Plan.
Use when the user explicitly invokes $agent-improve or asks what is worth improving in a codebase or branch and wants a read-only ranked audit. Return source-backed findings and stop. Do not use to review a specific artifact or diff (agent-review), implement a known change (steady-coding), or deliver a chosen finding (dev-flow).
Use only when the user explicitly invokes $agent-plan, or when an active workflow routes here, to convert locked Spec and Eval into implementation tasks, coverage matrix, dependencies, files/interfaces, verification commands, evidence expectations, risks, stop conditions, and lane candidates before execution.
Use only when the user explicitly invokes $agent-review, or when a loaded workflow routes here, for one focused reviewer or multiple agents to review the same artifact: Spec, Eval, plan, design, PR, diff, implementation, evidence package, or final result. Do not use for debate, lanes, or returned-lane integration.
| name | agent-runtime |
| description | Use only as an internal dependency after another workflow has selected an agent-backed step and explicitly routes here for shared runtime gates. Do not use as a user-facing entry workflow. |
Agent Runtime owns the common agent capability layer used by development workflow skills. It decides who may participate, how selected agents are checked, how external/session continuity works, and what can be claimed from agent coverage. It does not decide the product workflow, review topology, lane split, or implementation plan.
AUTHORIZATION, RUNNABILITY, AND SUITABILITY ARE SEPARATE GATES.
Do not collapse "visible", "installed", "authenticated", "authorized", and "suitable" into one vague available/unavailable state. A host-visible subagent surface and a shell agent such as OpenCode are different invocation surfaces.
Use lifecycle owner skills such as dev-flow, agent-review, agent-debate,
agent-lanes, and agent-self-driving to decide why agents are needed. Use
this skill to decide whether the chosen agents/models/tools are approved,
runnable, and recordable.
Classify the selected step before loading gates. Apply the first matching class in this order; classes are exclusive. A stronger boundary always wins over a lighter participant-selection match:
1. external/session:
external, paid, account-bound, editor/protocol, data-leaving, or continuity
for one of those surfaces -> profile + capability/authorization +
lifecycle/session gates
2. profile-governed:
otherwise named/model-selectable participant, requested model/provider
diversity, or a claim dependent on participant/model assignment
-> Agent Model Profile
3. native-default:
otherwise fresh or resumed host-exposed worker with no participant/model
choice or external boundary -> worker lifecycle only; no Agent Model Profile
Never classify an external, paid, account-bound, editor/protocol, or data-leaving
participant as profile-governed merely because it is also named or
model-selectable. Resuming a host-native worker does not by itself make that
worker external/session.
callable alone is not a profile trigger. Separate fresh native-default
sessions may support an independent-session claim, but never an unverified
model/provider-diversity claim.
opencode, or resuming an OpenCode session.Do not use this skill to choose requirements, Spec, Eval, Plan, lane decomposition, review findings, or implementation changes. Agent outputs remain claims until the owning workflow normalizes and verifies them.
Short polling timeouts are runtime state, not failure evidence.
There is no default wall-clock cutoff for a worker. A wait/poll timeout controls
how long the moderator waits for the next update; it does not limit worker
execution. Repeated silent polls do not accumulate into an execution timeout.
Keep the worker running and follow worker-lifecycle.md unless a documented
interruption condition occurs.