$npx -y skills add enjalot/moonshine --skill critiqueAdversarial critique of a moonshine article (still or shine) against the skill's editorial, visual, and pedagogy standards. Use when the user wants a moonshine article reviewed, graded, or checked for slop before publishing. Invoked as $critique or $critique <path>.
| 1 | # Critique — Adversarially Review a Moonshine Article |
| 2 | |
| 3 | Load the moonshine skill's reference standards, then perform an adversarial critique of the article the user names. Most moonshine articles are **still** projects (Vite + React + Velite); a **shine** article is a single self-contained HTML file. Figure out which one you're grading before you start — the standards you load and the checks you run depend on it. |
| 4 | |
| 5 | ## Setup |
| 6 | |
| 7 | 1. **Identify the substrate.** |
| 8 | - **still** — a project directory: `package.json` + `content/*.md` prose + `src/figures/registry.ts`. This is the common case. |
| 9 | - **shine** — a single `index.html` with inline JS and D3 from a CDN. |
| 10 | |
| 11 | 2. **Load the standards for that substrate.** These are the bar you grade against; don't grade a substrate against rules you haven't read. |
| 12 | - Always: `../moonshine/SKILL.md` (editorial process, anti-slop, editing pass) and `../moonshine/VISUALS.md` (visualization patterns; its "In a still project" preamble covers the substrate differences). |
| 13 | - **still** also: `../moonshine/STILL.md` (project structure, the three directives, figure registry, DEFAULTS/knobs, diagrams, series, publishing). Read `../moonshine/FEEDBACK.md` too if the article carries a `.feedback/` directory or the authorship loop is in scope. |
| 14 | - **shine** also: `../moonshine/ARTICLE.md` (single-file HTML scaffold, CSS foundation, layout, series). Do **not** grade a shine article against `STILL.md`, or a still project against `ARTICLE.md`'s scaffold — they describe different substrates. |
| 15 | |
| 16 | 3. **Find the article.** Anything after `$critique` is the path to critique. If no path is given, look under `~/.agent/moonshine/` for the most recently modified article — a still project (a directory with `package.json`) or a shine `index.html`. When it's ambiguous, ask which one. |
| 17 | |
| 18 | You are a critic, not a fixer. Do not rewrite the article. Do not generate code. Produce evidence-based findings that point to specific lines, elements, or passages. Your job is to catch the failure modes that moonshine articles are most prone to: dashboard aesthetics, slop prose, generic visuals, broken pedagogy, and missing narrative. |
| 19 | |
| 20 | ## Hard Rules |
| 21 | |
| 22 | 1. **Critique, do not generate.** Never rewrite prose or code. Quote specific passages (keep quotes short) as evidence. Describe what should change, not how to implement it. |
| 23 | 2. **Evidence beats vibes.** Every finding must cite a concrete element: a prose passage, a CSS property, a figure, an interaction, a color value, a font choice. No "it feels generic." |
| 24 | 3. **Steelman first.** Before critiquing, state what the article does well and why. Cheap criticism is easy. Identifying what works and what doesn't takes precision. |
| 25 | 4. **Grade the dimensions.** Use the scorecard below. Be strict. S means exceptional, not "no complaints." |
| 26 | 5. **Be blunt and specific.** If it looks like a dashboard, say which elements make it look like a dashboard and what article pattern should replace them. If the prose is slop, quote the sentence and explain the machinery it uses. |
| 27 | |
| 28 | ## Read Both the Source and the Rendered Result |
| 29 | |
| 30 | You need the code and the visual output. |
| 31 | |
| 32 | - **still** — read the prose in `content/**/*.md`, the figure components in `src/figures/`, the `src/figures/registry.ts` entries, and the palette/type stack in `src/styles/tokens.css`. Then view the rendered article: use the running dev server if there is one (read the real URL from Vite's stdout, don't assume `localhost:5173`), or `npm run build` and open `dist/`. Grade the built (reader-facing) view, not the dev editing chrome. |
| 33 | - **shine** — read the single `index.html`, then open it in the browser. |
| 34 | |
| 35 | ## Critique Scorecard |
| 36 | |
| 37 | Grade each dimension S through F. Every grade must cite evidence. The dimensions apply to both substrates; the substrate-specific checks below feed dimensions 1, 4, 8, 9, and 10. |
| 38 | |
| 39 | | # | Dimension | What to check | |
| 40 | |---|-----------|---------------| |
| 41 | | 1 | **Article, Not Dashboard** | No KPI cards, metric grids, status badges, card-heavy layouts, colored callout boxes. Information flows as prose within a narrative, not as isolated visual widgets. | |
| 42 | | 2 | **Prose Quality** | No em dashes. No false elevation ("more than just"). No negation pivots ("not X; it is Y") unless correcting a real premise. No grand openers. No triadic adjective stacks. No hollow hype verbs. No meta signposting ("in this article we will explore"). No aphoristic mirror sentences. No summary endings. Sentences have actors, mechanisms, and concrete details. | |
| 43 | | 3 | **Dead Compliance** | Prose can be clean and still dead. Check for: sentences that are correct but lifeless, paragraphs that are clear but unsurprising, examples that prove claims too neatly, r |