Skip to main content

feature

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.

Source facts

Repository
dreamiurg/porthole
Last source activity
September 25, 2026 at 09:37
Detected SKILL.md language
English
Stars
1
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
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.
View on GitHub