CtrlK
BlogDocsLog inGet started
Tessl Logo

brainstorming

Explore user intent, requirements, and design options through collaborative dialogue before implementation. Use before building new features, components, or systems — whenever the user describes something to build and design decisions are involved. Triggers: "brainstorm", "help me design", "think through the requirements", "头脑风暴", "设计方案", "梳理需求". Not for bug fixes, config changes, or tasks with an obvious implementation path.

64

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

70%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The workflow is exemplary — ordered checklist, flowchart, hard gate, self-review, and user-approval loops at every stage — and the prose is largely actionable. The two real weaknesses are broken progressive disclosure (two referenced files missing from the bundle, five existing scripts never referenced by path) and moderate redundancy, with the checklist, detailed-process, and core-principles sections repeating each other and one section re-teaching design concepts Claude already knows.

Suggestions

progressive_disclosure: add the missing referenced files (`spec-document-reviewer-prompt.md` and `visual-companion.md`) to the skill directory, or remove/inline the references — as written, both instructions dead-end.

progressive_disclosure: reference the existing bundle scripts by path where they are used (e.g. "用 `scripts/start-server.sh --open` 启动服务器"), so the visual-companion tooling in `scripts/` is discoverable from the body.

conciseness: collapse the triple repetition of the dialogue rules (检查清单 / 流程详解 / 核心原则) into the checklist plus one-line principles, and trim the "为隔离和清晰而设计" and "在已有代码库中工作" sections, which re-explain design concepts Claude already knows.

DimensionReasoningScore

Conciseness

The body is mostly lean procedural instruction, but there is measurable redundancy and padding: the "检查清单" nine steps are restated nearly verbatim in "流程详解" and again condensed in "核心原则" ("每次只问一个问题" appears three times), and the "为隔离和清晰而设计" section explains concepts Claude already knows ("对能在上下文中完整容纳的代码,推理更准确,编辑更可靠") and a whole "在已有代码库中工作" section on following existing patterns. Not a 4 because the duplication and concept re-teaching go beyond "minor instances that could be trimmed"; not a 2 because there is no padded tutorial-style explanation of basics and the core dialogue procedure is tight.

3 / 5

Actionability

The guidance is mostly directly executable: an ordered checklist, the exact spec path `docs/specs/YYYY-MM-DD-<主题>-design.md`, a copy-paste message to the user ("规格已编写并提交到 `<路径>`..."), a just-in-time offer script for the visual companion, and the `--open` flag for the server. Not a 5 because two referenced files — `spec-document-reviewer-prompt.md` and `visual-companion.md` — do not exist in the bundle, so the instruction to read them cannot be followed, and the `--open` instruction never names the actual script path (`scripts/start-server.sh`) that implements it. Not a 3 because the prose instructions themselves are concrete and specific, not pseudocode or vague direction.

4 / 5

Workflow Clarity

The sequence is explicit and fully checkpointed: a numbered 9-step checklist in order ("探索项目上下文 → ... → 过渡到实现"), an ASCII flowchart with decision branches ("用户认可设计? —[否,修改]→ 返回呈现设计"), a HARD-GATE preventing implementation before approval, a dedicated spec self-review with four concrete checks (占位符/一致性/范围/歧义), and a user review gate with an exact message and explicit retry loop. Error-recovery feedback loops are present at every stage.

5 / 5

Progressive Disclosure

The body is well-sectioned and nominally defers detail to one-level-deep files ("可以参考 `spec-document-reviewer-prompt.md`(在本 skill 目录中)派遣 subagent", "阅读详细指南:`visual-companion.md`(在本 skill 目录中)"), but neither file exists in the bundle — the only bundle files are five scripts under `scripts/` that the body never references by path (the visual-companion server scripts are used only via an unnamed `--open` flag). Scored against the actual bundle structure, navigation to the referenced detail is broken. Not a 4 because the referenced paths resolve to nothing and the existing scripts are undiscoverable from the body; not a 2 because the structure and reference signals themselves are clear and the body is not an inlined wall of text.

3 / 5

Total

15

/

20

Passed

Description

83%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: it explicitly states what the skill does and when to use it, provides natural trigger phrases in two languages, and includes an explicit exclusion clause that reduces conflict risk. The main gap is that it omits the skill's concrete deliverables (design proposals, a committed spec document), which slightly under-sells what the skill does.

DimensionReasoningScore

Specificity

"Explore user intent, requirements, and design options through collaborative dialogue before implementation" lists several concrete, specific actions (explore intent, requirements, design options) with precise scoping ("Not for bug fixes, config changes, or tasks with an obvious implementation path"). Not a 5 because it never states the skill's concrete outputs — producing 2-3 proposals, a design document, a spec file — so coverage of what the skill actually does has minor gaps; not a 3 because the actions named are distinct and concrete rather than the 1-2 generic actions of the anchor-3 example.

4 / 5

Completeness

Both questions are answered explicitly and concretely: what — "Explore user intent, requirements, and design options through collaborative dialogue before implementation"; when — "Use before building new features, components, or systems — whenever the user describes something to build and design decisions are involved", reinforced by explicit trigger phrases and an exclusion clause. Voice is third person ("Explore", "Use"), and no aspect of what/when is left implicit.

5 / 5

Trigger Term Quality

"Triggers: \"brainstorm\", \"help me design\", \"think through the requirements\", \"头脑风暴\", \"设计方案\", \"梳理需求\"" are natural phrases a user would actually say, in both English and Chinese. Not a 5 because common variations like "design", "spec", "requirements", "plan this feature", or "explore options" are missing; not a 3 because the terms present go well beyond bare domain labels and include genuine user phrasings.

4 / 5

Distinctiveness Conflict Risk

The pre-implementation design niche is fairly distinct, and "Not for bug fixes, config changes, or tasks with an obvious implementation path" explicitly fences off overlapping territories. Not a 5 because phrases like "building new features" and "design decisions are involved" still leave moderate overlap risk with general planning, architecture, or spec-writing skills that would trigger on similar requests.

4 / 5

Total

17

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
feiskyer/claude-code-settings
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.