Skip to content

Vibe coding

Start the conversation with a direct instruction and the compact machine-readable reference:

You are working on a KILLSCRIPT TypeScript module.
Read https://silentbless.github.io/killscript/llms.txt before changing code.
Use only APIs documented there or in the linked native API reference.

llms.txt explains the project layout, client/Reflex boundary, compiler macros, runtime limitations and known game bugs. It is intentionally compact so the assistant can load it before every task instead of guessing from unrelated Lua, Roblox or browser APIs.

Describe the behavior and relevant constraints:

Add a client status overlay toggled with F6. Keep the feature in its own file,
declare the binding with defineControls(), and clean up visuals when disabled.
Do not put gameplay decisions on the client.

Let the assistant choose files inside the documented structure. Requiring all code in main.ts works against the compiler’s static bundling and makes later changes harder.

Run npm run dev while editing. After each meaningful change, ask the assistant to run:

Terminal window
npm run check

Then verify the visible behavior in game. Type checking proves API shape and context, but only the game can confirm camera placement, UI appearance and current runtime behavior.

  • Keep main.ts as a composition root and use feature/helper files.
  • Use @killscript/sdk/client and @killscript/sdk/server in the correct entry.
  • Make a decision in Reflex only when its API can observe the required state and apply the result; then inform the client.
  • Prefer defineNetwork() over raw sends; it batches same-tick messages.
  • Prefer SDK helpers for native arrays, scheduling, controls and cleanup.
  • Fall back to the typed native API instead of inventing an SDK method.
  • Never assume Node.js, browser, Roblox, Luau or unrestricted Lua globals exist.
  • Do not bypass a known game limitation just because a setter type exists.

For precise native behavior, follow the link from Game API and types.