CtrlK
BlogDocsLog inGet started
Tessl Logo

readme

You are an expert technical writer creating comprehensive project documentation. Your goal is to write a README.md that is absurdly thorough—the kind of documentation you wish every project had.

40

Quality

40%

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 ./skills/readme/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

44%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 skill provides a comprehensive and well-structured template for README generation with clear sequencing and actionable guidance, but it is severely over-verbose. It spends hundreds of tokens on generic Rails/deployment templates and examples that Claude could generate from its training knowledge, treating the skill file as a README template rather than a concise set of instructions. The content would benefit enormously from being split into referenced files and trimmed to only include guidance Claude wouldn't already know.

Suggestions

Reduce the skill to ~50-80 lines covering the exploration workflow, section ordering, and key principles—remove all generic template content (Rails commands, deployment platform specifics, test examples) that Claude already knows how to generate.

Extract platform-specific deployment templates, testing framework examples, and troubleshooting patterns into separate bundle files (e.g., DEPLOYMENT_TEMPLATES.md, TESTING_EXAMPLES.md) referenced from the main skill.

Remove the 'Writing Principles' section entirely—instructions like 'use code blocks liberally' and 'be absurdly thorough' are meta-guidance Claude doesn't need, and 'explain the why' contradicts conciseness best practices for skills.

Add a validation step after README generation: verify that referenced files/paths exist in the project, confirm commands are consistent with the detected tech stack, and check that the README renders valid markdown.

DimensionReasoningScore

Conciseness

This skill is extremely verbose at ~500+ lines, extensively explaining concepts Claude already knows (what a README is, how Rails works, what PostgreSQL is, how to clone a repo). It includes massive template sections with generic example content (database schemas, test examples, deployment commands for 6+ platforms) that Claude could generate on its own. The 'Writing Principles' section tells Claude to 'use code blocks liberally' and 'assume fresh machine'—things Claude already understands. Nearly every section could be reduced to a brief structural outline.

1 / 5

Actionability

The skill provides concrete, executable guidance with specific commands, code examples, and structured templates. The step-by-step exploration process (Step 1-3) gives clear instructions on what to examine. However, much of the 'actionability' is in the form of generic Rails/deployment templates rather than skill-specific instructions, and the examples are illustrative rather than truly executable in context.

4 / 5

Workflow Clarity

The workflow is clearly sequenced: explore codebase (Step 1) → identify deployment target (Step 2) → ask only if critical (Step 3) → write sections in order. The exploration phase has clear checkpoints for what to examine. However, there are no explicit validation steps for the output (e.g., verify the README renders correctly, check that all referenced files exist, validate that commands actually work), which is a minor gap for a documentation generation task.

4 / 5

Progressive Disclosure

This is a monolithic wall of content with no bundle files or references to external resources. The massive template sections (architecture, deployment for 6 platforms, testing for multiple frameworks, troubleshooting) should be split into separate reference files. Everything is inlined in a single enormous SKILL.md, making it extremely token-expensive to load for every README generation task.

2 / 5

Total

11

/

20

Passed

Description

36%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 is written in second person ('Your goal') which is inappropriate for a skill description, and it reads more like a system prompt than a skill selector. It lacks concrete actions, a 'Use when...' clause, and sufficient trigger terms to reliably distinguish it from other documentation-related skills.

Suggestions

Add an explicit 'Use when...' clause with trigger terms like 'readme', 'project documentation', 'repo docs', 'README.md', or 'document this project'.

Replace vague qualifiers ('absurdly thorough', 'comprehensive') with concrete actions such as 'generates installation instructions, usage examples, API references, contributing guidelines, and license sections'.

Rewrite in third person voice (e.g., 'Generates comprehensive README.md files for projects, including...' instead of 'You are an expert...').

DimensionReasoningScore

Specificity

Names the domain (README.md / project documentation) and one action (write), but uses vague qualifiers like 'absurdly thorough' and 'comprehensive' rather than listing concrete actions such as generating installation steps, API references, or usage examples.

2 / 5

Completeness

Has a vague 'what' (write a README.md) but no explicit 'when' clause or trigger guidance. The absence of a 'Use when...' clause caps this at 3 per the rubric, and the weak 'what' brings it down to 2.

2 / 5

Trigger Term Quality

Includes 'README.md' and 'project documentation' which are relevant trigger terms users might say, but misses common synonyms and variations like 'docs', 'readme', '.md', 'project setup guide', or 'repo documentation'.

3 / 5

Distinctiveness Conflict Risk

Mentioning 'README.md' specifically provides some distinctiveness from generic documentation skills, but 'comprehensive project documentation' is broad enough to overlap with other documentation or technical writing skills.

3 / 5

Total

10

/

20

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.

Validation9 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (844 lines); consider splitting into references/ and linking

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

9

/

11

Passed

Repository
administrakt0r/AI-Agents-Safe-Coding-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.