Skip to content
Report library
Purpose / Other

Diagnose Ci Failures Skill Security Audit

What the author says it does (original text)

Diagnose CI failures for a PR using the GitHub CLI, extract error logs, and generate a plan to fix them. Use when the user asks to check CI status, pull CI issues, triage test failures, or investigate PR build failures.

Independent security check

Security risks found

Files checked
1
Risks found
2
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 1
Medium risk

Secrets in failed logs may be copied into the plan document

Source references: 4
What we found

The workflow calls for extracting complete error messages, stack traces, and build root causes and recording findings in a plan, but it provides no instruction to detect or redact tokens, credentials, private URLs, environment-variable values, or other sensitive log content.

Why this matters

If CI has already printed a secret into a failed log, the generated plan could preserve or expose it to additional readers and extend its lifetime. This does not mean that any particular log contains secrets.

The workflow extracts error messages, stack traces, and root causes from CI logs, then records findings and locations in a plan, without requiring detection or redaction of tokens, environment-variable values, private URLs, or other sensitive material. If failure output accidentally contains a secret, it could be carried into the persistent plan with the error context. The skill does not require copying entire logs, so the risk depends on whether the secret appears in extracted context. Users can require redaction before display or storage and limit captured context.

SKILL.md:50In the instructionsOpen original file
```bashGH_PAGER=cat gh run view <run-id> --log-failed```Focus on extracting:- Error messages and their locations (file paths, line numbers)- Compilation errors (unused imports, type mismatches, etc.)- Linting/clippy errors with specific lint names- Test failure messages and stack traces- Build failures and their root causes
Show 3 other places
SKILL.md:71In the instructionsOpen original file
Create a plan document (using `create_plan` tool) with:- **Problem Statement**: Summary of failing checks- **Current State**: What errors were found and where- **Proposed Changes**: Specific fixes needed for each error category- **Validation Steps**: Commands to verify fixes (fmt, clippy, tests, presubmit)
SKILL.md:47In the instructionsOpen original file
For each failed check, pull the logs using the run ID from the status check:```bashGH_PAGER=cat gh run view <run-id> --log-failed```
SKILL.md:53In the instructionsOpen original file
Focus on extracting:- Error messages and their locations (file paths, line numbers)- Compilation errors (unused imports, type mismatches, etc.)- Linting/clippy errors with specific lint names- Test failure messages and stack traces- Build failures and their root causes
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.No risks found
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.Risks found: 1
Medium risk

Untrusted CI logs can manipulate the diagnostic plan

Source references: 4
What we found

The workflow tells the agent to download and analyze failed logs, but never says to treat log text only as data or to ignore instructions embedded in it. Build steps, tests, and dependencies can print arbitrary text into CI logs.

Why this matters

A malicious or compromised CI job could cause a misleading root-cause assessment, hide the real failure, or place unauthorized commands and actions in the proposed fix plan. Because the Skill says not to change code directly, the supported immediate impact is primarily manipulation of the user's decisions.

The skill actively retrieves failed-run logs, analyzes errors and root causes, and uses the findings to generate a plan. CI builds or tests can emit arbitrary text, including text disguised as operational instructions. The workflow does not explicitly treat logs as untrusted data or require ignoring instructions found in them. This supports a prompt-injection risk affecting the diagnosis or plan, but does not show that an attack occurred. Users can ask for an explicit trust boundary and restrict plans to verifiable error fields.

SKILL.md:47In the instructionsOpen original file
For each failed check, pull the logs using the run ID from the status check:```bashGH_PAGER=cat gh run view <run-id> --log-failed```Focus on extracting:- Error messages and their locations (file paths, line numbers)- Compilation errors (unused imports, type mismatches, etc.)- Linting/clippy errors with specific lint names- Test failure messages and stack traces- Build failures and their root causes
Show 3 other places
SKILL.md:71In the instructionsOpen original file
Create a plan document (using `create_plan` tool) with:- **Problem Statement**: Summary of failing checks- **Current State**: What errors were found and where- **Proposed Changes**: Specific fixes needed for each error category- **Validation Steps**: Commands to verify fixes (fmt, clippy, tests, presubmit)
SKILL.md:53In the instructionsOpen original file
Focus on extracting:- Error messages and their locations (file paths, line numbers)- Compilation errors (unused imports, type mismatches, etc.)- Linting/clippy errors with specific lint names- Test failure messages and stack traces- Build failures and their root causes
SKILL.md:69In the instructionsOpen original file
### 5. Generate fix planCreate a plan document (using `create_plan` tool) with:- **Problem Statement**: Summary of failing checks- **Current State**: What errors were found and where- **Proposed Changes**: Specific fixes needed for each error category- **Validation Steps**: Commands to verify fixes (fmt, clippy, tests, presubmit)
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

5 instruction sections

The Skill uses the GitHub CLI identity available in the current environment to read the current branch's PR and CI status, then downloads failed logs by run ID. The shown commands are read-only and do not push, merge, or modify GitHub state.

View source
SKILL.md:22In the instructionsOpen original file
# Get current branchgit branch --show-current# Check for PRGH_PAGER=cat gh pr view <branch-name> --json number,title,url,state```
SKILL.md:34In the instructionsOpen original file
```bashGH_PAGER=cat gh pr view <branch-name> --json statusCheckRollup```
SKILL.md:47In the instructionsOpen original file
For each failed check, pull the logs using the run ID from the status check:```bashGH_PAGER=cat gh run view <run-id> --log-failed```

The intended output is a fix plan for user review, not direct code changes. The plan summarizes failed checks, error locations, proposed changes, and validation commands.

View source
SKILL.md:69In the instructionsOpen original file
### 5. Generate fix planCreate a plan document (using `create_plan` tool) with:- **Problem Statement**: Summary of failing checks- **Current State**: What errors were found and where- **Proposed Changes**: Specific fixes needed for each error category- **Validation Steps**: Commands to verify fixes (fmt, clippy, tests, presubmit)
SKILL.md:81In the instructionsOpen original file
- **GitHub CLI paging**: Set `GH_PAGER=cat` on every `gh` invocation. The GitHub CLI does not support `--no-pager` as a global option; `GH_PAGER` and `PAGER` are its documented paging controls- **Always create a plan first**: Never make code changes directly. Generate a plan for user review- **Check test status in CI**: Even if tests fail locally, verify they passed in CI before flagging as issues
Start here · InstructionsSKILL.md
diagnose-ci-failures
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.
Files and check records1 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions

Operations mentioned in code and instructions

Run commands
SKILL.md:20In the instructionsOpen original file
```bash# Get current branch
SKILL.md:34In the instructionsOpen original file
```bashGH_PAGER=cat gh pr view <branch-name> --json statusCheckRollup
SKILL.md:49In the instructionsOpen original file
```bashGH_PAGER=cat gh run view <run-id> --log-failed
Read files
SKILL.md:25In the instructionsOpen original file
# Check for PRGH_PAGER=cat gh pr view <branch-name> --json number,title,url,state```
SKILL.md:35In the instructionsOpen original file
```bashGH_PAGER=cat gh pr view <branch-name> --json statusCheckRollup```
SKILL.md:50In the instructionsOpen original file
```bashGH_PAGER=cat gh run view <run-id> --log-failed```
Lines read
114
File checksum (to compare versions)
2304f59632a77c02e638124069696f562a4a9e1c4b8a73cbb503fd939c2bfb98