docs: extract guide design into reusable skills

skills/README.md

@@ -0,0 +1,10 @@
+# Reusable skills
+
+These project-local skills extract the design and implementation patterns used by AI For Dummies. They are intentionally small: copy a skill into an agent's skill directory, or give the `SKILL.md` path to an agent when building a new chapter.
+
+## Skills
+
+- [`editorial-playbook`](editorial-playbook/SKILL.md) — shape a content-led, responsive, bilingual explainer with small interactive islands.
+- [`rules-case-study`](rules-case-study/SKILL.md) — turn repository rules, skills, CLI checks, hooks, and review policy into a source-linked teaching page.
+
+The reference files are deliberately disclosed beside each skill. The `evals/evals.json` files contain small prompts for checking that an agent reaches the right workflow.

skills/editorial-playbook/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: editorial-playbook
+description: Use when building or reshaping a content-led interactive explainer, technical playbook, or presentation-like static page; define the information architecture, visual system, responsive behavior, bilingual copy, and minimal interactive islands before coding.
+---
+
+# Editorial playbook
+
+Treat the page as a guided argument, not a dashboard. Give it one audience, one job, and one memorable thesis.
+
+## Workflow
+
+1. Write the chapter map before markup. Every section gets a stable slug, number, title, purpose, and a single interaction or proof point when useful. Reach for [page anatomy](references/page-anatomy.md) when adding a new section.
+2. Compose from a few editorial primitives: label, thesis, pipeline or diagram, comparison/table, code panel, callout, source card, and next-chapter link. Keep the content model separate from rendering so more sections stay cheap.
+3. Use a restrained visual system: paper background, ink text, muted copy, one cool accent, one warm signal, hairlines, and typography with a strong display/body contrast. Prefer intentional asymmetry and generous rhythm over cards everywhere.
+4. Keep runtime light. Use plain HTML/CSS/JS for static, mostly content-led pages. Choose Astro or MDX only when many chapters need shared templates, content collections, or build-time localization. Preserve an existing framework when it already owns routing and tokens.
+5. Make the page bilingual at the content boundary. Pair English and Portuguese strings, toggle the document language, persist the choice, and translate labels, controls, status text, and dynamic details—not paths, commands, or code.
+6. Make interactions causal and inspectable. One active state should explain one idea; expose it with keyboard focus, an accessible state, a live status region, copy feedback, and a reduced-motion path.
+7. Design for mobile, Full HD, and 4K. Use fluid type and spacing, cap readable measure, stack dense regions at narrow widths, keep diagrams scrollable only when semantically necessary, and test 390px, 1920px, and 3840px viewports.
+8. Finish with evidence: content verification, JavaScript syntax checks, interaction tests, responsive browser checks, and a diff check. The section is done when its content, dynamic states, links, and three viewport classes pass.

skills/editorial-playbook/evals/evals.json

@@ -0,0 +1,10 @@
+[
+  {
+    "prompt": "Add a new bilingual chapter to a dependency-free static explainer with one diagram and one copy control. What should you decide and verify first?",
+    "expected_behavior": "Create a chapter map and content model first; pair EN/PT strings; use a small accessible interaction; verify mobile, Full HD, and 4K behavior."
+  },
+  {
+    "prompt": "The explainer needs 20 more sections but has no data source for section metadata. Recommend a lightweight implementation.",
+    "expected_behavior": "Keep content in structured data and render shared editorial primitives; recommend plain HTML/CSS/JS for a small static site, or Astro/MDX when shared build-time content collections justify it."
+  }
+]

skills/editorial-playbook/references/page-anatomy.md

@@ -0,0 +1,16 @@
+# Page anatomy
+
+Use this as a compact design contract for a new AI For Dummies chapter.
+
+1. **Orientation** — eyebrow, chapter number, title, short promise, language control.
+2. **Thesis** — one sentence that changes how the reader sees the topic.
+3. **Model** — a pipeline, tree, timeline, or comparison that makes the relationship visible.
+4. **Practice** — a copy-ready prompt, command, example, or tiny exercise.
+5. **Proof** — source paths, checks, observed behavior, and the boundary between advice and enforcement.
+6. **Transfer** — a small “use this next” link to the next chapter or deeper source.
+
+Keep the first screen editorial and calm. Let code, diagrams, and controls earn their space by teaching something. Avoid a generic hero followed by an undifferentiated card grid.
+
+## Section contract
+
+Each new section should answer: what does the reader learn, what is the visible proof, what can they copy or try, and what source supports it? Add its copy to the language map before adding a control. Add its slug to navigation only after the section has a stable purpose.

skills/rules-case-study/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: rules-case-study
+description: Use when explaining how a repository turns agent guidance into enforceable behavior across context files, skills, CLI checks, Git hooks, CI, worktrees, or PR review; build a concise, source-linked case-study page.
+---
+
+# Rules case study
+
+Show the control loop: context → skills → CLI → commit → review. The reader should see where a rule lives, what executes it, and how to verify it.
+
+## Workflow
+
+1. Inspect authoritative files before writing copy. Start with the repository context file, skill directory, command or database ledger, enforcement scripts, hooks, staged-file config, CI, and review policy. Use [the interview source map](references/interview-source-map.md) as a routing hint, then confirm paths in the target repository.
+2. Separate guidance from enforcement. A context file or skill teaches an agent; a CLI check, hook, CI job, or reviewer blocks or reports behavior. Never describe prose as mechanically enforced.
+3. For every example, show the rule, exact source path, enforcement point, verification command, and remaining gap. Prefer one concrete ratchet or hook example over a list of vague best practices.
+4. Add a skills shelf. Each skill needs a trigger, the lesson it carries, a tiny example, and a source link. Keep examples short enough to copy into an agent prompt.
+5. Include a read-only exploration prompt that asks an agent to map rules to evidence and gaps. Add copy feedback and bilingual labels if the host guide supports both languages.
+6. Use a dependency-free standalone page when the case study is mostly explanatory. Link back to the main guide and exact source files. Do not modify the source repository merely to document it.
+7. Verify dynamic stage and skill states, source links, copy behavior, language switching, no horizontal overflow, and the 390px/1920px/3840px viewports. The page is done when every claim has a source or is clearly labeled as a design recommendation.

skills/rules-case-study/evals/evals.json

@@ -0,0 +1,10 @@
+[
+  {
+    "prompt": "Explain a repository's AGENTS.md, reusable skills, UI ratchet script, Husky hooks, and PR review config as one teachable page.",
+    "expected_behavior": "Build a context → skills → CLI → commit → review pipeline; link every claim to an exact source path; distinguish guidance from enforcement; include a short read-only exploration prompt."
+  },
+  {
+    "prompt": "A skill says all pages need an h1 and a pre-commit script checks it. How should the case study describe that relationship?",
+    "expected_behavior": "Describe the skill/context as guidance and the script/hook as executable enforcement, then show the verification command and any gap between local hooks and CI."
+  }
+]

skills/rules-case-study/references/interview-source-map.md

@@ -0,0 +1,18 @@
+# Interview source map
+
+This map records the implementation inspected for the rules case study. Reconfirm paths when the source repository changes.
+
+| Concern | Source | Role |
+| --- | --- | --- |
+| Shared context | `AGENTS.md` | Stack, commands, product shape, conventions, and verification expectations. |
+| Reusable procedures | `.agents/skills/` | Focused workflows such as gates, frontend, Go API, repo DB, and skill writing. |
+| Machine-readable routing | `.agents/db/commands.json` | Canonical checks and code-generation commands. |
+| UI enforcement | `scripts/check-ui-contract.mjs` | Ratchet for buttons, catches, headings, colors, and duplicate components. |
+| Ratchet state | `scripts/ui-contract-baseline.json` | Baseline counts that new violations cannot exceed. |
+| Commit boundary | `.husky/pre-commit` | Runs lint-staged and the UI contract check. |
+| Commit message boundary | `.husky/commit-msg` | Runs commitlint. |
+| Staged-file tools | `.lintstagedrc.cjs` | Biome, ESLint, Prettier, and Buf formatting by file type. |
+| Independent review | `.pr-review.json` | Review focus, exclusions, security constraints, and test expectations. |
+| Agent roles | `.claude/agents/` | Prior-art scout, scoped implementer, and verifier responsibilities. |
+
+The source of truth is the repository. This table is a teaching map, not a replacement for reading the files.