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.

2.1 KiB Raw Blame History