CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

writing-beats

Writing, exploit; assemble raw material into a journey of beats, grounding each term before a beat leans on it.

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/writing-beats/SKILL.md

The canonical home for this skill is writing-beats in mattpocock/skills

SKILL.md
Quality
Evals
Security

Quality

Content

92%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 well-crafted instruction-only skill body: it defines a novel methodology in lean, jargon-consistent prose, sequences it as an explicit loop with user-approval gates and preserved user edits, and keeps everything appropriately in one well-organized file. The only blemishes are cosmetic — the "Loop steps 3–5" self-reference and the lack of a worked example of presenting candidate beats.

DimensionReasoningScore

Conciseness

Lean and efficient throughout: the body teaches only skill-specific concepts (beats, grounding, reachability) that Claude does not already know, with no padding and no explanation of general knowledge. Sections like "If a 'beat' needs five paragraphs and three subheadings, it's not a beat; split it" deliver maximum rule per token.

5 / 5

Actionability

Concrete, executable procedural guidance: exact counts ("Write 2–3 candidate starting beats"), explicit behaviors ("write only that beat", "Re-read the article file from disk before every write", "edit in place, leave the rest alone"), and a worked example ("And then nothing happened for three weeks."). Not a 5 because step 5's "Loop steps 3–5" self-references confusingly, and no example shows how to present candidate beats or the running grounded list.

4 / 5

Workflow Clarity

Clear five-step sequence with explicit user-approval checkpoints ("Show the user the beats before writing to the article file. The User picks one") and genuine feedback loops (user edits change downstream beats; rewrite-in-place handling for "go back and try a different beat 3"). The one-beat-at-a-time, always-re-read-from-disk discipline makes file edits safe and recoverable, so the destructive/batch cap does not apply.

5 / 5

Progressive Disclosure

Single-file skill with no bundle files (no references/, scripts/, or assets/ exist) — nothing needs to live in a separate file at this size. The body is well-sectioned (<what-to-do> / <supporting-info> with ## headings) and its one link, [Grounding](#grounding), resolves to the in-file "## Grounding" section, so navigation is one level deep and clean.

5 / 5

Total

19

/

20

Passed

Description

42%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 conveys a distinctive methodology but does so in skill-internal jargon ("exploit", "journey of beats", "grounding") that a user would never say, and it omits any "Use when..." trigger clause. It reads more like a summary for someone who already knows the skill than a discovery description. Note the frontmatter also sets disable-model-invocation: true, so triggering is moot in practice, but the description as written still fails the rubric's what-and-when standard.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user provides a file of raw notes/transcript material and wants it assembled into an article, blog post, or essay."

Replace jargon with plain language: say "turns a pile of raw material into a draft article one section at a time" instead of "exploit" and "journey of beats"; keep "grounding" only if glossed ("introducing each concept before it is used").

Include natural user keywords — "notes", "draft", "outline", "article", "writing", "progressive" — so the description matches phrases users actually say.

DimensionReasoningScore

Specificity

Names the domain (writing) and 1–2 concrete actions — "assemble raw material into a journey of beats", "grounding each term before a beat leans on it" — but the actions are metaphorical and coverage is incomplete. Not a 4 because it lists only two actions wrapped in skill-internal jargon; not a 2 because it goes beyond a bare domain label.

3 / 5

Completeness

The 'what' is discernible (progressively assemble raw material into an article, introducing each concept before it's used), but the 'when' is entirely missing — there is no "Use when..." clause or equivalent, which caps completeness at 3. Not a 2 because the 'what' is more specific than the vague-only anchor.

3 / 5

Trigger Term Quality

Only "Writing" and "raw material" are terms a user would naturally say; "exploit", "beats", and "grounding" are skill jargon, and natural trigger phrases like "turn my notes into an article", "draft", or "outline" are absent. "exploit" is especially misleading, reading as a security term rather than "make full use of".

2 / 5

Distinctiveness Conflict Risk

The beat/grounding methodology is a fairly niche idea, but the broad "Writing" lead-in plus the absence of any explicit triggers means it could overlap with general writing, drafting, or outlining skills. Not a 4 because nothing in the description would prevent collision with those near neighbors.

3 / 5

Total

11

/

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

tonykay/transcriber

Path

.agents/skills/writing-beats/SKILL.md

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.