协作头脑风暴
brainstorming
在实现前澄清需求、探索设计选择,并形成清晰的开发方向。
writing-great-skills【开发与工程】Author a high-quality Agent Skill (SKILL.md) that an AI reliably triggers and executes well — strong frontmatter, a sharp description with trigger phrases, a clear output contract, quality checks, and anti-patterns. Use when asked to write a skill, create a SKILL.md, improve a skill, review a skill for quality, or contribute to a skills library. Prod…
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
A skill is a promise: given this kind of request, produce this kind of professional output, every time. The best SKILL.md files win on two things — the model triggers them at the right moment, and once triggered it produces the right artifact without hand-holding. This skill helps you write one that does both.
Given a rough idea ("a skill for writing changelogs"), produce the full SKILL.md anyway — infer the deliverable, inputs, and structure, and mark genuinely open choices. Never hand back a skeleton with <!-- TODO --> left in; fill them.
Ask for (if not already provided), else infer and label:
---
name: kebab-case-name # matches the folder; short, specific
description: "<one rich sentence>"
---
The description is the most important line in the file — it's all the model sees when deciding whether to load the skill (progressive disclosure: only names + descriptions are in context until one is invoked). A strong description has three parts:
Write triggers the way users speak, not the way you'd categorise the skill. Cover synonyms.
Open the body with a single sentence on the value, in the voice of a senior practitioner.
State that the skill delivers a complete artifact even with thin input — infer and label assumptions, never leave bracketed placeholders, never refuse for missing context. This is what separates a skill that works from one that nags.
A short list of what to ask for — and an instruction to proceed with labelled inferences if they're missing.
The heart of the skill: a concrete template — real headings, tables, and sections — of the final artifact. Show the shape, don't describe it abstractly. This is where most of the quality lives.
A short checklist the output must satisfy (the rubric a reviewer would apply). Make them observable.
The specific failure modes to avoid — the lazy or generic outputs a weaker model would produce.
npm run skillcheck (structure) and run it against a thin brief to confirm it doesn't beg for inputs.Return:
skills/<name>/SKILL.md.This skill ships with support files — use them when they are available:
references/description-engineering.md — Description Engineering: the 300 Characters That Decide Everything. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.templates/skill-scaffold.md — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.Score any output of this skill before handing it over; 32+ is ship-quality.
| Dimension | 0 | 5 | 10 |
|---|---|---|---|
| Description & trigger engineering | Description says what the skill is about, with no trigger phrases or named deliverable | Has "Use when…" and "Produces…", but triggers are category labels, not phrasings users actually type | All three parts present; triggers cover the real synonyms users would say, and are distinct enough that the model wouldn't confuse this skill with a neighbour |
| Output contract concreteness | Output Format describes the artifact ("a structured report with sections") | A partial template — some real headings, but key sections still described abstractly | A full template with real headings, tables, and field formats — two independent runs would produce recognisably the same product |
| Guardrail specificity | Quality checks are unobservable ("output should be clear"); anti-patterns missing or generic | Checks are observable but generic to any document; anti-patterns don't name this skill's failure modes | Every check is verifiable at a glance, and each anti-pattern names a specific lazy output a weaker model would actually produce for this artifact |
| Thin-brief resilience | The skill begs for inputs or would return a skeleton full of [placeholders] | Working-from-a-brief section exists, but there's no instruction to label inferences, so gaps get silently invented | Explicitly instructs: build the complete artifact anyway, infer and label assumptions, never leave TODOs — and the inputs list says what to ask for only when it changes the output |
name is kebab-case and matches the intended folderTODO/placeholder text left innpm run skillcheck with no errors<!-- TODO --> or [bracketed] placeholders in the final file