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.

소스 정보

저장소
dreamiurg/porthole
최근 소스 활동
2026년 9월 25일 09:37
감지된 SKILL.md 언어
영어
스타
1
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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.
GitHub에서 보기