メニュー
Use at the end of a SWUDeck (NOT overall TCGEngine work) working session to run a short retro, capture durable lessons, and hand off cleanly. Invoke when the user says they're wrapping up, asks to "close the session", "run the retro", or asks "what were the lessons learned this session".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when debugging a specific SWUSim in-game bug or unexpected behavior tied to a real game (e.g. "game 2619 auto-resolves this leader ability wrong", "why did this prompt appear", "this ability should have auto-passed", "the shield popped when it shouldn't"). For reproducing and root-cause-fixing a live-game defect from its saved gamestate.
Use when starting a NEW SWU set to generate its consolidated SWUSim/docs/<set>-implement.md plan (for swusim-implement-set-plan to drive). Scans the generated card dictionaries, classifies every card, surveys for unbuilt core mechanics (hard-stops if found), then batches needs-work cards autonomy-first. Generate-only; one set abbreviation as input.
Use when implementing SWU card abilities — looks up card text, writes all DSL tests first, then self peer-reviews against the CR + game logic + card data and implements; only stops for the user on a card it can't verify to 98% alone. Supports single cards and batches.
Use when the user wants to drive a whole multi-batch SWUSim implementation plan doc (e.g. docs/<set>-complex-plan.md) to completion in one session — "run/execute the <set> plan", "work through the remaining phases". For many card batches across phases at once; for a single batch use swusim-implement-card.
Use when asked to verify a SWU set is "card complete" / review a set for implementation gaps (e.g. "is JTL card complete?", "validate the SOR set", "what's left in LOF?"). Runs two independent completeness checks — a dictionary-vs-Done-list diff AND an inverse-stub sweep that proves every trigger stub has a real handler — classifies each finding as a real gap or a false positive, and reports. Read-only validation; hand real gaps to swusim-implement-card.
Use at the START of a SWUDeck (NOT overall TCGEngine) working session to get oriented — recall past gotchas/lessons, confirm the local dev environment + cross-browser verification tooling are ready, and surface in-flight work — before making changes. Invoke when the user signals they're beginning SWUDeck work ("let's work on SWUDeck", "start a SWUDeck session") or runs /swudeck-session-start.
| name | swudeck-session-close |
| description | Use at the end of a SWUDeck (NOT overall TCGEngine work) working session to run a short retro, capture durable lessons, and hand off cleanly. Invoke when the user says they're wrapping up, asks to "close the session", "run the retro", or asks "what were the lessons learned this session". |
A lightweight end-of-session ritual: surface process lessons, route durable facts to the right place, and leave the working tree in a clean, hand-off-ready state.
Create a todo per step and work through them in order.
Answer, honestly and specifically: "What were some lessons learned from this session that we might be able to use to improve future development?"
Draw from what actually happened this session — the wrong turns as much as the wins. Good
lessons are concrete and reusable ("verify CSS layout in Firefox/WebKit, not just
Chromium — height:100% doesn't resolve through a flex-stretched parent in strict
engines"), not platitudes ("test more"). Prefer lessons that would have saved real time or
avoided a wrong conclusion.
Add a dated entry to references/lessons-learned.md (newest at the bottom). Format:
## YYYY-MM-DD — <short session title>
- **<lesson headline>.** <1-2 sentences: what happened, what to do next time.>
- ...
Keep each lesson to a tight bullet. This log is for process/development lessons.
A retro lesson and a durable fact are different things. If the session surfaced a durable
codebase gotcha, tool/credential fact, or project constraint that will matter in future
sessions regardless of this retro, write it to the memory system (memory/ + a pointer in
MEMORY.md) — that's what gets recalled next time. The retro log is not loaded as context;
memory is. When in doubt, do both: a terse process bullet here, the durable fact in memory.
Examples of things that belong in memory, not (only) here:
A short retro summary to the user (the lessons), confirmation of what was written where (retro log vs memory), and the hand-off notes (uncommitted files, pending items).