Adom Wiki

@@ -17,7 +17,7 @@ project. You drive ALL of it with one tool: the `adom-wiki` CLI. ## Bootstrap: adom-wiki is missing or outdated  This skill assumes you HAVE the current `adom-wiki`. If commands fail, check-that first -- an old binary strands you with confusing errors:+that first, an old binary strands you with confusing errors:  - `adom-wiki pkg install ...` fails with **"unrecognized subcommand"**: the old   binary predates the `pkg` / `repo` / `release` verbs.@@ -107,10 +107,10 @@ the Windows installer; the laptop downloads the Windows asset directly by URL. The Dependencies tab/graph and the "Used by" list are fed ONLY by the `dependencies` in the last PUBLISHED package version. Declaring dependencies in package.json and `repo push`-ing it does NOT populate the graph ("Depends on-0") -- the repo layer is your source, the registry layer is what the graph+0"), the repo layer is your source, the registry layer is what the graph reads. To make an edge appear you must `pkg publish`. -Worked recipe -- link one hardware page as a dependency of another (a board+Worked recipe, link one hardware page as a dependency of another (a board depending on a part):  ```bash@@ -121,7 +121,7 @@ cd part/ && adom-wiki pkg publish --org adom # 2. declare the dep in the DEPENDENT board's package.json, owner-qualified: #    "dependencies": { "adom/<part-slug>": "^1.0.0" } -# 3. publish the board -- THIS is what draws the edge+# 3. publish the board, THIS is what draws the edge cd board/ && adom-wiki pkg publish --org adom ``` @@ -158,7 +158,7 @@ hints**: each carries a ready-to-run `cmd` for the next step.  Before the three tiers, one decision people get wrong constantly. When you make "a skill for my app", it belongs **inside that app's repo** as-`skills/<name>/SKILL.md` — it ships with the app and shows on the app's Skills+`skills/<name>/SKILL.md`, it ships with the app and shows on the app's Skills tab. **Do NOT create a separate wiki package/page for it.** A standalone skill package (its own page, its own `pkg publish`) is only for a **reusable skill that many apps or agents share** (e.g. `adom/google`, or this `adom/wiki` skill).@@ -168,13 +168,13 @@ many apps or agents share** (e.g. `adom/google`, or this `adom/wiki` skill).  `pkg init --type skill` and the first `pkg publish` of a standalone skill both emit an `APP_SKILL_LOCATION` hint reminding you of this, because the default AI-move — spinning up a separate skill repo for an app — is almost always wrong.+move, spinning up a separate skill repo for an app, is almost always wrong.  ### The three tiers (within an app)  Every app should ship a skill, but not every skill you write should reach the people who install the app. Skills come in **three types**, sorted by a top-level-directory. The directory IS the type — nothing about the type goes in the+directory. The directory IS the type, nothing about the type goes in the SKILL.md frontmatter.  | Directory | Type | For | Examples | In install tarball? | On the page? |@@ -192,14 +192,14 @@ There are two storage layers (see above), and the types map onto them: - **User skills ride the package layer.** `pkg publish` bundles `skills/` + the   root `SKILL.md` into the install tarball, so every `pkg install` gets them. - **Dev + Publish skills are source.** `pkg publish` / `pkg pack` **auto-exclude**-  `dev-skills/` and `publish-skills/` from the tarball — you never have to+  `dev-skills/` and `publish-skills/` from the tarball, you never have to   remember to strip them. They reach the wiki the way ALL your source does: a   **`repo push`** into the git page repo (the Files tab). Publish does NOT push   them for you.  So the normal flow is two commands: `pkg publish` (ships the user skills to-installers) and `repo push` (puts your source — including the dev/publish skills-— on the page). On every pack/publish the CLI prints a `SKILL_LAYOUT` hint with+installers) and `repo push` (puts your source, including the dev/publish skills+,  on the page). On every pack/publish the CLI prints a `SKILL_LAYOUT` hint with the split and, when dev/publish tiers exist, the exact command to run:  ```bash@@ -208,7 +208,7 @@ adom-wiki repo push <owner>/<slug> --files dev-skills publish-skills -m "add dev  ### Where they show up -The page's **Skills tab** splits into three sub-tabs — **User | Dev | Publish** —+The page's **Skills tab** splits into three sub-tabs, **User | Dev | Publish** ,  read from the git repo (with a `?` tooltip explaining the types). A visitor browsing the page sees all three tiers; a consumer who `pkg install`s the app gets only the User tier. That is the point of the split: teach/collaborate with@@ -223,16 +223,16 @@ wiring a release), it is a **dev** or **publish** skill → `dev-skills/` or  ### Publish enforces it (so a dev skill can't leak) -Putting a skill in the wrong folder is the easy mistake — a build/test/release+Putting a skill in the wrong folder is the easy mistake, a build/test/release skill dropped into `skills/` would ship to every install. So `pkg publish` **reads each `skills/<slug>` SKILL.md and blocks the publish** when one reads like dev or publish work (its description mentions e.g. "test suite", "cross-compile", "cut a release", "bump the version"). It names the skill and the fix. The message-is the only thing that catches this — the folder exclusion can't, because the+is the only thing that catches this, the folder exclusion can't, because the skill is in the wrong folder. -If it is a false positive — a genuine user skill for a tool that legitimately-talks about tests or releases (e.g. this CLI's own user skill) — confirm it in+If it is a false positive, a genuine user skill for a tool that legitimately+talks about tests or releases (e.g. this CLI's own user skill), confirm it in package.json. This is the one override, kept in the manifest (never in the SKILL.md), per-skill: @@ -244,7 +244,7 @@ SKILL.md), per-skill:  ### Writing a good skill (any type) -- YAML frontmatter with `name` and a rich, **trigger-laden `description`** — the+- YAML frontmatter with `name` and a rich, **trigger-laden `description`**, the   real phrases someone would say. Discovery search and the agent match on this;   a vague description makes the skill unfindable. - User skills add `user-invocable: true`.@@ -314,4 +314,4 @@ SKILL.md), per-skill:   tarball. - Re-supplying title/hero/body to bump a version. Metadata lives in package.json. - Dumping build/debug/publish skills into `skills/` so they ship to every install.-  Put them in `dev-skills/` or `publish-skills/` — publish auto-keeps them out.+  Put them in `dev-skills/` or `publish-skills/`, publish auto-keeps them out.