메뉴
Use whenever a task-notification arrives from a delegate, whenever you're asked "still going?" or "did it finish?", or whenever a dispatched delegate has gone quiet longer than its stated estimate. Classifies every completion signal before anything gets relayed as done.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use at the polish stage of a design direction, once structure is settled, to turn a prototype's own tokens into a small panel of eye-decidable knobs a designer drives by hand, and to route what they settle back into the token system and the taste rules. Emits an altitude-appropriate facet spec, and at polish a self-contained tunable playground. Skip it when the artifact has no eye-tunable surface.
Use when onboarding a new person or a new repo to this pack — constants files don't exist yet, need regenerating, or a repo needs its own landmine list captured. Also use when a standing correction keeps recurring and hasn't been turned into a candidate rule yet.
Use before grounding a design or technical direction in external references — comparing tools, evaluating approaches, gathering prior art — before committing to a direction. Produces a source index, a synthesis, and concrete candidate directions instead of a pile of links.
Use before writing any planning artifact a human has to approve - a spec, an implementation plan, or a long dispatch brief. Gate the full artifact behind a tight stub the human will actually read, get approval on the stub, then elaborate and adversarially review the full thing.
Use when receiving a design or code review to execute, or when writing a review someone else will execute. Splits every review item into one of four buckets before any work starts, so parked items don't get silently rebuilt and outgoing reviews arrive pre-executable.
Use any time more than one lane of work (delegate, agent, or workstream) is active against the same project. Maintains board.json as the single source of truth for lane state — written on every lane transition, not batched — so status reporting, "what's running", handoffs, and kill decisions are all queries against one file instead of reconstructed from memory.
| name | notification-triage |
| description | Use whenever a task-notification arrives from a delegate, whenever you're asked "still going?" or "did it finish?", or whenever a dispatched delegate has gone quiet longer than its stated estimate. Classifies every completion signal before anything gets relayed as done. |
Classify every completion signal into exactly one of four buckets before you relay anything. You are never the pass-through for a delegate's self-report — dispatching work does not transfer responsibility for judging whether it's actually finished.
This triggers on any of: a task-notification arriving from a delegate; being asked whether dispatched work is still going, has finished, or has an update; or a dispatched delegate going quiet for longer than the duration you estimated at dispatch time. If you never stated an estimate, that's a dispatch-brief defect — fix it going forward, but triage the current signal anyway using the four buckets below.
DONE-WITH-EVIDENCE — the report contains what its brief mandated (see the report-format block in a dispatch brief, and the evidence its verification gate requires for that class of work). Relay it as done.
STALLED — the result reads like the delegate is waiting on something that will never arrive: phrasing such as "waiting for my monitor," "will notify me automatically," "waiters are armed," or "background watcher will…" (and close variants of these). No such notification is coming. Do not relay this as done. Resume the delegate immediately with the standard resume message below.
Before calling something STALLED, check whether the quiet item is actually on the never-wait list from repo constants — an expected long-pending check sitting quietly is not a stall, and treating it as one causes you to interrupt a delegate that was behaving correctly.
FAILED — the delegate reports failure. Relay it with the delegate's own evidence attached, never softened, never summarized into something gentler than what actually happened.
SUSPECT — the claims in the report contradict what you can independently verify about the actual state of things, or the evidence its brief mandated is simply missing. Interrogate before relaying: verify the claim yourself, or send it back for the delegate to substantiate. Do not relay a SUSPECT report as done, and do not relay it as failed either — resolve which one it actually is first.
Send this back to a STALLED delegate, adjusted only for the specific check it should re-run:
"Nothing is watching this for you and nothing will notify you automatically — stop waiting. Resume now: run the check yourself in a foreground call with a long timeout, and repeat it until it resolves. Report back only once you're holding the actual result."
If the same delegate stalls a second time after receiving the standard resume message, prose didn't land — switch to explicit foreground-loop syntax instead of another prose instruction. Give it the literal loop construct to run (a while/until shell loop with a real sleep interval and exit condition), not another restatement of "poll synchronously." The second escalation is more concrete than the first, not just repeated louder.
While you are driving a delegate synchronously — actively watching it turn by turn, not fire-and-forget — there is no separate triage step until it hands you a candidate final report; triage applies to the completion signal, not to every intermediate line of output.
An explicit, in-session instruction to relay a report as-is, stated by the person you're reporting to and with the classification skipped on the record, is permitted. An assumption that a report is probably fine because it sounds confident is not — confidence is not one of the four buckets.
