The Wake-Up Call: Five Specs in Five Days
Last quarter, I had five art asset requests land on my desk. Each one represented about 32 hours of development work—modeling, texturing, integration, the works. Under my old workflow, each spec took a full day to write, from initial business review to a polished PRD plus reference mockups. Five specs meant five days of grinding, and that was if nothing exploded.
Then I switched my process. The same five requests? I handled them in a single morning, running them in parallel. The output quality was on par, and I had time to actually review and refine instead of just surviving.
People keep asking me if I found some magic prompt or a better model. The truth is less glamorous: it’s about the knowledge base you feed the AI and the production pipeline you design around it. Here’s what I learned.
Stop Tuning Prompts, Start Building a Knowledge Base
The typical reflex when an AI spits out a generic, off-base spec is to tweak the prompt—add more constraints, pile on rules, write longer instructions. I did that for months. The results barely moved.
The problem wasn’t the prompt. General-purpose LLMs are already good at logic and articulation. What they lack is your domain context. If you don’t give them your business rules, your historical decisions, your field definitions, and your scene boundaries, they’ll just hallucinate something that sounds plausible but has nothing to do with your project.
My core principle is simple: good stuff in, good stuff out. Build a high-quality knowledge base first, then let the agents work with that context. It’s more reliable than a hundred prompt tweaks.
Feeding the Beast: From Scans to Markdown
Getting the knowledge base right took several iterations. I started by dumping scanned PDFs and images into it. Big mistake. OCR errors mangled field names, formatting chaos confused the AI, and recall was a disaster.
Next I tried Word docs and spreadsheets. Better, but still noisy—too much layout fluff, low information density.
Finally, I settled on pure Markdown. Clean structure, no redundant formatting, clear hierarchy. It’s the closest thing to a format the AI can just read and understand without tripping over itself.
But Markdown alone wasn’t enough. I broke down my historical specs and operation manuals into separate MD files by subdomain, then had the AI do a second pass: unify terminology, extract core rules, map scene boundaries. After that, I imported everything into Dify to build a callable knowledge base.
Dify’s value is in chunking, recall tagging, sub-chunk management, and API access. It’s not just a document store—it turns knowledge into searchable snippets that agents can pull on demand, keeping irrelevant info out and saving tokens.
Your Knowledge Base Is a Living Thing
Treating the knowledge base as a one-time import is the second mistake. I now run it like an asset that needs constant upkeep. After each new spec is delivered, I extract the updates—new rules, changed fields—and merge them into the relevant subdomain. I log the update time so I always know what’s current.
When terminology conflicts show up, I have the AI flag them during the cleanup phase, and I manually confirm the standard before anything goes into the base.
If an AI output looks wrong, I don’t rewrite the prompt. I ask it: “Which knowledge snippet did you base that on?” That pinpoints whether the knowledge itself is faulty or the recall grabbed the wrong chunk. Fix the root cause, not the symptom.
Prompts are tricks. Knowledge is your moat. Tricks are easy to copy; a well-curated domain base isn’t.
Three Agents, Three Roles: My AI Art Team
With the knowledge foundation in place, I designed the production flow. Instead of one monolithic agent, I split the work into three specialized agents, each mirroring a real role in my art team: research, design, and QA. They work in sequence, like an assembly line.
1. The Research Agent: Your Art Direction Analyst
This is the first stop. Its job is to make sure we’re heading the right direction. It reads the knowledge base, brainstorms around my rough idea, and asks questions to fill gaps—clarifying business goals, defining scene boundaries, and so on. It outputs a structured design framework.
I gave it two skills: one for knowledge retrieval (so it stays grounded) and one for divergent brainstorming (so it surfaces angles I hadn’t thought of).
But a human must stay in the loop here. The AI can brainstorm and structure, but priority calls, core value judgments, and trade-offs are mine to make.
2. The Design Agent: Your Art Spec Writer
Once the framework is approved, the second agent takes over. It pulls the framework, applies the SPEC format rules, and produces a clean Markdown spec plus an HTML prototype.
SPEC is different from a traditional PRD. It strips away all the narrative fluff—background stories, interaction explanations, human-friendly padding. It only includes what the downstream developers need: core logic, workflows, boundary conditions, acceptance criteria. The prototype is a separate HTML file, linked but not embedded, so machines can read the structure directly.
This step is where the time savings really pile up. Writing docs and drawing mockups used to eat hours. Now the AI does the grunt work, and I review and tweak.
3. The Review Agent: Your QA/Art Lead
The final agent acts as a quality gate. It checks the spec and prototype for format compliance, logical gaps, unclosed scenarios, and potential business risks. It flags issues and sends them back for human review.
This step is non-negotiable. Even with the first two agents, you need a safety net. But instead of gathering the whole team to hunt for problems, the AI catches the obvious stuff first. I only step in for the gray areas that need judgment.
Because each agent is independent, I can run multiple pipelines in parallel. That’s the real reason I got five specs done in one morning—not magic, just concurrency.
Why I Ditched Superpowers for a Custom Rig
You might ask: why not just use Superpowers? It covers everything from brainstorming to coding to testing. I tried it. It’s powerful, no question. But for a game art lead who only needs to produce specs, it’s overkill.
Superpowers is built for full-stack developers. It assumes you’re taking an idea all the way to deployed code. My scope ends at the spec—the downstream coding is someone else’s job. So I was paying token costs for steps I didn’t need, and the review chain was longer than necessary.
My custom framework covers the front half—brainstorming, framework, spec, review—at the same quality level, but it cuts everything past the spec. The benefits? It’s lighter, starts faster, fits my daily workflow, and uses fewer tokens per run. And because it’s lean, I can spin up multiple instances without breaking a sweat.
Tools aren’t good or bad; they’re just fit or not. Superpowers is a godsend for developers. For a spec-focused art lead, a lean custom pipeline wins.
When the Knowledge Base Holds You Back
No method is universal. This knowledge-first approach shines when you have historical data—existing art assets, style guides, pipeline docs. It keeps the AI grounded so it doesn’t produce “expert-sounding nonsense.”
But for a brand-new IP, a new art style, or a 0-to-1 project with zero history, the knowledge base can become a straitjacket. Old knowledge will box the AI into old patterns, stifling innovation.
In those cases, I switch modes. I spin up a separate “research agent” that pulls external references—industry trends, competitor art, style references—plus whatever new context I feed it. That builds a fresh baseline before the spec machinery starts.
Simple rule: use your knowledge base for incremental work, use external research for greenfield work. Don’t try to hammer every nail with the same tool.
What This Means for Game Art Pros
Back to that “week in a morning” result. It’s not a miracle. It’s the sum of a solid knowledge base, a clear division of AI labor, and a pipeline that runs parallel when needed.
I’m convinced that the core skills for art leads—and product folks in general—are shifting fast. Being good at writing docs or drawing clean mockups won’t set you apart anymore. AI does that faster and with perfect consistency.
The real differentiators now are:
- Building and maintaining a domain knowledge base that AI can actually use.
- Designing a workflow that breaks complex requests into steps and delegates them to the right AI agents.
AI isn’t a document generator. It’s a team you can direct. The sooner you treat it that way, the more time you free up for the parts of the job that still need a human—like deciding what to build and why.
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!