Conciseness

Nearly every token is Databricks-platform-specific operational detail Claude cannot know (logz URL, SSO websocket-302 limitation, exact log signatures, env var table, 'no ptrace / CAP_SYS_PTRACE' rationale). A couple of minor trims exist — the parenthetical '(Node's default `--unhandled-rejections=throw` escalates it to `uncaughtException`)' and 'the app's log stream' re-explain behavior Claude already knows — which fits the 4 anchor ('efficient; minor instances of over-explanation') rather than 5.

Actionability

Copy-paste-ready throughout: the logz viewer URL, `databricks apps logs <app-name> --follow --profile <profile>`, the `jq '.app_status'` pipeline, a complete app.yaml env snippet, `kill -USR1 <pid>`, and the exact log signatures to grep for — covering the common cases (crash, worker-thread crash, SIGTERM kill, unhandled rejection, hang) for both Python and Node. Nothing is pseudocode or vague.

Workflow Clarity

The diagnostic flow is clear and branch-aware: environment check (SSO vs CLI) for reading logs, a signature catalog to match against, and ordered hang guidance ('the SIGTERM all-thread dump (above) shows where it was stuck — check that first') plus an if-then escalation (enable the watchdog env var and redeploy; 'If you can signal the pod, kill -USR1'). Not 5 because the sequence is conveyed by section order rather than explicit steps, and there is no closing validation loop (e.g. confirm `.app_status` is healthy after a fix) — minor checkpoint gaps matching the 4 anchor; well above 3, whose sequence lacks checkpoints entirely.

Progressive Disclosure

Well-organized sections (Reading the logs / What to look for / Diagnosing a hang / Environment toggles / Notes), and at ~75 lines of dense operational reference the inline content is appropriately sized — no monolith or buried references. Not 5 because the one outbound pointer, 'Runnable crash fixtures + the e2e crash test live in `.scripts/agent-integration-tests/crash-examples/`', does not resolve within the skill bundle (no references/, scripts/, or assets/ exist), so it is not a well-signaled one-level reference; that plus the env-toggle table being borderline extractable leaves a minor organization gap at the 4 anchor.

Specificity

The what-clause names the domain and a single concrete action ('Diagnose a crashed, hung, or erroring deployed Databricks App'), while the when-clauses imply further capabilities (stack traces, log reading, env toggles) — a base of 4 ('several specific actions; minor gaps'). However, trigger (3) 'you need the stack trace behind a failure' uses second-person voice, which the rubric penalizes by reducing specificity by 1, yielding 3.

Completeness

Explicitly answers both: what ('Diagnose a crashed, hung, or erroring deployed Databricks App') and when ('Use when: (1) an app is crashed / UNAVAILABLE / 502s, (2) an app hangs or is unresponsive, (3) you need the stack trace behind a failure, (4) questions about reading app logs or the diagnostics env toggles') — four concrete trigger phrases, matching the 5 anchor exactly.

Trigger Term Quality

Comprehensive natural terms users would actually say: 'crashed', 'hung', 'unresponsive', '502s', 'UNAVAILABLE', 'stack trace', 'app logs', and the diagnostics env toggles — covering synonyms and concrete status codes the way the 5-anchor covers file extensions. Not 4 because no common variation of a crash/hang/log-reading request is missing.

Distinctiveness Conflict Risk

'deployed Databricks App' with crash/hang/log-diagnosis triggers carves a clear niche with minimal overlap; a generic deployment or non-Databricks debugging question would not fire these triggers. Not 4 because the trigger set is uniformly diagnostics-flavored rather than broadly matching Databricks work.