concept-art

name	concept-art
description	Compose concept-art briefs from the project's GDD and run the generate→review→lock/regen loop on a persistent concept board (docs/concept-art/board.md).
model	sonnet
allowed-tools	Read, Write, Edit, Glob, Bash, AskUserQuestion, Skill
argument-hint	[focus, e.g. 'origin pet', 'chassis silhouettes', 'round 2']

Godot — Concept Art

Turn a project's GDD into concept-art briefs, generate against them, and run the review → lock/reject → regen loop on a persistent concept board. This skill is generic; the project supplies the content (its docs/gdd/ notes) and the image backend (its .claude/imagegen/ profile, consumed via the gen-art skill).

Why this shape (read before running)

• Briefs come from the GDD, not from taste-in-the-moment. Concept art exists to test the documented visual direction (register, silhouette rules, palette discipline). A brief that can't cite the GDD note it tests is exploration without a hypothesis — fun, but it can't be locked or falsified. Every brief carries acceptance criteria in the GDD's own language.
• The board is the single source of verdicts. Same law as the GDD's Open-Questions note: one canonical home, stable IDs, statuses + reasons live there. The payoff is verdict memory — a regen round reads why C3 was rejected and writes a brief that states the delta, instead of regenerating blind and re-rolling the same failure.
• Explore cheap, commit late. Rounds are capped small; the cloud lane at low quality is for falsifying register questions fast, the forge lane is for volume once a register survives. Locked survivors get promoted (copied to the project's tracked final destination) — raw generation output is disposable and usually gitignored.

The loop

1. Load context. Glob docs/gdd/ and read the visual-direction / theme / subject-schema notes (whatever the project names them). Read docs/concept-art/board.md if it exists — its existence means this is a continuing round, and its verdicts are input, not history. No docs/gdd/ at all → this project isn't GDD-driven; say so and stop.

2. Determine the round.

   • Fresh board: the matrix covers the subjects the GDD says matter first (e.g. the key creature, the silhouette set, one environment/mood).
   • Regen round: only 🔁 iterate / ❌ rejected / new subjects enter the matrix, and each brief names what it inherits ("C3 round-1 rejected: read as anthro → this round forces quadruped stance, adds negative"). Locked concepts are done — never re-generate them without being asked.

3. Build the brief matrix — rows = subjects, columns = register variants (2–3 deliberate deltas within the GDD's stated register, so a round answers a question: "warmer vs cooler", "minimal vs mid fidelity"). Each cell = one brief per references/brief-template.md. Cap a round at roughly 6–12 generations — a bigger matrix means you're not sure what question you're asking.

4. Confirm the matrix with the user before generating. Show the table (subjects × variants + what each tests). The user may cut, add, or re-scope. Never fire generations unconfirmed.

5. Route each brief through gen-art (invoke it as a skill — it discovers the project's imagegen profile and owns the backend mechanics):

   • cloud lane for exploration rounds — synchronous, iterate while reviewing; keep the quality ladder (low → review → high only on survivors).
   • forge lane for volume once the register is locked — tickets resolve asynchronously (/gen-fulfill on the hub); write the board entries as 🟡 proposed (ticket queued).
   • No imagegen profile → don't improvise a backend: write the briefs to the board marked manual, tell the user they're ready for outside generation, and stop after the board write.

6. Write the board at docs/concept-art/board.md per references/board-template.md — one entry per concept (stable C# ID), the brief, image paths + backend/quality, status 🟡 proposed.

7. Review pass. Present results grouped by the question each variant tested. Capture the user's verdicts — ✅ locked / ❌ rejected (reason mandatory — the reason is the next round's input) / 🔁 iterate (+ what to change). Write verdicts to the board. Copy locked images to the project's tracked destination (the profile's dest_final or equivalent).

8. Close the round. Summarize: verdicts, what the round settled about the register, and the suggested next-round matrix (from the 🔁/❌ deltas). If a verdict settles something the GDD leaves gate-deferred, say so — updating the GDD is the write-gdd skill's job, not a silent side-effect here.

Bilingual (VN/EN) — match the language the user writes.

Rules

• Board statuses: 🟡 proposed · ✅ locked · ❌ rejected + reason · 🔁 iterate + delta. A rejected entry without a reason is a bug — it starves the next round.
• IDs are stable — one C# per falsifiable question, not per subject. A cell keeps its C# across rounds; rounds append attempts under it. When one subject legitimately fans into simultaneous variants in the same round (e.g. a fidelity ladder over the same creature), each variant is its own cell with its own ID — verdicts must be independently lockable — and the board groups them under a shared subject heading.
• Dry-run honesty. --dry-run (or a user asking to "see the briefs first") = do steps 1–4 and 6, no generation. Entries carry their real intended lane (the round fires on it once confirmed) with status 🟡 proposed (dry-run). This must work with zero backend configured — only in that case is the lane itself manual.
• Inference is visible, never silent. Where the GDD is silent and a brief needs something it doesn't provide (a body plan, a canonical subject assignment), record the guess in the board's Drafter assumptions block for the user to confirm or correct — the skill tests documented direction; it must not quietly author new design.
• Stay art-light. Briefs describe register tests, not shipping assets. If the user starts requesting per-asset production art here, point at the project's art pipeline instead.