← Commit history

Delete skills/skill-authoring/SKILL.md

John Lauer ·5bdcd0dfa5 ·3mo ago ·parent 31ee3f9
1 file changed −100
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.