- name
- feature
- description
- Any game (apps/porthole/games/<game>/). Use when adding or changing a player-visible mechanic, screen, reward, progression rule, or persisted state. Covers stating the feature contract before editing, the failing-test-first workflow, and the proof list before calling it done.
1. State the contract before touching code: what the player and the game do together and why it's worth returning to; entry, play, completion, replay, sleep, and Back behavior; one-time vs. repeat rewards, including midnight, reload/restart, clock rollback, and duplicate-action behavior; which persisted fields it touches, whether any id or array order has to stay stable, and what migration it needs; every screen or state that must agree with the rest of the game.
2. Read the game's own `apps/porthole/games/<game>/CLAUDE.md` and the shared `apps/porthole/CLAUDE.md` first -- they name the hard constraints (round screen, tap targets, append-only save layout, nothing punishes absence) this feature has to respect regardless of which game it's in.
3. Add a failing rule-level test first, in the game's state-simulation layer (Pets Club: `pet.*`; Biscuit: `pet.h`), before touching screen code -- see `superpowers:test-driven-development`. Cover the outcome and the failure mode most likely to lose or duplicate progress: repeat completion, sleep/offline decay, cross-midnight state, clock rollback, and (if the field is persisted) an old-save migration path.
4. Implement the smallest diff that fits the game's existing style (see the `game-engineer` agent). Prefer extending an existing loop (care, reading, play, training, daily hooks, collections, growth) over adding an isolated menu activity.
5. Prove it: the game's `apps/porthole/host/test_<name>.cpp` (shared `host/` directory, named per game) passes; a script tour (see the `tour` skill) or `make -C apps/porthole playtest` shows the new screen(s) working and reachable/escapable by touch; if you added or resized a persisted field, a migration test covers the old-save path.
6. A feature is ready when: rules and migrations pass; restart, replay, and time changes (skip forward, clock rollback) preserve progress correctly; every changed screen is reachable and has a way back; `make -C apps/porthole playtest`'s UI audit is at zero FAIL and zero WARN for anything touched. A successful build or a single screenshot is not proof by itself.
Voir sur GitHub