gameplay-mechanics

Gameplay Mechanics

When to Use

Use this skill when:

• a task changes player verbs, mechanics, resource loops, combat, movement, progression, or balance behavior
• mechanic implementation needs feedback-loop, event, or tuning guidance
• a gameplay_designer or gameplay implementation slice needs reusable mechanics reference material

Do not use this skill when:

• the request is only high-level product strategy or architecture documentation
• the task is visual/UI presentation without changing gameplay rules or player verbs

Core Workflow

1. Route through the appropriate professional gameplay slice before presenting gameplay conclusions.
2. Read references/full-guidance.md for detailed mechanics patterns, code examples, balance loops, and troubleshooting.
3. Tie each mechanic change to an observable player-facing behavior and a verification command or playtest note.

Supporting Files

• references/full-guidance.md: detailed original guidance, examples, patterns, and command/reference material.

Oasis7-Specific Surfaces

• .agents/roles/gameplay_designer.md
• GitHub Project task status and issue evidence comments
• gameplay/runtime tests or playtest evidence for changed mechanics

Known Failure Modes

• A mechanic that compiles can still feel wrong; include feedback timing and player-readable state in acceptance.
• Balance changes without instrumentation or replayable scenarios are hard to verify later.
• Avoid changing economy/progression constants without documenting the expected player impact.

Guardrails

• Keep this entrypoint concise; move heavy examples or catalog material to supporting files.
• Do not bypass oasis7 task/worktree truth or professional role ownership when the workflow requires it.
• Do not present reference material as verified project behavior without checking the current repo state.

Verification

• Run the focused gameplay/runtime test or playtest harness tied to the mechanic.
• Run ./scripts/lint-skills.sh after skill edits.