Adding skills & isac talent updates
This commit is contained in:
@@ -0,0 +1,42 @@
|
||||
---
|
||||
name: import-talent-screenshot
|
||||
description: 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](references/shd-talent-entry.md) before entering a talent. Re-check the referenced source files when the application schema or editor changes.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Import Talent Screenshot"
|
||||
short_description: "Create modeled talents from game screenshots"
|
||||
default_prompt: "Use $import-talent-screenshot to extract and enter a talent from my screenshots."
|
||||
@@ -0,0 +1,58 @@
|
||||
# SHD Talent Entry Reference
|
||||
|
||||
## Canonical surfaces
|
||||
|
||||
- Talent editor: `src/routes/isac/talents/+page.svelte`
|
||||
- Talent action and validation: `src/routes/isac/talents/+page.server.ts`
|
||||
- Mechanic editor: `src/lib/components/isac/MechanicProgramEditor.svelte`
|
||||
- Mechanic draft types: `src/lib/calculations/mechanic-editor.ts`
|
||||
- Mechanic runtime and validation: `src/lib/calculations/mechanic.ts`
|
||||
- Mechanic persistence: `src/lib/server/conditional-effects.ts`
|
||||
- Supported recipes: `src/lib/calculations/mechanic-recipes.ts`
|
||||
- Attribute registry and actions: `src/routes/isac/attributes/`
|
||||
- Icon validation and persistence: `src/lib/server/game-data-icons.ts`
|
||||
|
||||
Treat these files as the current authority. Inspect them before acting when fields or behavior may have changed.
|
||||
|
||||
When a pictured mechanic is not representable, add the smallest reusable runtime capability and its validation, persistence, editor controls, migration, reference entry, and tests before entering the talent. A missing runtime feature is an implementation task, not a reason by itself to leave a talent under assumptions.
|
||||
|
||||
## Request path
|
||||
|
||||
Prefer a direct authenticated request to the SvelteKit talent action over editor interaction:
|
||||
|
||||
- Load or inspect `/isac/talents` to obtain current registry data and confirm the authenticated session.
|
||||
- Construct `FormData` from the current contract in `+page.svelte` and `+page.server.ts`.
|
||||
- Include the icon as the `icon` file part and the complete mechanic program as serialized `conditionalRule`.
|
||||
- Submit one `POST` request to `/isac/talents?/saveTalent` with an accepted SvelteKit action response type.
|
||||
- Parse the action result, then query the registry and audit surfaces for readback.
|
||||
|
||||
Do not treat the action path as a public, version-stable REST API. Re-check the route implementation when it changes. Do not insert into the embedded database or call persistence utilities directly.
|
||||
|
||||
## Talent form
|
||||
|
||||
The user-facing categories are:
|
||||
|
||||
- `Weapon Talent 1`
|
||||
- `Weapon Talent 2`
|
||||
- `Backpack`
|
||||
- `Body Armor`
|
||||
|
||||
Talent descriptions use one shared template. Number tier-varying outcomes as `{1}`, `{2}`, and so on in reading order. The action derives Tier I and Tier II descriptions from each outcome's variant values.
|
||||
|
||||
## Mechanic entry
|
||||
|
||||
Use the `health_threshold_bands` recipe for non-stacking current-health ranges. Enter thresholds from strongest to weakest in the editor and assign one outcome to each band. Verify exact boundary behavior after saving.
|
||||
|
||||
For the Spirited example:
|
||||
|
||||
- Base name: `Spirited`
|
||||
- Tier I: 9% below 75% Health; 12% below 50%; 15% below 25%
|
||||
- Tier II: 12.60% below 75% Health; 16.80% below 50%; 21% below 25%
|
||||
- Shared template: `Grants +{1} Damage Reduction while below 75% Health. Grants +{2} Damage Reduction while below 50% Health. Grants +{3} Damage Reduction while below 25% Health.`
|
||||
- Attribute: `Damage Reduction`, unit `%`
|
||||
- Scope: self
|
||||
- Phase: while active
|
||||
- Basis: flat percentage points
|
||||
- Bands: `[50,75)`, `[25,50)`, and `[0,25)`; no effect at or above 75%
|
||||
|
||||
Confirm that `Damage Reduction` already exists before creating it. Confirm the category/slot with the user before saving.
|
||||
Reference in New Issue
Block a user