Designing a Prompt Contract for a Photo-to-Coloring-Page App

A photo-to-coloring-page feature sounds like a small image-generation task: send a photo, ask for outlines, and return an image. The more interesting engineering problem is defining what the output is allowed to change.

Should a cartoon style add more detail? Should tracing use solid outlines? Can an optional text field override the requirement for a printable page?

This case study uses the prompt composer in my project, Picture To Coloring Page, as a concrete example. I maintain the project. The focus here is the server-side contract and its limitations; the site link identifies the project discussed.

1. Separate the controls before composing the prompt

Three settings can sound similar while controlling different properties:

Control	Responsibility	Example
Art style	Shape language and contour character	Natural proportions versus rounded cartoon forms
Line rules	Stroke weight and continuity	Continuous outlines versus dashed tracing guides
Detail level	Number and size of regions	A few large regions versus more interior contours

Keeping these concerns separate makes conflicts easier to identify. A cartoon style should not silently select a higher detail level. A richer detail setting should not introduce shading or dense textures that undermine the output format.

In the composer, each setting contributes a distinct instruction block. The combined prompt explicitly states that style must not override line rules or force additional detail.

This is a design constraint, not a guarantee that every model will follow it. It gives us a clearer target for reviewing outputs.

2. Make exceptions explicit

Tracing illustrates why simply concatenating every setting is insufficient.

The tracing style in this project requests thin, pale, light-gray dashed guides. Ordinary coloring output requests black outlines. If both instructions are appended without precedence, the model receives conflicting requirements.

The composer therefore selects tracing-specific line instructions instead of the ordinary line-mode block. It also states that those tracing rules take precedence over requests for solid outlines.

Conceptually, the composition looks like this:

// Simplified illustration of the composition boundary.
const lineRules = isTracing
  ? tracingGuideRules
  : lineModeRules[mode];

const prompt = [
  outputTask,
  styleRules[style],
  precedenceRules,
  lineRules,
  detailRules[detail],
  outputGuardrails,
].join(" ");

An explicit branch is easier to reason about than hoping the model reconciles contradictory fragments consistently.

3. Give the reference photo a clear role

Reference-based conversion and text-only generation need different instructions.

When a photo is present, the composer asks the model to preserve the main subject's identity, pose, and composition. Style can simplify or gently exaggerate forms, but should not replace the subject or invent unrelated scenery.

Optional user text becomes secondary subject guidance. Without a photo, that text supplies the subject to draw.

This avoids treating an attached photo as a vague inspiration image when the intended task is conversion. It also makes the expected behavior reviewable: did the result preserve the recognizable subject and composition?

4. Treat free text as data

An optional subject field is untrusted input. The project normalizes that text before inserting it into the composed prompt:

• Remove control characters.
• Collapse whitespace.
• Neutralize strings that imitate the subject-block delimiters.
• Enforce a 500-character limit.

The text is then wrapped in a labeled block with instructions to treat it as a subject description rather than as a new role or a replacement task.

These steps improve input hygiene and make the intended boundary explicit. They do not make prompt injection impossible. Delimiters and instruction wording are not a security boundary; authorization and other application restrictions must remain enforced outside the model.

5. Distinguish instructions from output validation

The composer requests a white background, no shading, no color fills, and no text overlays. Those are requested properties, not evidence that a generated image satisfies them.

A useful evaluation checklist follows directly from the contract:

• Does a reference-based output preserve the subject and pose?
• Does the line treatment match the selected mode or tracing override?
• Does changing detail level change region complexity without changing the line treatment?
• Is unwanted shading, text, or background clutter present?
• Does subject text that asks for another output format fail to redirect the task?

These are suggested evaluation cases, not measured model-performance results. Static inspection of a prompt composer cannot establish conversion quality or print quality. That requires inspecting generated outputs, including the intended print size.

The reusable idea is to assign every control one responsibility, define precedence where responsibilities overlap, and turn the resulting contract into concrete evaluation questions. That applies to other image tools too: the interface becomes easier to explain when each option has a predictable job.