CtrlK
BlogDocsLog inGet started
Tessl Logo

technical-articles

Technical articles and blog posts with honest trade-offs. Use when: "write a blog post", "draft an article", "write about this", creating articles in docs/articles/.

59

Quality

74%

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

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/technical-articles/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

A strong, example-driven style guide: nearly every principle comes with quantified constraints and a bad/good pair, which makes it highly actionable despite containing no executable code (appropriate for a writing skill). Its weaknesses are redundancy in the summary lists and a mostly implicit drafting workflow with no validation checkpoint.

Suggestions

Cut the "What Makes Articles Good" and "What Makes Articles Bad" bullet lists or reduce each to only rules not already stated in Rhythm/Constraints/Visual Elements — roughly every item currently duplicates an earlier section.

Add an explicit drafting-order sequence (title → opening → sections with alternating prose/code → closing) with a final self-check step, e.g. 'verify: prose never exceeds 4 sentences without a visual break; ≤2 bullet lists total'.

Move the voice-transcript rules and their long good/bad examples into a references/ file (e.g. references/voice-transcripts.md) and link to it from the body to reduce inline length.

DimensionReasoningScore

Conciseness

The body doesn't pad with concepts Claude already knows, but at ~230 lines it has real redundancy: "What Makes Articles Good" and "What Makes Articles Bad" restate rules already given in Rhythm, Constraints, and Visual Elements ("More than 4-5 sentences of prose without a visual break" and "Max 3-4 sentences of prose before a code block" say the same thing; bullet-list limits appear twice), and "Articles Have Different Shapes" repeats "No rigid template". Fits 'mostly efficient but includes some unnecessary explanation or could be tightened'; not a 2 because there is no filler about what articles/PDFs/libraries are, not a 4 because the good/bad summary lists and the repeated rhythm rule are trimmable.

3 / 5

Actionability

For an instruction-only skill the guidance is maximally concrete: quantified rules ("Max 3-4 sentences of prose before a code block", "core code transformation... in the first ~100 words", "max 1-2 of each per article") and matched bad/good example pairs for nearly every principle (openings, headings, voice, mechanism prose, rhythm). The scoring note says absence of code is not penalized in instruction-only skills when guidance is actionable — these specific examples cover the common cases. Not a 4 because no common case lacks a concrete, imitable example.

5 / 5

Workflow Clarity

The only explicit sequence is the three-step architecture-article composition ("1. Build the private model... 2. Turn that model into a public argument... 3. Use writing-voice"), which is clear but has no checkpoints; the general article-writing workflow (title → opening → sections → closing) must be inferred from the section order. Fits 'steps listed but validation gaps; sequence present but checkpoints missing or implicit'. Not a 4 because there is no explicit validation pass (the closest is the voice-fidelity 'test' question, which is a one-off check in one section), not a 2 because a rough, coherent sequence does exist.

3 / 5

Progressive Disclosure

Structure is good: every section is an argument-styled header, content is grouped logically, and the single external dependency ([writing-voice](../writing-voice/SKILL.md)) is clearly signaled with its scope stated up front and pointed to exactly three times, one level deep. Not a 5 because at ~230 lines some self-contained subsections (e.g. the ~40-line "When the User Gave You the Voice" rules and examples) would slot naturally into a references/ file; not a 3 because nothing that clearly belongs in a separate file is inlined wholesale and navigation is easy.

4 / 5

Total

15

/

20

Passed

Description

70%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 solid description with an explicit, natural-sounding trigger set and a clear niche, weakened only by a vague 'what' that names the artifact rather than the skill's capabilities. Adding one clause enumerating what the skill governs (article shape, openings, pacing, closings) would lift it to the top anchor.

Suggestions

Enumerate concrete capabilities in the description, e.g. 'Structures technical articles: argument-driven headings, insight-first openings, prose/code rhythm, honest trade-offs. Use when...'

Add missing natural trigger variations such as 'publish a blog post', 'blog about', or 'technical writeup' to broaden keyword coverage.

Note the boundary explicitly in the description (voice/punctuation live in writing-voice) so it is distinguishable at trigger time, not only from the body.

DimensionReasoningScore

Specificity

"Technical articles and blog posts with honest trade-offs" names the domain and one characteristic, but lists no concrete capabilities (structure, openings, pacing, drafting from transcripts) — the skill's actual scope only becomes clear in the body. Fits the 'names domain and 1-2 concrete actions, but not comprehensive' anchor; not a 2 because 'writing articles with honest trade-offs' is more informative than 'Processes PDF files', not a 4 because no several specific actions are enumerated.

3 / 5

Completeness

Both parts are present: the 'what' ("Technical articles and blog posts with honest trade-offs") and an explicit 'Use when' clause with concrete trigger phrases and a target directory. Not a 5 because the 'what' is thin — it describes the artifact, not what the skill does with it (shape, structure, voice preservation); not a 3 because the 'when' is fully explicit, not merely implied.

4 / 5

Trigger Term Quality

Triggers "write a blog post", "draft an article", "write about this", "creating articles in docs/articles/" are natural phrases a user would actually say, plus a concrete path. Not a 5 because common variations like "publish a post", "blog about", "technical writing", or "article" (bare) are missing; not a 3 because coverage is well beyond 'some relevant keywords'.

4 / 5

Distinctiveness Conflict Risk

The article/blog-writing niche is clearly distinct with its own trigger phrases, and it explicitly delegates voice/punctuation to a separate writing-voice skill, which reduces overlap. Not a 5 because triggers like "write about this" are broad enough to potentially fire for general writing tasks; not a 3 because the domain framing and the writing-voice boundary make conflicts unlikely.

4 / 5

Total

15

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 4 suspicious

Warning

Total

15

/

16

Passed

Repository
EpicenterHQ/epicenter
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.