CtrlK
BlogDocsLog inGet started
Tessl Logo

tlc-plan

Turns decided work — a PRD, design doc, RFC, or thread — into tasks a builder can act on without guessing. Finds slices that each prove something, grounds them in the code, and writes intent, observable criteria with concrete values, the boundary, what the change disturbs, and only the decisions that are hard to reverse. Walks every surface the work exposes and sweeps the nine unwritten requirements, recording each landing as a criterion already in the source, existing behaviour, n/a, or Unresolved — never as a criterion the walk invented. Defaults to one task per source. Use when the user says "write the task", "cut this PRD into tasks", "turn this design doc into work", or "tlc-plan". Do NOT use for discovery itself or to implement — a one-line ticket is a decision; a blank wish is not.

67

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./packages/skills-catalog/skills/(development)/tlc-plan/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%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-structured instruction-only skill with a clear phase sequence, fixed walkable checklists, and a properly signaled single reference file. Its main weakness is token economy: dense rhetorical prose and repeated statements of the same rules across four sections inflate the body well beyond what the methodology requires.

Suggestions

Tighten the prose: cut the rhetorical justifications and state each rule once — the refuse-rather-than-guess rule currently appears in four places (Critical rules, Walk the surfaces, Sweep, and its own section).

Move the question-asking etiquette and the Common failures catalogue into a reference file, keeping SKILL.md as a lean overview of the Cut → Ground → Walk → Sweep → Write flow.

Add an explicit final verification step after writing the artifact — re-read the task and confirm every surface item and all nine sweep dimensions have a recorded landing — to close the workflow's validation loop.

DimensionReasoningScore

Conciseness

The body is ~186 lines of dense prose. It never explains concepts Claude already knows, but it is heavily padded with rhetorical justification ('A round number the skill suggests is an opinion dressed as arithmetic', 'The default buys something real, too') and the refuse-rather-than-guess rule is restated across Cut, Walk the surfaces, Sweep, its own section, and Common failures. Not 2: the content is genuinely novel methodology rather than unnecessary explanation of known things; not 4: noticeable trimming of the persuasive asides and repetition is possible without losing clarity.

3 / 5

Actionability

Concrete, executable guidance for an instruction-only skill: fixed walkable lists (the five-row surface table, the nine named sweep dimensions), a controlled landing vocabulary ('a criterion already in the source, existing behaviour, n/a, or Unresolved'), a five-item criterion gate, and a worked split example (the p95 percentile line split into criterion plus observability target). Not 5: no complete worked example of the output artifact inline — the format is delegated to references/document-format.md — so the common case is covered by reference rather than by a copy-paste-ready model.

4 / 5

Workflow Clarity

The sequence is explicit and well-marked: Cut → Ground → Walk the surfaces → Sweep → the refuse-rather-than-guess gate → Format → Output, reinforced by the ASCII diagram and numbered Examples. Checkpoints exist inside the flow (the five-question gate before writing any criterion, mandatory recorded landings for every surface item and all nine dimensions). Not 5: there is no explicit post-write verification of the artifact — e.g. a final step re-reading the task to confirm every landing is filled — the sweep's recording mechanism implies it but never states it.

4 / 5

Progressive Disclosure

One reference, references/document-format.md, exists and is well-signaled with explicit load timing ('Read references/document-format.md when you write the .tasks/<name>.md artifact — after the cut, the grounding, the surface walk, and the sweep. Do not load it during Cut.') and a one-level-deep structure. Not 5: the SKILL.md body itself is long and monolithic — material such as the question-shaping etiquette and the Common failures catalogue arguably belongs in a second reference file, keeping the overview lean.

4 / 5

Total

15

/

20

Passed

Description

92%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: concrete third-person capabilities, an explicit trigger clause with natural quoted phrases, and explicit negative boundaries that separate it from discovery and implementation. The only gap is a handful of natural trigger synonyms (spec, ticket, break down) that would push trigger coverage from good to comprehensive.

DimensionReasoningScore

Specificity

The description lists many concrete, third-person actions — 'Finds slices that each prove something, grounds them in the code', 'writes intent, observable criteria with concrete values, the boundary, what the change disturbs', 'Walks every surface the work exposes and sweeps the nine unwritten requirements' — with comprehensive coverage of the skill's behavior. Not 4: coverage is comprehensive rather than having minor gaps; not below because nothing here is vague filler.

5 / 5

Completeness

Both questions are answered explicitly: a detailed 'what' up front, then 'Use when the user says "write the task", "cut this PRD into tasks", "turn this design doc into work", or "tlc-plan"' — plus an explicit negative boundary ('Do NOT use for discovery itself or to implement'). Clearly matches the anchor-5 example structure.

5 / 5

Trigger Term Quality

Quoted natural trigger phrases are strong ('"write the task"', '"cut this PRD into tasks"', '"turn this design doc into work"') and source-document synonyms are covered (PRD, design doc, RFC, thread). Not 5: a few natural variations users would say are missing ('spec', 'ticket', 'break down into tasks'), and the anchor-5 pattern of exhaustive synonym coverage is not fully met.

4 / 5

Distinctiveness Conflict Risk

It carves a clear niche (decomposing decided work into verifiable tasks) and explicitly distinguishes itself from adjacent skills: 'Do NOT use for discovery itself or to implement — a one-line ticket is a decision; a blank wish is not.' Minimal conflict risk; the named sibling (tlc-implement) is fenced off.

5 / 5

Total

19

/

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
tech-leads-club/agent-skills
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.