fixing-streamlit-ci
Analyze and fix failed GitHub Actions CI jobs for the current branch/PR. Use when CI checks fail, PR checks show failures, or you need to diagnose lint/type/test errors and verify fixes locally.
About this skill
The `fixing-streamlit-ci` skill empowers an AI agent, specifically within the `streamlit/streamlit` repository context, to efficiently diagnose and rectify failed GitHub Actions Continuous Integration (CI) jobs for the current branch or pull request. It utilizes command-line tools like `gh` (GitHub CLI) and `git` to thoroughly analyze CI logs, pinpointing the root causes of failures such as linting issues, type mismatches, or failing tests. This skill is critical for maintaining the high quality and stability of the Streamlit framework by ensuring that all pull requests adhere to established CI standards and pass all automated checks, helping developers quickly understand and resolve build errors.
Best use case
Diagnosing and resolving CI failures in Streamlit pull requests, understanding why specific workflows failed, and applying/verifying fixes locally before re-pushing to trigger new CI runs.
Analyze and fix failed GitHub Actions CI jobs for the current branch/PR. Use when CI checks fail, PR checks show failures, or you need to diagnose lint/type/test errors and verify fixes locally.
The AI agent will provide a clear diagnosis of the CI failure's root cause, suggest concrete steps or code modifications to resolve the issue, and guide the user towards achieving a passing CI status for their Streamlit pull request.
Practical example
Example input
My pull request #1234 on the `streamlit/streamlit` repository has failed CI checks. Can you analyze the failures and suggest a fix?
Example output
{"diagnosis": "The CI run for PR #1234 failed in the 'test-suite' job, specifically during the 'Run pytest' step. The logs indicate a 'TypeError' in `streamlit/elements/foo.py` on line 42, likely due to an incorrect type annotation for variable `bar`.", "proposed_fix": "I recommend modifying `streamlit/elements/foo.py` line 42 to `bar: str = ...` instead of `bar: int = ...` (example fix).", "next_steps": ["Apply the proposed fix locally.", "Verify the fix by running `pytest streamlit/elements/foo.py` or the specific failing test.", "Once verified, commit the changes and push to your branch to re-trigger CI.", "Would you like me to attempt to apply this fix to your current local branch now?"]}When to use this skill
- CI checks have failed on a pull request within the `streamlit/streamlit` repository.
- You need to understand the underlying reasons why a particular workflow or job failed.
- You want assistance in applying fixes and verifying them locally before committing.
When not to use this skill
- When CI checks are passing successfully.
- When the issue is unrelated to CI (e.g., a pure application bug that doesn't manifest as a CI failure).
- When working on a repository other than `streamlit/streamlit`.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/fixing-streamlit-ci/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How fixing-streamlit-ci Compares
| Feature / Agent | fixing-streamlit-ci | Standard Approach |
|---|---|---|
| Platform Support | Claude | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | easy | N/A |
Frequently Asked Questions
What does this skill do?
Analyze and fix failed GitHub Actions CI jobs for the current branch/PR. Use when CI checks fail, PR checks show failures, or you need to diagnose lint/type/test errors and verify fixes locally.
Which AI agents support this skill?
This skill is designed for Claude.
How difficult is it to install?
The installation complexity is rated as easy. You can find the installation instructions above.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
AI Agents for Coding
Browse AI agent skills for coding, debugging, testing, refactoring, code review, and developer workflows across Claude, Cursor, and Codex.
Best AI Skills for Claude
Explore the best AI skills for Claude and Claude Code across coding, research, workflow automation, documentation, and agent operations.
ChatGPT vs Claude for Agent Skills
Compare ChatGPT and Claude for AI agent skills across coding, writing, research, and reusable workflow execution.
SKILL.md Source
# Fix CI Failures
Diagnose and fix failed GitHub Actions CI jobs for the current branch/PR using [`gh` CLI](https://cli.github.com/manual/) and `git` commands.
## When to Use
- CI checks have failed on a PR
- You need to understand why a workflow failed
- You want to apply fixes and verify locally
## Workflow
Copy this checklist to track progress:
```
- [ ] Verify authentication
- [ ] Gather context & find failed jobs
- [ ] Download & analyze logs
- [ ] Present diagnosis to user
- [ ] Apply fix & verify locally
- [ ] Push & recheck CI
```
### 1. Verify Authentication
```bash
gh auth status
```
If authentication fails, prompt user to run `gh auth login` with appropriate scopes.
### 2. Gather PR Context
```bash
# Get PR for current branch
gh pr view --json number,title,url,headRefName
# Get PR description and metadata
gh pr view --json title,body,labels,author
# List changed files
gh pr diff --name-only
# All changes
gh pr diff
```
### 3. Check CI Status
```bash
# List all checks (shows pass/fail status)
gh pr checks
# Get detailed check info
gh pr checks --json name,state,conclusion,detailsUrl,startedAt,completedAt
# List only failed runs
gh run list --branch $(git branch --show-current) --status failure --limit 10
# Check if CI is still running
gh run list --branch $(git branch --show-current) --status in_progress
```
### 4. Find Failed Jobs
```bash
# View run details (get RUN_ID from previous step)
gh run view {RUN_ID}
# List failed jobs with IDs
gh run view {RUN_ID} --json jobs --jq '.jobs[] | select(.conclusion == "failure") | {id: .databaseId, name: .name}'
# List failed jobs with their failed steps
gh run view {RUN_ID} --json jobs --jq '.jobs[] | select(.conclusion == "failure") | {name: .name, steps: [.steps[] | select(.conclusion == "failure") | .name]}'
```
### 5. Download & Analyze Logs
**Primary method:**
```bash
# Get failed logs (last 250 lines usually contains the error)
gh run view {RUN_ID} --log-failed 2>&1 | tail -250
# Target a specific failed job by ID
gh run view {RUN_ID} --job {JOB_ID} --log-failed 2>&1 | tail -100
```
**Fallback for pending logs:**
```bash
REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')
gh api "/repos/${REPO}/actions/jobs/{JOB_ID}/logs"
```
**Smart log extraction (examples):**
```bash
# Context around failure markers
gh run view {RUN_ID} --log-failed 2>&1 | grep -B 5 -A 10 -iE "error|fail|exception|traceback|panic|fatal" | head -100
# Python tests - pytest summary
gh run view {RUN_ID} --log-failed 2>&1 | grep -E -A 50 "FAILED|ERROR|short test summary"
# TypeScript/ESLint errors
gh run view {RUN_ID} --log-failed 2>&1 | grep -E -B 2 -A 5 "error TS|error "
# E2E snapshot mismatches
gh run view {RUN_ID} --log-failed 2>&1 | grep -E -B 2 -A 5 "Missing snapshot for|Snapshot mismatch for"
```
### 6. Analyze Failure
Identify:
- **Error type**: Lint, type check, test failure, build error
- **Root cause**: First/primary error (not cascading failures)
- **Affected files**: Which files need changes
- **Error message**: Exact error text
**Common CI failure categories:**
| Category | Workflow | Make Command | Auto-fix |
|----------|----------|--------------|----------|
| Python lint | `python-tests.yml` | `make python-lint` | ✅ `make autofix` |
| Python types | `python-tests.yml` | `make python-types` | ❌ Manual |
| Python tests | `python-tests.yml` | `make python-tests` | ❌ Manual |
| Frontend lint | `js-tests.yml` | `make frontend-lint` | ✅ `make autofix` |
| Frontend types | `js-tests.yml` | `make frontend-types` | ❌ Manual |
| Frontend tests | `js-tests.yml` | `make frontend-tests` | ❌ Manual |
| E2E tests | `playwright.yml` | `make run-e2e-test <file>` | ❌ Manual |
| E2E snapshots | `playwright.yml` | `make run-e2e-test <file>` | ✅ `make update-snapshots` |
| NOTICES | `js-tests.yml` | `make update-notices` | ✅ `make update-notices` |
| Min constraints | `python-tests.yml` | `make update-min-deps` | ✅ `make update-min-deps` |
| Pre-commit | `enforce-pre-commit.yml` | `uv run pre-commit run --all-files` | ✅ Mostly auto-fix |
| Relative imports | `ensure-relative-imports.yml` | Check script output | ❌ Manual |
| **PR Labels** | `require-labels.yml` | N/A | ⏭️ **Ignore** |
> 💡 **Quick win:** Run `make autofix` first for lint/formatting failures.
### 7. Present Diagnosis
**For multiple failures**, list all and let user choose:
```
CI Failure Analysis for PR #{NUMBER}: {TITLE}
═══════════════════════════════════════════════════════════════
Found {N} failed jobs/checks:
─────────────────────────────────────────────────────────────────
1. [LINT] Python Unit Tests → Run Linters
Workflow: python-tests.yml (GitHub Actions)
Error: Ruff formatting error in lib/streamlit/elements/foo.py
Auto-fix: ✅ `make autofix`
2. [TYPE] Javascript Unit Tests → Run type checks
Workflow: js-tests.yml (GitHub Actions)
Error: TS2322: Type 'string' is not assignable to type 'number'
File: frontend/lib/src/components/Bar.tsx:42
Auto-fix: ❌ Manual fix required
─────────────────────────────────────────────────────────────────
Which failures should I address?
Recommended: "1" (auto-fixable)
Options: "1" | "1,2" | "1-2" | "all" | "only auto-fixable"
```
**For single failure**, show detailed analysis:
```
─────────────────────────────────────────────────────────────────
Analyzing: [TYPE] Javascript Unit Tests → Run type checks
─────────────────────────────────────────────────────────────────
Category: TYPE
Workflow: js-tests.yml
Job: js-unit-tests (ID: 12345678)
Step: Run type checks
Error snippet:
frontend/lib/src/components/Bar.tsx:42:5
error TS2322: Type 'string' is not assignable to type 'number'.
Proposed Fix:
Change type annotation or fix the value type
─────────────────────────────────────────────────────────────────
Would you like me to:
[1] Apply the fix automatically
[2] Show the proposed changes first
[3] Run local verification only
[4] Skip this and move to next failure
```
### 8. Apply Fix & Verify Locally
After user approval, apply fix and run verification:
```bash
# Run all checks (lint, types, tests) on changed files
make check
# Python tests (specific)
uv run pytest lib/tests/path/to/test_file.py::test_name -v
# Frontend tests (specific)
cd frontend && yarn test path/to/test.test.tsx
# E2E tests
make run-e2e-test {test_file.py}
# E2E snapshots
make update-snapshots
```
### 9. Summary & Push
```bash
git status --short
git diff --stat
```
Report what failed, what changed, and local verification result.
```bash
git add -A
git commit -m "fix: resolve CI failure in {workflow/step}"
git push
```
### 10. Recheck CI Status
```bash
gh pr checks --watch
# Or re-run failed jobs
gh run rerun {RUN_ID} --failed
```
## Rules
- **Focus on root cause**: First error, not cascading failures
- **Minimal fixes**: Smallest change that fixes the issue
- **Don't skip tests**: Never disable tests to "fix" CI
- **Verify locally**: Always run appropriate local command
- **Preserve intent**: Understand what code was trying to do
## Error Handling
| Issue | Solution |
|-------|----------|
| Auth failed | `gh auth login` with workflow/repo scopes |
| No PR for branch | `gh run list` to check workflow runs |
| CI still running | `gh pr checks --watch` |
| Logs pending | Retry with job logs API |
| No failed checks | All passing ✅ |
| Rate limited | Wait and retry |
| Flaky test | Re-run: `gh run rerun {RUN_ID} --failed` |Related Skills
fixing-flaky-e2e-tests
Diagnose and fix flaky Playwright e2e tests. Use when tests fail intermittently, show timeout errors, have snapshot mismatches, or exhibit browser-specific failures.
debugging-streamlit
Debug Streamlit frontend and backend changes using make debug with hot-reload. Use when testing code changes, investigating bugs, checking UI behavior, or needing screenshots of the running app.
finalizing-pr
Finalizes branch changes for merging by simplifying code, running checks, reviewing changes, and creating a PR if needed. Use when ready to merge changes into the target branch.
discovering-make-commands
Lists available make commands for Streamlit development. Use for build, test, lint, or format tasks.
creating-pull-requests
Creates a draft pull request on GitHub with proper labels, branch naming, and description formatting. Use when changes are ready to be submitted as a PR to the streamlit/streamlit repository.
checking-changes
Validates all code changes before committing by running format, lint, type, and unit test checks. Use after making backend (Python) or frontend (TypeScript) changes, before committing or finishing a work session.
assessing-external-test-risk
Assesses whether branch or PR changes are high-risk for externally hosted or embedded Streamlit usage and recommends whether external e2e coverage with `@pytest.mark.external_test` is needed. Use during code review, PR triage, or test planning when changes touch routing, auth, websocket/session behavior, embedding, assets, cross-origin behavior, SiS/Snowflake runtime, storage, or security headers.
addressing-pr-review-comments
Address all valid review comments on a PR for the current branch in the streamlit/streamlit repo. Covers both inline review comments and general PR (issue) comments. Use when a PR has reviewer feedback to address, including code changes, style fixes, and documentation updates.
ui-demo
Record polished UI demo videos using Playwright. Use when the user asks to create a demo, walkthrough, screen recording, or tutorial video of a web application. Produces WebM videos with visible cursor, natural pacing, and professional feel.
microsoft-docs
Query official Microsoft documentation to find concepts, tutorials, and code examples across Azure, .NET, Agent Framework, Aspire, VS Code, GitHub, and more. Uses Microsoft Learn MCP as the default, with Context7 and Aspire MCP for content that lives outside learn.microsoft.com.
jupyter-notebook
Use when the user asks to create, scaffold, or edit Jupyter notebooks (`.ipynb`) for experiments, explorations, or tutorials; prefer the bundled templates and run the helper script `new_notebook.py` to generate a clean starting notebook.
n8n-expression-syntax
Validate n8n expression syntax and fix common errors. Use when writing n8n expressions, using {{}} syntax, accessing $json/$node variables, troubleshooting expression errors, or working with webhook data in workflows.