Treat a Skill as a repeatable job
A Plotia Skill should describe a bounded transformation: the input it needs, the visual result it targets, and when it should not be used. Choose a Skill because its structure fits the task—not because its sample happens to look attractive. Pet portraits, badges, repeat patterns, and photo keepsakes have different quality checks.
A reusable Skill needs at least six parts: input requirements, intended output, fixed rules, variable fields, failure examples, and quality checks. It should state whether it creates a candidate, an edited master, or a production export rather than promising a finished product in one click.
The public Skill page explains the expected input and output. Its private production instructions and reference system remain internal.
Build an asset library, not a downloads folder
Store original inputs, licensed elements, generated candidates, selected artwork, editable masters, production exports, and mockups as distinct asset types. Keep one source of truth for approved files. Folders alone become ambiguous once one design has several products and personalizations.
Keep failed examples as deliberately as successful ones. Plotia's seller-evidence review records benefits, rework, and evidence gaps separately; the same pattern helps an asset library teach what to reject instead of becoming only a gallery of attractive outputs. [Plotia Research, 2026]
Use stable names such as concept ID, product code, locale, version, and status. Avoid names like “final-final-2.”
Metadata makes reuse safe
Useful fields include creator or source, license, date acquired, model or tool, Skill slug, subject consent, product compatibility, dimensions, transparency, color notes, review status, and linked listings. For customer photos, record permission and retention expectations.
Tags should describe content and production behavior: isolated subject, seamless repeat, dark garment, embroidery-friendly, editable text, or identity-sensitive.
Reuse systems, not accidental artifacts
Turn successful work into a template only after identifying what is fixed, variable, and prohibited. Reuse palette rules, layout grids, quality checks, and export recipes. Do not blindly reuse generated defects, customer data, or assets with narrow licenses.
Review the library periodically: archive obsolete exports, update supplier-template links, and preserve the master and rights record.