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.

Informations de source

Dépôt
dreamiurg/porthole
Dernière activité de la source
25 septembre 2026 à 09:37
Langue détectée de SKILL.md
anglais
Étoiles
0
Forks
0

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
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