Reverse-Engineer a Server Protocol from a Game Client and Reproduce a Deployable Server

Who It Is For

This Skill is for people who only have a game client and want to reconstruct the server protocol so the original client can run locally offline. It suits tasks that need the reverse-engineering process organized into checkable artifacts: first state what has already been read and what is still missing, then maintain evidence and confidence, next form a protocol specification, and only then move on to server code, deployment, and validation.

Its core value is not having the agent immediately produce a pile of scattered code, but using the protocol specification as the basis for later implementation. When switching games, the focus should be on replacing the specification and evidence, rather than repeatedly piling up code whose origin cannot be traced. If your goal is to clarify the protocol first, control the boundaries of inference, and only then attempt offline operation, this sequence is a good fit.

Complete the First Attempt in 3 Minutes

The premise is that you are genuinely starting from the client and are prepared to limit the first task to analysis and artifact checks, rather than immediately generating or deploying a server. In a project you are authorized to handle, first execute the sole recommended path in the terminal:

npx skills add ShrugYu/game-client-to-server-reverse

The installation location is determined by the skills CLI result and the list of Skills visible to the selected agent. The page provides the official installation command but does not provide a fixed disk path, so do not guess the directory yourself; after the command finishes, first confirm that the agent can recognize this Skill.

Next, in an agent that supports Skills, trigger a low-risk task: ask it to read the existing client materials first and output only project-profile.yaml, evidence-inventory, and protocol.spec.yaml, without writing server code, deploying, or performing operations that change external state. Have it clearly label known information, gaps, the evidence and confidence for each conclusion, and treat the protocol specification as the sole source of truth.

The success signal for the first attempt is that the agent produces results in the order project-profile.yaml, evidence-inventory, protocol.spec.yaml, without jumping directly to code before the specification is complete. After checking these three artifacts, explicitly confirm whether file writes, deployment, or other external actions are allowed; if the agent immediately throws out code without a specification and evidence inventory, ask it to redo the previous step.

Use Cases

Case one: With only a client, first reconstruct the protocol and prepare for offline operation.

When the goal is to turn a game with “only a client” into a “server protocol + usable server,” first have the agent complete the material inventory, evidence inventory, and protocol specification. The key deliverables for this case are project-profile.yaml, evidence-inventory, protocol.spec.yaml, and an explanation of missing information and confidence. It is suitable for establishing shared facts when approaching a game for the first time and avoiding treating guesses as protocol. Only after the specification is complete should you check whether it is sufficient to support local offline operation of the original client; before then, generated code should not be treated as success.

Case two: Once the specification is stable, derive the server from it and complete validation.

After the protocol specification has been formed and confirmed, ask the agent to derive server code from protocol.spec.yaml, then handle deployment and validation. The real workflow in this case is “server code + deployment + validation,” but every step should be based on the specification. Stop file writes, deployment, or actions that require external connections at the confirmation point, and execute them only after explicit permission; the observable completion signal is that implementation, deployment, and validation can all be traced back to the same specification, rather than producing a batch of unexplained code.

Usage Boundaries

The page explicitly requires a specification before code, so this is not suitable as an instant code-generation tool. The available information does not provide a fixed installation directory, a specific game case, or a set of deployment parameters ready to copy, so the first attempt can only verify installation visibility and the order of prerequisite artifacts; it cannot promise that a particular project will definitely run offline. The listed agents are known supported targets, not an exclusive range; likewise, do not infer an unspecified language range from the example. Any file writes, deployment, or external actions beyond analysis, specification organization, and controlled validation must wait for confirmation.