From game-porting-skills
Reads goal documents, handoff notes, and relevant skills, then studies code paths to produce a preparation summary for a porting milestone. Does not write code.
How this skill is triggered — by the user, by Claude, or both
Slash command
/game-porting-skills:porting-start-milestoneThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are entering Phase 1: Prepare for the current milestone.
You are entering Phase 1: Prepare for the current milestone.
Locate the agent's artifact directory at <project-root>/.porting/ (defined in porting-methodology). All artifacts live there. Load the porting-methodology skill if not already in context.
Check for a goal document (goal-*.md in the artifact directory). If none exists, tell the user: "No goal document found. Run /porting-plan-goal first." and stop.
Read the goal document. Find the first milestone with status "Not started" or "In progress":
/porting-plan-goal to define the next porting goal." and stop.Read porting-memory.md — review the watch list and feature status. Note any items relevant to this milestone.
Read the latest handoff note (porting-handoff-*.md in the artifact directory, if one exists). This is your memory from the last session — what was done, what's deferred, known issues, what to watch for.
Then load domain skills based on what the current milestone will involve. Use the skill-loading table defined in the porting-methodology skill, the goal document's milestone description, and the handoff note's "skills needed next" recommendation to decide. Load what's relevant — not everything.
You MUST actually read each loaded skill — not just list it. After loading a skill, read through its key sections (workflow patterns, API patterns, anti-patterns, common pitfalls). Extract the specific patterns and conventions that apply to this milestone's work items. You will cite these in your preparation summary.
Do NOT ask the user questions whose answers are already in your loaded skills. If a skill documents the API pattern, the binding convention, or the architectural approach — use that answer. Only ask the user about things that are genuinely undiscoverable from the codebase and loaded skills combined.
This is where the planned scope is validated against the actual codebase. Be thorough — everything needed to meet the success criterion must be identified here, not discovered during execution.
Identify work items:
STUB comments from previous milestones that this milestone resolves: grep -r "STUB" <backend-directory>Trace dependencies for each work item. Read the code paths that will change — the functions, their call sites, the data they consume and produce. Identify everything required to make the success criterion pass: prerequisite infrastructure, data flow dependencies, format conversions, resource creation paths.
Check scope against the milestone principle. Each milestone should target one feature. If the work items span multiple unrelated features, the milestone is too large. Flag this to the user and propose splitting — either by carving out new milestones or by deferring items that fit naturally into existing future milestones.
Ask the user about anything undiscoverable — binding conventions, engine-specific constants, architectural decisions you can't verify from the codebase or loaded skills. Do not guess.
Present a preparation summary to the user. The Work Items list is the scope contract for this milestone — only these items will be implemented during /porting-execute.
## Milestone Preparation: [milestone name]
### Goal
[From goal document — milestone success criterion]
### Skills Loaded
[For each skill loaded, list:
- Skill name and why it's needed for this milestone
- Key patterns from the skill that apply to the work items (cite specific API calls, conventions, or anti-patterns you found by reading the skill)]
### Work Items
[Complete list of what will be implemented this milestone — from STUBs, handoff note, dependency tracing, and milestone scope. This list is the scope contract for /porting-execute.]
### Code Paths Affected
[Key files and functions that will be modified]
### Watch List Items (from porting-memory.md)
[Any relevant items from the watch list that affect this milestone]
### Questions for User
[Anything undiscoverable or uncertain — ask before starting. Do NOT include questions answered by your loaded skills.]
Do NOT proceed to writing code. Wait for the user to review the preparation summary, answer questions, and explicitly approve.
The user's approval sets the scope boundary for this milestone. The /porting-execute phase will implement only the approved work items.
After the user approves: Update porting-memory.md with the current milestone's success criterion and approved work items. Keep it concise (a few lines) — this ensures the scope contract survives in persistent memory throughout the execute phase. Remember that porting-memory.md must stay under 200 lines total.
Once the user approves, tell them: "Preparation approved. Run /porting-execute to begin implementation."
npx claudepluginhub apple/game-porting-toolkit --plugin game-porting-skillsCloses out the current milestone by prompting a commit, updating porting-memory.md, writing a handoff note, and updating the goal document milestone status.
Automates pre-development workflow for large-scale project transformations like rewrites, migrations, refactors: performs full analysis, task decomposition, documentation generation, progress tracking, and sub-SKILL creation before coding.
Manages project milestones: create new cycles with phases, complete/archive versions, preview changes, audit integration, analyze gaps. For structured delivery checkpoints.