CtrlK
BlogDocsLog inGet started
Tessl Logo

render-ios-keyboard

Render a static iOS QWERTY keyboard as inline HTML+CSS sized for the 750-wide 9:16 stage. Includes the 3-suggestion bar, alpha keys, shift/backspace, 123/emoji/space/return row, and the bottom globe+mic strip. No animation logic — slide up/down is the molecule's job (CSS transform on the .keyboard root).

59

Quality

67%

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/ads/packs/video-ad-formats/render-ios-keyboard/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.

The body is highly actionable with executable code and a clear, well-structured workflow, but it carries redundancy (duplicate Quality Checks sections and overlap between Workflow, Failure Modes, and the spec) that hurts token efficiency, and lacks a single explicit post-render verification checkpoint.

Suggestions

Merge the two 'Quality Checks' sections (the checkbox list and the prose spec) into one to eliminate duplication and reclaim tokens.

Add one explicit verify step to the Workflow (e.g., 'Open --out in a browser and confirm 518px height, 3 suggestions, and wide modifier keys') as a concrete checkpoint.

Consider moving the detailed rendered-DOM spec into a short reference file referenced from the Files table, keeping SKILL.md a lean overview.

DimensionReasoningScore

Conciseness

Mostly efficient with a tight Inputs snippet and a focused workflow, but there is redundancy — two 'Quality checks' sections (a checkbox list and a prose spec that largely restate each other) and the Failure Modes section repeats details already covered in the Workflow, which could be tightened.

3 / 5

Actionability

Fully executable guidance: a copy-paste require call with concrete options, a runnable CLI command ('node render.js --out /tmp/kb.html --suggestions ...'), explicit DOM shape, and exact fallback/escaping behavior — covers the common cases copy-paste ready.

5 / 5

Workflow Clarity

A clear seven-step sequence with concrete commands and explicit ownership boundaries; the destructive/batch cap does not apply (this is a pure render with no batch/destructive ops), but the workflow lacks an explicit validate/verify checkpoint after rendering (the standalone preview step is optional), leaving a minor validation gap.

4 / 5

Progressive Disclosure

Good structure with well-organized sections (Purpose, Inputs, Workflow, CLI, Output, Files, Quality Checks, Failure Modes) and a Files table pointing to generate.js/render.js/templates/keyboard.css at one level; no nested references and the body is an overview, though it inlines a fairly detailed spec rather than splitting it into a reference file.

4 / 5

Total

16

/

20

Passed

Description

60%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 is highly specific about what the skill produces and its boundaries, but it is written in internal technical jargon rather than natural user-trigger language and lacks an explicit 'use when' clause, capping trigger-term quality and completeness.

Suggestions

Add an explicit 'Use when...' clause naming natural triggers, e.g., 'Use when a video needs to show someone typing on an iPhone and the molecule needs a static iOS QWERTY keyboard fragment.'

Soften jargon in the opening to include user-facing phrases ('iOS keyboard', 'typing keyboard') alongside the technical detail so a user's natural request language matches.

Keep the boundary note ('No animation logic...') but consider moving the molecule/transform implementation detail to the body, since it does not help a user decide when to invoke the skill.

DimensionReasoningScore

Specificity

Lists multiple concrete actions/components explicitly — 'Render a static iOS QWERTY keyboard as inline HTML+CSS', 'Includes the 3-suggestion bar, alpha keys, shift/backspace, 123/emoji/space/return row, and the bottom globe+mic strip' — and an explicit boundary ('No animation logic'), giving comprehensive coverage.

5 / 5

Completeness

It clearly answers 'what' (renders a static iOS QWERTY keyboard with specific parts) but contains no 'Use when...' clause or equivalent trigger guidance for when Claude should invoke it, which the guidelines say caps completeness at 3.

3 / 5

Trigger Term Quality

Keywords are highly domain-specific technical jargon ('inline HTML+CSS', '750-wide 9:16 stage', 'CSS transform on the .keyboard root') with no natural user-facing phrases a person would actually say when needing this skill (e.g., 'iOS keyboard', 'typing keyboard', 'typing animation'); matches the 'one or two generic keywords / missing natural phrases' anchor.

2 / 5

Distinctiveness Conflict Risk

A clear niche — a static iOS keyboard HTML/CSS fragment for a 750-wide stage — with distinct triggers and minimal overlap risk; unlikely to fire for the wrong skill.

5 / 5

Total

15

/

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
gooseworks-ai/goose-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.