thalysjuvenal/advpl-specialist

# ADVPL/TLPP Code Generation

This skill provides patterns, templates, and mandatory structural rules for generating new ADVPL (`.prw`) and TLPP (`.tlpp`) code for TOTVS Protheus. It covers naming conventions (module prefixes, Hungarian notation), the mandatory User Function skeleton with Protheus.doc headers and error handling, variable scope rules, TLPP namespace conventions (`custom.<agrupador>.<servico>`), and the 8/10/255-character identifier length limits per construct type.

Activate this skill whenever the user requests new code creation: a new function, a TLPP class, an MVC screen, a REST endpoint, a SOAP web service, an entry point, a report, a batch job, or any new `.prw`/`.tlpp` file. It does not cover reviewing existing code (see `advpl-code-review`), fixing errors in existing code (see `advpl-debugging`), improving existing code structure without adding features (see `advpl-refactoring`), or converting legacy `.prw` to `.tlpp` (see `advpl-to-tlpp-migration`).

The reference and pattern files below hold the concrete templates -- read the specific pattern file that matches the type of code being generated instead of relying on memory.

| Reference file | Read when |
|---|---|
| reference.md | Always -- overview, naming conventions, mandatory User Function structure, namespace rules, identifier length limits, common mistakes |
| templates-classes.md | Generating a TLPP class (data, methods, constructor) |
| patterns-mvc.md | Generating an MVC screen (ModelDef/ViewDef/MenuDef) |
| patterns-rest.md | Generating a REST API endpoint (WsRestFul or TLPP `@Get/@Post` annotations) |

# ADVPL/TLPP Code Review

This skill provides a systematic code review methodology for existing ADVPL/TLPP code, producing findings tagged with a rule ID (`BP-*`, `PERF-*`, `SEC-*`, `MOD-*`), a severity (CRITICAL/WARNING/INFO), the file/line, the issue, and the fix. It covers four review categories: best practices, performance, security, and modernization, and can map findings to the official TOTVS SonarQube quality gate.

Activate this skill when the user wants existing code inspected for quality, compliance, security, or performance issues -- e.g. before a merge, before a deploy, during an onboarding audit, or when assessing migration readiness from `.prw` to `.tlpp`. It does not cover generating new code (see `advpl-code-generation`), diagnosing a specific runtime/compilation error (see `advpl-debugging`), restructuring code without adding features (see `advpl-refactoring`), or performing the actual `.prw` to `.tlpp` conversion (see `advpl-to-tlpp-migration`).

| Reference file | Read when |
|---|---|
| reference.md | Always -- review categories, output format, severity levels, review process, rule ID prefixes |
| rules-best-practices.md | Checking RecLock/MsUnlock pairing, variable scope, area management, error handling, documentation (BP-* rules) |
| rules-performance.md | Checking Embedded SQL efficiency, loop efficiency, string operations, index usage (PERF-* rules) |
| rules-security.md | Checking SQL injection, input validation, credential exposure, sensitive data logging (SEC-* rules) |
| rules-modernization.md | Checking TLPP migration candidates, namespace usage, OOP patterns, modern UI frameworks (MOD-* rules) |
| sonarqube-rules-catalog.md | Aligning findings with the official TOTVS SonarQube ruleset (groups G1-G5, CA/BG/CS codes) |

# ADVPL/TLPP Debugging

This skill provides a systematic methodology for diagnosing and resolving ADVPL/TLPP errors: a decision flow (compilation vs. runtime), a quick-diagnosis table by symptom, logging tool guidance (`Conout`, `FWLogMsg`, `ErrorBlock`), database lock diagnosis (`RecLock`/`MsUnlock`), and quick performance checks (wrong index, array growth in loops, Embedded SQL vs ISAM).

Activate this skill when the user reports an error message, a stack trace, a compilation failure, a hanging/locked record, a slow routine, or an AppServer crash/log to investigate. It does not cover generating new code from scratch (see `advpl-code-generation`), a general quality audit of working code (see `advpl-code-review`), restructuring code that already works correctly (see `advpl-refactoring`), or converting `.prw` to `.tlpp` (see `advpl-to-tlpp-migration`).

| Reference file | Read when |
|---|---|
| reference.md | Always -- debug methodology flow, quick diagnosis by symptom, logging tools, lock diagnosis, performance quick checks, common debugging mistakes |
| common-errors.md | Looking up a specific compilation or runtime error message (top 50 ADVPL/TLPP errors with cause and fix) |
| performance-tips.md | Investigating a performance bottleneck in depth (query optimization, loop efficiency, memory) |

# ADVPL/TLPP Refactoring

This skill defines safe refactoring patterns (RF-001 through RF-006) for improving ADVPL/TLPP code structure without altering behavior: extract function, simplify conditionals with guard clauses, remove dead code, improve naming to Hungarian notation, eliminate duplication, and reduce function parameter count. It also defines the mandatory process -- analyze, prioritize, present a before/after plan, wait for user approval, apply one change at a time, verify -- and hard safety rules (never change business logic, never rename externally-used symbols without a caller check).

Activate this skill when the user wants existing, working code restructured for readability or maintainability: long functions, deep nesting, unclear names, copy-pasted blocks, or functions with excessive parameters. It does not cover fixing bugs or errors (see `advpl-debugging`), generating brand-new functionality (see `advpl-code-generation`), a formal quality/security audit (see `advpl-code-review`), or converting procedural `.prw` to object-oriented `.tlpp` (see `advpl-to-tlpp-migration`, which is a structural paradigm change rather than a behavior-preserving cleanup).

| Reference file | Read when |
|---|---|
| reference.md | Always -- the only file in this skill; contains all refactoring patterns (RF-001 to RF-006), the refactoring process, and safety rules |

# ADVPL to TLPP Migration

This skill guides the conversion of legacy `.prw` procedural code (User Functions, Static Functions, Private/Public variables) into modern `.tlpp` classes with `namespace` declarations, `data` properties, and `public`/`private` methods -- following the official TOTVS naming conventions (lowercase dot-separated namespaces, PascalCase classes, camelCase methods, no underscores). It defines the migration workflow (analyze -> identify -> map to class design -> user approval -> generate -> checklist -> validate) and mandates keeping the original `.prw` User Function as a thin backward-compatible wrapper delegating to the new class.

Activate this skill when the user wants an existing procedural routine converted to TLPP, needs help deciding a namespace, or is modernizing multiple `#Include` directives to `.th` includes. It does not cover generating brand-new TLPP code that has no ADVPL predecessor (see `advpl-code-generation`), behavior-preserving cleanup of code that stays in ADVPL (see `advpl-refactoring`), auditing code quality before migration (see `advpl-code-review`), or fixing errors encountered during or after migration (see `advpl-debugging`).

| Reference file | Read when |
|---|---|
| reference.md | Always -- overview, migration strategy flow, core conversion rules table, TLPP naming conventions, full before/after example, key migration decisions, common mistakes |
| migration-rules.md | Needing the complete mapping of every ADVPL construct (preprocessor directives, database operations, error handling, UI elements) to its TLPP equivalent |
| migration-checklist.md | Verifying a completed migration is thorough before declaring it done |

# ADVPR — Automação de Testes Protheus

This skill covers writing and running automated business-rule regression tests for TOTVS Protheus using ADVPR, the internal ADVPL-based test robot. It explains the `FWTestHelper` assertion API, how to register and organize test cases in a TestSuite (GPS de Testes), how to run suites with or without UI (`FWMyTestRunner` vs headless `FwExecSuite`), and per-routine-pattern scripting guidance for MVC, ExecAuto/MSExecAuto, reports, processing routines, webservices (REST/SOAP/Portal), SmartLink, Smart View, and TOTVS Message (single-message) flows. It also covers "routine preparation" -- adjusting legacy code so it runs screen-free during official headless execution -- and general ADVPR scripting best practices.

Activate this skill when the user wants to create or debug an ADVPR test script, set up a TestSuite, diagnose a TimeOut or unexpected-screen failure during headless execution, or needs guidance on which ADVPR pattern applies to a given routine type. It does not cover manual/interface-driven QA, unit testing of isolated ADVPL functions outside ADVPR, or general debugging of runtime/compilation errors unrelated to test automation (see `advpl-debugging`).

The referenced files are written in Brazilian Portuguese.

| Reference file | Read when |
|---|---|
| reference.md | Always -- ADVPR concept, patch prerequisite, FWMyTestRunner vs FwExecSuite headless execution, TimeOut causes |
| api-fwtesthelper.md | Writing assertions/expectations -- full FWTestHelper method reference |
| best-practices.md | Reviewing or writing ADVPR scripts -- recommended scripting conventions |
| gps-de-testes.md | Creating/organizing a TestSuite and its test cases (GPS de Testes) |

# Changelog Patterns

This skill defines how to analyze ADVPL/TLPP code changes (via git diff or a supplied file list) and produce a structured changelog: change type classification (NEW/FIX/CHANGE/REMOVE/REFACTOR with Portuguese labels), impact level assessment (ALTO/MEDIO/BAIXO), detection of affected database tables from `DBSelectArea`/`RecLock`/`BeginSQL` patterns, and output in either Markdown or plain-text format.

Activate this skill when the user wants a client-facing or internal changelog, release notes, or delivery documentation generated from a set of code changes. It does not cover generating documentation headers or technical routine specs from a single source file with no diff context -- that is closer to a documentation-generation task and out of scope for this skill's diff-analysis process; it also does not cover code review findings (see `advpl-code-review`) or the migration checklist for `.prw` to `.tlpp` conversions (see `advpl-to-tlpp-migration`).

| Reference file | Read when |
|---|---|
| reference.md | Always -- the only file in this skill; contains change types, impact levels, Markdown/TXT changelog formats, and the full analysis process |

# ADVPL/TLPP Code Explanation

This skill provides a methodology for explaining existing ADVPL/TLPP code in plain language, tailored to three audience levels: a junior developer needing line-by-line detail, a senior developer needing a business-logic summary with risks and technical debt, and a functional consultant needing a non-technical description of what the routine does from a business perspective.

Activate this skill when the user wants an existing routine, function, or snippet explained -- e.g. onboarding a new developer, understanding legacy code with no documentation, or briefing a functional consultant on a customization. It reads the target code, determines the requested (or asked) explanation level, and structures the output accordingly, optionally pulling in native-function meanings, business-process context, or SQL details as needed.

It does not cover generating formal documentation artifacts like Protheus.doc headers or full routine specs (see `documentation-patterns`), looking up native function syntax in isolation (see `protheus-reference`), or explaining embedded SQL macro semantics in depth (see `embedded-sql`).

| Reference file | Read when |
|---|---|
| reference.md | Always -- explanation levels, structure per level (junior/senior/funcional), and the analysis process |

# ADVPL/TLPP Documentation Patterns

This skill provides templates and a generation process for turning ADVPL/TLPP source code into Protheus-standard technical documentation. It covers three output types: a `header` Protheus.doc comment block for a single function/method, a `full` markdown routine specification (objective, module, tables read/written, MV_* parameters, entry points, execution flow, dependencies, change history), and an `api` REST endpoint document (authentication, path/query parameters, request body, response schemas).

Activate this skill when the user asks to generate or add documentation for existing code -- headers, full routine specs, or API docs -- following TOTVS conventions. The process reads the target file, extracts functions/parameters/tables/MV_* usage/entry points/dependencies from the code itself, cross-checks git history for author and change log when available, then fills the appropriate template.

It does not cover explaining code in plain conversational language for an audience (see `code-explanation`), looking up native function signatures to fill in documentation accurately (see `protheus-reference`), or documenting the semantics of embedded SQL macros used inside a routine (see `embedded-sql`).

| Reference file | Read when |
|---|---|
| reference.md | Always -- the three documentation type templates (header/full/api) and the generation process |

# Embedded SQL in ADVPL/TLPP

This skill covers writing SQL inside ADVPL/TLPP using `BeginSQL ... EndSQL` blocks and their special macro expressions -- `%table:TABLE%` for physical table resolution, `%xfilial:TABLE%` for branch filtering, `%notDel%` for logical-deletion filtering, `%exp:EXPRESSION%` for safe variable binding, and `%Order:TABLE%` for primary-key ordering. It also covers `column` type declarations, JOIN and aggregation patterns, subqueries, and migrating legacy `TCQuery` string-concatenation code to Embedded SQL.

Activate this skill whenever the user is writing a new query, reviewing an existing one for correctness/safety, or converting old concatenated-string SQL to the modern BeginSQL syntax. It also covers the restrictions and gotchas of BeginSQL (no `*` at line start, always include `%notDel%` and filial filtering, use `GetNextAlias()`, close aliases) and when to use `TCSqlExec` instead for INSERT/UPDATE/DELETE.

It does not cover general native function lookups unrelated to SQL (see `protheus-reference`), business-process context for which tables/fields to query (see `protheus-business`), or generating documentation for a routine that happens to contain SQL (see `documentation-patterns`).

| Reference file | Read when |
|---|---|
| reference.md | Always -- BeginSQL syntax, macro expressions, JOIN/aggregation/subquery patterns, DML via TCSqlExec, performance tips, and TCQuery migration |

# ProBat Testing (TLPP)

This skill covers ProBat, the native unit/functional/integration testing engine of tlppCore, used exclusively with TLPP (`.tlpp`) source files -- even when the code under test is legacy `.prw`. It covers the required `#include "tlpp-probat.th"`, the `test.<module>` namespace convention, the full annotation set (`@TestFixture`, `@Test`, `@Setup`, `@TearDown`, `@OneTimeSetUp`, `@OneTimeTearDown`, `@Skip`, `@ErrorLog`), the `tlpp.probat` assertion functions, the class-based execution lifecycle, and `SKIPASSERT` for conditional assertion skipping.

Activate this skill when the user wants to create a new ProBat test fixture, add test methods to cover a routine, set up setup/teardown logic, or understand how ProBat discovers and executes tests (via REST API or the VSCode extension). Concrete test-writing templates live in the sibling patterns file.

It does not cover generating the production TLPP code being tested (see `advpl-code-generation`), reviewing code quality outside of tests (see `advpl-code-review`), or writing embedded SQL used inside test fixtures (see `embedded-sql`).

| Reference file | Read when |
|---|---|
| reference.md | Always -- includes, namespace convention, annotations, assertion function reference, execution lifecycle, and how tests are run |
| patterns-unit-tests.md | Writing a concrete ProBat test fixture and need ready-to-adapt templates/patterns |

# Protheus Business Processes

This skill is a reference guide for TOTVS Protheus ERP business processes across eight modules: Compras, Estoque, Faturamento, Financeiro, Contabilidade, Fiscal, PCP, and Manutencao de Ativos. For each module it documents the main tables and fields, the key routines (e.g. MATA110, MATA460, MATA103), step-by-step business flows, and how the module integrates with others.

Activate this skill when the user asks how a business process works, which tables/fields a routine touches, or how two modules integrate (e.g. Compras feeding Estoque and Financeiro). Look up the module first in the local reference files; if the answer isn't found locally, fall back to a TDN web search as described in the lookup strategy.

It does not cover native function syntax (see `protheus-reference`), writing the SQL to query these tables (see `embedded-sql`), or generating/reviewing code that implements these processes (see `advpl-code-generation`, `advpl-code-review`).

| Reference file | Read when |
|---|---|
| reference.md | Always -- module index, lookup strategy (local first, then TDN), and response format per query type |
| modulo-compras.md | Questions about Compras (COM): solicitacoes, cotacoes, pedidos de compra, liberacao, entrada de NF |
| modulo-estoque.md | Questions about Estoque (EST): movimentacoes, saldos, armazens, inventario |
| modulo-faturamento.md | Questions about Faturamento (FAT): pedidos de venda, notas fiscais de saida, faturamento |

# Protheus Locks & Deadlocks

This skill documents the Protheus hybrid locking model -- record-level Workarea locks (`RecLock`/`MsUnlock`) coordinated by DBAccess on top of the underlying RDBMS (PostgreSQL, MSSQL, Oracle) -- and how to diagnose and prevent the lock leaks, contention, and deadlocks that are among the most common production issues. It covers lock API semantics (`RecLock`, `MsUnlock`/`MsUnlockAll`, `SoftLock`, `LockByName`, `TCSqlExec`, `BeginTran`/`EndTran`/`DisarmTransaction`), safe transaction scoping with `BEGIN SEQUENCE/RECOVER`, and live diagnostic procedures per database engine.

Activate this skill when the user reports a "Record locked by user XYZ" error, needs to investigate performance degradation under concurrent load, is writing or reviewing code that locks records, or is designing a batch job over large data sets where lock ordering matters. It does not cover query design or `%nolock%` usage in Embedded SQL (see `query-builder`), general runtime/performance debugging unrelated to locking (see `advpl-debugging`), or `BeginSQL`/`EndSQL` macro syntax (see `embedded-sql`).

| Reference file | Read when |
|---|---|
| reference.md | Always -- lock types table, core lock/transaction APIs, when-to-use guidance |
| patterns-prevention.md | Writing or refactoring code that locks records -- `BEGIN SEQUENCE/RECOVER`, `SoftLock`, transaction scoping, lock ordering rules |
| diagnostics.md | Investigating live lock contention or deadlocks -- `TopMemoStatus`, MonitorActiveLocks, DBAccess monitor, engine-specific SQL lock queries |

# 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 |

# Protheus Query Builder

This skill helps build correct, safe, and optimized SQL against Protheus ERP tables, respecting the platform's database conventions: mandatory soft-delete (`D_E_L_E_T_`) and multi-branch (`xFilial`) filters, Hungarian-notation field names, dictionary-driven physical schemas (`RetSqlName()`), and SIX index alignment. It guides the agent to choose the right access pattern -- Workarea navigation vs Embedded SQL vs raw `TCSqlExec` -- enforce mandatory filters, order `WHERE` clauses to match available indexes, and parameterize every dynamic value with `FWPreparedStatement` to eliminate injection risk.

Activate this skill when building any query against Protheus tables (standard `SA*`/`SE*`/`SF*` or custom `Z*`), deciding between `DbSelectArea`/`DbSeek` and Embedded SQL, reviewing code for missing mandatory filters, adding parameterized queries, diagnosing slow queries via index misalignment, or writing cross-database code. It does not cover `BeginSQL`/`EndSQL` macro syntax itself (see `embedded-sql`, its companion skill for macro details), nor record locking semantics during writes (see `protheus-locks-deadlocks`).

| Reference file | Read when |
|---|---|
| reference.md | Always -- database conventions, table/field naming, mandatory filters, pattern-choice overview |
| patterns-workarea.md | Generating record-by-record code with `DbSelectArea` + `DbSeek` + `RecLock` |
| patterns-fwpreparedstatement.md | Building parameterized `TCQuery`/`TCSqlExec`, LIKE clauses, INSERT/UPDATE/DELETE |
| index-awareness.md | Choosing/validating an index, ordering WHERE clauses, common SIX key expressions |
| cross-database.md | Using `ChangeQuery()`, `TCGetDB()`, DBAccess macros, MSSQL/PostgreSQL/Oracle equivalents |

# Smart View

This skill covers building custom Smart View business objects on TOTVS Protheus: the TLPP class that inherits from `totvs.framework.treports.integratedprovider.IntegratedProvider`, declares the `@totvsFrameworkTReportsIntegratedProvider` annotation, and implements `new()`, `getSchema()` and `getData()`. It documents the schema contract (`addProperty`, column types, dates), the parameter contract (`addParameter`, `setPergunte`, advanced search via `setCustomURL`, and the custom REST endpoint a combo requires), the query patterns inside `getData`, the `callTReports` menu source, and the full `.trp` resource publication cycle that makes the object reachable from the Protheus menu.

Activate this skill when the user is creating a new Smart View report or data view from scratch, migrating an existing TReport/FWMSPrinter/TMSPrinter/FWMSExcel report into a Smart View business object, wiring parameters with advanced search or combo values, or diagnosing why an object does not appear in the tool, returns no rows, or fails to import its resource. It does not cover Smart X (see `smartx-development`), automated testing of Smart View objects (see `advpr-test-automation`, which has `UTSchemaSmartView`/`UTGetDataSmartView`), nor SX dictionary scripts for the tables being read (see `sx-configuration`).

The referenced files are written in Brazilian Portuguese.

| Reference file | Read when |
|---|---|
| reference.md | Always -- Smart View vs Smart X, environment prerequisites, minimum contract, annotation, REST routes, object identity, end-to-end example |
| patterns-schema.md | Defining columns with `addProperty`: types, dates, calculated columns, discriminator column, page size |
| patterns-parameters.md | Defining parameters: `addParameter`, `setPergunte`, advanced search (lookup), combo values and the custom options endpoint |
| patterns-getdata.md | Writing the query and feeding rows: BeginSQL vs FWExecStatement, multi-branch, currency, workarea rules |

# Smart X

This skill covers developing TOTVS Smart X routines: the Object -> Model -> Interface -> Launcher chain that turns a data dictionary table (SX2/SX3) into an automatically-rendered PO-UI screen without hand-written Angular components. It documents the required includes and annotations for the Model (`totvs.framework.structure.model.th`) and Interface (`totvs.framework.structure.Interface.th`) TLPP classes, the Launcher function that registers the routine in the Protheus menu, integrating existing ADVPL functions into the interface via `pageActions`/`tableActions`/events, and converting only the browse (Data View) of a legacy MVC routine to Smart X while keeping ModelDef/ViewDef/MenuDef intact.

Activate this skill when the user is creating a new Smart X routine from scratch, wiring an ADVPL function call into a Smart X page/table action, converting a legacy MVC browse to a Smart X browse, or debugging a Smart X screen/model/interface issue. It does not cover classic MVC routine development without Smart X (see `advpl-code-generation`, file `patterns-mvc.md`), nor data dictionary configuration scripts for SX2/SX3 themselves (see `sx-configuration`). It is also unrelated to **Smart View**, the TReports analytics tool whose custom business objects are covered by `smartview-development` -- the names are similar, the frameworks are not.

The referenced files are written in Brazilian Portuguese.

| Reference file | Read when |
|---|---|
| reference.md | Always -- Smart X concept, Object/Model/Interface/Launcher architecture, includes/annotations, minimal end-to-end example |
| patterns-model.md | Writing or reviewing the Model (`model.tlpp`) class and its data/business-rule definitions |
| patterns-interface.md | Writing or reviewing the Interface (`interface.tlpp`) class and its UI contract (browse/forms) |
| patterns-launcher-browse.md | Converting only the browse (Data View) of an existing MVC routine to Smart X rendering |

# SX Configuration

This skill provides templates and validation rules for generating Protheus data dictionary configuration scripts: SX2 table headers, SX3 field definitions, SIX indexes, SXG field groups, SXA form folders/tabs, SX1 report parameter questions, SX5 generic tables, SXB standard F3 lookup queries, and SX7 field triggers. It covers required field values, naming conventions (3-char aliases, `Z`-prefixed custom tables, `XX_FIELD` naming), share-mode semantics (`C`/`E`/`M`), and common pitfalls such as creation order (SX2 before SX3 before SIX) and hardcoded physical table names.

Activate this skill when the user is registering a new custom table, adding custom fields, defining indexes, grouping fields for cross-table validation, organizing MVC form tabs, setting up report parameter questions, creating a generic lookup table, or configuring an F3 query or field trigger. It does not cover programmatic READ access to the dictionary at runtime (`Posicione`, `TamSx3`, FW APIs) -- see `protheus-reference/sx-dictionary.md` for that.

| Reference file | Read when |
|---|---|
| reference.md | Always -- SX2/SX3/SIX/SXG/SXA/SX1/SX5/SXB/SX7 field templates, share modes, naming rules, and common pitfalls |

# TDN Lookup — Online Search Strategy

This skill defines the standardized fallback strategy for finding official TOTVS documentation on TDN (tdn.totvs.com, a public Confluence Data Center 7.19 site with an unauthenticated REST API) whenever local reference material is insufficient. It specifies a five-tier escalation: Tier 1 always checks the relevant local cache file first (native functions, SX dictionary, common errors, entry points, business modules); Tier 2 queries the Confluence REST search API directly via WebFetch with a CQL query; Tier 3 falls back to Playwright hitting the same API when WebFetch is blocked; Tier 4 uses WebSearch plus Playwright navigation when CQL search yields nothing; Tier 5 is a last-resort manual/visual search on the TDN site itself.

Activate this skill whenever a native function, entry point, error code, or business process is not found (or only partially found) in the local reference files, or whenever the user explicitly asks for official TOTVS documentation. It does not itself contain domain knowledge -- it only orchestrates the search process; the actual native function, entry point, and error catalogs live in `protheus-reference`, `advpl-code-generation`, `advpl-debugging`, and `protheus-business`.

| Reference file | Read when |
|---|---|
| reference.md | Always -- tier-by-tier search strategy, CQL query construction, HTML/JSON parsing steps, fallback conditions per tier |