skill
Adom UI Design System
Public Made by Adomby adom
How the AI builds and tests interfaces people love to use in Adom. Ships as one installable skill that bundles focused skills (tooltips, floating-windows, toasts, responsive-ui, app-shell, ai-driven-apps, clickable-paths).
← Commit history
skills/skill-authoring/SKILL.mddeleted−100@@ -1,100 +0,0 @@-name: skill-authoring-user-invocable: true-description: >-- How to author a new set of Adom skills as a standalone wiki package, the right way. A wiki repo on- wiki.adom.inc is a full git repo that holds MANY skill files; bundle related skills as separate- files in ONE repo and let the package install deploy them all, never create a separate wiki repo- (page) per skill. Read BEFORE creating any new skill or skill set so you never spin up a repo per- small skill. Covers the bundle layout (root SKILL.md plus skills/<sub>/SKILL.md), an install.sh- that copies every skill, the package.json files whitelist, frontmatter conventions, and publishing- with adompkg. Trigger words: make a skill, create a skill, new skill, author a skill, skill file,- SKILL.md, skill bundle, bundle skills, wiki package, adompkg package, install.sh skills, publish a- skill, set of skills, how do skills work, one repo many skills, do not make a repo per skill.--# Authoring an Adom skill set--A skill is a Markdown file (SKILL.md) that teaches the AI to do a specialized task. The AI loads a-skill by matching its frontmatter `description` to what the user is doing, then reads the body.--The rule that matters most, and the one that gets broken: **a wiki repo is a full git repo that-holds many skill files. Bundle related skills as separate files in ONE repo. Never make a separate-wiki repo, or page, per skill.**--> **THE MISTAKE TO NEVER MAKE.** Do not create one wiki page per small skill. A skill as small as a-> tooltip spec is a file in a bundle, not its own repo. A page per skill clutters the owner's-> namespace, fragments install (the user has to find and install each one separately), and-> duplicates metadata. A stray page can be purged by its owner (`DELETE /api/v1/pages/<slug>?hard=true`,-> irreversible: row, repo, and tarballs gone, slug freed), but the right move is to never create it.-> If you catch yourself looping `POST /pages` to create many small skills, stop. You want one-> package with many files under `skills/`.--## The bundle layout--One wiki repo equals one installable package that can carry a whole set of skills:--```-my-set/ (one wiki repo, one adompkg package)- SKILL.md # the main skill (REQUIRED at repo root by the registry)- README.md # rendered on the page Overview tab- page.json # page metadata (title, brief, hero, visibility)- package.json # version, files[] lists EVERY skill file, scripts.install/uninstall- install.sh # copies the main skill AND every sub-skill to ~/.claude/skills/<name>/- uninstall.sh # removes them all- skills/- sub-skill-a/SKILL.md # each sub-skill: its own folder and SKILL.md- sub-skill-b/SKILL.md- sub-skill-c/SKILL.md-```--A single `adompkg install my-set` then drops the main skill plus every sub-skill onto the user's-container as separate skill files, each loadable by its own trigger words.--## install.sh deploys every skill, explicitly--The publish linter rejects an `install.sh` that misses any bundled sub-skill, so list each one. Do-not rely on a glob.--```bash-#!/usr/bin/env bash-set -e-DEST="$HOME/.claude/skills"-install_skill() { mkdir -p "$DEST/$1"; cp "$2" "$DEST/$1/SKILL.md"; }--install_skill my-set SKILL.md-install_skill sub-skill-a skills/sub-skill-a/SKILL.md-install_skill sub-skill-b skills/sub-skill-b/SKILL.md-install_skill sub-skill-c skills/sub-skill-c/SKILL.md-echo "OK: Installed my-set plus 3 bundled skills to $DEST/."-```--`uninstall.sh` removes the same set. `package.json` `files[]` must list `SKILL.md`, `README.md`,-`package.json`, `install.sh`, `uninstall.sh`, and every `skills/<sub>/SKILL.md`, plus-`scripts.install` and `scripts.uninstall` pointing at the two scripts.--## Frontmatter--```yaml-name: my-sub-skill # kebab-case, matches the folder name-user-invocable: true # set if the user can trigger it with /name-description: >- # third person, what + when, with quoted trigger phrases at the end- What this skill does and when to use it. Read BEFORE doing X. Trigger words: ...-```--Only `name` and `description` are pre-loaded, so the description must carry enough signal for the AI-to pick the skill, and a generous list of trigger phrases. Keep the body focused; one skill, one job.-If a skill is growing past one purpose, split it into another file in the same bundle.--## Publishing--Publish the whole package with the Adom Wiki (`adom-wiki-v2`) workflow: create the page once, push-all files to the git layer (text as plain content, binaries base64), then `adompkg publish` for the-installable tarball. `adompkg publish` resets the page title and brief to the package values, so-re-PUT the title, brief, and hero afterward. Always verify the page renders, and that-`adompkg install` deploys every skill, before calling it done.--The live example of this whole pattern is the `adom-ui-design` package, which bundles this skill-alongside the UI skills.