Conciseness

Every token carries non-obvious, platform-specific information (SSO websocket 302 blocking the CLI, SIGTERM all-thread dumps, pods lacking CAP_SYS_PTRACE) with no padding and no explanation of concepts Claude already knows. Even the 'Why not pyspy/gdb/strace' note conveys real constraints rather than filler.

Actionability

Fully executable throughout: the log-viewer URL pattern, 'databricks apps logs <app-name> --follow --profile <profile>', 'databricks apps get ... | jq '.app_status'', a concrete app.yaml env snippet, 'kill -USR1 <pid>', and exact log signatures to match — covering the common Python, Node, crash, and hang cases.

Workflow Clarity

The diagnostic sequence is clear (read logs → match signatures → hang-specific escalation) with a built-in checkpoint ('app.diagnostics: installed (pid=…)' confirms the bootstrap ran) and explicit SSO/non-SSO branching. It falls short of anchor 5 only because there is no explicit error-recovery loop, e.g. what to do when the log viewer shows nothing or how to confirm the watchdog toggle took effect after redeploy.

Progressive Disclosure

Well-organized sections with no content that belongs in a separate file at this size, and the single external pointer (crash fixtures at '.scripts/agent-integration-tests/crash-examples/') is clearly signaled and exactly one level deep. Navigation is easy and there are no nested references.

Specificity

The 'what' clause is a single concrete action — "Diagnose a crashed, hung, or erroring deployed Databricks App" — which names the domain plus one action but does not list several distinct capabilities; sub-actions like retrieving stack traces appear only as trigger conditions. This matches 'Names domain and 1-2 concrete actions' rather than the level above ('Lists several specific actions').

Completeness

Explicitly answers both questions: the 'what' ("Diagnose a crashed, hung, or erroring deployed Databricks App") and a numbered 'Use when:' clause with four concrete trigger conditions. This matches the anchor for clearly and explicitly answering both what and when with concrete trigger phrases.

Trigger Term Quality

Strong natural coverage: "crashed / UNAVAILABLE / 502s", "hangs or is unresponsive", "stack trace", "app logs", "diagnostics env toggles" — terms a user would actually say, including status codes. A few common variations (e.g., 500s, failing health checks, restart loop) are missing, keeping it below comprehensive anchor 5.

Distinctiveness Conflict Risk

"deployed Databricks App" carves out a clear niche with platform-specific triggers (UNAVAILABLE, 502s, diagnostics env toggles) that are unlikely to fire for the wrong skill. Overlap with generic debugging or logging skills is minimal.