shd.build/.agents/skills/import-talent-screenshot/SKILL.md

name, description

name	description
import-talent-screenshot	Extract a Division Resurgence talent from one or more screenshots, isolate its icon, reconcile Tier I and Tier II wording and values, create any missing mechanic prerequisites, and enter the reviewed talent through SHD.build ISAC. Use when the user supplies talent screenshots or asks to import, create, model, or enter a pictured talent.

Import Talent Screenshot

Create a complete, modeled talent from screenshots. Submit mutations to the authenticated ISAC server action so validation, permissions, relationships, icon handling, and audit logging remain intact. Prefer direct requests over operating the editor UI.

Workflow

1. Inspect every supplied screenshot at original detail.
2. Extract the displayed title, description, highlighted values, thresholds, durations, stacks, and other mechanically meaningful wording.
3. Classify a title ending in II as Tier II. Classify the matching title without II as Tier I. Store one talent under the base title without the tier suffix. Do not strip a numeral that is genuinely part of the base name; ask when the screenshots do not establish the distinction.
4. Reconcile both tiers into one shared description template. Replace tier-varying values with numbered placeholders in reading order. Use {duration} and {max_stacks} only when the mechanic defines them.
5. Ask the user for exactly one required choice before entry: Weapon Talent 1, Weapon Talent 2, Backpack, or Body Armor. Do not infer this choice from the icon or talent wording.
6. Ask other questions only when missing evidence would materially change stored data or combat behavior. State the unresolved alternatives precisely.
7. Search the Talent registry for the same base name and category. Update only when the user explicitly requests an update; otherwise stop on a duplicate.
8. Search active attributes, supported mechanic recipes, runtime events, outcomes, scopes, resources, and state behavior before creating prerequisites. Reuse semantically identical records.
9. Implement missing mechanic functionality when the screenshot establishes behavior that the runtime cannot yet represent. Extend the shared mechanic types, validation, persistence, ISAC editor, runtime execution, pseudo-script, reference UI, schema migration, and focused tests as required. Preserve generic semantics; do not add talent-name checks or a one-off recipe when a reusable event, outcome, scope, resource, or state rule fits. Follow the repository's database-preservation procedure before applying a schema migration.
10. Create a missing attribute or other data requirement through its authenticated ISAC server action only when its name, unit, type, category, and calculation semantics are established by the screenshots or project data. Ask for any material field that cannot be derived safely.
11. Model the mechanic with the narrowest supported recipe. Prefer health-threshold bands for wording such as “while below N% Health.” Treat those bands as mutually exclusive strongest-matching ranges unless the source explicitly says effects stack.
12. Set each numbered outcome's Tier I and Tier II values, phase, scope, basis, and attribute. Mark the mechanic READY only after the full behavior is executable and tested. Use ASSUMPTIONS or CAPTURE ONLY only when source evidence is incomplete, not merely because runtime functionality is missing.
13. Isolate the icon from the screenshot. Preserve the pictured silhouette rather than redesigning it. Remove text and UI background, center it on a square transparent canvas, retain antialiased edges, and validate it at small display size. Use the image-generation editing workflow only when a faithful crop and local cleanup are insufficient.
14. Build one multipart/form-data payload matching the current talent form contract, including the prepared icon and serialized mechanic program. Submit it directly to the authenticated /isac/talents?/saveTalent server action. Use browser-side fetch when the browser holds the authenticated session. Do not open, populate, click, or submit the talent editor. Do not use the editor's file input to stage the icon. Make the icon available to the browser-side request without interacting with the editor, then attach it to the FormData as a File. Inspect the current route source before relying on a field name or action path.
15. Read the saved registry row back. Verify the name, category, icon, both rendered tier descriptions, modeled state, thresholds, values, and any newly implemented runtime behavior. Confirm the successful game_data audit event when audit access is available.

Guardrails

• Never invent values hidden by cropping, blur, overlays, or missing tiers.
• Preserve strict wording: “below 25%” means < 25, not <= 25.
• Do not add tier values together. For ordered health thresholds, select the value for the current non-overlapping band unless the source states that effects accumulate.
• Do not create a near-duplicate attribute because of capitalization, spacing, or a synonymous label.
• Do not expose credentials, session data, or personal data in screenshots or audit checks.
• Never write talent, tier, effect, mechanic, icon, or audit rows directly to the database. Never call lower-level persistence helpers to bypass the route action.
• Do not manually create an audit event. A successful server action must create it.
• Never use the talent editor UI for an import. If direct submission cannot preserve the authenticated session, file upload, or current form contract, stop and report the blocker.
• Preview extracted fields and planned mechanics before the first external mutation when the user has not already approved entry.

Project Reference

Read references/shd-talent-entry.md before entering a talent. Re-check the referenced source files when the application schema or editor changes.