CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

replit-deck

For product and technical management work: turn PRDs, roadmaps, RFCs, architecture reviews, and retros into decision documents. Built around the core query "pm-feature-business-case-deck", with product strategy lead judgment, buyer-ready proof, and this outcome: approve the feature, architecture, roadmap, or incident follow-up.

54

Quality

68%

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

Quality

Content

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

The body is a well-engineered, highly executable workflow: a mandatory-reads pre-flight, theme lock-in with an enforced P0 gate, a critique-driven self-check with redo loops, and hard rules that resolve genuine ambiguity. Its main deductions are the self-congratulatory verification JSON dump and provenance prose that inflate token cost, and the resource map's promise of example decks that are not present in the bundle.

Suggestions

Trim the 'Verification' section to the one-line curl check plus the expected id match — the 30-line JSON response dump adds tokens without adding executable guidance.

Ship the advertised 'examples/' directory (example-helix/holm/atlas/bluehouse.html) or remove those entries from the resource map and verification section so navigation matches the actual bundle.

Condense 'Scope & provenance' to the snapshot date and one maintenance pointer, moving the re-sync procedure details fully into references/themes.md, which already documents it.

DimensionReasoningScore

Conciseness

The body is dense and teaches genuinely non-obvious material (theme lock rules, nav-script constraints, slide rhythm), with no padding about concepts Claude already knows. But it carries trimmable sections: the ~30-line curl/JSON dump in 'Verification' and the fine-grained provenance/maintenance policy (snapshot procedure, issue-opening instructions) that is not needed to execute the task. This is 'mostly efficient but includes some unnecessary explanation or could be tightened', not the lean every-token-earns-its-place profile of 5.

3 / 5

Actionability

Guidance is overwhelmingly executable: copy 'assets/template.html' to 'index.html', set '<body data-theme="<chosen>">', a runnable P0 gate ('grep -E 'data-theme|style="--' index.html | head'), a concrete slide-rhythm example, artifact emit syntax, and explicit placeholder-replacement rules. It falls short of 5 because the resource map directs the reader to four 'examples/example-*.html' decks (and 'examples/README.md') that do not exist in the bundle, so those copy-and-inspect steps cannot be executed.

4 / 5

Workflow Clarity

A six-step sequence (pre-flight reads → theme commit → rhythm plan → seed copy → layout paste → self-check → emit) with explicit validation and feedback loops: the Step 5 P0 theme-lock grep gate, the 'Any dimension ≤ 3 → re-do before emit' critique loop, and a dedicated checklist file ('references/checklist.md') with FAIL-flagged grep checks. This matches the top anchor: clear sequence, explicit validation steps, error-recovery loops, and a checklist.

5 / 5

Progressive Disclosure

The structure is genuinely good: a resource map with a file tree, mandatory reads consolidated in Step 0, and one-level-deep references (verified: themes.md, layouts.md, components.md, checklist.md, and template.html all exist and do not nest further). It does not reach 5 because the resource map and verification section advertise an 'examples/' directory with four HTML decks that is absent from the bundle — navigation that points at missing files. Not 3, since all existing references are clearly signaled and appropriately split.

4 / 5

Total

16

/

20

Passed

Description

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

The description communicates a real niche (PM decision documents) with one clear action and a defined outcome, but it is capped by the absence of an explicit 'Use when...' clause, missing natural trigger variations (business case, deck, slides), and buzzword-heavy framing ('product strategy lead judgment', 'buyer-ready proof') that substitutes for concrete capability statements. All four dimensions land at the midpoint anchor.

Suggestions

Add an explicit 'Use when...' clause, e.g. 'Use when the user asks for a business case, approval memo, decision deck, or go/no-go document for a feature, architecture, or roadmap change.'

Replace buzzword phrases ('product strategy lead judgment', 'buyer-ready proof', 'Built around the core query') with 2-3 additional concrete actions, e.g. 'structure options with trade-offs and risks, quantify the recommendation, and pre-empt reviewer objections'.

Include the natural trigger variations users would say — 'business case', 'feature pitch', 'decision deck', 'approve/reject proposal' — instead of the machine-facing slug 'pm-feature-business-case-deck'.

DimensionReasoningScore

Specificity

The description names one concrete action — "turn PRDs, roadmaps, RFCs, architecture reviews, and retros into decision documents" — but the remainder ("product strategy lead judgment", "buyer-ready proof", "Built around the core query 'pm-feature-business-case-deck'") is buzzword-adjacent framing rather than additional concrete capabilities. It clearly exceeds the score-2 anchor (domain named, generic actions) but does not list several distinct actions needed for 4.

3 / 5

Completeness

The 'what' is clear (turn rough PM material into decision documents), but there is no 'Use when...' clause or equivalent explicit trigger guidance — only the domain scoping "For product and technical management work". Per the judging guidelines, a missing explicit trigger clause caps completeness at 3; the outcome clause ("approve the feature, architecture, roadmap, or incident follow-up") partially compensates but is not trigger guidance.

3 / 5

Trigger Term Quality

Natural terms are present ("PRDs", "roadmaps", "RFCs", "architecture reviews", "retros", "decision documents") but common variations a user would actually say are missing: "business case", "deck", "slides", "presentation", "approval memo". The phrase "core query 'pm-feature-business-case-deck'" is machine-facing metadata, not a phrase a user would naturally utter. This sits at the 'some relevant keywords but missing common variations' anchor, not clearly below (2) or above (4).

3 / 5

Distinctiveness Conflict Risk

The description stakes a recognizable niche (turning PM artifacts into approval-oriented decision documents), but the opening "For product and technical management work" is broad, and the deck/presentation domain (per the skill's own peer table: simple-deck, magazine-web-ppt, replit-deck) has several closely related skills it could overlap with. It is 'somewhat specific but could still overlap with similar skills' — not the minor-overlap profile of 4, and far above generic (1–2).

3 / 5

Total

12

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

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

Warning

Total

15

/

16

Passed

Repository

nexu-io/open-design

Path

design-templates/replit-deck/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.