chore: publish 25ef5af
Built from main 25ef5af63e
fix: refuse to publish a build that logged a vite error
This commit is contained in:
@@ -1,19 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,10 +0,0 @@
|
||||
[
|
||||
{
|
||||
"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."
|
||||
}
|
||||
]
|
||||
@@ -1,16 +0,0 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user