new-skill

Prompt file imported from bruceyen32/ProjectDST (.github/prompts/new-skill.prompt.md). Copyright stays with the author.

Create and wire a new ProjectDST battle skill end-to-end.

Collect required inputs first:

• class_name (warrior/rogue/mage/cleric)
• skill_family_id (example: mage_fireball)
• display_name_zh
• display_name_en
• desc_zh
• desc_en
• target_type
• effect_pattern
• damage_type
• numeric fields: ap_cost, cooldown_turns, range, area_radius, base_damage, damage_multiplier, knockback_force
• behavior notes (special pre-damage/post-hit/filtering logic)

Then execute this checklist in order:

1. Add or update skill row in resources/units/skills/skill_data.csv with all required fields.
2. Create matching resource file resources/units/skills/skill_{id_suffix}.tres with sane defaults.
3. Register path in scripts/units/SkillDataCsvLoader.gd SKILL_PATHS for the new skill_family_id.
4. Add localization keys in resources/text/game_strings.csv:
   • skill.{skill_family_id}.name
   • skill.{skill_family_id}.desc
5. Implement behavior in the correct class logic file under scripts/battle/skills/:
   • WarriorSkillLogic.gd / RogueSkillLogic.gd / MageSkillLogic.gd / ClericSkillLogic.gd
6. If class-level tuning knobs are needed, add/update resources/config/battle_skill_tuning.csv.
7. Ensure any newly created non-localization CSV has paired .import with importer="keep".
8. Run error checks and fix issues related to touched files.

Implementation constraints:

• Keep numeric tuning centralized in data, avoid magic numbers in logic.
• Keep BattleManager focused on turn flow; place domain logic in delegated modules.
• Route all player-facing text through localization flow; do not hardcode Chinese strings in code.
• Keep edits minimal and consistent with surrounding style.

Final response format:

• Inputs used
• Files changed
• What logic was implemented
• Validation results
• Follow-up tuning suggestions