# Blog design — agent rules

Design and content rules for agents writing tinqs/blog posts.

## Voice

- **Confident, shipped.** Every feature is presented as built, complete, and working. Never "we plan to," "we're working on," "next we'll."
- **No evolution narrative.** Don't tell the "first we tried X, then we fixed Y" story. Present the final design as if it was the plan from day one.
- **External audience.** Readers are game developers and technical audiences outside Tinqs. No internal project names, no team org charts, no "Ozan decided" or "Uygar built."

## What to never mention

- **Asset pack names or vendors.** Polyperfect, Low Poly Ultimate Pack, Quaternius, Kevin Iglesias, etc. Say "our animal models" or nothing at all.
- **Unity import details.** FBX source format, `.anim` files, `.meta` clip ranges, `isleborn/` paths.
- **Internal tooling specifics.** `migrate_animals.py` internals, Blender pipeline details, repo paths.
- **Things that failed or were removed.** Failed migrations, broken assets, animals we deleted, bugs we shipped then fixed. If you must mention a bug, frame it as a design insight learned during development — never "we shipped this broken."
- **Roadmaps, tiers, trade-offs, future plans.** The post describes what exists. No "Tier A/B/C," no "recommended build order," no "what's next."

## Structure

- **Title:** technical, specific, bold. "How We Made 1,000 Animals Animate Without a Single Skeleton" not "Crowd Animation Update."
- **Opening:** state the problem (what stock Godot can't do), state our solution, give the numbers.
- **Body:** architecture, shader code, data flow, VRAM math, benchmarks. Ground everything in numbers.
- **Closing:** where to get it, what it drives (Ariki), related posts. No roadmap.

## Numbers rule

Every claim about performance, VRAM, or scale must cite a measured number. "60 FPS at 1,000 agents on M1 Pro" not "great performance." "1.6 MB per type" not "tiny VRAM."

## Code

Shader code and architecture diagrams are encouraged — this is a technical blog. But keep code blocks focused on the key insight, not the whole file.