菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | desk-research |
| description | 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. |
Reading around a topic and producing a decision are different activities. This skill turns a research pass into three artifacts a decision-maker can actually use: an index of what was found, a synthesis of what it means, and a short list of candidate directions with their tradeoffs made explicit. It also protects against the two most common research failures: citing something nobody actually verified, and re-discovering something the project already decided.
One entry per reference consulted: its source, the specific surface of it that was examined (a page, a section, a release note — not "the whole site"), and the one transferable thing this project can actually take from it. Not a general summary of the source — the specific takeaway.
One entry per research question: what the sources agree on (the consensus), any source that says the opposite (a named outlier — don't quietly average it into the consensus), and any example that superficially resembles the pattern but isn't actually one (a counter-example, flagged explicitly so it doesn't get miscopied later as supporting evidence).
Each candidate direction states all of:
For each candidate direction that has an eye-tunable, token-bound surface at the current altitude, produce a tuning panel per the tuning-playground skill: a facet spec at wireframe altitude or higher, and a live playground at polish. Skip the panel, out loud, for any direction whose open questions are structure, flow, or copy rather than eye-decidable tokens. The panel is never required — it is offered when the direction has a last mile a designer would tune by hand, and omitted otherwise.
When a person needs to view the index, synthesis, or candidate directions somewhere other than this conversation, publish them via the channel named in personal constants (publishing, or a tool_mapping entry's publishing override for the active context) — never a specific tool named in this skill's own text. When no channel is configured, or the configured one fails, fall back to a local file with its full path printed; that floor needs no setup and is always available.
Before treating any external finding as a reason to change direction, check whether the project's own spec, design doc, or a prior recorded decision already covers it. Present "the spec already answers this" findings first and separately from genuinely new external findings. A not-required-after-all discovery buried inside a pile of new research wastes the reader's time re-deciding something already settled.
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 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.
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.
