메뉴
Use when reviewing any codebase for logic errors, spec compliance, boundary conditions, and test coverage gaps. Universal correctness truths independent of language or framework.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use for any container agent that posts progress to the coordination server's message board. Defines the curl format, channels, message types, payload conventions, posting responsibilities, and verbosity levels.
Use when a review agent must produce structured output. Defines the BLOCKING/NOTE/Summary/Verdict template, the two-tier confidence rubric, and the JSON shadow block consumed by POST /tasks/:id/reviews. Compose with review-process and a domain skill.
Use when an agent evaluates the output of other agents or decides whether work meets the bar. Enforces rigorous quality standards — reject shortcuts, demand evidence, no rubber-stamping.
Use when an agent is the FSM arbitrator on a durable task. Defines the two triggers, the three ruling types, the POST contract, the addendum-file rules for contradiction rulings, and the 409 handling. Project-agnostic.
Tells container agents where the Unreal Engine source tree is mounted inside the container, so they can grep and read engine headers to verify API signatures and class hierarchies.
Use when an agent must review code changes. Defines the universal review sequence — identify files, read context, check against domain criteria, score, filter. Compose with a domain skill and review-output-schema.
| name | general-correctness |
| description | Use when reviewing any codebase for logic errors, spec compliance, boundary conditions, and test coverage gaps. Universal correctness truths independent of language or framework. |
Universal correctness concerns applicable to any codebase. These are truths about software, not about any specific language or framework.
For each requirement in the spec:
The plan defines a non-negotiable behaviour contract: the inputs the code accepts, the outputs it returns, the invariants it maintains, the side effects it performs, the edge cases it handles. The implementation must produce exactly that behaviour. A function that omits an edge case, returns a value the spec does not describe, or skips a side effect is BLOCKING regardless of how clean the code reads.
Code samples in the plan (signatures, type sketches, snippets) are best-effort guidance, not part of the contract. The implementer is allowed — and expected — to adapt sample shapes when they conflict with standing style or best-practice rules in the project's loaded domain skills, provided the adaptation preserves the specified behaviour. Do not flag such adaptations as fidelity deviations. Do flag any change that alters what the code can compute, return, or affect.
When evaluating a deviation:
Watch for language in the implementation, its JSDoc, or its debrief that reframes the behaviour as aspirational:
When any such phrase argues the behaviour has been replaced with a looser invariant, it is BLOCKING. Do not accept the paraphrase as a valid framing, regardless of how internally consistent the alternative invariant sounds. The fix is to restore the literal behaviour, or to escalate the behaviour as undeliverable. See review-output-schema for the finding-resolution protocol.
When a similar phrase explicitly justifies a code-sample adaptation against a named style or best-practice rule (e.g., "Adapted the sample signature to satisfy ; behaviour unchanged: "), it is not a fidelity finding. Verify the behaviour claim against the diff before accepting; if the behaviour is preserved, allow it.
For each changed function:
