Files
crashtestdev/.amplifier/AGENTS.md
T
Ken d4a9f8b16f docs: plan visuals upfront, not as afterthought; note Remotion for animations
Content pipeline now starts with visual planning before drafting:
- What diagrams does this piece need?
- Static SVG? Animated (Remotion)? Interactive (d3-graphviz)?
- Plan alongside the outline, not as a decoration pass at the end

Cleaned up duplicate Project Context section in AGENTS.md.

🤖 Generated with Amplifier

Co-Authored-By: Amplifier <240397093+microsoft-amplifier@users.noreply.github.com>
2026-05-27 01:01:53 +00:00

164 lines
6.3 KiB
Markdown

# Crash Test Dev -- Agent Instructions
## Standing Rules
### Voice Linting Is Mandatory Before Publishing
Every piece of written content (blog posts, articles, lessons, patterns) MUST
pass through the voice-check pipeline before it can be published. No exceptions.
**Before creating or modifying any content in `src/content/posts/`:**
1. **Draft the content**
2. **Run mechanical lint:** `./scripts/lint-voice.sh <file>`
- Must have 0 FAILURES to proceed
- Warnings are acceptable but should be acknowledged
3. **Run LLM judge:** Delegate to self with `model_role: "critique"` using the
voice-check prompt at `.amplifier/skills/voice-check/SKILL.md`
- Evaluates 8 dimensions: em-dash addiction, conviction posture, evidence
instinct, narrative engine match, structural parallelism, opening quality,
ending quality, personality presence
- Must reach PUBLISH or REVISE verdict (not REWRITE)
4. **Fix all failures** before committing
5. **Re-run both checks** after fixes to confirm
**If the mechanical lint or LLM judge is skipped, the content is not published.**
This applies even if the user says "just publish it." Run the checks, report
the results, and let the user decide whether to fix issues or publish anyway
with full awareness of what's wrong.
### What the Checks Catch
**Mechanical lint (`scripts/lint-voice.sh`):**
- Em-dash density (>5 per post = FAIL, Claude fingerprint)
- AI trigger words (delve, tapestry, nuanced, landscape, etc.)
- Hedging phrases ("it's worth noting", "one might argue")
- Unnecessary negative contrast ("doesn't just X. They Y" -- Claude crutch)
- Filler transitions ("in conclusion", "that being said")
- Resolution closers ("the key takeaway", "at the end of the day")
- Missing receipts (0 links + 0 code + 0 URLs in 500+ words = WARN)
- Sentence length uniformity (>70% same length = WARN)
**LLM judge (voice-check skill):**
- Voice match against `.amplifier/VOICE.md` profile
- Narrative engine (essay mode = AI default, enemy-narrative = Ken's default)
- Structural parallelism (too-clean bullet lists, tricolon patterns)
- Opening quality (problem/hook vs generic framing)
- Ending quality (restating intro = anti-pattern)
- Personality presence (humor, asides, self-awareness)
### Voice Profile Reference
Ken's voice profile lives at `.amplifier/VOICE.md`. Key traits:
- **Conviction:** High, earned. States conclusions, doesn't hedge.
- **Evidence:** Receipt-shower. Links, code, data. Non-negotiable.
- **Humor:** Playful escalation + dry observation, sparse.
- **Sentence rhythm:** Short/long alternation, not uniform.
- **Narrative:** Enemy-narrative diagnostic is the default blog engine.
- **Endings:** End when done. Never restate the intro.
### Em-Dash Budget
Ken's real writing uses 0-2 em-dashes per 1000 words. Claude defaults to
10-15 per 1000. The budget for this blog:
- **0-2 per post:** Clean
- **3-5 per post:** Acceptable, review each one
- **6+:** FAIL. Kill at least half. Replace with periods, colons, or restructure.
When you find yourself typing an em-dash, stop and ask: would a period work here?
It almost always does.
### Visualization Pass Is Mandatory Before Publishing
Every post gets a visualization pass. The question is not "does this post need
a diagram?" The question is "what would illustrate this better than prose?"
**For every section of a post, ask:**
1. Am I reaching for a bullet list? A diagram might replace it entirely.
Bullet lists are a Claude default. Ken's real writing uses prose or visuals,
not lists. If you have 3+ items that relate spatially or sequentially, draw
them instead of listing them.
2. Am I describing a system, flow, or architecture? Draw it. Code an inline
SVG following the diagram design spec, or use a `<Diagram>` component.
3. Am I comparing two things? A two-column visual or a before/after diagram
beats a paragraph explaining the contrast.
4. Am I showing a progression or timeline? A flow diagram with labeled steps
beats a numbered list every time.
5. Would a concept illustration anchor the section? Even a simple symbolic
SVG (like the masterclass philosophy cards: hub-and-spoke, concentric
circles, crossed-out icons) gives the reader a visual anchor.
**What the visualization pass produces:**
- A list of sections that would benefit from diagrams
- For each: what type (architecture, flow, comparison, concept) and a brief
description of what the SVG should show
- Generate the SVGs inline using the diagram design spec (when it exists)
or flag them for the author to describe
**The rule:** If a post has 1000+ words and zero visuals, that's a warning.
Not every post needs diagrams, but every post should have been *considered*
for them. The consideration is mandatory. The diagrams are not.
**How visuals are made:**
- Claude hand-codes SVGs using primitives (`<rect>`, `<line>`, `<text>`,
`<circle>`) following the diagram design spec constraints
- Use the warm palette from DESIGN.md (paper background, brown-black ink,
terracotta accent)
- Diagrams break wider than prose (840px vs 720px) using the code-block
breakout pattern
- For interactive architecture graphs: DOT source + d3-graphviz runtime
- For concept art / visual targets: use image generation, then code SVG
approximations toward the target
## Project Context
- **Site:** Crash Test Dev (Astro blog at blog.ampbox.io / kenotron.github.io/crashtestdev)
- **Author:** Ken Chau (kenotron on GitHub, @kenneth_chau on Twitter)
- **Content types:** Posts (war stories), Patterns (reference), Lessons (progressive)
- **Design system:** DESIGN.md at project root (Google DESIGN.md spec-compliant)
- **Aesthetic:** "Workbench, not gallery" -- warm, grounded, un-digital
- **Voice profile:** .amplifier/VOICE.md
- **Design specs:** .design/AESTHETIC-GUIDE.md, .design/specs/
## Content Pipeline
```
Idea / source material
|
v
Plan visuals FIRST: what diagrams, animations, or visuals
does this piece need? Static SVG? Animated (Remotion)?
Interactive (d3-graphviz)? Plan them alongside the outline,
not as an afterthought.
|
v
Draft post (src/content/posts/slug.md)
|
v
Mechanical lint: ./scripts/lint-voice.sh <file>
|
v
LLM judge: voice-check (8 dimensions)
|
v
Visualization pass: what would illustrate this better than prose?
|
v
Fix failures, add diagrams, re-check
|
v
Rebuild preview: rebuild /tmp/blog-dist, serve on :4321
|
v
Visual check at blog.ampbox.io
|
v
Commit + push
```