distill-verified-keypoints

Files (2)

• SKILL.md
• keypoint.md · references/

SKILL.md (first lines)

## Input

1. **Game description file path from the user request**

**Processing Steps:**
- Resolve description path in this order:
  1. Use the path explicitly provided by the user request.
  2. If missing and `game_name` is known, prefer `descriptions_example/{game_name}.md` when it exists.
  3. If still missing and there is exactly one candidate under `descriptions_example/**/*.md`, use that file.
  4. Ask the user only when multiple candidates remain ambiguous.
- Read the resolved game description file content
- Extract the game name from the file path (removing the .md extension) to use as the game project identifier

## Task Overview
Reference `skills/distill-verified-keypoints/references/keypoint.md` for the extraction principles and categories.
You are a professional game development expert, and you are now tasked with evaluating the correctness of game logic for a generated game. Game logic correctness is derived from the game description and common sense. Based on the game description file and the assumption that "critical nodes determine global correctness", your task is to decompose the complex task of verifying game logic correctness into a set of discrete and verifiable keypoints. Subsequent automatic evaluation will verify the logical correctness of each individual keypoint.

Important: this is a **specification-first** extraction step, not a feature checklist. The goal is not to prove that the game has obvious controls or a visible basic loop. The goal is to choose the keypoints that are most likely to separate a shallow implementation from a faithful implementation.

## Contract Alignment

This skill produces the description-layer keypoint artifact consumed by orchestrator:

- File output: `games/{game_name}/keypoints.md`
- Logical fields (parsed downstream):
  - `prestate_from_game_description`
  - `instruction_from_game_description`
  - `expected_result_from_game_description`

These three fields are fuzzy semantic text from the game description layer.

Contract references:
- Canonical API contract: `docs/inter_skills_structure.md`
- Workflow graph and orchestration semantics: `docs/agentic_workflow_graph_api.md` (non-canonical)

The first line of `games/{game_name}/keypoints.md` must be:
- `<!-- KEYPOINT_POLICY_VERSION: 2026-04-21-spec-v3 -->`

## Process

### 1. Read and Understand Game Description
* Read the game description file content
* Identify the game's core mechanics, rules, and interactions
* Note important state variables, win/loss conditions, and interaction behaviors

### 1.2 Core Mechanic Planning

Before writing keypoints, internally list the game's core mechanic families and ensure the final file covers them.

For each important mechanic, prefer a **family** of keypoints instead of a single isolated check:
- one success case
- one nearby failure / forbidden / boundary case
- one persistence / order / precedence / resource-consequence case when the specification supports it

Do not emit only the easiest observable behavior for a mechanic when a stronger nearby contrast exists in the description.

Also ask, for each proposed keypoint:
- what bug pattern would this catch?
- what nearby incorrect behavior must be ruled out?
- what concrete observation would make the verdict defensible?

### 1.1 Scope Control

Keep the extraction scoped to the current game only.

Allowed inputs:
- the resolved target description file
- `skills/distill-verified-keypoints/references/keypoint.md`
- the current game's own files under `games/{game_name}/` only when the description is ambiguous and a local game artifact is strictly needed to disambiguate a mechanic

Do not:
- inspect `keypoints.md` from other games
- use other games as templates
- copy headings, phrasing, or mechanics from unrelated game artifacts
- search the repo broadly for arbitrary `keypoints.md` files
- browse the current game directory broadly by default when the description already specifies the mechanic

The goal is to avoid cross-game contamination. Every keypoint must be grounded in the current game's specification, not in examples from another title.

### 2. Extract Keypoints

* Read `skills/distill-verified-keypoints/references/keypoint.md` first, then extract keypoints accordingly
* **Keypoint Format Standard**: `## Keypoint {ID}: [{Category}] {Description}`
* **Minimum Count Requirement**: Produce **at least 60 keypoints** per substantial game description unless the specification is genuinely sparse
* For substantial games, target roughly **30-40** keypoints
* Ensure comprehensive coverage across all four keypoint categories (State Transition, Boundary Condition, Interaction Logic, Game Rule)
* Prioritize keypoints that represent critical game logic
* Aim for atomic keypoints that can be verified independently
* Prefer keypoints that require **specific state construction plus short interaction**, not just idle observation

### 2.1 Difficulty and Coverage Budget

Your keypoint set must not be dominated by trivial checks.

Aim for this distribution:
- **At most 15%** may be "basic sanity" keypoints such as obvious start-up behavior or single-input existence checks
- **At least 50%** should be branch-sensitive negative/exception/boundary/forbidden cases
- **At least 45%** should involve multi-step logic, carry-over state, resource preservation, ordering, or interaction between multiple mechanics/entities
- **At least 85%** overall should be hard/discriminative: either contrastive or multi-step

Good high-value keypoints usually test one of these:
- failure vs recovery
- allowed vs forbidden action under a modifier state
- resource accounting or persistence
- state carry-over across phases, rooms, deaths, retries, or chapter transitions
- precedence between two competing rules
- multi-entity coupling
- "works in one setup but must not work in the nearby counterexample"
- exact consequence after the trigger, not just trigger detection
- observability strong enough for a short-horizon verifier to defend the verdict

### 2.2 Anti-Patterns to Avoid

Do not fill the file with verifier-friendly but low-discriminative keypoints.

Avoid or strictly limit patterns like:
- "the game starts"
- "the player can move left/right"
- "tapping a reachable destination moves the character"

From NetX-lab/GameGen-Verifier, MIT.

More from NetX-lab/GameGen-Verifier