/adobe-standardize-headshots

name: adobe-standardize-headshots
description: >
  Gives a team's headshots the same crop, background, and tone using Adobe
  image tools while preserving each person's appearance. Use when the user
  wants to standardize employee portraits, match staff headshots, or make
  team profile photos consistent for a directory, website, or presentation.
  Not for generating new portraits, general photo enhancement, or official
  passport and identity-document compliance.
license: Apache-2.0
compatibility: "Targets Claude and Codex. Uses Adobe picker and preview widgets when available, with programmatic staging and labeled-link fallbacks for non-widget surfaces. Local staging requires an exposed initialization tool that permits egress; raw local paths never reach image tools."
allowed-tools: adobe_mandatory_init asset_add_file read_widget_context asset_initialize_file_upload asset_finalize_file_upload asset_preview_file image_read image_apply_adjustments image_crop_and_resize image_remove_background
metadata:
  version: 1.0.0
  visibility: public
  surface: [claude, codex]

Adobe Standardize Headshots

Requirement

Gives a team's headshots the same crop, background, and tone. Produce a cohesive set of head-and-shoulders portraits with consistent dimensions, relative head size, headroom, background color, and tonal treatment. Preserve identity, facial features, natural skin tone, hair, clothing, and expression; do not generate faces, reshape bodies, or apply beauty retouching.

Tool Reference

| Step | Tool | Purpose | |---|---|---| | Initialize | `adobe_mandatory_init` | When exposed, obtain file-handling and routing rules first | | Collect | `asset_add_file`, `read_widget_context` | Use the Adobe picker when available and resolve selected asset URLs | | Stage without widgets | `asset_initialize_file_upload`, `asset_finalize_file_upload` | Use the approved two-step upload only when initialization permits egress | | Inspect | `image_read` | Inspect sources and edited outputs; follow initialization guidance for any required visual-preview tool | | Match tone | `image_apply_adjustments` | Correct exposure and color differences conservatively | | Match crop | `image_crop_and_resize` | Subject-aware crop to shared dimensions and framing | | Match background | `image_remove_background` | Replace the background using `options.backgroundColor` | | Deliver | `asset_preview_file` | Show results when this widget is available; always provide labeled links |

Workflow

Step 0 - Initialize Adobe Tools

When exposed, call `adobe_mandatory_init` before any other tool. Follow its returned file-handling, authentication, egress, and routing rules throughout the workflow. This also applies when the request starts with an approved sample or asks to resume a batch. Do not infer that initialization already ran in this session.

{ "skill_name": "adobe-standardize-headshots", "skill_version": "1.0.0" }

If this tool is absent, do not call it or assume its rules were returned. Use accessible Adobe assets or the picker when available, but do not attempt programmatic local-file staging. Decide staging from initialization-tool availability and its returned rules, not from the surface name or network-message tags. A failed or denied initialization is a blocker, not tool absence.

The tool reference and `allowed-tools` list describe this workflow, not what the current session exposes. Use only available tools and their actual schemas. Do not invent initialization rules, image observations, session handles, or intermediate/final URLs. When execution is unavailable, state what has not run; explain intended steps without fictional tool results or claims of verification.

Step 1 - Collect Headshots and Agree on the Standard

Use headshots already supplied in the conversation when they are accessible under the applicable file-handling rules. Stage local files with `asset_add_file` when the picker is available; never pass raw local paths to remote image tools. The picker initially returns an empty image list: wait for the user's selection, then use `read_widget_context` to resolve the usable asset URLs.

For each source with blocked ingestion, mark it not run and request an accessible Adobe asset link or a supported upload surface. Continue accessible independent sources through the sample-approval gate without waiting for blocked files. If no source is accessible and no permitted ingestion route exists, the entire response is the blocker and that request, for example: "The local portraits have not been staged or edited. Programmatic staging is unavailable here; please supply accessible Adobe asset links or use an Adobe file-picker surface." End the turn there; do not describe hypothetical upload calls or editing recipes that cannot run in the current session.

> **No-widget fallback** (when `asset_add_file` is unavailable, e.g. Codex): > use already accessible Adobe assets directly. For local files, proceed only > when `adobe_mandatory_init` is exposed, its rules permit egress, and both > upload tools are available. Call `asset_initialize_file_upload` using the > exposed schema, PUT the bytes/parts only to its returned Adobe-issued upload > destinations, then call `asset_finalize_file_upload` with the returned transfer > document after all required uploads succeed. Use only the finalized asset URLs > as image-tool inputs. If staging is blocked or fails, explain the limitation > and request accessible Adobe assets or a supported upload surface; never > invent an upload destination, finalize failed uploads, or pass raw local paths.

Do not route portraits through third-party storage, install software, or create public links.

Keep a per-image mapping of source label, original URL, latest output URL, session handle when returned, and processing status. Use neutral labels such as `headshot-01` unless the user supplied filenames. Do not identify people from their faces or put names and other perso