-
Inspect the official identity source completely with the tools appropriate to its format. Record pages, sections, states, viewports, assets, licenses, and limitations.
-
When the user also names an approved application or dashboard as an experience reference, inspect its rendered states and real component implementation separately. Extract reusable composition and interaction rules without copying its brand, data, or business language.
-
Write the visual-system specification before implementation: identity tokens, application header or Home hero, action toolbar, filter behavior, help canvas when applicable, component anatomy, information hierarchy, responsive layout, semantic accents, focus/tooltip behavior, reduced motion, and the explicit legacy patterns that must not survive.
-
Create a consumer-owned brand-profile that validates against schemas/brand-profile.schema.json. Preserve provenance for every important token and asset decision.
-
Create a report-profile that validates against schemas/report-profile.schema.json. Set package names only after confirming they exist or are explicitly authorized.
-
Review both profiles against the versioned schemas. If the optional Python tooling is available, add deterministic validation and a write-free scaffold preview:
python skills/build-apex-brand-reports/scripts/validate_theme.py brand-profile.json
python skills/build-apex-brand-reports/scripts/scaffold_project.py \
--target /path/to/project --config report-kit.yaml --platform apex --dry-run
-
With or without the scripts, review the complete target file list and diffs before writing. Apply only when the target and ownership are correct.
-
Keep engine, theme, document composition, and business content in separate files and package responsibilities.
-
Implement the public report function in the confirmed consumer-owned domain package. Keep queries, filters, metrics, organizational scope, and permission checks there.
-
If a chart was explicitly requested, let the same domain package produce its authorized ChartSpec and embed PK_APEX_ECHARTS output in the report CLOB. Require one approved RUNTIME_ONLY loader and an essential textual or tabular fallback; do not emit <script src> or bundle bytes.
-
Configure the mandatory native Dynamic Content region through Page Designer. A thin modal page is the default host unless the project explicitly authorizes another native APEX page route.
-
Implement XLSX/CSV as separate server-side processes only after confirming the real APEX API version and query types.
-
Compile or publish only when explicitly authorized by the request and local policy. Acquire and release project locks when required.
Change the central runtime only for behavior reusable across consumers. Change a consumer theme only for that consumer's visual identity. Change document composition for layout requirements. Keep business queries and authorization in the consumer package. Backport community improvements through the central repository rather than copying private business code upstream.
