embodiment-description
Write detailed embodiment descriptions for patent specifications. Use when user says "撰写实施例", "write embodiment", "实施例描述", "detailed description", or wants to describe how to practice an invention.
85
83%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid skill description with excellent trigger term coverage in both Chinese and English, a clear 'Use when' clause, and a well-defined niche in patent writing. Its main weakness is that the 'what' portion could be more specific about the concrete actions involved beyond just 'write detailed embodiment descriptions'—for example, mentioning structuring technical details, referencing drawings, or covering alternative implementations.
Suggestions
Expand the capability description to list more specific actions, e.g., 'Write detailed embodiment descriptions for patent specifications, including structuring technical implementations, referencing drawings, and covering alternative embodiments.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (patent specifications) and one action (write detailed embodiment descriptions), but does not list multiple concrete actions like drafting claims, adding figures references, or structuring sub-embodiments. | 2 / 3 |
Completeness | Clearly answers both 'what' (write detailed embodiment descriptions for patent specifications) and 'when' (explicit 'Use when' clause with specific trigger phrases and a conceptual trigger scenario). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms in both Chinese and English: '撰写实施例', 'write embodiment', '实施例描述', 'detailed description', and the conceptual trigger 'describe how to practice an invention'. Good coverage of bilingual user queries. | 3 / 3 |
Distinctiveness Conflict Risk | The combination of patent-specific terminology ('embodiment descriptions', 'patent specifications') and bilingual Chinese/English trigger terms creates a very distinct niche that is unlikely to conflict with other skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, domain-specific skill that provides actionable patent embodiment writing guidance with clear workflow steps and validation checkpoints. Its main strengths are the concrete examples (correct vs. incorrect language), structured verification tables, and critical rules that encode specialized patent drafting knowledge. Minor weaknesses include some verbosity in the repeated warnings about experimental data and the monolithic structure that could benefit from splitting into referenced files for advanced topics.
Suggestions
Consolidate the multiple 'no experimental data' warnings and examples into a single concise 'Critical Constraints' section to reduce redundancy and improve token efficiency.
Consider splitting the reference numeral formatting rules and software/algorithm embodiment guidance into separate referenced files to improve progressive disclosure for this longer skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient and contains domain-specific knowledge Claude wouldn't inherently know (patent embodiment writing conventions, reference numeral formatting, US best mode requirement). However, some sections are somewhat verbose — the repeated emphasis on 'no experimental data' with multiple examples could be consolidated, and the explanatory framing ('they are the patent equivalent of experiment sections') adds minor padding. | 2 / 3 |
Actionability | The skill provides highly concrete, actionable guidance: specific formatting rules for reference numerals (first mention vs. subsequent), exact output file paths, table templates for planning and verification, example text patterns for opening paragraphs and variations, and clear examples of correct vs. incorrect embodiment language. The pseudocode example and claim support verification table are copy-paste ready templates. | 3 / 3 |
Workflow Clarity | The 6-step workflow is clearly sequenced with logical progression: plan → write → integrate numerals → verify claim support → handle special cases → output. Step 4 serves as an explicit validation checkpoint with a verification table, and includes a feedback loop ('If any claim element lacks embodiment support, add the necessary description'). This is well-structured for a multi-step document generation process. | 3 / 3 |
Progressive Disclosure | The skill references input files (patent/INVENTION_DISCLOSURE.md, patent/CLAIMS.md, patent/figures/numeral_index.md) and output paths clearly, but all content is inline in a single file. Given the length (~100+ lines) and complexity, some content like the detailed reference numeral formatting rules or the software/algorithm embodiment section could be split into referenced files. However, no bundle files exist to support this, and the organization with clear headers is reasonable. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Commit
2028ac4
- 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.