dx-devops-test-failures-analyze

Name: dx-devops-test-failures-analyze
Author: forcedotcom

1.7kinstalls272forks

How to install dx-devops-test-failures-analyze?

forcedotcom/sf-skills/dx-devops-test-failures-analyze

$npx -y skills add forcedotcom/sf-skills --skill dx-devops-test-failures-analyze

Installs into the current project.

Summary

Analyzes DevOps Center test failures and Code Analyzer violations in plain language — failure category, offending file/class/method/line, rule violated, fix direction, and prioritized improvement suggestions (test-code vs production-code) — then optionally creates a tracked fix W

Files · 1

View on GitHub

SKILL.md

1	# Analyze DevOps Center Test Failures
2
3	Parses a test failure or Code Analyzer violation payload, explains it in plain language, produces prioritized improvement suggestions, and — only on explicit user request — creates a tracked fix work item. Parts 1–2 are pure reasoning (no writes); Part 3 is an optional, confirmation-gated write.
4
5	Never expose raw JSON, stack traces, or internal Salesforce error codes to the user. Always translate to file name, method, line, and plain description.
6
7	---
8
9	## Prerequisites
10
11	- Parts 1–2 (analysis): If the failure payload is already in context, no prerequisites are needed — this is pure reasoning. If you must fetch the payload yourself, run prerequisites (`references/prerequisite-checks.md`, Prereqs 1–4) and obtain the execution result via `dx-devops-test-suite-run` (its polling step).
12	- Part 3 (work item): Run Prerequisites 1–4. You also need a `DevopsProjectId` to file under and an `OwnerId` (assignee). See `references/work-item-creation.md`.
13
14	---
15
16	## Part 1 — Classify and explain each failure
17
18	Determine the failure category, then for each failure extract and translate to plain language: offending file/class, method, line number, the rule or assertion violated, and a fix direction (without writing code). Group failures by category if more than one.
19
20	\| Category \| Description \|
21	\|---\|---\|
22	\| Assertion failure \| A test assertion failed (expected vs actual mismatch) \|
23	\| Exception \| An unhandled exception was thrown \|
24	\| Code Analyzer violation \| A static-analysis rule was violated (e.g. `ApexCRUDViolation`) \|
25	\| Timeout \| Test exceeded execution time limit \|
26	\| Compile error \| Class failed to compile \|
27
28	Output format:
29
30	```text
31	Test failure summary:
32
33	<N> failure(s) found:
34
35	1. [<Category>] `<ClassName>.cls` — `<methodName>()` at line <N>
36	What happened: <plain-language description>
37	Rule violated: <ruleName or assertion description>
38	Fix direction: <plain-language suggestion>
39	```
40
41	Full category/pattern tables and Code Analyzer rule translations: `references/failure-categories.md` and `references/code-analyzer-violations.md`.
42
43	Empty / no-data case: If the payload contains no failures or violations, report that clearly (e.g. "No failures found in the provided execution results.") and stop. Do NOT fabricate failures or suggestions.
44
45	---
46
47	## Part 2 — Improvement suggestions
48
49	Run this after execution completes with failures, not on static source. For each failed test, reason over the failure message (the primary signal) to identify what the test is not handling, then produce a specific, actionable suggestion and a fix location (Test vs Production code). The full failure-pattern → suggestion mapping is in `references/failure-categories.md`.
50
51	```text
52	Test improvement suggestions based on execution results:
53
54	`<testMethodName>()` — [Assertion Failure / Exception / etc.]
55	Failure: "<failure message>"
56	What this reveals: <plain-language explanation>
57	Suggestion: <specific, actionable recommendation>
58	Fix location: Test \| Production code
59
60	Overall: <N> improvement(s) across <M> failed test(s).
61	```
62
63	Do not rewrite the test — only describe what needs to change and why. Fix location: Production code indicates a code defect exposed by a sound test (track separately, not a test-quality blocker). Fix location: Test indicates the test needs hardening (setup, assertions, edge cases).
64
65	---
66
67	## Part 3 — Create a fix work item (optional, on request only)
68
69	Trigger only when the user wants to create a fix work item, log a remediation, or assign a failure to a developer. This is a write operation with a mandatory confirmation gate. Follow `references/work-item-creation.md` for inputs, the subject/assignee/project confirmation gate, the `sf data create record --sobject WorkItem` call, and error handling.
70
71	> Use `WorkItem` (no namespace) — `DevopsWorkItem` is not a supported sObject in this org version.
72
73	If no `DevopsProje

People who liked this also viewed

6 picks

Type

dx-devops-test-failures-analyze

1.7kinstalls272forks

View on GitHub

How to install dx-devops-test-failures-analyze?

forcedotcom/sf-skills/dx-devops-test-failures-analyze

$npx -y skills add forcedotcom/sf-skills --skill dx-devops-test-failures-analyze

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Analyze DevOps Center Test Failures
2
3	Parses a test failure or Code Analyzer violation payload, explains it in plain language, produces prioritized improvement suggestions, and — only on explicit user request — creates a tracked fix work item. Parts 1–2 are pure reasoning (no writes); Part 3 is an optional, confirmation-gated write.
4
5	Never expose raw JSON, stack traces, or internal Salesforce error codes to the user. Always translate to file name, method, line, and plain description.
6
7	---
8
9	## Prerequisites
10
11	- Parts 1–2 (analysis): If the failure payload is already in context, no prerequisites are needed — this is pure reasoning. If you must fetch the payload yourself, run prerequisites (`references/prerequisite-checks.md`, Prereqs 1–4) and obtain the execution result via `dx-devops-test-suite-run` (its polling step).
12	- Part 3 (work item): Run Prerequisites 1–4. You also need a `DevopsProjectId` to file under and an `OwnerId` (assignee). See `references/work-item-creation.md`.
13
14	---
15
16	## Part 1 — Classify and explain each failure
17
18	Determine the failure category, then for each failure extract and translate to plain language: offending file/class, method, line number, the rule or assertion violated, and a fix direction (without writing code). Group failures by category if more than one.
19
20	\| Category \| Description \|
21	\|---\|---\|
22	\| Assertion failure \| A test assertion failed (expected vs actual mismatch) \|
23	\| Exception \| An unhandled exception was thrown \|
24	\| Code Analyzer violation \| A static-analysis rule was violated (e.g. `ApexCRUDViolation`) \|
25	\| Timeout \| Test exceeded execution time limit \|
26	\| Compile error \| Class failed to compile \|
27
28	Output format:
29
30	```text
31	Test failure summary:
32
33	<N> failure(s) found:
34
35	1. [<Category>] `<ClassName>.cls` — `<methodName>()` at line <N>
36	What happened: <plain-language description>
37	Rule violated: <ruleName or assertion description>
38	Fix direction: <plain-language suggestion>
39	```
40
41	Full category/pattern tables and Code Analyzer rule translations: `references/failure-categories.md` and `references/code-analyzer-violations.md`.
42
43	Empty / no-data case: If the payload contains no failures or violations, report that clearly (e.g. "No failures found in the provided execution results.") and stop. Do NOT fabricate failures or suggestions.
44
45	---
46
47	## Part 2 — Improvement suggestions
48
49	Run this after execution completes with failures, not on static source. For each failed test, reason over the failure message (the primary signal) to identify what the test is not handling, then produce a specific, actionable suggestion and a fix location (Test vs Production code). The full failure-pattern → suggestion mapping is in `references/failure-categories.md`.
50
51	```text
52	Test improvement suggestions based on execution results:
53
54	`<testMethodName>()` — [Assertion Failure / Exception / etc.]
55	Failure: "<failure message>"
56	What this reveals: <plain-language explanation>
57	Suggestion: <specific, actionable recommendation>
58	Fix location: Test \| Production code
59
60	Overall: <N> improvement(s) across <M> failed test(s).
61	```
62
63	Do not rewrite the test — only describe what needs to change and why. Fix location: Production code indicates a code defect exposed by a sound test (track separately, not a test-quality blocker). Fix location: Test indicates the test needs hardening (setup, assertions, edge cases).
64
65	---
66
67	## Part 3 — Create a fix work item (optional, on request only)
68
69	Trigger only when the user wants to create a fix work item, log a remediation, or assign a failure to a developer. This is a write operation with a mandatory confirmation gate. Follow `references/work-item-creation.md` for inputs, the subject/assignee/project confirmation gate, the `sf data create record --sobject WorkItem` call, and error handling.
70
71	> Use `WorkItem` (no namespace) — `DevopsWorkItem` is not a supported sObject in this org version.
72
73	If no `DevopsProje

People who liked this also viewed

6 picks

Type