The script under review is a dashboard portlet that renders a month-to-date gross margin tile. Its header documents a script parameter that lets an administrator set the margin floor. The parameter doesn't exist in the account. Every render has silently fallen back to the hardcoded 38% default, and nothing on the tile tells anyone that the advertised control is dead.
The code is fine. The review found that the account wasn't. That's the first finding in the SuiteScript Review Agent sample report, and it's the reason the prompt verifies deployment state and schema references live against the account rather than reading source in isolation. It went into the Sonar AI Prompt Library in September. If you're new to this, Sonar AI is an AI agent that runs inside NetSuite. Every prompt in the library is a playbook that I engineered and tested against live NetSuite data, and you run it inside your own account, against your own records. Nothing leaves the account, and nothing is written to it.
What It Reviews
The prompt takes one script, reads the full source from the File Cabinet, and then goes and checks. It finds the script record and its deployment, resolves the owner, reads the execution history, and verifies every field ID, table, and script parameter the code references against the live schema. Then it works through a fixed checklist: security, best practices by category, documentation quality, and a findings register with severities and line numbers.
On the test account, the script was a 263-line SuiteScript 2.1 portlet, one day old at review time. The verdict was "solid," with zero critical findings, three important ones, and seven nice-to-haves. The one-line summary in the report: read-only, injection-free, escaped against cross-site scripting, governance-bounded, fails gracefully, and one configuration defect and one scalability gap stand between it and clean.
The Security Pass
All eight standard checks passed, and the report shows its work on each. The three SuiteQL queries are static template literals, and the only external input, the floor parameter, goes through a numeric parse and range check and is never interpolated into SQL. An escape helper covers every data-derived string that reaches the generated HTML, and the report notes that single quotes are unescaped but every generated attribute uses double quotes, so no vector exists. The portlet isn't available without login. There are no external calls, no dynamic requires, no credentials. The one soft note is that the raw error message is echoed to the dashboard in the failure path, which exposes internal error text to any viewer and is tracked as a low-severity finding.
What It Got Right
I want to spend a paragraph on the section headed "patterns worth preserving," because a review that only lists defects teaches nothing. The script computes margin from the accounting-line table with correct sign handling, joined to the transaction-line table on the composite key, which the report calls the join most scripts get wrong. It filters subsidiary on the line rather than the header because the header subsidiary isn't exposed to SuiteQL on this account, which the report notes most scripts also get wrong. The header documents live validation against the August income statement with exact reconciliation figures. Every referenced column is real. The report says there are no signs of unverified generation, and that the single unverified identifier is the script parameter, a configuration gap rather than a fabrication.
The Findings
Three important ones. The missing parameter, which is a five-minute fix on the script record or a one-line deletion from the header comment. No caching, which is fine at this account's volume and becomes the slowest tile on the dashboard at ten to a hundred times the data, because three aggregate scans over accounting lines run on every dashboard load for every user. And the silent fallback that masks the first finding, fixed by tracking a flag and rendering "(default)" beside the floor.
The seven nice-to-haves include a systematic one: every HTML fragment is built by multi-line string concatenation while the SQL correctly uses template literals, roughly forty quote-plus seams, each a latent mismatch. The report shows the current code and the standard version side by side. The rest are the kind of thing a careful reviewer catches and a deadline skips: no JSDoc on any of the eight functions, an implicit timezone on the month-to-date window, a sparkline that compresses its axis when a month has no postings, an error log that omits the stack, and the elimination subsidiary ID hardcoded in all three queries.
The Evidence Trail
The methodology section lists every query and operation in order, with results. Including the one that failed. The first execution-history query errored because the script-note table on this account links to scripts through a differently named column, and the corrected query is shown beside it. The report says the failed attempt is part of the evidence trail and is disclosed rather than omitted. It also notes that the script record is owned by a different employee record than the one the reviewing session runs under, with the same person's name on both, which is harmless and worth knowing.
The assumptions are numbered. The header's reconciliation claim was taken at face value and not re-run. Zero rows in the execution log is read as no errors, with the column mapping stated. All line references bind to one file revision, and finding IDs stay stable if the file changes.
Wrapping Up
The Script Stacking Review in the same release tells you which scripts share a record and in what order. This prompt reads one of them properly, and the natural sequence is stacking first, then review the ones that run last.
SuiteScript Review Agent is in the paid tier of the library. The full sample report from the test account is online, and I covered the whole September release in a separate post.
The script was production-worthy the day it was written. The review is what makes it durable.