← 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)

John Lauer ·8d1155fff9 ·4mo ago ·parent 3279162
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