> For the complete documentation index, see [llms.txt](https://triton.pharos.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://triton.pharos.ai/instrumentation-skills.md).

# Instrumentation Skills

Agent-agnostic skills that add production-grade Triton instrumentation to Apex, LWC, and Flows — one file or a whole org — with a human-reviewed diff first.

Adding good logging to an existing codebase is the least glamorous job in the world. You know what a well-instrumented class looks like — entry-point templates, resume-first transactions, `logNow` in every catch, `dmlResults` on partial DML — but hand-applying that pattern to a backlog of hundreds of Apex classes, LWCs, and Flows is a slog nobody volunteers for.

The **instrumentation skills** do that slog for you. They're a set of **portable, agent-agnostic recipes** — the Triton conventions plus a step-by-step, human-in-the-loop workflow — that any AI coding agent can follow to read a file, classify its structure, and add convention-following Triton instrumentation, then show you a diff and let you accept, tweak, or skip it before anything is written. Nothing is applied blindly.

{% hint style="info" %}
**Not tied to any one agent.** These skills are plain Markdown playbooks that target the Triton 2.0 static API. They were first shipped as Claude Code slash commands under the `/pharos:` namespace, but the logic is tool-neutral — the same recipe runs in Cursor, GitHub Copilot, Windsurf, the Codex CLI, or any agent you can point at a file. See [Running these in your agent](#running-these-in-your-agent) below.
{% endhint %}

{% hint style="warning" %}
**Companion tooling, not part of the managed package.** The skills ship **alongside** Triton 2.0 as developer tooling — they are not part of the core Triton managed package you install into an org. You run them from your coding agent against your local Salesforce project; the logging code they generate targets the Triton 2.0 static API.
{% endhint %}

## The skill catalog

The three per-technology skills are the primitives. Everything else composes them.

| Skill              | What it does                                                   | Page                                                               |
| ------------------ | -------------------------------------------------------------- | ------------------------------------------------------------------ |
| `instrument-apex`  | Instruments Apex classes and triggers                          | [Instrument Apex](/instrumentation-skills/instrument-apex.md)      |
| `instrument-lwc`   | Instruments Lightning Web Components                           | [Instrument LWC](/instrumentation-skills/instrument-lwc.md)        |
| `instrument-flows` | Instruments Flow metadata XML                                  | [Instrument Flows](/instrumentation-skills/instrument-flows.md)    |
| `instrument-org`   | Orchestrates the three across a whole project/org              | [Instrument the Org](/instrumentation-skills/instrument-org.md)    |
| `audit-logging`    | Read-only coverage & gap report (no writes)                    | [Audit Logging Coverage](/instrumentation-skills/audit-logging.md) |
| `migrate-to-2.0`   | Mechanically converts 1.x singleton code to the 2.0 static API | [Migrate to 2.0](/instrumentation-skills/migrate-to-2.0.md)        |
| `setup-standards`  | Generates CI guardrails and `Log_Level__mdt` config            | [Set Up Standards](/instrumentation-skills/setup-standards.md)     |

For the "point at an org and instrument everywhere" experience, package the whole catalog behind one persona — see [The Triton Instrumentation Agent](/instrumentation-skills/instrumentation-agent.md).

## Running these in your agent

Each skill is a Markdown file describing a capability. How you *invoke* it depends on your agent, but the behavior is identical.

| Agent                             | How to run a skill                                                                                                                                         |
| --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Claude Code**                   | Drop the skill in `.claude/commands/` (or a plugin) and call it as a slash command, e.g. `/pharos:instrument-apex <path>`.                                 |
| **Cursor**                        | Add the skill as a [Command](https://docs.cursor.com/) or a Rule, then invoke it from chat, or `@`-mention the skill file and give it the path.            |
| **GitHub Copilot**                | Reference the skill file in your prompt (or add it to `.github/copilot-instructions.md`) and ask it to instrument the file.                                |
| **Windsurf / Codex CLI / others** | Point the agent at the skill file and the target path, e.g. *"Follow `instrument-apex.md` to instrument `AccountService.cls`."*                            |
| **Any agent**                     | Paste the skill's instructions plus the target file and ask it to apply them. The diff-review loop still applies — you approve before anything is written. |

{% hint style="info" %}
Throughout these pages we use the `/pharos:instrument-*` slash-command form as a concise, readable stand-in for "invoke this skill." Read it as *"run the instrument-apex skill on this path"* — substitute your agent's own invocation syntax.
{% endhint %}

## The workflow — human in the loop

Every per-file skill runs the same seven-beat loop. The important part is **Step 4**: the skill never writes to your file until you've seen the diff and said yes.

1. **Step 0 — Prerequisites.** Confirm the [Salesforce CLI](https://developer.salesforce.com/tools/salesforcecli) (`sf` or `sfdx`) is installed and a default org is connected. The Flow skill additionally verifies that Triton is installed in the target org (its `TritonFlow` invocable has to exist). If a prerequisite is missing, the skill stops and tells you exactly what to run.
2. **Parse arguments.** Read the target path and flags; ask for anything required that wasn't supplied.
3. **Analyze.** Read the file and classify its structure — trigger vs. `@AuraEnabled` controller vs. batch vs. queueable, wired vs. imperative LWC, screen vs. autolaunched Flow — because the transaction and flush pattern differs per structure. This is also where the skill infers the **Area**.
4. **Apply.** Generate the instrumented version in memory, following the 2.0 static API and Triton best practices.
5. **Review the diff — `yes` / `modify` / `skip`.** The skill presents a summary plus the key changes. Say `yes` to apply, `modify` to give free-form corrections (it re-applies and asks again), or `skip` to walk away with nothing written.
6. **Write.** On `yes`, the instrumented content is written back to the **original** file — no new files, no renames.
7. **Optional deploy.** If you passed `--deploy` (or answer yes when asked), the skill runs `sf project deploy start` for just the file or component directory it touched.

{% hint style="success" %}
**Area gets special attention.** Area is the primary grouping and search key in Pharos, so the skills work hard to keep it consistent: they first look for the Area already used by *related* code — the same-object trigger, the paired Apex controller, the LWC or Flow on the other side of the call — and reuse that exact value so a whole feature's logs group together. `.area(...)` accepts a plain String, so the `TritonTypes.Area` enum values are treated as examples, not a required mapping.
{% endhint %}

## Instrumentation at scale

The single-file loop is the primitive. The real payoff is running it **across a backlog** — and you no longer have to hand-loop it.

Because the skills follow shared conventions — resume-first transactions, one Area per feature, `logNow` + rethrow in catches, flush at boundaries — you get *consistent* instrumentation no matter who (or what) runs them. There are two ways to work at scale:

* **Drive the primitives yourself.** Run `instrument-apex` down a list of classes in a service layer, reusing one `--area` so the feature groups cleanly; loop an agent over a directory of LWCs or `.flow-meta.xml` files, reviewing each diff as it comes; add `--deploy` once you trust the pattern for a batch.
* **Let the orchestrator do it.** [`instrument-org`](/instrumentation-skills/instrument-org.md) inventories your whole project, prioritizes it using the [Legacy Code Logging Rollout](/triton-best-practices/legacy-migration.md) strategy, threads one Area per feature across Apex/LWC/Flow, and works the backlog with review checkpoints and batched deploys — then hands you a coverage report.

{% hint style="info" %}
**"Instrument everything" without giving up control.** The orchestrator is the closest thing to an "instrument the whole org" button, but it keeps the human-in-the-loop diff at its core: it batches changes and checks in at boundaries instead of writing hundreds of files blindly. You automate the tedious 90% while staying in control of every change. Start with [`audit-logging`](/instrumentation-skills/audit-logging.md) to see the map before you drive.
{% endhint %}

## OpenTelemetry readiness

Triton 2.0's [distributed tracing](/end-to-end/spans-and-tracing.md) — a transaction id that correlates a whole operation, plus `Span_Id__c` / `Parent_Span_Id__c` for parent-child structure — gives your logs a shape that maps cleanly onto OpenTelemetry's vocabulary: **trace**, **span**, and **parent span**. The instrumentation skills are how you get that shape *everywhere* without hand-writing it: the Apex skill threads one transaction id through async hops, the LWC skill's `timeBackendCall` carries span context across the call, and the Flow skill stitches the Flow leg into the same transaction.

{% hint style="warning" %}
**"OTEL-ready" means aligned, not exported.** Triton is not an OpenTelemetry SDK and does not emit OTLP. What 2.0 gives you is a data model whose concepts line up with OTel's, so instrumented Triton logs are a solid foundation for an observability story and a future OTel integration. See [Spans & Distributed Tracing → How this maps to OpenTelemetry](/end-to-end/spans-and-tracing.md#how-this-maps-to-opentelemetry) for the full mapping.
{% endhint %}

## Where to go next

* [Instrument Apex](/instrumentation-skills/instrument-apex.md) — classes and triggers, transaction resume/stitching, DML and callout logging.
* [Instrument LWC](/instrumentation-skills/instrument-lwc.md) — `c/triton`, `bindToComponent`, `timeBackendCall`, transaction stitching to Apex.
* [Instrument Flows](/instrumentation-skills/instrument-flows.md) — the `TritonFlow` "Log" action, fault-path logging, the never-pass-a-collection rule.
* [Instrument the Org](/instrumentation-skills/instrument-org.md) — the orchestrator that rolls the three out across a whole project.
* [Audit Logging Coverage](/instrumentation-skills/audit-logging.md) — see where the gaps are before you start.
* [Migrate to 2.0](/instrumentation-skills/migrate-to-2.0.md) · [Set Up Standards](/instrumentation-skills/setup-standards.md) — convert 1.x code and lock in CI guardrails.
* [The Triton Instrumentation Agent](/instrumentation-skills/instrumentation-agent.md) — package the whole catalog as one reusable, agent-agnostic persona.
* [Spans & Distributed Tracing](/end-to-end/spans-and-tracing.md) — the tracing model these skills roll out, and the OpenTelemetry mapping.