gh-aw: Skill for Claude Code

Workflow Diagnosis and Debugging Evidence

Use this reference to diagnose workflows: download/analyze existing logs, audit runs, and trace failures. These reads are not an active debug loop.

Follow the shared local-first strategy for all reproduction, fixes, uploads, and live tests. This page is an evidence and CLI reference, not a separate execution policy. Respect explicit no-dispatch contexts. Apply its live-outcome table, credential triage and untrusted-evidence rules. Without accessible existing logs, use source/fixtures; never dispatch for evidence.

Require one read-only security-review agent per revision, not multiple judges. Show the user an annotated overview of changed authored .md sources explaining their security impacts; ignore .lock.yml diffs in that overview while retaining generated locks as execution-review evidence. Follow the shared single-reviewer and annotated overview rules.

Workflow registration/activation and secret presence, validity, or expiry are runtime readiness checks, not pre-dispatch prerequisites. Do not require workflow or secret inventories or organization-admin metadata access. An otherwise authorized dispatch and the workflow's startup/authentication checks determine readiness; report their failures without automatic enabling, provisioning, or dispatch retries. Missing readiness metadata alone is not a safety finding. Declared credential flows, authorized destinations, permissions, source/lock review, and human live-validation gates remain in scope.

The user may grant explicit session authorization for bounded in-scope debug iterations without repeated approval. Re-review every changed source/lock revision; any compiler security warning invalidates the grant and requires fresh authorization after resolution.

For workflow updates, recommend publishing the reviewed Markdown and generated lock on a feature branch and opening a draft PR, then testing that explicit reviewed ref rather than requiring a merge or simply refusing because the changes are unpublished. Reuse an existing suitable branch or PR. The agent owns authorized preparation, compilation, publication and testing; the user owns the required live-effect authorization. Follow the shared branch-testing path. A branch or PR does not isolate secrets, queue state or outputs, and cannot bypass a security gate, dispatch denial or explicit no-dispatch context. The first accepted producer submit automatically installs Policy and Work; no administrator seed or repository-administration inventory is required. Follow the queue protocol.

Always provide separate short user-visible result sentences for each security review and dry-run attempt, including failed, blocked, or unavailable outcomes. Name the artifact/scope, checks actually performed, and material findings or coverage gaps; do not leave the result only in logs or artifacts or imply live execution. Follow the shared review result and dry-run result rules. When debugging is refused, follow the blocked-result requirements: explain each concrete cause, link the reviewed source and lines, distinguish confirmed defects from incomplete evidence or authorization, and name the necessary resolution and its owner. Do not report disagreement alone as a code vulnerability. Include the branch/PR testing path when it resolves unpublished changes; explain any independent blocker that it cannot resolve. In dry-run mode, reject enabled dangerously-* entries in workflow Markdown configuration, including imported configuration, under the strict security gate. This filter does not reject implementation-internal flags used by trusted built-in engines. Review their runtime isolation separately. Link the authored field responsible for a refusal; do not claim compiler rejection when none occurred.