diff --git a/skill/agents/impeccable-asset-producer.md b/skill/agents/impeccable-asset-producer.md index e8e668296..7f0dbbdfc 100644 --- a/skill/agents/impeccable-asset-producer.md +++ b/skill/agents/impeccable-asset-producer.md @@ -67,7 +67,7 @@ Codex: the imagegen skill's built-in `image_gen` path is the native tool here; p 7. Remove baked-in UI text, navigation, buttons, body copy, and mock chrome unless the text is part of the asset. 8. Think through the final DOM/CSS representation before generating. If CSS will own radius, clipping, shadows, borders, perspective, responsive cropping, captions, or card frames, do not bake those into the bitmap. -9. Save outputs non-destructively in the requested project directory. +9. Save outputs non-destructively in the requested project directory, and leave the intent with the file: when the generation tool does not write a prompt sidecar itself, write `.json` with the prompt beside each produced asset, because the build thread composes what you made and needs to know what it is looking at. 10. Compare each output against its source crop, opening every image by its workspace-relative path; sandboxed viewers reject absolute paths. If a review/QA tool is available, run it before the final manifest, then retry each major/fatal finding once before finalizing. Use `direct` only for provided source assets that can already ship after crop tightening, conversion, compression, or naming. Do not ship a small crop from the full-page mock as `direct` just because it looks close. diff --git a/skill/reference/visualize.md b/skill/reference/visualize.md index 4ee315e13..3d43ff15f 100644 --- a/skill/reference/visualize.md +++ b/skill/reference/visualize.md @@ -8,6 +8,7 @@ The purpose of a probe is to test composition, narrative, hierarchy, density, fo Render three distinct high-fidelity north-star comps of the requested surface, with whatever generation capability exists, saved under `.impeccable/mocks/` so they survive the session; record the approved comp's path in the surface brief. Open every image you produce or reference by its workspace-relative path, never an absolute one: sandboxed viewers reject absolute paths, and everything under the project root has a relative path. Base them on the real content and the surface concepts already developed with the user. Three is the number: one comp invites rubber-stamping, and the spread between three is what surfaces the composition worth building. A decision-page sketch is not a probe: it chose the direction at deliberately unfinished fidelity, so the three comps render regardless, and the chosen card's sketch seeds at most one of them. +- A comp is a designed page, not a picture of the subject. State the page's literal skeleton in the generation prompt, navigation bar and its items, headline block and its scale, each section in order, the footer, because a prompt that leads with the world's atmosphere gets a vignette back: the model paints the fish market instead of the fish market's website. Self-check every render: if it could hang as a poster, or reads as a photograph or scene with some text on it, it is not a comp; regenerate with the layout scaffold stated more literally. - When the user shortlisted multiple concepts, spread the three across them. - When one direction is committed, vary the structural uncertainty an image can resolve: topology, sequence, density, hierarchy, focal composition, or interaction framing. - Show enough beyond the opening moment to prove the concept can govern the whole requested surface. @@ -33,6 +34,8 @@ Treat the comp as a north star, not something to trace, and know what that allow ## Produce only the assets the build needs +Generation context is part of the asset: the thread that wrote a prompt knows what the image contains, why, and how it is meant to sit in the layout, and a build composed by a thread without that knowledge places assets it does not understand. So prefer generating build-critical imagery in the build thread when the budget allows, and when a subagent produces assets instead, every asset must carry its prompt (the generation sidecar or the manifest's prompt_used), and the builder reads those prompts before composing a single one of them. + When clean raster ingredients are required and the harness runs subagents, use the shipped asset producer, `impeccable-asset-producer` (`impeccable_asset_producer` in codex): give it the approved comp, output paths, required dimensions and formats, transparency needs, crop notes, and what must remain semantic code. Otherwise produce the minimum required assets in the current thread by the book: load [degraded/asset-producer.md](degraded/asset-producer.md) and follow it inline, with whatever generation exists, the native tool or generate-image.mjs. Return to [new-work.md](new-work.md) for the direction contract, implementation, and the finishing pass. diff --git a/skill/scripts/generate-image.mjs b/skill/scripts/generate-image.mjs index 873bc84c8..12e29b78f 100644 --- a/skill/scripts/generate-image.mjs +++ b/skill/scripts/generate-image.mjs @@ -229,4 +229,9 @@ if (!b64) { process.exit(1); } fs.writeFileSync(out, Buffer.from(b64, 'base64')); -console.log(`IMAGE: ${out} (${size}, ${quality}, gpt-image-2, billed to your OpenAI key)`); +// The prompt travels with the asset: any thread that later composes this image +// can recover the intent behind it without the generating thread's context. +try { + fs.writeFileSync(`${out}.json`, JSON.stringify({ prompt, createdAt: new Date().toISOString(), tool: 'generate-image.mjs', model: 'gpt-image-2' }, null, 2)); +} catch { /* sidecar is best-effort */ } +console.log(`IMAGE: ${out} (${size}, ${quality}, gpt-image-2, billed to your OpenAI key); prompt sidecar at ${out}.json`);