CtrlK
BlogDocsLog inGet started
Tessl Logo

standards-to-tooling

Translates project coding standards into concrete linting and formatting tool configurations. Given human-readable conventions (from AGENTS.md, code review guidelines, or team standards), this skill produces ESLint, Prettier, Biome, TypeScript, and other tool configs that enforce them automatically. Covers discovery, mapping, implementation, verification, and CI integration.

65

Quality

77%

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/software-engineering/standards-to-tooling/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

75%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-built, highly actionable skill: exact rule configurations, executable verification commands, and a clear five-phase workflow organized almost entirely as dense tables with negligible padding. Weaknesses are minor — a fragmentary CI example, one vague rule-mapping row, no explicit fix-and-retry checkpoints, and reference tables that could be moved into bundle files to slim the always-loaded body.

Suggestions

Replace the CI fragment with a complete, copy-paste-ready GitHub Actions workflow (or explicitly label it as a skeleton), and resolve the 'Custom or import/extensions rule' row to the exact rule configuration.

Add an explicit validation checkpoint after implementation, e.g. 'Run the three verification commands; fix and re-run until lint/format/typecheck all pass before wiring up CI.'

Move the large rule-mapping tables and the language quick reference into a references/ file (e.g. references/rule-mappings.md) to reduce the always-loaded token footprint, keeping only the workflow and principles in SKILL.md.

DimensionReasoningScore

Conciseness

The body is dense and table-driven with almost no padding — rule mappings, config principles, and commands are delivered as compact reference tables rather than prose, and the 'Mindset' section is a short two-line framing rather than a lecture. Not 5 because a few rows restate defaults Claude already knows (e.g. 'tabWidth: 2 (default)', 'strict: true' alongside the two flags it subsumes) and the import-sorting plugin is explained twice (sections 2 and 3), which could be trimmed.

4 / 5

Actionability

Mostly executable guidance: rule tables give exact config strings with severities and options ('@typescript-eslint/no-unused-vars: ["warn", { argsIgnorePattern: "^_"... }]'), and verification ships copy-paste commands ('npx eslint 'web/src/**/*.{ts,js,vue}'', 'npx vue-tsc --noEmit') plus ready package.json scripts. Not 5 because of two minor gaps: the row 'Explicit .js extensions in imports | Custom or import/extensions rule' defers the actual rule to pseudocode-level guidance, and the CI snippet is a fragment ('name: Lint & Typecheck / steps:') rather than a complete workflow file.

4 / 5

Workflow Clarity

A clear five-phase sequence (Discovery → Mapping → Implementation → Verification → CI Integration) with an explicit verification phase of runnable commands, so the destructive/batch cap at 3 does not apply. Not 5 because there are no error-recovery checkpoints or gating — nothing like 'if lint reports errors, fix and re-run before adding CI' — and the workflow proceeds straight from implementation to CI without an explicit pass/fail checkpoint.

4 / 5

Progressive Disclosure

Good structure: well-organized sections, external links are real, clearly signaled, and one level deep (vuejs.org style guide, ESLint flat config docs, typescript-eslint rules, Prettier options, Biome), and the References section doubles as a navigation index including a related-skill pointer. Not 5 because no bundle files exist and ~130 lines of lookup tables (the rule-mapping tables and the language quick reference) are inline reference material that a references/ file could offload from the always-loaded body; not 3 because the inline content is genuinely used by the core workflow and organization is clean.

4 / 5

Total

16

/

20

Passed

Description

80%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, comprehensive, and clearly niched, with good natural keyword coverage anchored by specific tool and file names. Its main weakness is the absence of an explicit 'Use when...' clause with concrete trigger situations, leaving the 'when' implied by an input description rather than stated as usage triggers.

Suggestions

Add an explicit 'Use when...' clause with concrete trigger situations, e.g. 'Use when setting up linting/formatting for a new project, adding a machine-enforceable convention, or migrating a codebase (e.g. JS → TS)' — the body's 'When to Use' section already has this content.

Include natural synonyms and artifacts users would mention, such as 'style guide', 'lint rules', 'enforce conventions', or config filenames like eslint.config.js / .prettierrc.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — 'produces ESLint, Prettier, Biome, TypeScript, and other tool configs that enforce them automatically' — and enumerates the full process scope ('Covers discovery, mapping, implementation, verification, and CI integration'), which is comprehensive coverage. Not 4 because there are no meaningful gaps: input sources, output artifacts, and pipeline phases are all named specifically.

5 / 5

Completeness

The 'what' is explicit ('Translates project coding standards into concrete linting and formatting tool configurations... produces ESLint, Prettier, Biome, TypeScript... configs'), and the 'when' is addressed via the explicit input condition 'Given human-readable conventions (from AGENTS.md, code review guidelines, or team standards)'. Not 5 (and not capped at 3) because the trigger guidance is present but not phrased as concrete usage triggers — there is no 'Use when...' clause with situations like onboarding a project, adding a convention, or migrating JS→TS that the body's 'When to Use' section already contains.

4 / 5

Trigger Term Quality

Good keyword coverage including natural user terms like 'coding standards', 'linting', 'formatting', 'AGENTS.md', 'code review guidelines', 'team standards', and tool names (ESLint, Prettier, Biome, TypeScript). Not 5 because common synonyms users would say are missing — e.g. 'style guide', 'lint rules', 'enforce conventions', or file extensions like .eslintrc / eslint.config.js — and there is no 'Use when...' phrasing enumerating trigger situations.

4 / 5

Distinctiveness Conflict Risk

The niche — converting written conventions into enforcement tooling — is clearly distinct and unlikely to trigger for unrelated skills, anchored by specific inputs (AGENTS.md, review guidelines) and outputs (tool configs). Not 5 because a user asking generically to 'set up ESLint' or 'configure Prettier' could plausibly trigger both this skill and a generic linting-setup skill, a minor overlap risk.

4 / 5

Total

17

/

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
pantheon-org/tekhne
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.