protheus-reference
Skill183 starsChanged 2 months agoMITView on GitHub
Use when the user needs to look up a TOTVS Protheus native function's syntax/parameters/return value, the SX data dictionary structure (SX1-SX9, SIX), REST API endpoint patterns (FWRest, WsRestFul), MV_* system parameter behavior, SX3 field validation, or whether a function is restricted/internal-only. Also triggers on Portuguese phrasing like "funcao nativa", "dicionario de dados", "parametro MV_", "campo SX3", "API REST protheus", "essa funcao e restrita".
In this repository21 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- advpl-code-generationSkill
- advpl-code-reviewSkill
- advpl-debuggingSkill
- advpl-refactoringSkill
- advpl-to-tlpp-migrationSkill
- advpr-test-automationSkill
- changelog-patternsSkill
- code-explanationSkill
- documentation-patternsSkill
- embedded-sqlSkill
- probat-testingSkill
- protheus-businessSkill
- protheus-locks-deadlocksSkill
- query-builderSkill
- smartview-developmentSkill
- smartx-developmentSkill
- sx-configurationSkill
- tdn-lookupSkill
The file
Files
Protheus Reference
This skill is a quick-lookup reference guide for the TOTVS Protheus ecosystem: native function syntax/parameters/return values across categories (String, Date/Time, Array, Database, Interface, Network, JsonObject, ExecAuto, etc.), the SX data dictionary (SX1 Perguntas through SXB/SIX), REST API patterns (FWRest annotations vs. legacy WsRestFul), and MV_* system parameters.
Activate this skill when the user needs to confirm how a native function works, validate a custom field against SX3, check REST endpoint conventions, or verify a function isn't on the restricted/internal-only list (checked first, always, before recommending any function). The lookup strategy is local-first (native-functions.md, sx-dictionary.md, sx3-common-fields.md, rest-api-reference.md), falling back to a tiered TDN online search (WebFetch API, then Playwright API JSON, then Playwright HTML) via the tdn-lookup skill when not found locally.
It does not cover business-process context for why a table/field is used (see protheus-business), writing the SQL to query these tables (see embedded-sql), or generating documentation that references these functions (see documentation-patterns).
| Reference file | Read when |
| reference.md | Always -- function category index, data dictionary overview, REST API pattern summary, and the local-first/TDN lookup strategy |
| native-functions.md | Looking up exact syntax, parameters, and return value of a specific native function |
| sx-dictionary.md | Understanding SX1-SX9/SIX table structure and programmatic usage of the data dictionary |
| sx3-common-fields.md | Validating whether a custom or standard field exists on a table before referencing it in code |
| restricted-functions.md | Checking whether a function/class is internal-only or blocked from compilation before recommending it |
| rest-api-reference.md | Building or documenting a REST endpoint (FWRest annotations or legacy WsRestFul) |
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.