Use this skill to create reusable attack-skill and movement-skill implementation patterns for this project's MSW player stacks.

This is not a basic MSW combat-rule summary. Treat it as a project-specific implementation guide for skills whose gameplay timing and visual timing may intentionally diverge from the default MSW presentation flow.

The intended design is type-driven: define a small number of skill types, then stamp out concrete attack or movement skills by tuning family-specific data.

Create advanced player-skill implementation patterns from reusable types. Attack skills tune damage/judgment/presentation; movement skills tune movement power/distance, air-use count, collision policy, and authority/prediction.

For the attack family, this guide handles authoritative judgment, HP/death state, and visual hit timing. For the movement family, use the platform-aware execution and validation contract in references/movement/skills.md.

Before editing project files, load the normal MSW foundation for the task:

For every player attack, player movement, or monster-presentation create/modify request, read references/execution-core.md first and follow its stage gates and sole detail-loading matrix. Do not select required contracts from the catalog below. For guide-only work, use the lightweight route under Request Modes.

Treat every applicable required rule as work to execute, not commentary to repeat. Do not stop with an apology, realization, praise of the guide, or a restatement such as “this must be followed,” and do not hand the rule back to the user for confirmation.

When a missed or unevidenced obligation is discovered, immediately reopen the affected ledger rows to , inspect the required project evidence, correct the implementation, and run the named verification before continuing. Mark a row only when the exact required access or evidence is unavailable; record what is missing and ask only for that specific external artifact. For per-model HIT/death obligations, execute the required model-by-model artifact and gates rather than merely citing them. (→ references/player/preflight.md, references/verification/monster-visual-harness.md)

This section is intentionally in because linked references are loaded progressively and an agent that skips the first link would otherwise miss the attack's foundation and presentation obligations. It fixes the first actions and required artifacts; leaf references still own exact behavior.

For every player attack create/modify request, complete these actions before any project write:

DATA

DATA-01

DATA-02

DATA-03

DATA-04

PAP

PAP-01

PAP-04

PAJ

PAJ-01

PAJ-04

MHP

MHP-01

MHP-04

Do not create or edit project scripts, components, entities, DataSets, or CSVs until this startup ledger exists. A damaging player attack is not implemented unless all four families have implementation locations: attack data, player casting presentation, immediate judgment, and monster receiving-hit/death presentation. Missing Maker/runtime access changes runtime-dependent rows to ; it never authorizes omitting their implementation or silently narrowing the attack to damage-only behavior.

This is a document dictionary, not a second routing table. The fixed player-attack startup list above protects progressive loading; after that entry gate, references/execution-core.md is the only authority for conditional document selection and timing. Leaf references own exact behavior.

Classify every request before loading domain references:

If a request spans modes, record the combination explicitly. Do not import another mode's defaults or deliverables without a matching execution-core condition.