| name | nt-game-feature |
| description | Use when creating a reusable feature or deciding whether game code belongs in a root module, a template feature-pointer, or game-owned code. |
NT Game Feature
Workflow router for reusable modules and template feature-pointers. Canonical
feature contracts live with their owners, not in this skill.
Start
- Read
features/README.md for category selection and current modules.
- Read
templates/template/src/features/README.md for template-pointer
conventions, layers, lifecycle, state, and asset boundaries.
- For every existing owner being changed, read its local
README.md,
INSTALL.md, and feature.json. Those files own its public surface,
wiring, validation, compatibility, and extension rules.
Choose the owner
- Byte-identical reusable code configured through data belongs under
features/.
- A reusable reference games are expected to repaint or hand-edit belongs
under
templates/template/src/features/.
- Game-specific seed, verbs, save history, and composition remain game-owned.
Consumer count does not decide the category. Do not add speculative switches,
registries, or hooks without a real consumer need.
Workflow
- Follow the closest owner's local contract instead of copying it here.
- For a new owner, create local contract files and register it through
features/README.md; synchronize its version with dependency records.
- Keep layer edges downward and declare dependencies in
feature.json.
- For relocation, preserve byte identity and public include spelling, change
only paths/wiring, verify generated-output identity, then run consumer tests.
- Prove a root module through a throwaway
games/new_game.mjs consumer.
- Keep each increment buildable.
Routing
- Items catalog/runtime workflow:
nt-game-items.
- State schemas, generation, saves, and migrations:
nt-game-state-management.
- Live runtime proof:
nt-runtime-automation.
- Acceptance evidence:
nt-quality-checks.