CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

plain-english

Translates technical content into plain English for non-technical stakeholders by converting jargon into business language, surfacing decisions and impact early, and producing actionable recommendations with clear ownership and timeline. Use when the user asks to simplify technical content, write an executive summary, explain something in layman's terms, rewrite for non-technical audiences, or translate jargon for management or stakeholders. Applies to document types such as technical reports, architecture decision records, incident summaries, risk assessments, and status updates. Distinct from general writing or documentation skills by its focus on audience identification, decision-first structure, and jargon elimination for non-technical readers.

Quality

97%

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

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-structured instruction-only skill: the decision-first framework, BAD/GOOD examples, action template, and verification checklist make it directly actionable, and the bundle is cleanly organized with all five reference files real and one level deep. The only weakness is minor verbatim duplication between the Constraints hard rules / fallback table and the Anti-Patterns entries.

Suggestions

Remove the duplicated fallback prefix from Step 1 (or from the Constraints fallback table) and let the single occurrence plus the pointer to references/constraints-and-fallbacks.md carry it.

Drop the Fix column's restated ALWAYS/NEVER rules in the Anti-Patterns table (AP-2, AP-3, AP-5, AP-6 duplicate the Constraints hard rules verbatim) and reference the constraint instead, keeping the table focused on the failure-mode descriptions.

State what to do when a Step 5 checklist item fails (e.g., 'fix and re-run the checklist before delivering') to close the loop from verification back to drafting.

DimensionReasoningScore

Conciseness

The body is lean and skill-specific (mindset framing, decision framework, BAD/GOOD contrasts, checklist) with no filler explaining concepts Claude already knows. Not 5: there is verbatim duplication — the fallback prefix "Audience: unknown. Applying manager-level clarity (fallback)" appears in both Step 1 and the Constraints fallback table, and the Constraints hard rules ("ALWAYS lead with key message", "NEVER leave deadlines undefined") are restated nearly verbatim as AP-2/AP-6 fixes in the Anti-Patterns table.

4 / 5

Actionability

Fully executable, instruction-only guidance: a copy-paste-ready command (`grep -oE '\b[A-Z]{2,}\b' file.md | sort -u`), a concrete action template "[Owner] must [specific action] by [concrete deadline]", paired BAD/GOOD examples covering the common cases, and a verification checklist. Not 4: no missing key details for an instruction-only skill.

5 / 5

Workflow Clarity

Five clearly sequenced steps (identify audience → define outcome → draft key message → add supporting context → verify) with explicit validation via the Step 5 checklist ("Every acronym defined on first use", "Opening paragraph contains the key decision or recommendation"). Not 4: validation is an explicit checkpoint, not implicit; not lower because this is a non-destructive writing task with no cap-triggering batch/destructive operation.

5 / 5

Progressive Disclosure

SKILL.md is an overview with all detail correctly split into five real, one-level-deep reference files (all verified to exist), each cited inline where relevant and again in a purpose-annotated References table. Not 4: navigation is easy, no content that belongs in a bundle file is inlined, and no nested references.

5 / 5

Total

19

/

20

Passed

Description

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

An exemplary description: concrete capabilities, natural trigger phrases with synonyms, explicit what/when coverage, and an explicit differentiation clause against adjacent writing skills. It is concise for the breadth it covers and stays in third person throughout.

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions — "converting jargon into business language", "surfacing decisions and impact early", "producing actionable recommendations with clear ownership and timeline" — plus applicable document types (technical reports, ADRs, incident summaries, risk assessments, status updates), matching the comprehensive-coverage anchor. Not 4: there are no notable gaps in the action coverage, and the third-person voice avoids the penalty.

5 / 5

Completeness

Explicitly answers both what ("Translates technical content into plain English for non-technical stakeholders by...") and when ("Use when the user asks to simplify technical content...") with concrete trigger phrases — the exact pattern of the 5 anchor. Not 4: the when-clause is fully explicit, not merely present.

5 / 5

Trigger Term Quality

Covers natural phrasings users would actually say, including synonyms: "simplify technical content", "write an executive summary", "explain something in layman's terms", "rewrite for non-technical audiences", "translate jargon for management or stakeholders". This matches the comprehensive-synonyms anchor; not 4 because no common natural variant is missing.

5 / 5

Distinctiveness Conflict Risk

Explicit differentiation clause — "Distinct from general writing or documentation skills by its focus on audience identification, decision-first structure, and jargon elimination for non-technical readers" — plus niche-specific triggers give it a clear niche with minimal conflict risk. Not 4: the description itself names the boundary rather than leaving overlap to inference.

5 / 5

Total

20

/

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

pantheon-org/tekhne

Path

skills/documentation/plain-english/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.