--- name: charakit-outfits description: Recolor or replace garments, replace a complete outfit, or add, remove and replace accessories or props in visual novel character artwork while preserving identity, expression, pose and original style. Use for outfit and object edits, human-guided revisions, review previews and PNG exports. --- # CharaKit Outfits Human review defaults to all readable candidates in the current batch, including failures and earlier rounds. Recommendations stay separate and never preselect the user's decision. Failed versions can receive actual feedback and specific revision requests; final delivery still requires all gates. Do not restrict the view without an explicit user request and a recorded omission reason. For optional garment, outfit or object reference images in any mode, follow the shared [scoped edit references](../../references/edit-references.md). Snapshot and bind their actual inputs, include a target check for every reference, and retain them in every internal redraw and human revision. This rule also governs future editing modules. Create complete character images with one garment recolored (`recolor`), one garment replaced (`replace`), a coherent ensemble replaced (`outfit_replace`), or one explicitly scoped accessory/prop added, removed or replaced (`prop_edit`). Full outfits use an explicit clothing inventory; props use an explicit `prop_action`. Unlisted components stay protected. All modes preserve facial design, expression, mouth state, hair design, body/arm pose, proportions and composition, allowing only the operation's necessary interfaces and occlusion changes. Read the shared [editing boundaries](../../references/edit-boundaries.md) before defining an edit. For color-only edits, use the [garment domains](references/garment-domains.md) and [recolor guide](references/recolor-guide.md). For a new single garment, follow the [replacement guide](references/replacement-guide.md); recolor's old-cut/material invariants do not apply. For an ensemble, follow the [full outfit guide](references/full-outfit-guide.md). For an accessory or prop, follow the [prop edit guide](references/prop-edit-guide.md), including action-specific scope, contacts, occlusion and reconstruction checks. Color-specific paragraphs below apply to `recolor`; shared source, inspection, human revision and delivery rules apply to all modes. Undressing and pose editing are not implemented. Expressions remain independent: users can manually submit a resulting PNG to `charakit-expressions`; this workflow does not share state or trigger it automatically. Combined garment/object requests must keep each operation's scope and checklist explicit; do not disguise a prop edit as clothing replacement. ## Candidate selection and human review For every new request, follow [candidate selection and human review](../../references/candidate-review.md). Define source-grounded checks before generation, start a candidate pool before scoring, and use rubric 1.2 with five evidence-linked dimensions. Default to three total attempts per requested result, including the initial image. A requested output count is distinct from an image-tool attempt cap; honor an explicit smaller cap. If any of the five dimensions, domain checks or applicable fidelity checks fails or remains uncertain, redraw from the recorded findings and reassess every check. A total of 80 or more cannot override a dimension below 4/5. Stop on full internal passage or budget exhaustion; only then create the user review page, explaining unresolved issues when exhausted. Show an anonymous review page and inline candidates, collect actual user feedback, and only then deliver/package accepted eligible artwork. Chat replies are sufficient; do not demand a second approval or a feedback file. This workflow replaces sequential refinement for new work; old tracked cases retain [their original workflow](../../references/refinement.md). For a specific correction after human review, follow the [linked human-revision procedure](../../references/candidate-review.md#continue-a-specific-human-correction). Use `revision-prepare` and `revision-import` to retain the actual chosen parent, original comment, clothing definition, full inventory when applicable, and brief and protection checks. One correction starts a new default three-attempt internal review/redraw batch with fresh fidelity and quality assessments; show the returned before/after comparison. Do not substitute the latest candidate or inherit acceptance. ## Language and input Respond and write generation prompts, visible names, explanations, and review notes in the user's current or preferred language. Keep CLI arguments, JSON keys, outfit IDs, filenames, and status/error codes stable English identifiers. Translate preview titles with a flat UTF-8 JSON file whose keys include outfit IDs, `source`, `reference`, review statuses, technical statuses, and error codes; pass it to `preview --labels-file`. Inspect the actual source first and identify the garment, ensemble or object/addition site, its boundaries, and the requested operation/result. Ask only when these cannot be resolved from the request and artwork. Target descriptions are free text; the helper records them but cannot verify which pixels the model changed. Use a separate project such as `art-output//outfits/`; do not initialize or add outfits inside an existing Expressions project. Each project has one immutable source snapshot. New pools follow `pool-status` and `pool-reserve`: begin with the source, then use recorded failures to redraw within the default three-attempt budget. The immutable source controls identity/design/material, pose and framing; a correction reference supplies successful authorized edits. Existing legacy pools/refinements retain their recorded reference strategy. Before generating a new option, use `prepare` to record the mode's requested change, included surfaces, permitted interface changes, remaining invariants, exclusions and protected remainder in the user's language. Single replacement uses `--edit-type replace --replacement`; full outfits use `--edit-type outfit_replace --replacement --components-file`. Both omit `--color`. Every unrequested component/property is protected, including the face, expression, mouth state, hair, pose, and unlisted clothing/props. Derive concrete exclusions from the actual source; sharing a color or material does not join two components into one target. Choose a source-coordinate target box with enough context; it is a rectangular reference crop, not an edit mask. Props use `--edit-type prop_edit --prop-action add|remove|replace` with their guide's fields and interfaces. Only add/replace specify `--replacement`; all prop actions omit `--color` and `--components-file`. ## Generation and inspection Read and apply the shared [quality review and delivery policy](../../references/quality-review.md). New projects enable internal review by default; run `enable-quality` before a new generation in a legacy project. After inspecting comparisons, record evidence-backed rubric scores with `quality`, keep the independent `fidelity` observations, and present the anonymous human review before `deliver` and final packaging. Serious defects, uncertainty and technical failure other than temporarily excluded canvas mismatch cannot be offset by a high total. Internal passage does not imply user acceptance. Use the active domain: `garment_recolor` for color/invariants; `garment_replace` for design, fit and coverage; `outfit_replace` for overall design and every inventory item. `prop_edit` records the matching `prop_action` and target object, placement/contacts, occlusion/reconstruction and anatomy/pose checks. All check face/expression, protected remainder and rendering. Identify the actual target in `component` and use only its mode guide's checklist. Failed/uncertain items veto delivery even at 100/100. Explain the observed failed property in the user's language. Use the OpenAI image editing tool available in the host. This Skill supplies instructions and local file management, not an image model or external API. If the tool is unavailable, explain the missing capability. Record the model as `unknown` unless reported. Generate only requested options and final-result counts; use the recorded internal attempt allowance for corrections. Each deliverable is one full illustration with original framing. Preserve source transparency or its opaque background as appropriate. Do not crop to the garment, extract body parts, paste recolored clothing onto the source, or claim that a global tint is a selective recolor. State the target garment and color in the prompt; distinguish fabric from trim, buttons, lining, and nearby garments when that affects the request. Preserve the original lighting and material behavior instead of using one flat color. A color name or hex value is a direction, not a guarantee that every shaded pixel has that exact value. Read the prepared brief and default to one complete source reference. State the permitted garment change or ensemble mappings, domain invariants, concrete boundaries/exclusions, protected remainder and complete-image output once each. Include necessary detail, but merge repeated or synonymous requirements instead of copying several review summaries into the prompt. Facial preservation instructions retain original features and rendering; they do not ask for reconstruction, beautification, cleanup or style enhancement. See the mode guide's template and the shared refinement guide for compact repair prompts. Semantic instructions are not a demonstrated pixel-preservation solution. Keep the prepared detail for inspection. Submit it only when the garment is ambiguous in the full source or the user requests a reference comparison, and the host supports additional references. Inspect it first and state that it only locates the target in the full source, not the output framing or a replacement design. Save the actual submitted prompt and reference paths, including whether the prepared crop was sent. Do not claim a mask was applied unless the host actually accepts a mask. All final artwork edits stay in the host image tool; local reference/preview crops do not recolor or composite candidate pixels. Save each real tool output before reviewing it. The helper copies raw generated image bytes and never resizes, repaints, changes alpha, or removes backgrounds. Check PNG content, exact source canvas, transparency requirements, source and candidate fingerprints. Keep failed readable candidates and explain their errors; technical failure does not discard progress. Temporarily exclude output resolution/source-canvas mismatch from rubric scoring and preview-delivery rejection. Record actual dimensions and retain the raw mismatch report; evaluate visible quality defects on their own evidence. Other technical/fidelity/quality gates remain, and formal acceptance/selection/ZIP export still require the source canvas. See the shared delivery policy. Inspect full-image comparisons, whole-face enlargements, target invariants, and interfaces from the selected domain. Enlarge relevant protected details chosen from the source, especially fine construction or complex overlaps; do not require an object absent from the artwork. Reuse `preview --detail-box` with distinct output paths. Check color spill and changes in geometry, texture, patterns, seams, folds, trim, expression, pose, and outline; an unchanged broad color is insufficient. Inspect edges on light and dark backgrounds. Scripts cannot judge these artistic properties or game-switching quality. Human pages retain full illustrations and choose local views for the current operation and observed risks. Use the shared [revision baseline and inspection rules](../../references/candidate-review.md#revision-baselines-and-task-based-inspection): human corrections edit the chosen candidate first, retain successful authorized changes and separately recheck still-protected regions against the immutable source. Correct documented unauthorized drift in protected properties or explicitly requested restoration checks; never restore superseded features. Record focused, localized regions through `--inspection-file`; garment/prop corrections need not show a face view unless it is relevant to the task or an observed issue. New revisions do not inherit all earlier views or the old full-outfit box. Initial edits can still use the prepared target box; explicit face/detail boxes remain supported. Crops share source coordinates without alignment or pixel repair, remain separate from full PNGs, and follow actual acceptance into the final report. After viewing the actual source and candidate comparisons, use `fidelity` to record two independent observations: the requested target edit and preservation of protected regions. Choose `passed`, `failed`, or `uncertain` for each and cite the visible findings in the note. A recognizable character or successful color change alone is insufficient: extra facial repainting, changed weapon/hair geometry, or color spill makes protection fail. Use `uncertain` when evidence is insufficient; never fabricate pixel equality or objective automatic visual scores. The shared quality rubric records attributed assistant judgments and cannot override failed fidelity. Assistant observations use `--basis assistant`; use `user` only for findings actually supplied by the user. These checks remain separate from technical status and user acceptance. Preserve failed results and describe the limitation; revise through the image tool only when requested, without automatically repairing the face or other protected parts. ## Local helper `scripts/studio.py` uses Python 3.11+ and the plugin's Pillow dependency. Resolve its absolute installed path; keep the complete plugin including `lib/studio_core.py` together. It runs once and exits, with no service or API key. Work sequentially within one project. ```text python /scripts/studio.py init --project --source --character python /scripts/studio.py prepare --project --outfit coat_navy --target --color --boundary --protect --protect --target-box python /scripts/studio.py add --project --outfit coat_navy --target --color --image --prompt-file --brief-file python /scripts/studio.py preview --project --asset coat_navy_v001 --asset coat_navy_v002 --output --face-box --detail-box --background light --labels-file python /scripts/studio.py fidelity --project --asset coat_navy_v001 --target-check passed --protection-check --basis assistant --note python /scripts/studio.py quality --project --asset coat_navy_v001 --assessment-file --comparison --comparison python /scripts/studio.py review-sheet --project --asset coat_navy_v001 --purpose user # Wait for actual user feedback, then record its packet and alias. python /scripts/studio.py human-feedback --project --feedback-file python /scripts/studio.py deliver --project --asset coat_navy_v001 python /scripts/studio.py select --project --asset coat_navy_v001 python /scripts/studio.py export --project ``` - `init` creates an Outfits schema 1.2 project; first single replacement upgrades to 1.3, first full outfit to 1.4, and first prop edit to 1.5, backing up exact old metadata. Use helper 0.1.22 or later for props. Existing projects never downgrade. Expression projects remain separate with their original schema; wrong-module operations fail before writing. - `prepare` saves versioned `briefs/` JSON and `references/` source detail PNG without changing project metadata or source/candidate bytes. Use its returned paths, inspect the reference, and preserve both. It does not generate an image, create a mask, or lock pixels. - `add` requires a lowercase outfit option ID and existing garment `target`: `recolor` needs `color`, while `replace` needs `replacement`, a matching prepared brief and a nonempty actual prompt. `outfit_replace` additionally requires the explicit clothing inventory (inherited from a matching brief). Use one ID per target/color combination, for example `coat_navy` and `coat_red`. Revisions use the exact existing target/color values, preserve history, and increment versions within that ID. Use a new ID when changing the garment or color. Replacement uses a new option ID per requested garment design; full ensemble definitions also include the immutable component mappings. - `add --brief-file` validates the source/option definition and detail-reference fingerprint, then embeds the brief with the candidate. Later revisions inherit the latest brief if omitted; each new candidate needs its own fidelity observations. Old schema 1.2 assets without a brief or fidelity record remain readable with their prior gates; never infer past checks or silently rewrite them. Use the prepared workflow for new generation requests. - `preview --outfit coat_navy` filters one option's versions. Repeated `--asset` arguments compare specific candidates. `--face-box` and `--detail-box` use source-canvas coordinates and add separate face and garment rows. Candidate-size mapping is for viewing only; it does not fix alignment. - `review accepted` records real user satisfaction and selects a technically valid version for that outfit ID. `select` switches accepted versions. Unreviewed candidates remain unreviewed. Explicit user satisfaction or selection is sufficient; do not request duplicate approval. - `fidelity` records manual observations without accepting a candidate. It can record readable, unchanged candidates even when canvas checks fail. Brief-linked candidates require both observations passed before acceptance, selection, or export; a recorded failed/uncertain check also blocks legacy candidates. Recording a failure removes that candidate's selection while retaining user-review history. Passing fidelity alone does not select anything or satisfy technical/user-review gates. Preview labels `fidelity_pending`, `fidelity_passed`, `fidelity_failed`, and `fidelity_uncertain` can be localized. - If the user likes a technically failed image, preserve their feedback separately; the helper cannot mark it accepted or include it in formal export until checks pass. - `export` rechecks accepted selections, allows one version per option ID, and copies unchanged PNG bytes into `sprites//outfits/.png`. The manifest follows project schema: 1.2 recolor, 1.3 single replacement, 1.4 full outfits, 1.5 props. It records the edit definition, inventory or prop action when applicable, version, reviews, actual feedback and fingerprint. Existing outputs and candidates are not overwritten. ## Revision and delivery For new generation and revision batches, use the candidate-pool and human-review workflow above. The [bounded refinement reference](../../references/refinement.md) applies only to existing `refinements` records; never reset those budgets or rewrite historical assessments. New pools use rubric 1.2 and the default three-attempt review/redraw policy (helper 0.1.23). Explicit smaller limits remain binding. Saved 1.0 pools and legacy refinements retain their original strategy and spent budgets. Revise only the requested option and preserve other candidates and selections. Run targeted revisions through a new fixed-budget batch and review every candidate afresh; do not exceed the recorded attempt budget. Use `deliver` to check image eligibility and retain submitted prompts as linked evidence in the delivery report. Keep blocked candidates internally and report unmet criteria in text, unless the user explicitly requested failed/experimental comparisons; label those as inspection evidence. Report visual limitations and technical status separately. Workflow support and internal scoring do not guarantee preservation or a lower user revision rate. After internal evaluation, present the human review stage before final delivery. Once actual user acceptance is recorded and gates pass, finish with the shared [delivery report](../../references/delivery-report.md): show accepted full PNGs and final preview inline, and link the Markdown report. Complete already requested packaging without another permission question. If no candidate passes, provide a failure report and clearly labeled inspection candidates for user feedback; they are not final assets. Keep all prompts, findings, candidates and actual feedback.