updating-dawncaster-filters

This skill provides a rigorous, fail-safe workflow for developers maintaining the Dawncaster cards alternative frontend. It is specifically designed to handle the post-expansion release cycle where new cards, talents, and filter metadata are introduced into the Blightbane API. The primary objective is to prevent incomplete updates—a common failure mode where users cannot access or filter new content due to stale frontend mappings. By following a strict discovery and verification sequence, this skill ensures that all UI components reflect the authoritative state of the game data.

• Automatically discovers the current Blightbane bundle version to query the most recent source of truth for filter arrays.
• Implements a systematic verification protocol covering all five filter types: categories, types, rarities, banners, and expansions.
• Mandatory TodoWrite checklist integration to prevent skipping steps or partial updates, enforcing synchronization between HTML select dropdowns and JavaScript helper arrays.
• Supports multi-file updates, ensuring changes are correctly propagated to both cards.html and talents.html files.
• Includes data validation steps to ensure array index mappings match the corresponding dropdown option values, critical for correct UI rendering.
• Provides a clear methodology for querying live index.bundle.js files via curl and grep, enabling headless data extraction.

Usage notes and constraints:

• Always initiate the discovery phase by fetching the latest Blightbane bundle; never assume existing local files match the current game version.
• You must create a TodoWrite checklist at the start of any maintenance task; bypassing this step is considered a violation of the 'Iron Law' of this skill.
• Pay close attention to the JavaScript mapping functions (e.g., getCategoryName); the array index and the HTML value attribute must be strictly identical.
• While the user may only mention one expansion, you are required to perform a comprehensive check across all filter categories as secondary metadata often shifts with major updates.
• The output is intended for static site updates without a backend build process; ensure final verification against the live site deployment.