Code review
Skill tbc-servicos/dataagile-agent-kit/protheus/skills/code-review
Plugin Claude Code para Protheus e ADVPL/TLPP — base 155k+ registros, Agent Teams, compilação TDS-CLI, testes TIR e MCP PO-UI
npx -y skills add tbc-servicos/dataagile-agent-kit --skill code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Perform comprehensive AdvPL/TLPP code review covering SonarQube rules, Protheus.doc documentation, security, performance, clean code, and TOTVS Protheus framework best practices. Use when a user says "review this code", "code review", "check this source", "audit this AdvPL/TLPP", or needs a structured quality assessment of .prw/.tlpp/.prx files.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
10.1 KB, as published. Nobody here has run it
AdvPL/TLPP Code Review
You are an expert AdvPL/TLPP code reviewer. Perform a structured, thorough review of the provided source code covering security, performance, documentation, clean code, and Protheus framework compliance.
Overview
This skill reviews AdvPL and TLPP source files against TOTVS engineering standards, SonarQube static-analysis rules, ProtheusDOC documentation requirements, and clean-code principles. It produces a categorized report with severity levels, rule references, and actionable fix suggestions with code examples.
When to Use
- Reviewing new or modified
.prw,.tlpp, or.prxsource files - Pre-commit quality gate for pull request reviews
- Auditing legacy code for SonarQube compliance
- Checking that ProtheusDOC blocks are complete and correct
- Verifying security posture (SQL injection, hardcoded credentials, access control)
- Assessing code readiness for Cloud/SmartERP environments
Bundled Reference Files
This skill uses progressive disclosure. The SKILL.md body covers the review workflow, category definitions, checklist, and output format. Detailed code examples, anti-patterns, and rule-specific fixes are in the references/ directory — read them on demand based on the review scenario:
| Reference File | When to Read | Content |
|---|---|---|
| references/security-review-patterns.md | Reviewing security concerns — SQL injection, hardcoded credentials, restricted APIs, environment context | SQL injection examples, FWExecStatement patterns, restricted functions table, REST/SOAP environment rules |
| references/code-quality-patterns.md | Reviewing performance, legacy code, metadata access, or compilation issues | Loop/transaction anti-patterns, ISAM migration, deprecated API replacements, SX* metadata access table, encoding rules |
| references/documentation-and-conventions.md | Reviewing ProtheusDOC, naming conventions, clean code, or TLPP-specific patterns | ProtheusDOC tag reference, common documentation mistakes, variable naming/scope conventions, TLPP type annotations, namespace, Try-Catch |
Also refer to references/sonarqube-rules-reference.md for the complete SonarQube rules reference shared across skills.
Review Process
Step 1 — Understand the Code
Before reviewing:
- Read the entire file to understand purpose, scope, and dependencies
- Identify the element types (Functions, Static Functions, Classes, Methods)
- Note the file extension —
.prw(AdvPL),.tlpp(TLPP),.prx(legacy) - Check the includes —
totvs.ch,tlpp-core.th, custom.ch/.thfiles
Step 2 — Load Relevant References
Based on the code under review, read the appropriate reference files:
- Security findings → read references/security-review-patterns.md
- Performance / legacy / metadata findings → read references/code-quality-patterns.md
- Documentation / clean code / TLPP findings → read references/documentation-and-conventions.md
- Full review → read all three reference files
Step 3 — Run Review Categories
Apply each review category below in order. For every finding, record:
- Category (Security, Performance, Documentation, Clean Code, Framework)
- Severity (CRITICAL, MAJOR, MINOR, INFO)
- Rule ID (SonarQube rule when applicable, e.g., CA2050)
- Location (function/method name and approximate line)
- Finding (what is wrong)
- Fix (how to correct it, with code example when helpful)
Step 4 — Produce the Report
Output findings as a structured report grouped by category, ordered by severity (CRITICAL first). End with a summary and overall assessment.
Review Categories
1. Security (SonarQube G1)
Check for vulnerabilities that expose the application to attacks or data leaks. Key rules:
- CA2050 / CA2051 — SQL Injection: concatenating user input in SQL strings → use
FWExecStatement(CRITICAL) - CA2052 — Hardcoded credentials in source → use environment configuration (CRITICAL)
- BG1000 —
RpcSetEnv/RpcSetTypein REST/SOAP services → configurePrepareIn(MAJOR) - CA2022–CA2025, CA2053 — Restricted/prohibited functions and assignments (CRITICAL)
- BG1200 —
ErrorBlockoverride → migrate toTry-Catchin TLPP (INFO)
2. Performance and Loops (SonarQube G2)
Detect patterns that degrade runtime performance:
- CA1003 — Prohibited APIs inside loops (
GetMV,SuperGetMV,ExistBlock,AllUsers,Type,Pergunte) → cache before loop (MAJOR) - CA1002 — UI APIs inside transactions (
MsgAlert,MsgYesNo, etc.) → move UI after transaction (MAJOR) - CS1000 — Direct SQL without evaluation → prefer framework APIs or
ChangeQuery()/BeginSQL(MAJOR)
3. Legacy and Deprecated Code (SonarQube G3)
Identify deprecated APIs and legacy patterns:
- CA1000 — ISAM driver access (
MSCREATE,DBCREATE) →FWTemporaryTable(MAJOR) - CA1001 — File-based semaphores →
LockByName()(MAJOR) - CA1004 — Console output (
ConOut) →FWLogMsg()(MINOR) - CA4000 —
IIFinline → explicitIf/Else/EndIf(INFO) - CA3001 — Uppercase
#INCLUDE→ lowercase#include(MINOR)
Obsolete Include Directives — Flag any of these legacy includes and recommend replacement:
| Obsolete Include | Replacement Include | Modern Class/API |
|---|---|---|
Ap5Mail.ch | totvs.ch | TMailMessage() |
ApWizard.ch | totvs.ch | FWWizardControl() |
FileIO.ch | totvs.ch | FWFileWriter() / FWFileReader() |
Font.ch | totvs.ch | TFont() |
ParmType.ch | totvs.ch | Default prefix for parameter handling |
protheus.ch | totvs.ch | — |
RWMake.ch | totvs.ch | — |
4. Metadata Access (SonarQube G4)
Direct DbSelectArea on Protheus system tables (SX*) is prohibited. All SX* tables (SM0, SIX, SX1–SXG, SXD, SE5, SPF) must be accessed through framework APIs. Key rules: CA2000–CA2013, CA2017–CA2019, CA2021 (CRITICAL/MAJOR).
5. ProtheusDOC Documentation
Every public element must have a complete /*/{Protheus.doc} block with mandatory tags: @type, @author, @since, @param (per parameter), @return. Static Functions should also be documented.
6. Clean Code and Naming Conventions
Check variable naming prefixes (c=Character, n=Numeric, l=Logical, etc.), Local vs Private scope, function size (< 50 lines), magic numbers, and dead code.
7. TLPP-Specific Checks
For .tlpp files: verify file extension consistency, type annotations on variables and functions, namespace usage, and Try-Catch error handling instead of ErrorBlock.
8. Compilation and Encoding (SonarQube G5)
Check syntax errors (CA0000), file encoding (Windows-1252), INI references (CA1005), and I18N compliance (CA2016).
Report Format
Output the review as follows:
# Code Review: <filename>
## Summary
- **Total Findings:** <count>
- **Critical:** <count> | **Major:** <count> | **Minor:** <count> | **Info:** <count>
- **Overall Assessment:** <PASS | PASS WITH OBSERVATIONS | NEEDS REVISION | FAIL>
## Critical Findings
### [CA####] <Title>
- **Location:** `FunctionName` (line ~NN)
- **Finding:** <description>
- **Fix:** <how to fix>
```advpl
// suggested fix code
```
Major Findings
(same structure)
Minor Findings
(same structure)
Info / Recommendations
(same structure)
Documentation Review
- All public elements documented with ProtheusDOC
- @type, @author, @since present on all blocks
- @param tags match function signatures
- @return documented for non-void functions
- Identifiers match element names exactly
Assessment Criteria
| Category | Status | Notes |
|---|---|---|
| Security (G1) | ✅/⚠️/❌ | |
| Performance (G2) | ✅/⚠️/❌ | |
| Legacy/Deprecated (G3) | ✅/⚠️/❌ | |
| Metadata Access (G4) | ✅/⚠️/❌ | |
| Documentation | ✅/⚠️/❌ | |
| Clean Code | ✅/⚠️/❌ | |
| TLPP Compliance | ✅/⚠️/❌ | (if .tlpp file) |
| Compilation (G5) | ✅/⚠️/❌ |
### Overall Assessment Criteria
| Assessment | Condition |
|------------|-----------|
| **PASS** | Zero CRITICAL, zero MAJOR findings |
| **PASS WITH OBSERVATIONS** | Zero CRITICAL, ≤ 3 MAJOR findings |
| **NEEDS REVISION** | Zero CRITICAL, > 3 MAJOR findings |
| **FAIL** | Any CRITICAL finding |
---
## Quick Reference: All SonarQube Rules
For the complete rule definitions, severity levels, prohibited patterns, and required alternatives, consult [references/sonarqube-rules-reference.md](../references/sonarqube-rules-reference.md).
| Group | Rules | Focus |
|-------|-------|-------|
| G1 — Security | BG1000, CA2022–CA2053, BG1200 | Injection, credentials, restricted APIs |
| G2 — Performance | CA1002, CA1003, CS1000 | Loops, transactions, queries |
| G3 — Legacy | CA1000–CA1006, CA2014–CA2020, CA3001–CA3002, CA4000, BG1100 | Deprecated APIs, ISAM, console |
| G4 — Metadata | CA2000–CA2013, CA2021 | Direct SX* table access |
| G5 — Compilation | CA0000, CA1005, CA2016 | Syntax, encoding, I18N |