菜单
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.
用 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 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.
Use when declaring any work item done, or when writing the report/evidence block of a dispatch brief. Defines the gate list — the specific evidence required before something counts as done — per class of work, plus universal rules that apply to every class.
| name | feedback-triage |
| description | 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. |
A review arrives as a flat list of comments. Treating every comment as "go fix it" burns time on decisions nobody has actually made yet, and it silently re-opens scope that was deliberately parked. This skill sorts every review item into a bucket before any work begins — whether the review is coming in or going out — and makes sure the reasoning behind a "not now" survives long enough to matter.
Every review item gets exactly one, no exceptions:
A scope guard is a short, quotable sentence written at triage time: "do not restyle X until Y is decided." Every parked item gets one. The guard is not reconstructed later from memory — it is copied verbatim into any dispatch brief for work touching the same area, so a delegate working nearby sees the guard directly instead of rediscovering, the hard way, why that area is off-limits.
When writing a review for someone else to execute, sort your own comments into the same four buckets before sending. A review that arrives pre-bucketed is pre-executable: the recipient doesn't have to re-triage your comments from scratch, and a needs-decision item is visibly flagged as a question rather than disguised as an instruction to just go build it.
A bucket assignment is not permanent. When new information supersedes an earlier call — research answers a needs-decision item, a parked item's blocking decision finally lands, a fix-now turns out to hide a real decision — send an explicit descope or rescope message to every lane whose work depends on the old bucket, immediately, not folded into the next routine status update. Silence at this moment is how a lane burns real time building against a bucket assignment that no longer holds.
tool_mapping, never whichever tracker CLI happens to already be open. A follow-up filed in the wrong tracker looks done from here and is invisible to whoever actually owns the right one.publishing, or a tool_mapping entry's override for the active context), falling back to a local file with its path printed when none is configured — never a specific tool named in this skill's own text.Some reviewer objections are predictable and already have a pre-authorized answer on file — for example, an automated reviewer flags a breaking change as risky on a project whose standing policy is to roll forward without a compatibility shim. Before triaging a repeat or automated reviewer's comment into needs-decision, check the project's standing-responses list (kept with its other standing corrections, in the project's own constants). If the objection matches an entry there, the right bucket is fix-now-with-a-reasoned-reply: post the standing response with its reasoning attached. Don't silently comply against standing policy just because a reviewer asked, and don't silently dismiss the comment either — the response goes on the record either way. Only genuinely new objections go to needs-decision.
tool_mapping