You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: clarify triage preflight checks and repo guidelines (#153)
Reorder the antithesis-triage preflight as an ordered checklist (auth key,
snouty doctor, API reachability) so failures get surfaced one cause at a
time. Expand AGENTS.md with what `make validate` actually checks, the
sibling `<skill>-test/` harness convention, and an explicit note on the
automation that owns version bumps and CHANGELOG entries. Add a
CLAUDE.md that points Claude Code at AGENTS.md.
Copy file name to clipboardExpand all lines: antithesis-triage/SKILL.md
+11-13Lines changed: 11 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,25 +23,23 @@ Use this skill to analyze Antithesis test runs.
23
23
- DO NOT PROCEED if `jq` is not installed. See `https://jqlang.org/download/` for installation options.
24
24
-**Note:**`snouty runs` may be hidden from `snouty --help` but is still supported. If you need to confirm availability or see subcommand syntax, `snouty runs --help` still works.
25
25
26
-
### API access (rollout in progress)
26
+
### Preflight: confirm triage can work
27
27
28
-
This version of the triage skill talks to Antithesis through the snouty API (`snouty runs ...`). The API is currently being rolled out to all tenants; however, you may encounter a tenant that isn't updated yet. You should detect access before continuing unless you already know (from context or memory) that the tenant in question has the API enabled.
28
+
This version of the triage skill talks to Antithesis through the snouty API (`snouty runs ...`). Several things can prevent that from working. Walk down the checklist below in order — it is ordered from the most-likely cause (auth not exported) to the least-likely (tenant missing API access). Stop at the first failing check and surface **only that cause** to the user; do not list the others. Do not attempt real triage work until every check passes.
29
29
30
-
**Detect missing API access** before doing real work:
30
+
You can skip preflight if you already know (from context or memory) that the user's setup is working.
31
31
32
-
1. Check that `$ANTITHESIS_API_KEY` is set. `snouty doctor` reports this too.
33
-
2. If unset, ask the user whether their tenant has API access. If they don't
34
-
know or say no, treat the API as unavailable.
35
-
3. Optionally probe: `snouty runs list -n 1` — if it fails with an error, the tenant is not yet enrolled.
32
+
1.**Is `$ANTITHESIS_API_KEY` set?** This is the most common cause of failure. If unset, tell the user to export it (e.g., `export ANTITHESIS_API_KEY=<their key>`) and stop. Do not speculate about other causes.
36
33
37
-
**If API access is unavailable**, do NOT attempt to run this skill. Instead, tell the user to either:
34
+
2.**Does `snouty doctor` pass?** Run `snouty doctor`. If it reports any failure, relay that failure to the user and stop. Today this mostly re-confirms environment variables, but it is the canonical place where key validity, network reachability, and API-access checks will be surfaced as they are added — so always run it here.
38
35
39
-
-**Contact Antithesis support** to request API access for their tenant.
40
-
-**Or downgrade this skill** to the previous browser-based version on the
3.**Can the API actually be reached?** Probe with `snouty runs list -n 1`. If this errors, the most likely remaining cause is that the tenant is not yet enrolled in the snouty API rollout. Tell the user to either:
37
+
-**Contact Antithesis support** to request API access for their tenant, or
38
+
-**Downgrade this skill** to the previous browser-based version on the
0 commit comments