메뉴
Output contract for round-1 council reviewer subagents in pr-workflow. The JSON shape of findings, location kinds, thread-relation fields, and the verify_output self-check protocol. Loaded into each reviewer subagent via --skill.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Drive a real browser with the browser_go, browser_see, browser_do and browser_check tools: navigate, read the page as an accessibility outline, query the DOM across frames and shadow roots, inspect one element's box and cascade, run expressions, press keys and gestures, wait for conditions, read console and network telemetry, emulate devices, shape the network, take screenshots, and form verdicts about accessibility, layout, design drift, visual diffs and performance. Use when asked to "open a page", "look at this site", "click the button", "what does the page say", "why is this element red", "check the console", "what requests did it make", "test it on mobile", "is this accessible", "did the layout break", "what changed visually", or any request that involves looking at or operating a web page.
How to audit a web page for accessibility with browser_check and browser_see: the keyboard walk, the axe and structural rule sets, reading order, live region announcements, contrast and target size. Covers what the tools decide, what they deliberately refuse to decide, and how to report findings without overstating them. Use when asked "is this accessible", "check accessibility", "run an a11y audit", "will a screen reader work", "can you use this with a keyboard", "check the contrast", "is this WCAG compliant", or when reviewing a change that touches markup, focus, colour or interaction.
Output contract for round-3 critique reviewer subagents in pr-workflow. The JSON shape of critique entries, position vocabulary, rationale requirements, and the verify_output self-check protocol. Loaded into each critique reviewer subagent via --skill.
Output contract for round-2 judge subagents in pr-workflow. The JSON shape of consolidated findings, attribution fields, the optional self-signal, and the verify_output self-check protocol. Loaded into each judge subagent via --skill.
Output contract for stack-wide judge subagents in pr-workflow. The JSON shape with per-PR and cross-PR findings, attribution fields, optional self-signal, membership rules, and the verify_output self-check protocol. Loaded into each stack-judge subagent via --skill.
Output contract for stack-wide reviewer subagents in pr-workflow. The JSON shape with per-PR and cross-PR findings, perPr key rules, cross-PR span fields, and the verify_output self-check protocol. Loaded into each stack-review reviewer subagent via --skill.
| name | pr-workflow-council-output |
| description | Output contract for round-1 council reviewer subagents in pr-workflow. The JSON shape of findings, location kinds, thread-relation fields, and the verify_output self-check protocol. Loaded into each reviewer subagent via --skill. |
Reply with a single fenced JSON block. No prose outside the
block. If you have nothing to flag, return
{"findings": []}.
{ "findings": [ <Finding>, ... ] }
Each Finding must include:
location — see Location kinds.label — a Conventional Comments label: praise,
nitpick, suggestion, issue, todo, question,
thought, chore or note.subject — a short headline.discussion — concrete prose explaining the concern,
citing the code you saw and the user, backend or
operational impact.Optional decorations:
decorations — free-form short tags
(e.g. "non-blocking", "if-minor").severity — "critical", "medium" or "minor". The
parent process also accepts the common aliases
"required"/"blocking"/"high" (mapped to
"critical") and
"non-blocking"/"nice-to-have"/"info"/"low"
(mapped to "minor"); unknown values are dropped with
a warning rather than rejecting the finding. Use the
canonical set when you can.confidence — a number 0.0 to 1.0.threadRelation — see
Existing review threads."line" — has file, start, end and
side: "old" | "new" | "both". Anchor only to
lines that appear in the PR diff hunks; the prompt
lists the anchorable line ranges per file under
Anchorable line ranges. Each row reads:
path/to/file.ts: new 12-34, 50-78 | old 12-34
The new ... ranges are valid line numbers on the
right side of the diff (added or context lines, set
side: "new"). The old ... ranges are valid on the
left side (removed or context lines, set
side: "old"). Either segment is omitted when that
side has no anchorable lines. The parent process warns
when a line finding falls outside the listed ranges —
the finding survives but will silently degrade to a
body comment unless the user fixes the range. Stale
line numbers and lines outside any hunk are not valid
anchors.
"file" — has file only.
"global" — PR-level finding, no file.
When your finding relates to a [T#] thread surfaced in
the prompt, set threadRelation:
kind: "duplicates-existing" — drop the finding because
[T#] already covers it.kind: "supports-existing" — fresh evidence that
substantiates [T#].kind: "disputes-existing" — fresh evidence that
disproves [T#].kind: "amplifies-existing" — fresh evidence that
accentuates [T#].In each case, include threadIndex (the numeric T index)
and a short rationale. Omit threadRelation, or use
kind: "new", when no existing thread is relevant.
The subagent has access to the verify_output tool from
the pr-workflow-council-verify extension. Before
finishing your run:
verify_output with output set to the object
you intend to emit (pass the object itself, not a
stringified copy).ok: true with the parsed finding
count, or ok: false with a list of
{path, message, hint} errors.verify_output again.ok: true.If the verifier keeps reporting the same error after three attempts, emit your best attempt and the parent will surface the warnings.