gameplay-design-verify

---

name: gameplay-design-verify description: Explicitly verify CubeGame gameplay code against Doc/GameplayIntent design documents. Use only when the user asks to verify, audit, review, or check whether gameplay implementation matches accepted design intent. This is one-way verification: if code and intent disagree, report or fix code; never rewrite intent documents to match the current code unless the user separately asks for design sync.

Gameplay Design Verify

Purpose

Check whether gameplay implementation under CubeEngine/Application/CubeGame matches the accepted design intent in Doc/GameplayIntent/.

This skill is explicit only. It should not run merely because gameplay files changed.

Required Reads

Read:

1. AGENTS.md
2. Doc/GameplayIntent/README.md
3. the relevant design docs under Doc/GameplayIntent/
4. the requested source files, changed files, or CodePlan step
5. only the source code needed to verify the design question

Do not scan unrelated gameplay files broadly.

Scope Gate

• Verify only CubeEngine/Application/CubeGame/ gameplay behavior and concepts.
• Ignore pure engine, renderer, backend, build, asset, or formatting changes unless they directly affect a gameplay concept described in Doc/GameplayIntent/.
• If the request is purely engine-side, say this skill does not apply.

One-way Rule

Doc/GameplayIntent/ is the accepted design source for this verification.

• If code conflicts with the design docs, treat the code as suspect.
• Do not update intent documents based on current code.
• If the design itself seems outdated, report that as an open question and recommend using $gameplay-design-sync only after the user confirms the design changed.
• If the user asks you to fix the mismatch, edit code or implementation-side docs, not intent docs.

Verification Focus

Prioritize mismatches in:

• gameplay design intent
• concrete mechanisms under Design
• game concepts and aliases
• object relationships
• design boundaries
• thin Concept Code Anchors canonical code anchors

Do not report issues for harmless implementation details that preserve the design meaning.

Output

Lead with findings, ordered by severity.

For each finding, include:

• design expectation
• code behavior or risk
• file/line reference when possible
• recommended code-side correction

If no issues are found, say the code appears consistent with the relevant gameplay intent and mention residual uncertainty.