qbcore-framework
Skill19 starsChanged 2 months agoMITView on GitHub
Trigger: QBCore, qb-core, Player object, PlayerData, QBCore.Functions.GetPlayer, Player.Functions, QBCore callbacks, jobs, gangs, economy. Build qb-core resources with player methods, callbacks and events.
In this repository12 other files it gives its agents.
- skill-creatorSkill
- esx-frameworkSkill
- fivemanageSkill
- fivem-basicsSkill
- fivem-deploymentSkill
- fivem-nuiSkill
- fivem-securitySkill
- lua-basicsSkill
- ox-inventorySkill
- oxlibSkill
- oxmysqlSkill
- ox-targetSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 24
Always nil-check: if not Player then return end before calling any method.
- Distinctive: line 27
Use state bags OR events for a given piece of state, never both.
- Distinctive: line 29
Prefer ox_lib for notifications, menus, dialogs and progress bars.
- Very specific: line 30
Use dynamic Wait() values in loops.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
QBCore Framework
Server/client API for qb-core: Player object, PlayerData, callbacks, jobs, gangs, money and metadata.
Activation Contract
Load this skill when the user creates or edits a qb-core resource, touches Player / QBCore.PlayerData, needs jobs, gangs, money, items or metadata through QBCore, or asks about QBCore callbacks, events or best practices.
This skill targets qb-core (qbcore-framework). If the user is on Qbox (qbx_core, exports.qbx_core), the APIs diverge: state it and do not apply this skill blindly.
Hard Rules
- Acquire the core once with
local QBCore = exports['qb-core']:GetCoreObject(); never call it inside every function. Playerexists on the SERVER only (QBCore.Functions.GetPlayer(source)).QBCore.PlayerDataexists on the CLIENT only, populated afterQBCore:Client:OnPlayerLoaded.- Always nil-check:
if not Player then return endbefore calling any method. - Money, jobs, gangs, items and metadata are mutated on the server through
Player.Functions.*, never from the client. - Pass a
reasontoAddMoney,RemoveMoney,SetMoney. - Use state bags OR events for a given piece of state, never both.
- Validate every client-supplied argument on the server; never trust amounts, prices or item names sent by the client.
- Prefer ox_lib for notifications, menus, dialogs and progress bars.
- Use dynamic
Wait()values in loops; avoidWait(0)unless per-frame work is required.
Decision Gates
| Need | Use |
| Client asks server for data | QBCore.Functions.CreateCallback + QBCore.Functions.TriggerCallback |
| Money | Player.Functions.AddMoney/RemoveMoney/SetMoney/GetMoney(moneyType, ...) |
| Job / duty / gang | Player.Functions.SetJob, SetJobDuty, SetGang |
| Persistent per-player flags | Player.Functions.SetMetaData / GetMetaData |
| Items (qb-inventory) | Player.Functions.AddItem/RemoveItem/GetItemByName/GetItemBySlot |
| Shared runtime state | state bags (see rules/core-concepts.md) |
Execution Steps
- Confirm
qb-corestarts before the resource; cacheQBCoreper side. - Decide the side: mutation and validation on server, display on client.
- Fetch
Player, nil-check, then validate every client-supplied argument. - Pick the call from Decision Gates; read the matching rules file for signatures.
- Return data via callbacks, not paired events.
Output Contract
Return runnable Lua with the client/server split explicit, Player nil-checked, and reasons on money operations. Use ox_lib for UI unless the user asks otherwise.
References
- rules/core-concepts.md — architecture, PlayerData, Player object, events, state bags.
- rules/player-methods.md — Player.Functions money, job, gang, metadata, items.
- rules/best-practices.md — naming, caching, waits, state management, security.
- rules/reference-links.md — official QBCore documentation links.
Upstream docs: https://docs.qbcore.org
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

