creative-project

Creative project

1. Understand the request before choosing a look. Identify the deliverables, intended audience, exact copy, dimensions/crop requirements, and what the person wants preserved or changed. For an edit, resolve the named candidate or source attachment, not the newest image. Use available project context before asking questions. Make reasonable reversible assumptions; ask one focused question only when a missing decision would materially change the work. Check: the requested outcome and still-active constraints are clear.

2. Inspect the actual visual references. For requests such as “use the designs in this repo,” locate relevant artwork, finished layouts, editable sources, and project guidance in the authorized workspace. Inspect representative full compositions as images, not just filenames, source code, isolated crops, or color samples. A poster's character grid, typography, hierarchy, and negative space can matter more than its pictured subject. Use a labeled contact sheet when comparing several sources helps; keep important details readable. Follow the active image-reading tool's schema. A file listing or image-loading acknowledgment is not an aesthetic assessment. Check: observations identify the actual reference compositions and their visual treatment.

3. Choose a direction from those observations. Separate what the references show from your proposed interpretation: medium, typography, geometry, composition, texture, palette, and visual hierarchy. Preserve an existing design system unless the person requests a departure. Do not reinterpret every reference as support for a mascot, palette, slogan, or layout you already invented. Assign each selected input a purpose: style reference, composition reference, identity reference, edit target, or supporting content. A new design may use references without being an edit of their subject. Check: the proposed treatment follows the request and each reference has a reason to be used.

4. Keep revisions and related outputs coherent. For a substantial multi-output or multi-turn project, maintain one concise named review document alongside the deliverables. Record the current brief, stable candidate names, the selected sources and their purposes, protected elements, rejected directions, latest requested changes, and the current output for each deliverable. Link existing files/attachments rather than copying the conversation or creating another media store. For a simple one-image request, the conversation can carry this context; do not create a project manifest unnecessarily. Reopen the current brief and relevant visuals on continuation or after context loss. Never infer human approval from recency, generation success, or delivery. Check: “revise B” and the current icon/header/poster resolve unambiguously.

5. Use the appropriate creation path. Prefer editing existing SVG, HTML/CSS, canvas, or other native sources for deterministic typography, ASCII/character grids, precise layouts, and work extending those assets. Use the available image-generation/editing tool for requested raster illustration, photography, textures, or image transformations. Do not replace requested raster artwork with a low-fidelity code placeholder, or rasterize an editable design without a reason. Inspect unseen local edit targets first. Pass the selected image inputs explicitly using the tool's advertised reference mechanism; earlier inspection does not automatically forward them to a generator. Check supported provider/model capabilities and returned dimensions rather than assuming an option worked. Check: the chosen path preserves the requested medium and the actual request includes its intended references.

6. Create and inspect the result. Follow the active tool's synchronous or background completion contract. When the generator supports privately held review candidates for this chat, choose that mode before generation, inspect the retained candidate through its advertised interface, then explicitly release only the current result for delivery. Otherwise follow automatic delivery without promising that inspection can withhold an attachment already sent. Do not restart a pending task because a person asks for progress. Inspect completed outputs as images against the current request and selected references: subject, medium, composition, typography and exact copy, protected elements, crop safety, and requested dimensions. Judge layout at its intended use size, not only zoomed in. State an unavailable visual inspection honestly; filenames, successful execution, and programmatic dimensions do not prove the design looks right. Check: each candidate has an observed result and any unmet requirement is identified.

7. Revise deliberately. For a local correction, describe both the change and the elements that must stay unchanged. For a major style reset, release rejected style/composition references and conflicting self-imposed constraints, while preserving still-active copy and requirements. Inspect the revised result again. Use supported exact-task supersession or review controls when available; do not assume a new request cancels an older job, an abort retracts a delivered image, or “latest wins” applies to independent requests. Keep a late obsolete result distinct from the current design. Check: the next request addresses the feedback without silently reverting accepted work or reusing a rejected direction.

8. Deliver usable work. Show the requested artifacts through the conversation's supported attachment/preview path, not merely a local path or a claim that they exist. Reuse host-delivered attachments rather than sending them twice. Label candidates and meaningful revisions concisely. Keep project-bound final assets and useful editable sources in the authorized project/workspace, not only temporary generation storage; preserve requested output formats and names. Update the review document when one exists, distinguishing current, rejected, superseded, and explicitly approved work. Do not publish to a public account or change sharing permissions without that separate authority. Check: the person can inspect the right result and the project can use the retained files.