QBCore development guide

QBCore AI script generator: jobs, events and server-side checks

QBCore makes it convenient to work with players, jobs, money and metadata, but that convenience does not remove the need for server authority. When you use AI to build a QBCore resource, the useful question is not “can it write Lua?” It is whether the resource keeps trust boundaries clear and fits the framework your server actually runs.

1. Define the job or system as state transitions

For a mechanic job, a player might go on duty, inspect a vehicle, consume a repair item, complete an animation and receive a server-approved result. For a police evidence system, a player might collect an item, store metadata and retrieve it only with the correct job and permissions. Writing these transitions first gives the AI something testable to implement.

Who can start?Job, grade, duty state, item or location checks.

What can change?Inventory, money, metadata, shared state or cooldowns.

Who approves it?The server, using current framework state.

What can fail?Disconnects, duplicate events, missing exports and stale state.

2. Keep QBCore object usage on the correct side

Client code can read local player data for presentation, but server-side code should be responsible for authoritative job checks, money changes and item transactions. Do not let a client send a final payout or claim it owns an item without verification.

3. Make event validation part of the prompt

When a server event is called: - Resolve the player from source. - Verify the expected job/grade/duty state. - Verify required inventory and position when relevant. - Enforce cooldown or one-time state. - Calculate reward on the server. - Apply the result once. - Log or safely reject invalid requests.

4. Keep framework assumptions visible

QBCore servers differ. Inventory resources, target libraries, notification systems and database patterns vary. Ask the AI to list assumptions at the top of the README or configuration instead of silently choosing one implementation.

5. Separate configuration from logic

Locations, grades, item names, prices and cooldowns often belong in configuration. Business logic should read those values rather than scattering magic numbers through client and server files.

6. Test the resource privately

Test with the correct job and without it.
Test while on duty and off duty.
Trigger the network event repeatedly.
Test missing inventory.
Restart the resource during an interaction.
Test two players using the same state.

7. A prompt for a stronger first version

Build a QBCore [job/system] as a complete resource. Return: - fxmanifest.lua - config.lua - client.lua - server.lua - README.md Server requirements: - Validate job, grade, duty state, inventory and relevant position. - Never accept a payout or final inventory state from the client. - Prevent duplicate rewards and event spam. - List external dependencies and assumptions. After implementation, include a private test matrix and explain the highest-risk server events.

8. Why project context matters

The second and third change to a resource are often harder than the first generation. A project workspace is useful because you can bring back a bug, change a dependency or add a feature without throwing away the existing structure.

Stellar is designed for that loop: structured brief → related files → private testing → error/change request → next revision.

9. Think about abuse cases before adding polish

Every valuable action is an abuse target. If a job pays money, assume someone will try to trigger the payout event without doing the job. If an item is removed and another is granted, assume someone will retry the event or call it from the wrong location. If a shared cooldown exists, think about two players reaching it at the same time. These questions should shape the server implementation before you add UI animations or extra effects.

A useful AI review prompt is to ask for the highest-value events in the resource and then request an abuse-case table for each one: what the client sends, what the server should verify, what state changes, and what happens on a duplicate or malformed request.

10. Keep logs useful, not noisy

Server logs are valuable when they help explain a failed or suspicious action. Log unexpected state, missing dependencies and rejected high-value actions where appropriate, but avoid printing every normal interaction. For production servers, consistent identifiers and concise messages make support easier than dozens of ad-hoc prints.

11. Plan framework upgrades

QBCore APIs and the surrounding ecosystem evolve. Keep direct framework calls concentrated where practical so changes are easier to update. If the resource depends on an inventory or target package, isolate those calls behind a small adapter or clearly documented integration section. This reduces the amount of code you need to touch when a server changes a dependency.

12. Release checklist

All network events have server-side validation.
Job, grade and duty checks use current server state.
Money and items cannot be awarded twice from the same action.
Dependencies and configuration are documented.
Client UI still behaves when the server rejects a request.
Resource restart behaviour has been tested.
Multiple players have been tested together.
The previous working release is tagged or otherwise recoverable.

Once those basics are reliable, then add convenience features, richer interfaces and more content. This order keeps the resource easier to debug because the trusted core already works.

Official references

Before shipping, check the current platform documentation: QBCore server function reference; FiveM event security guidance.