skill
Adom Wiki Skill Pack
Public Made by Adomby adom
The Adom Wiki Skill Pack : one main skill plus the focused sub-skills that teach the AI to publish to wiki.adom.inc without breaking pages, name the wiki repo archetypes (Page, Skillpack, Family), and publish rich component pages (chips, molecules, boards). The wiki is six tools in one: git, package manager, releases, discussions, pull requests, and discovery. One package manager install drops the whole set onto your container. Includes reviewed Z-up component artwork, surface-selected MPN marki
← Commit history
wiki-readme: 3 detailed feature images + open-source section; wiki-hero: full-toolbar laptop hero + value-prop subhead (EDA-apps feedback 2026-06-21)
2 files changed
+46−2
skills/wiki-hero/SKILL.md+18@@ -35,6 +35,24 @@ shot of the real UI as a floating Windows-style webview window. Readable in one second. (Faux app windows use **Windows** min/max/close controls, never macOS dots.) For Family children, also carry the family chip (e.g. `ADOM-USB · SNIFFER`). +### The hero shot: laptop width, full toolbars OPEN (show the sophistication)++The single most important choice is the screenshot. For an app, capture the+**laptop-browser view with every toolbar / studio / HUD / layers panel OPEN** —+the busy, sophisticated state, not the default empty one. A loaded part with the+control panel deployed tells the viewer "this tool is capable" at a glance; a bare+canvas reads as a toy. Capture at ~1440px wide (deviceScaleFactor 2 for crispness)+with real content loaded, and click the panel(s) open before the shot. (Lesson+from the EDA apps, 2026-06-21: John explicitly wanted the full-toolbar laptop view+so users "understand how sophisticated the apps have gotten.")++### The subhead carries the VALUE PROP, not a restatement of the name++The headline can be a punchy phrase; the **subhead must be the value proposition**+— one line on what the app is *for* and its differentiator (e.g. "preview the+InstaPCB 300µm solder-paste dots no other tool shows"). Don't waste the subhead+paraphrasing the title. Keep it to ~1 line so the composer doesn't truncate it.+ > TODO (pack maintainers): we depend on `adom-wiki-hero-image` rather than folding > its content in. Revisit whether to inline it here later.
skills/wiki-readme/SKILL.md+28−2@@ -91,8 +91,13 @@ for the AI — the README is for the person deciding whether to install. `demo/index.html` with baked-in sample data (no server dependency). 4. **Install** — `adompkg install <slug>` 5. **Quick start** — 3–5 lines showing the most common workflow-6. **Screenshots** — 2–4 inline images, each with a caption heading. These are- **other** images, NOT the hero (see the #1 rule above).+6. **Feature images** — for an app, show **exactly 3 inline images of the major+ elements of the app**, each under its own `##` heading and each **described in+ detail**: a full paragraph on *what's in the shot and why it matters*, not a+ one-line caption. Make the three DIFFERENT elements (e.g. the control panel,+ the rendered output, the signature feature) — and never the hero. A close-up+ crop of a region is a fine "different" image; an identical copy of the hero is+ not. (Pattern proven on adom-symbol / adom-footprint / adom-lbr, 2026-06-21.) 7. **Dependencies** — a table: Dependency / Required? / Why (explain the *why*) 8. **Features** — bullet list 9. **Talk to the AI** — paste-ready prompts grouped by action, using the exact@@ -100,6 +105,27 @@ for the AI — the README is for the person deciding whether to install. 10. **Skills** — table of the main skill + sub-skills with a purpose column 11. **CLI reference** — command table (if there's a CLI) +## Open-source pages need a "check it out, vibe-code it, send it back" section++If the page's source is public (open source), the README MUST teach the+contribution loop — otherwise "open source" is a hollow claim. The proven section+(used across the Adom EDA apps, 2026-06-21) is a `## Open source` heading with a+short intro ("the complete source is in this page's **Files** tab") plus four+numbered steps:++1. **Build it** — the one-command build (`cargo build --release`, etc.).+2. **Point your install at your checkout** — `adompkg link <owner>/<slug> ./<dir>`+ so the installed command runs the local copy.+3. **Vibe-code a change** — open the folder in Claude Code and describe the change;+ name a couple of concrete, small extension points so it feels approachable.+4. **Send it back** — open a **pull request** on the page (the wiki merges per-repo+ PRs) or start a discussion thread.++For this to be TRUE, you must actually push the source (`src/` + build manifest)+into the page repo so the Files tab really shows it — don't write the section+against source that isn't there. Don't invent a `git clone` URL you haven't+verified; lean on the **Files** tab, `adompkg link`, and PRs, which exist.+ ## Embeds Inline image from the repo (blob endpoint) — point at a NON-hero screenshot