Marcos Paulo
ab2308441c
The repository had two skill directories. `skills/` held the four written for this project; `.agents/skills/` held the ones the agent context refers to. Nothing said which an agent should read, and `.agents/ORCHESTRATOR.md` only ever pointed at the second. Move the first four into `.agents/skills/` so there is one location, and add the vendored packages this chapter work used: `animation-vocabulary` and `improve-animations` (emilkowalski/skills), `teach` (mattpocock/skills), plus a local `translation` skill and `audit-translations.mjs` for the EN/PT pairs. `skills-lock.json` pins the vendored three by source and content hash, so a later re-vendor is a diff rather than a guess. `.claude/skills/` is symlinks into `.agents/skills/`, which is what makes them loadable here without a second copy on disk. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
46 lines
2.3 KiB
Markdown
46 lines
2.3 KiB
Markdown
---
|
|
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.
|