What problem does it solve? Editing levels in Mapas.asm is error-prone because the format is partially undocumented, the level-completion counter lives in an undocumented byte 0, and level progression silently depends on maps being physically adjacent in memory — mistakes produce no assembler errors, only broken gameplay at runtime. ## Core Features & Use Cases - Verified format reference: Documents the true per-map layout (destructible-brick count byte, then Y/count/colour rows terminated by $FF), verified by counting every cell in all four maps. - Rendering and collision constraints: Explains the colour-to-attribute mapping (colour << 3), the special-cased $78 attribute for indestructible colour-8 bricks, and why classify_cell's comparison must stay in sync. - Safe editing checklist: Provides a step-by-step checklist for adding or editing levels, covering byte-0 counting, the 15-entries-per-row limit, the adjacency dependency, and CantidadNiveles synchronization. - Use Case: You want to add a fifth level to the game. The Skill tells you to append it after map3 with no padding, count only destructible bricks (colours 1-7) into byte 0, terminate with DEFB 255, and bump CantidadNiveles — avoiding the silent failure where the level renders garbage or can never be completed. ## Quick Start Ask the assistant to walk you through adding a new level to Mapas.asm using the map data format rules, including the correct byte-0 brick count and placement after map3.
