agentleFS
germanfndezgermanfndez/fiveai-skills/skills/qbcore-framework/SKILL.md

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.

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
  1. Very specific:

    Always nil-check: if not Player then return end before calling any method.

    line 24
  2. Distinctive:

    Use state bags OR events for a given piece of state, never both.

    line 27
  3. Distinctive:

    Prefer ox_lib for notifications, menus, dialogs and progress bars.

    line 29
  4. Very specific:

    Use dynamic Wait() values in loops.

    line 30

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.
  • Player exists on the SERVER only (QBCore.Functions.GetPlayer(source)). QBCore.PlayerData exists on the CLIENT only, populated after QBCore:Client:OnPlayerLoaded.
  • Always nil-check: if not Player then return end before calling any method.
  • Money, jobs, gangs, items and metadata are mutated on the server through Player.Functions.*, never from the client.
  • Pass a reason to AddMoney, 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; avoid Wait(0) unless per-frame work is required.

Decision Gates

NeedUse
Client asks server for dataQBCore.Functions.CreateCallback + QBCore.Functions.TriggerCallback
MoneyPlayer.Functions.AddMoney/RemoveMoney/SetMoney/GetMoney(moneyType, ...)
Job / duty / gangPlayer.Functions.SetJob, SetJobDuty, SetGang
Persistent per-player flagsPlayer.Functions.SetMetaData / GetMetaData
Items (qb-inventory)Player.Functions.AddItem/RemoveItem/GetItemByName/GetItemBySlot
Shared runtime statestate bags (see rules/core-concepts.md)

Execution Steps

  1. Confirm qb-core starts before the resource; cache QBCore per side.
  2. Decide the side: mutation and validation on server, display on client.
  3. Fetch Player, nil-check, then validate every client-supplied argument.
  4. Pick the call from Decision Gates; read the matching rules file for signatures.
  5. 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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.