CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

kami-landing

Produce a print-grade single-page kami (紙 / 纸) document — warm parchment canvas, ink-blue accent, serif at one weight, no italic, no cool grays. The output reads like a professional white paper or studio one-pager, not an app UI. Multilingual by design (EN · zh-CN · ja). One self-contained HTML file, zero dependencies.

58

Quality

73%

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 ./design-templates/kami-landing/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%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, token-efficient contract with a concrete page spec and a genuine validation checklist — the strongest part of the skill. Its main defect is that its most important references (example.html and the kami DESIGN.md token spec) are missing from the bundle, leaving the guidance partially unactionable.

Suggestions

Ship the referenced bundle files (example.html, README.md, design-systems/kami/DESIGN.md) or inline the essential token table and one canonical HTML snippet into SKILL.md — progressive_disclosure and actionability both suffer because the declared source of truth is absent.

Close the workflow loop after step 4: add 'If any self-check item fails, fix it and re-run the checklist before delivering' to convert the checklist into a feedback loop.

Consolidate the triple statement of the core rules (What you get / Self-check / Boundaries) — state each rule once in the spec and let the checklist reference it, trimming repeated hex values and justifications.

DimensionReasoningScore

Conciseness

The body is dense with information Claude does not already know — exact hex tokens (#f5f4ed, #1B365D), line-heights 1.10–1.55, per-language letter-spacing, the rgba double-paint rationale, breakpoints 1280/980/768/560 — and it assumes competence rather than explaining basics. It is not a 5 because the core rules (parchment background, ink-blue ≤ 5%, tabular-nums, solid-hex tags, no italic) are stated three times across 'What you get', the self-check, and 'Boundaries', which could be consolidated.

4 / 5

Actionability

Concrete, executable guidance throughout: a fully dimensioned page structure (96–106px display headline, 24px tabular-nums metric values), a language→font-stack table, a list of drop-in class primitives, data-od-id tagging instruction, and a 10-item self-check. It is not a 5 because the implementation is delegated to 'Mirror the structure of example.html' and to tokens in design-systems/kami/DESIGN.md, neither of which is present in the bundle — no executable HTML/CSS snippet is inlined, so the agent cannot complete the task from the skill alone.

4 / 5

Workflow Clarity

The workflow contract is a clear four-step sequence (gather brief in two rounds → pick language stack → write index.html → self-check) with an explicit validation checkpoint: a 10-item self-check checklist before delivery. It is not a 5 because there is no feedback loop after the checklist (no 'if a check fails, fix and re-verify' instruction); this is a generative, non-destructive skill, so the missing-validation cap at 3 does not apply.

4 / 5

Progressive Disclosure

Structure and signaling are good — links are explicit, one level deep, and labeled ('Design system source of truth ... Read it before shipping'), with a 'Files in this skill' listing. But scored against the actual bundle, the referenced files do not exist: there is no README.md, no example.html, and no design-systems/kami/DESIGN.md, so the declared source of truth for every token and the canonical rendering are unreachable. That is why it sits at 3 rather than 4–5; it is above 2 because the SKILL.md itself is well organized and nothing is buried.

3 / 5

Total

15

/

20

Passed

Description

66%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 specific, distinctive description that paints the deliverable in concrete terms, but it never tells Claude when to use it. Adding an explicit 'Use when...' clause with natural trigger phrases would complete it.

Suggestions

Append an explicit when-clause, e.g. 'Use when the user asks for a white paper, one-pager, editorial landing page, or kami-style print document' — this lifts completeness from its current cap of 3.

Work the natural phrase 'landing page' (and close variants like 'one-page site' or 'homepage') into the description or triggers, since the skill is named kami-landing but that phrase never appears.

Disambiguate from the sister kami-deck skill in the description (e.g. 'single-page document, not a slide deck') to reduce conflict risk on the shared 'kami' trigger.

DimensionReasoningScore

Specificity

The description names several concrete capabilities and output properties — 'print-grade single-page kami (紙 / 纸) document', 'warm parchment canvas, ink-blue accent, serif at one weight', 'One self-contained HTML file, zero dependencies', 'Multilingual by design (EN · zh-CN · ja)'. It falls short of a 5 because it describes one deliverable's attributes rather than a comprehensive set of distinct actions, and it is well above a 3 since the what is fully concrete, not generic.

4 / 5

Completeness

The 'what' is clearly and concretely stated (a print-grade, self-contained, multilingual single-page HTML document with a defined aesthetic), but there is no 'Use when...' clause or equivalent explicit trigger guidance in the description, which caps completeness at 3 per the judging guidelines. It is not a 2 because the 'what' is specific rather than vague, and it is not a 4 because no 'when' guidance appears at all, not even a weakly explicit one.

3 / 5

Trigger Term Quality

Natural user phrasings appear directly in the description: 'kami (紙 / 纸)', 'professional white paper or studio one-pager', 'parchment', 'print-grade'. A few natural terms a user would plausibly say are missing — notably 'landing page' despite the skill being named kami-landing, plus 'homepage'/'one-page site' — which keeps it below a 5; coverage is clearly above the midpoint because several distinct natural synonyms are present.

4 / 5

Distinctiveness Conflict Risk

The niche aesthetic vocabulary ('kami', 'parchment canvas', 'ink-blue accent', 'print-grade', 'no cool grays') carves out a clear niche that a generic page or document skill would not claim. It is not a 5 because the sister skill kami-deck shares the same kami design language and trigger word 'kami', creating minor overlap risk with a closely related skill.

4 / 5

Total

15

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

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

Warning

relative_links

Relative link issues: 1 missing, 3 suspicious

Warning

Total

14

/

16

Passed

Repository

nexu-io/open-design

Path

design-templates/kami-landing/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.