to-spec

把当前对话转成 spec 并发布到项目 issue tracker——不做访谈，只综合已经讨论的内容。

Quality

66%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/engineering/to-spec/SKILL.md

Quality

Content

78%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.

This is a well-built instruction-only skill: a tight process, a concrete full spec template with an example, and explicit behavioral boundaries (no interviews, no file paths in decisions, prototype-snippet exception). The only notable gaps are a missing post-publish validation step and the unstated mechanism for actually publishing to the issue tracker. No bundle files exist, and nothing in the body references files that are not present.

Dimension	Reasoning	Score
Conciseness	The body is lean, assumes Claude's competence, and explains no known concepts; the template sections are terse and each earns its place. Not 5 because step 2 repeats the seam-height guidance across three sentences ('优先使用现有 seams… 使用尽可能高层的 seam… 尽可能在最高层提出'), which could be tightened to one.	4 / 5
Actionability	As an instruction-only skill it gives concrete, specific guidance: a complete spec template with a worked user-story example, the exact triage label ('ready-for-agent'), and an explicit user-confirmation step for seams. Not 5 because publishing to the issue tracker has no concrete mechanism and depends on externally-provided vocabulary the skill only points at; not 3 because the core deliverable is fully specified.	4 / 5
Workflow Clarity	The 3-step Process is clearly sequenced (explore repo → draft/confirm seams → write and publish spec) and includes a user-confirmation checkpoint in step 2. Not 5 because there is no validation or feedback step after publishing (e.g., re-checking the spec against the discussion); not 3 because a checkpoint is present and the operation is neither destructive nor batch.	4 / 5
Progressive Disclosure	There are no bundle files and none are referenced, so there are no dangling references; the template is integral to every invocation and belongs inline, and the sections (intro, Process, delimited spec-template) are well-organized. This fits the simple-skill exception: a short skill with no need for external references scores 5 on well-organized sections alone.	5 / 5
	Total	17 / 20 Passed

Description

53%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.

The description communicates a clear, concrete purpose (conversation-to-spec, published to the issue tracker) with a useful behavioral boundary ('no interviews'), and it is appropriately concise. Its main weaknesses are the total absence of any 'when to use' trigger guidance and sparse natural trigger terms, which cap both completeness and trigger quality at the midpoint.

Suggestions

Add an explicit trigger clause, e.g. 'Use when the user asks to turn a discussion into a spec / write a spec from this conversation / create an issue from what we discussed.'

Include natural synonyms and variations users would actually say — 'spec', 'specification', 'requirements doc', 'create an issue' — so trigger matching has more than three keywords to work with.

Mention one or two of the distinctive artifacts the spec contains (numbered user stories, testing decisions, out-of-scope section) to lift specificity from 'domain + 1-2 actions' toward comprehensive coverage.

Dimension	Reasoning	Score
Specificity	Names the domain and 1-2 concrete actions — '转成 spec' (turn into a spec), '发布到项目 issue tracker' (publish to the project issue tracker), '只综合已经讨论的内容' (only synthesize what was discussed) — but coverage is not comprehensive; the spec's actual contents (user stories, seams, testing decisions) and the labeling behavior are not mentioned. This matches anchor 3, not 4, because several specific capabilities from the body are omitted.	3 / 5
Completeness	The 'what' is clear (synthesize the current conversation into a spec and publish it to the issue tracker), but 'when' is completely absent — no 'Use when...' clause or equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. Not 2 because the 'what' half is concrete, not vague.	3 / 5
Trigger Term Quality	Contains some relevant keywords ('spec', '对话/conversation', 'issue tracker') but misses natural trigger phrases, common variations, and synonyms entirely. Anchor 4 requires good keyword coverage with only a few missing terms, which the absence of any 'use when'-style phrasing precludes; it clears anchor 2 because the keywords present are specific rather than generic.	3 / 5
Distinctiveness Conflict Risk	The combination of 'spec from the current conversation' plus 'publish to issue tracker' carves a fairly distinct niche with only minor overlap risk against closely related spec/issue-writing skills. Not 5 because no trigger phrases are given to sharpen the distinction further.	4 / 5
	Total	13 / 20 Passed

Validation

100%

Warnings & errors only

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: vinvcn/mattpocock-skills-zh-CN
Path: skills/engineering/to-spec/SKILL.md
Commit: 3f92a83

Reviewed: 4 days ago

Table of Contents

Discovery Implementation Validation

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.