SuperAPI AI Directory

portrait-retouch

Design & creation

View repository

Updated 10-25 03:19

About this skill

Portrait Retouch

Runtime entry: show navigation first

Immediately after this Skill loads, send the user the compact navigation menu in references/navigation.md before inspecting the image, connecting Photoshop, or mutating any file. Recommend AI photo diagnosis as the first step.

  • If the user has not selected a route, stop after the menu and wait for a selection.
  • If the user already explicitly selected a route, show the menu briefly, state the selected route, and continue without asking them to repeat the choice.
  • Do not reveal every upload requirement or implementation detail at entry. Ask only for the inputs required by the selected branch.
  • Do not connect to Photoshop merely to diagnose an image. Follow the Photoshop consent gate in the navigation reference.

AI photo diagnosis is a complete standalone function, not an internal note. Read references/ai-photo-diagnosis.md and return its structured diagnosis report without editing the image. After the report, present the approved next routes: conservative retouch, Photoshop production, AI regeneration, hybrid execution, or stop after diagnosis.

Operating contract

Treat the input as a portrait to improve, not evidence of an objectively defective face. Describe what appears in this photograph and separate it from claims about permanent anatomy.

Match the retouching strength and finish to the user's explicit request. Preserve identity, facial width, age cues, pores, facial hair when present, stable marks, and useful asymmetry. Do not impose a gendered beauty template, V-line, square jaw, large eyes, narrow nose, pointed chin, whitening, or perfect symmetry unless the user explicitly requests an isolated preference preview.

Interpret "修容" as digital portrait retouching when the surrounding request concerns photos, filters, prompts, or image generation. Do not branch into makeup, haircut, grooming, or shooting advice unless the user requests those topics or they are required to explain a capture confounder. Keep hairstyle and hair volume unchanged by default.

Do not infer health, ethnicity, personality, gender identity, or other sensitive traits from appearance. Do not assign an attractiveness score.

Never store API keys or secrets in the skill or output files. Do not upload a private portrait to an untrusted face-morphing website without explicit consent.

Select the mode

  • Diagnosis only: Inspect, measure when possible, and return a correction plan. Do not generate an image.
  • Staged comparison: Use this by default when the user asks Codex to retouch or “make it look better” without already specifying the desired direction. Diagnose first, create isolated previews, return them for comparison, then combine only approved changes.
  • Direct final: Use when the user already specifies the desired lighting, skin, geometry, or finish and asks for autonomous completion. Diagnose internally, apply the requested strength, inspect the result, and iterate when needed without forcing a comparison stop.
  • Fast preview: Use only when the user explicitly prioritizes speed or asks for one image immediately. Diagnose internally first, then make one targeted edit at the requested strength and label it a preview.
  • Deterministic implementation: Use when the user needs repeatability, parameter control, batch processing, or a production pipeline. Prefer landmarks, local warp masks, and separate tone/texture passes over prompt-only regeneration.
  • Photoshop production: Use when Photoshop is available or the user asks for editable masks/layers. Keep the original as a locked identity anchor, separate local geometry from tone/texture, and deliver an editable PSD plus a rendered proof.

If the user asks only for an explanation or diagnosis, do not mutate files beyond an explicitly requested report. If the user requests edited images, completing and saving the previews is in scope.

Load the relevant references

Route reference-image requests

Extract the reference into structured JSON before editing. Treat the reference as a source of visual attributes, not as a source identity to copy.

  • Route colour, tone, lighting, face/body skin rendering, grain, lens character, and effects that do not change scene geometry to a nondestructive Photoshop grade.
  • Route pose, limb action, gaze direction, expression, camera viewpoint, or composition changes that require new pixels to an independent AI-regeneration branch.
  • For mixed requests, regenerate the approved action or composition first, then finish tone and texture in Photoshop.
  • Keep the original portrait as the identity anchor in every branch. Keep the reference subject's identity, facial geometry, body identity, and unique marks out of the transfer.
  • Never infer that the user wants pose, gaze, expression, or anatomy changes merely because they appear in the reference. Require an explicit request for identity-sensitive or geometry-changing transfer.

Workflow

1. Preserve and inspect the source

  1. Confirm that the original image is readable and contains one primary face.
  2. Inspect it at original resolution before commenting on fine features.
  3. Record image dimensions, orientation, crop, and any missing metadata. Do not invent camera distance or focal length.
  4. Establish identity anchors: face width, hairline, hairstyle, hair volume, eye corners, iris size, nose base, mouth, chin, moles or scars, facial hair, ears, expression, background lines, and clothing.
  5. Save requested outputs under output/portrait-retouch_<source-stem>/ unless the user supplies another location. Preserve the original as 00_original.<ext> and never overwrite it.

2. Diagnose before writing a prompt

Analyze in this order:

  1. Capture confounders: near-camera perspective, optical lens distortion, head pose, expression or blink, lighting, white balance, crop, and occlusion.
  2. Global form: face width, upper/middle/lower thirds, cheek-to-jaw continuity, jaw endpoints, and centreline.
  3. Local geometry: eye aperture and shape, eyelids, brows relative to eyes, nose alignment, mouth alignment, and chin alignment.
  4. Tone and texture: under-eye transitions, temporary raised blemishes, permanent identity marks, hotspots, colour variation, pores, facial hair when present, makeup when present, and sharpening.
  5. Uncertainty: mark every conclusion as measured, visually supported, or ambiguous.

Do not write an instruction such as “stronger jaw,” “better nose,” or “more attractive” without first identifying the observed issue, plausible photographic cause, targeted operation, requested amount, locked anchors, and confidence.

When an iBUG/Dlib-style 68-point .pts file is available, run:

python3 scripts/measure_ibug68.py landmarks.pts --image-width WIDTH --image-height HEIGHT --json

Use the measurements as evidence, not as a beauty standard. If landmarks are unavailable, report visual estimates without fabricated precision.

3. Produce an adjustment map

For each proposed change, specify:

Field Required content
Observation What is visible or measured in this image
Likely cause Capture, pose/expression, anatomy, tone, or uncertain
Operation Exact local correction
Strength Relative amount or safe upper bound
Locked anchors Features that must not move or be redrawn
Confidence Measured / visually supported / ambiguous

Default unsupported nose, mouth, chin, forehead, and global face-width changes to zero. Correct local asymmetry toward a midpoint, not toward perfect mirroring.

Treat an explicitly requested unsupported reshape as a user-preference override, not a diagnosis. Do not equate an app slider value such as 20/100 with a literal 20% geometric reduction. Explain the distinction, keep the actual edit within the engineering guardrails unless the user knowingly requests a stronger transformation, and isolate it in a separate preference preview. Do not include that preference in the final version until the user selects it after comparison.

4. Create isolated previews

For a generative editor, create independent branches from the original image so the user can attribute each effect:

  • 01_capture_only: Correct only high-confidence capture or perspective presentation. Do not beautify features.
  • 02_geometry_only: Correct only measured local asymmetry or contour discontinuity. Do not retouch skin or redesign unsupported features.
  • 03_tone_texture_only: Correct only light, colour, temporary blemishes, and micro texture. Do not change geometry.

When the user explicitly asks for a non-diagnostic reshape such as a narrower nose or slimmer face, add 04_user_preference_only from the original. Keep it separate from the evidence-led branches and label it as a subjective requested direction.

Do not recursively use one generated preview as the only source for another. Include the original as the identity anchor in every generative edit. If capture distortion is severe enough to invalidate geometry judgment, produce 01_capture_only first, return it for selection, and re-diagnose the selected result before creating the geometry branch.

For deterministic local warps, sequential nondestructive passes are acceptable because each mask and displacement remains inspectable.

For Photoshop production, map the isolated branches to the layer contract in references/photoshop-uxp-workflow.md. Do not flatten the working PSD or apply a global face-aware preset. Use the companion UXP panel when present to create the identity anchor, local geometry layer, frequency-separated tone/texture layers, and neutral dodge-and-burn layer.

When actual image generation or editing is requested, also load and follow the imagegen skill before calling the image-generation tool. If the user explicitly requests a Meitu one-click baseline, also load meitu-beauty; keep its result as a separate comparison branch rather than treating it as ground truth.

5. Build prompts from evidence

Use the templates in references/prompt-stages.md. Write one prompt per preview. Every prompt must:

  • identify image-left and image-right explicitly, with subject-side labels when useful;
  • state the observed difference and correction direction;
  • change only one module;
  • list identity and scene anchors that must remain fixed;
  • state prohibited compensating edits;
  • instruct the model to reduce the edit rather than alter another feature when a conflict occurs.

Do not rely on adjective stacks such as “handsome, beautiful, masculine, feminine, refined, cinematic.” Translate the desired effect into geometry, light, colour, and texture operations.

6. Inspect and reject failures

Inspect every output at fit-to-screen and original resolution. Reject or redo an output if it introduces:

  • identity drift or a different apparent age;
  • changes to an unrequested nose, mouth, chin, face width, expression, or gaze;
  • copied eyes, perfect symmetry, altered iris size, or new eyelid creases;
  • waxy skin, erased facial hair, whitening, makeup, or synthetic sharpening;
  • bent background lines, melted hairline, changed furniture, or crop drift;
  • an edit stronger than the user's requested strength or approved adjustment map.

Return the original and previews with a compact comparison table: changed module, intended effect, observed side effects, and recommendation. Do not select a “best-looking” result as an objective fact; explain which version best matches the requested presentation.

7. Create the final version

After the user selects directions, combine only approved operations. For a generative final pass, start from the original again and use the approved values as explicit constraints. For a deterministic pipeline, apply the approved masks sequentially and preserve an editable intermediate for each stage.

Save the final image, a side-by-side comparison, and a concise manifest containing the diagnosis, approved operations, any user-preference overrides, tool route, and prompt or parameters. Never include secrets in the manifest.

When Photoshop is the implementation route, also save an editable 05_final_approved.psd. Verify the installed Photoshop app, the loaded UXP panel, layer names, layer masks, rendered output dimensions, and that masked-out regions remain unchanged.

Default stopping points

  • Stop after diagnosis when the user asked only for analysis.
  • Stop after isolated previews when user preference is required to choose among valid aesthetic directions.
  • Finish the final composite without another question when the user already approved the directions or explicitly requested autonomous completion.