Marcos Paulo
7f11b6e88e
`styles.css` line 1 carried a malformed rule for the life of the site:
@font-face{font-family:Manrope;src:url('https://fonts.googleapis.com/css2?...')}
`src:` in an @font-face must point at a font binary. That URL returns a CSS
stylesheet, so no browser could ever load a face from it. Every
`font-family:Manrope,Arial,sans-serif` fell through to Arial, and 'DM Mono' was
never declared as a family at all, so it fell through to generic monospace. The
intended typography has never once been seen.
Task 02 spotted this and was told to default to deleting the dead rule and
declaring the stacks that actually render. It recorded that decision, deferred
the deletion to "future component tasks", and nothing picked it up. The human
has now chosen the other branch: the real fonts.
Self-hosted rather than linked from fonts.googleapis.com because
scripts/audit-ui.mjs rejects any external <link>/<script>, and because the site
is presented in workshop rooms with unreliable networks. Latin and latin-ext
subsets only — the site is EN and PT-BR, so the cyrillic, greek and vietnamese
subsets Google also serves are dropped. Manrope ships as one variable file
covering 400-800. 89 KB total across six faces, all SIL OFL.
One public/fonts/fonts.css serves both trees, with relative url()s that each
consumer resolves against that file's own location: BaseLayout.astro links it
for Astro pages, the legacy root styles.css @imports it.
This changes how every page renders. That is the point, and it is the one
sanctioned visual change in the migration — screenshots taken before today show
Arial and are no longer a valid baseline. The three governing documents that
said "do not add a webfont" are updated so the next design-system-keeper does
not undo this.
Adds .stylelintignore, mirroring .prettierignore's legacy list for the same
reason: staging the minified styles.css to change one declaration produced ~180
declaration-block-single-line-max-declarations errors and blocked the commit.
public/fonts/fonts.css is deliberately excluded from that ignore list.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
AI For Dummies
A lightweight, presentation-style field guide to AI-assisted engineering.
It explains how to combine a strong planning/review model with faster workers,
reusable skills, subagent handoffs, Git worktrees, and explicit verification. An
interactive field kit compares common behavior skills such as ponytail-lite,
caveman, unlazy, research, debugging, and review. The skill-forge workflow
covers discovery, triggers, package anatomy, progressive instructions,
structural validation, and behavioral iteration. The hands-on lab provides a
tiny starter project and copy-ready baseline and skill-enabled prompts for a
short side-by-side exercise. An interactive model gearbox separates capability
tier from reasoning effort across OpenAI, Claude, and Gemini, and every featured
skill links to a pinned source with an approval-first installation prompt.
Run locally
This is a dependency-free static site:
python3 -m http.server 4173
Then open http://localhost:4173.
Verify the content and interaction contracts with:
pnpm run verify
Project structure
index.html— default route map and focused chapter navigationfull-guide/— the complete bilingual presentation, with responsive audit overridesstyles.css/app.js— editorial visual system and bilingual field-guide interactionsresponsive.css— interactive diagrams and Full HD-to-4K adaptationsdocs/references/— bundled research sources and notesdocs/operations-guide.md— canonical SilverBullet operations and skills guidehands-on/starter/— dependency-free Tiny Tasks exercisehands-on/rules/— dependency-free Guardrails lab; toggles rule sources into the promptrules/— bilingual case study of skills, CLI ratchets, Husky, and PR reviewskills/— reusable design and rules-case-study skills, plus an interactive package anatomy explorerskills-review/— static review desk for submitted skills; its reader vote widget calls the separatevote-servicevote-service/— small Go API + Kubernetes manifests backing the skills-review vote widget (seevote-service/README.md)GATES.md— acceptance ledger for the project
Publishing
The Gitea instance has a Pages Server configured to publish a repository’s
pages branch under pages.marcospaulo.dev.br. The intended site address is:
https://netcracker.pages.marcospaulo.dev.br/ai-for-dummies/
If the URL is not available yet, verify that the pages branch exists and that
the repository’s pages branch exists. Gitea itself does not provide a built-in
Pages server; this setup uses the instance’s separate Pages Server and Actions
deployment path.
For the complete authoring, verification, publication, rollback, worktree, and skill workflow, see docs/operations-guide.md.
Reader voting on the skills-review desk
skills-review/ is static, so its "which draft would you ship?" vote widget
calls a separate stateful service — vote-service/, a small Go API on its own
pod, one vote per visitor enforced server-side by IP (a MAC address is never
visible to a server across the internet, so it cannot be used). See
vote-service/README.md for the API, the anti-abuse
design, and the build/push/deploy steps; skills-review/index.html sets
window.SKILLS_REVIEW_VOTE_API to point at it once deployed.
Research
See docs/references/README.md for official Claude, Codex, and Git documentation. The additional reading path bundles 12 verified articles and guides, including Medium and practitioner sources. See model routing for current provider controls and verified skill sources for commit-pinned provenance.
Rules and enforcement case study
Open /rules/ for a concise walkthrough grounded in the netcracker/interview
repository. It shows how AGENTS.md, project-local skills, machine-readable
repo ledgers, a UI contract ratchet, lint-staged, Husky, commitlint, specialist
verifier agents, and PR review reinforce one another. Every example links to its
source file in Gitea, and the page includes a copy-ready prompt for mapping the
same layers in another repository.
The implementation patterns are also packaged as project-local skills in
skills/. Use editorial-playbook when adding chapters or
sections, and rules-case-study when turning repository controls into a
source-linked teaching page.