domino-extensions

Build and operate Domino UI Extensions (mount Domino Apps in the shell with page context). Covers extension_manifest.json, official installer vs manual Extension API, publish and identity requirements, auth and host splits, and beta REST routes. Use when creating an Extension, wiring mount points, publishing an Extension App from a project, or automating Extension install lifecycle. Not for generic App deployment alone (see domino-apps) or SPA scaffolding (see domino-ui-bootstrap).

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Quality

Content

68%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, information-dense body with one executable core example and honest platform caveats. Its main weakness is the missing feedback loops in the publish-and-create workflow, plus some repeated cross-references and inline detail that would fit better in dedicated bundle files.

Suggestions

Add validation checkpoints to the publish workflow: after POST /api/extensions/beta/extensions, check the response status and re-GET the extension to confirm it is enabled and mounted before declaring success; include error-recovery guidance for common failures.

Consolidate the four repetitions of 'confirm paths/routes in API-SPECS.md (public routes)' into a single 'Related API reference' note to trim redundancy.

Move the platform caveats and prerequisites tables into a references/ file (e.g., references/caveats.md) and keep one-line pointers in SKILL.md, deepening the progressive-disclosure structure.

Dimension	Reasoning	Score
Conciseness	The body is dense and assumes platform familiarity — no padding explaining what Domino or Apps are — but carries minor redundancy: 'confirm paths/routes in API-SPECS.md (public routes)' is repeated four times, and the auth code block restates the host/proxy logic already in the auth table.	4 / 5
Actionability	The create-Extension REST example is copy-paste ready (env-var host resolution, token fetch, realistic body with uiMountPointTypeConfigs), and mount-point keys plus 'renderIFrame = !deepLinkingEnabled' are concrete. Gaps: the Apps publish chain and official-install operations are named and delegated to other files rather than shown, leaving minor holes in executable coverage.	4 / 5
Workflow Clarity	The three-step publish workflow ('1. Build the App... 2. Publish the App... 3. Create the Extension') is clearly sequenced, but there are no validation checkpoints — the REST call has no status/error handling and nothing verifies the Extension is enabled or visible — matching 'sequence present but checkpoints missing or implicit' rather than the level above.	3 / 5
Progressive Disclosure	The body acts as an overview pushing detail one level deep through clearly signaled links (API-SPECS.md, API-APPS.md, official GitHub repos with 'read the file matching your Domino version'). However, no bundle files of its own exist, so inline material like the caveats and prerequisites tables is exactly what a references/ file could absorb — good structure with minor organization gaps.	4 / 5
	Total	15 / 20 Passed

Description

92%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: it states concrete capabilities, explicit use triggers, and explicit exclusions that route users away from sibling skills. The only weakness is that a few natural trigger synonyms are implied rather than stated.

Dimension	Reasoning	Score
Specificity	Multiple concrete actions are enumerated ('Build and operate Domino UI Extensions', 'wiring mount points', 'publishing an Extension App from a project', 'automating Extension install lifecycle') anchored by specific artifacts like extension_manifest.json and beta REST routes — comprehensive and concrete, matching the top anchor rather than the 'minor gaps' level below.	5 / 5
Completeness	Both halves are explicit: a concrete 'what' ('Build and operate Domino UI Extensions... Covers extension_manifest.json, official installer vs manual Extension API, publish and identity requirements, auth and host splits, and beta REST routes') and an explicit 'Use when' clause with concrete triggers, plus negative scope boundaries — matching the top anchor exactly.	5 / 5
Trigger Term Quality	Natural trigger phrases are present ('creating an Extension', 'wiring mount points', 'publishing an Extension App', 'automating Extension install lifecycle'), but some common variants a user might say (e.g., 'install an extension', 'extension manifest') are only implied through the 'Covers...' clause, so it sits just below the comprehensive-synonyms anchor.	4 / 5
Distinctiveness Conflict Risk	The description carves out a clear niche and actively disambiguates: 'Not for generic App deployment alone (see domino-apps) or SPA scaffolding (see domino-ui-bootstrap)' — minimal conflict risk with sibling skills.	5 / 5
	Total	19 / 20 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
relative_links	Relative link issues: 13 suspicious	Warning

	Total	15 / 16 Passed

Repository: dominodatalab/domino-claude-plugin
Path: skills/domino-extensions/SKILL.md
Commit: 92a240b

Reviewed: 3 days 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.