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).

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

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

Quality

Content

77%

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, a clear sequenced workflow, and strong error-recovery guidance, but it is monolithic and carries duplicated quality-check/limitations material. Consolidating the redundant sections would improve token efficiency and structure.

Suggestions

Merge the two 'Quality checks' / 'Quality Checks' sections into a single consolidated checklist to remove the duplicated material.

Move the detailed 'Failure Modes' or the long 'Quality Checks' spec into a separate referenced file (e.g. VERIFICATION.md) and link to it one level deep, improving progressive disclosure.

Reconcile 'Known limitations' with 'Failure Modes' so each behavior is documented in one place rather than two.

Dimension	Reasoning	Score
Conciseness	Mostly efficient with concrete code and commands, but the two overlapping '## Quality checks' / '## Quality Checks' sections and the overlap between 'Known limitations' and 'Failure Modes' are redundant and could be tightened, matching 'mostly efficient but includes some unnecessary explanation'. It never explains concepts Claude already knows (so above 1) but the duplicated quality-check material keeps it below 3.	2 / 3
Actionability	Provides fully executable guidance — the require() snippet, the CLI 'node render.js --out /tmp/kb.html --suggestions ...', and concrete Output/Files tables — making it copy-paste ready per the top anchor.	3 / 3
Workflow Clarity	A clear 7-step Workflow sequence is paired with a 'Failure Modes' section giving explicit symptom→fix recovery loops and quality checklists, satisfying 'clear sequence with feedback loops for error recovery'. It is not capped at 2 because the operation is static rendering (not destructive/batch), so missing in-step validation checkpoints is not penalized.	3 / 3
Progressive Disclosure	Well-sectioned but monolithic (>50 lines) with all content inline in SKILL.md and no bundled reference files present (references/, scripts/, assets/ absent), plus duplicated quality-check content that should be consolidated — matching 'some structure but content that should be separate is inline'. It does not reach 3 because the under-50-lines simple-skill exemption does not apply and no one-level-deep reference files exist.	2 / 3
	Total	10 / 12 Passed

Description

67%

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 specific and clearly niche-scoped but is written in implementation/developer voice rather than trigger-oriented voice, and it omits any explicit 'when to use' guidance. Tightening trigger terms and adding a Use-when clause would raise the two capped dimensions.

Suggestions

Add an explicit trigger clause, e.g. 'Use when a video or mockup needs to show someone typing on an iPhone keyboard (iMessage, ChatGPT-style chat UIs).'

Lead with natural user-facing terms ('iOS keyboard', 'typing', 'messaging mockup') before the implementation details so trigger-term quality reaches full coverage.

Move low-level details like 'CSS transform on the .keyboard root' and '750-wide 9:16 stage' into the body so the description stays concise and trigger-focused.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete components — '3-suggestion bar, alpha keys, shift/backspace, 123/emoji/space/return row, and the bottom globe+mic strip' — matching the 'lists multiple specific concrete actions' anchor rather than the partial level-2 example.	3 / 3
Completeness	The 'what' is strong but there is no 'Use when...' clause or equivalent explicit trigger guidance, and the rubric guideline explicitly caps completeness at 2 in that case; it is above level 1 because the capability is clearly stated.	2 / 3
Trigger Term Quality	'iOS QWERTY keyboard' is a natural term, but it is buried in implementation jargon ('750-wide 9:16 stage', 'CSS transform on the .keyboard root', 'molecule's job') with no common user phrasings like 'typing' or 'messaging mockup', so it sits at 'some relevant keywords but missing common variations' rather than full coverage.	2 / 3
Distinctiveness Conflict Risk	Rendering a static iOS QWERTY keyboard is a narrow, well-defined niche unlikely to trigger for unrelated skills, matching the 'clear niche with distinct triggers' anchor rather than the overlapping level-2 example.	3 / 3
	Total	10 / 12 Passed

Validation

100%

Warnings & errors only

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: gooseworks-ai/goose-skills
Path: skills/ads/packs/video-ad-formats/render-ios-keyboard/SKILL.md
Commit: 8866b2a

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

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.