platform-apex-logs-debug — Claude Code skill: Apex log analysis
This skill reads Salesforce debug logs: finds the root cause of a failure, spots governor limit hits and explains stack traces.
npx skills add forcedotcom/sf-skills --skill platform-apex-logs-debug -a claude-codeWhat platform-apex-logs-debug does
The skill kicks in when .log files from Salesforce, stack traces, limit errors or slow SOQL queries show up in the task. It walks the log in a fixed order: entry point and transaction type, exceptions, governor limits, repeated SOQL and DML, CPU and heap hotspots, callout timing. Every finding gets a severity — Critical, Warning or Info.
Under the hood are reference files in references/: an analysis playbook, a catalog of log event types, SF CLI commands for pulling and streaming logs, and write-ups of patterns like SOQL in a loop. You need sf 2.0.0 or newer and jq 1.6.0 or newer. It suggests starting with references/analysis-playbook.md.
Diagnosis is all it does. Code fixes go to platform-apex-generate, test runs to platform-apex-test-run, Agentforce session traces to agentforce-observe. Watch two traps. Logs get truncated at 2 MB, so lower the debug levels and capture again. And the CPU limit is 60,000 ms async against 10,000 ms sync — check the transaction type before blaming the code.
What it helps with
- trace a failed transaction back to its root cause
- work out which governor limit ran out and where
- pull SOQL and DML out of loops using repeated log events
- check CPU and heap pressure against the sync limit
- explain why a query scans too many rows
Example prompts for the agent
- analyze this Salesforce .log and tell me what failed
- why did the transaction hit a governor limit — check the log
- find repeated SOQL in the log and suggest the smallest fix
How to install platform-apex-logs-debug
1Skills CLI (Vercel)
npx skills add forcedotcom/sf-skills --skill platform-apex-logs-debug -a claude-code2Manually: put the files in place
~/.claude/skills/platform-apex-logs-debug/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/platform-apex-logs-debug/
1Skills CLI (Vercel)
npx skills add forcedotcom/sf-skills --skill platform-apex-logs-debug -a codex2Manually: put the files in place
.agents/skills/platform-apex-logs-debug/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add forcedotcom/sf-skills --skill platform-apex-logs-debug -a cursor2Manually: put the files in place
.cursor/skills/platform-apex-logs-debug/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install forcedotcom/sf-skills platform-apex-logs-debug2Manually: put the files in place
.github/skills/platform-apex-logs-debug/SKILL.md1Skills CLI (Vercel)
npx skills add forcedotcom/sf-skills --skill platform-apex-logs-debug -a gemini-cli2Platform CLI
gemini skills install https://github.com/forcedotcom/sf-skills --path skills/platform-apex-logs-debugManually: put the files in place
.devin/skills/platform-apex-logs-debug/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add forcedotcom/sf-skills --skill platform-apex-logs-debug -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about platform-apex-logs-debug
How do I install platform-apex-logs-debug in Claude?
Run npx skills add forcedotcom/sf-skills --skill platform-apex-logs-debug -a claude-code. The skill lands in ~/.claude/skills/platform-apex-logs-debug/SKILL.md.
What does platform-apex-logs-debug do?
It analyzes Salesforce debug logs: root cause of a failure, stack trace interpretation, governor limits, repeated SOQL and DML. Output is a report with location, cause, severity and a verification step.
How is it different from platform-apex-generate and platform-apex-test-run?
It only diagnoses from logs. Apex code changes go to platform-apex-generate, test execution and repair to platform-apex-test-run, Agentforce session tracing to agentforce-observe.
Source text
SKILL.md · Apache-2.0
---
name: platform-apex-logs-debug
description: "Salesforce debug log analysis and troubleshooting with 100-point scoring. TRIGGER when: user analyzes debug logs, hits governor limits, reads stack traces, or touches .log files from Salesforce orgs. DO NOT TRIGGER when: running Apex tests (use platform-apex-test-run), generating or fixing Apex code (use platform-apex-generate), or Agentforce session tracing (use agentforce-observe)."
metadata:
version: "1.1"
domains: ["Platform"]
relatedSkills:
- "agentforce-observe"
- "platform-apex-generate"
- "platform-apex-test-run"
- "platform-data-manage"
- "platform-metadata-deploy"
- "platform-soql-query"
cliTools:
- tool: ["sf"]
semver: ">=2.0.0"
- tool: ["jq"]
semver: ">=1.6.0"
---
# platform-apex-logs-debug: Salesforce Debug Log Analysis & Troubleshooting
Use this skill when the user needs **root-cause analysis from debug logs**: governor-limit diagnosis, stack-trace interpretation, slow-query investigation, heap / CPU pressure analysis, or a reproduction-to-fix loop based on log evidence.
## When This Skill Owns the Task
Use `platform-apex-logs-debug` when the work involves:
- `.log` files from Salesforce
- stack traces and exception analysis
- governor limits
- SOQL / DML / CPU / heap troubleshooting
- query-plan or performance evidence extracted from logs
Delegate elsewhere when the user is:
- running or repairing Apex tests → [platform-apex-test-run](../platform-apex-test-run/SKILL.md)
- generating or implementing the code fix → [platform-apex-generate](../platform-apex-generate/SKILL.md)
- debugging Agentforce session traces / parquet telemetry → [agentforce-observe](../agentforce-observe/SKILL.md)
---
## Required Context to Gather First
Ask for or infer:
- org alias
- failing transaction / user flow / test name
- approximate timestamp or transaction window
- user / record / request ID if known
- whether the goal is diagnosis only or diagnosis + fix loop
---
## Recommended Workflow
### 1. Retrieve logs
Use the commands in [references/cli-commands.md](references/cli-commands.md) to list, download, or stream logs for the target org.
### 2. Analyze in this order
1. entry point and transaction type
2. exceptions / fatal errors
3. governor limits
4. repeated SOQL / DML patterns
5. CPU / heap hotspots
6. callout timing and external failures
### 3. Classify severity
- **Critical** — runtime failure, hard limit, corruption risk
- **Warning** — near-limit, non-selective query, slow path
- **Info** — optimization opportunity or hygiene issue
### 4. Recommend the smallest correct fix
Prefer fixes that are:
- root-cause oriented
- bulk-safe
- testable
- easy to verify with a rerun
Expanded workflow: [references/analysis-playbook.md](references/analysis-playbook.md)
---
## High-Signal Issue Patterns
| Issue | Primary signal | Default fix direction |
|---|---|---|
| SOQL in loop | repeating `SOQL_EXECUTE_BEGIN` in a repeated call path | query once, use maps / grouped collections |
| DML in loop | repeated `DML_BEGIN` patterns | collect rows, bulk DML once |
| Non-selective query | high rows scanned / poor selectivity | add indexed filters, reduce scope |
| CPU pressure | CPU usage approaching sync limit | reduce algorithmic complexity, cache, async where valid |
| Heap pressure | heap usage approaching sync limit | stream with SOQL for-loops, reduce in-memory data |
| Null pointer / fatal error | `EXCEPTION_THROWN` / `FATAL_ERROR` | guard null assumptions, fix empty-query handling |
Expanded examples: [references/common-issues.md](references/common-issues.md)
---
## Output Format
When finishing analysis, report in this order:
1. **What failed**
2. **Where it failed** (class / method / line / transaction stage)
3. **Why it failed** (root cause, not just symptom)
4. **How severe it is**
5. **Recommended fix**
6. **Verification step**
Suggested shape:
```text
Issue: <summary>
Location: <class / line / transaction>
Root cause: <explanation>
Severity: Critical | Warning | Info
Fix: <specific action>
Verify: <test or rerun step>
```
---
## Rules / Constraints
| Rule | Rationale |
|------|-----------|
| Always base fix recommendations on log evidence | Avoid speculative diagnosis — root cause must be traceable in the log |
| Report all six output fields for every issue found | Ensures actionable, complete findings for each problem |
| Classify every finding as Critical, Warning, or Info | Helps the user prioritize which issues to address first |
| Delegate code generation to `platform-apex-generate` | This skill diagnoses; it does not rewrite Apex code |
| Delegate test execution to `platform-apex-test-run` | This skill does not run or repair test classes |
| Never assume limits are safe without reading `LIMIT_USAGE` events | Limits may be consumed by earlier operations not visible in the failure point |
---
## Gotchas
| Pitfall | Resolution |
|---------|------------|
| Log truncated at 2 MB | Reduce debug levels (e.g., `ApexCode: INFO`, `ApexProfiling: FINE`) and re-capture |
| Same issue appears as both SOQL and CPU problem | Fix SOQL-in-loop first — it typically drives the CPU spike as a secondary effect |
| No logs appear after trace flag is set | Verify the trace flag `ExpirationDate` is in the future and the correct user is traced |
| Async context changes limit values | CPU limit is 60,000 ms async vs 10,000 ms sync — check transaction type before flagging limits |
| Stack trace points to framework line, not user code | Walk up the call stack past trigger handlers to find the originating user code |
---
## Cross-Skill Integration
| Need | Delegate to | Reason |
|---|---|---|
| Implement Apex fix | [platform-apex-generate](../platform-apex-generate/SKILL.md) | code change generation / review |
| Reproduce via tests | [platform-apex-test-run](../platform-apex-test-run/SKILL.md) | test execution and coverage loop |
| Deploy fix | [platform-metadata-deploy](../platform-metadata-deploy/SKILL.md) | deployment orchestration |
| Create debugging data | [platform-data-manage](../platform-data-manage/SKILL.md) | targeted seed / repro data |
| Optimize slow SOQL queries | [platform-soql-query](../platform-soql-query/SKILL.md) | query shape / performance tuning |
---
## Reference File Index
| File | When to read |
|------|-------------|
| `references/analysis-playbook.md` | Start here — expanded step-by-step workflow for any debugging session |
| `references/common-issues.md` | Quick lookup for SOQL in loop, DML in loop, CPU/heap pressure, null pointer patterns |
| `references/cli-commands.md` | SF CLI commands for retrieving, streaming, and managing debug logs |
| `references/debug-log-reference.md` | Full event type catalog, log levels, and governor limit reference values |
| `references/log-analysis-tools.md` | Tool guide: Apex Log Analyzer, Developer Console, CLI grep patterns |
| `references/benchmarking-guide.md` | Performance benchmarking techniques, benchmark data, and anti-patterns |
| `references/scoring-rubric.md` | 100-point scoring rubric for evaluating analysis quality |
| `assets/benchmarking-template.cls` | Copy-paste Anonymous Apex template for running performance benchmarks |
| `assets/cpu-heap-optimization.cls` | Apex patterns for reducing CPU time and heap allocation |
| `assets/dml-in-loop-fix.cls` | Before/after example for resolving DML-in-loop violations |
| `assets/soql-in-loop-fix.cls` | Before/after example for resolving SOQL-in-loop violations |
| `assets/null-pointer-fix.cls` | Patterns for guarding against null pointer exceptions |
---
## Score Guide
| Score | Meaning |
|---|---|
| 90+ | Expert analysis with strong fix guidance |
| 80–89 | Good analysis with minor gaps |
| 70–79 | Acceptable but may miss secondary issues |
| 60–69 | Partial diagnosis only |
| < 60 | Incomplete analysis |
© forcedotcom · Apache-2.0 · forcedotcom/sf-skills