agentleFS
stoa-platformstoa-platform/stoa/.claude/skills/ci-fix/SKILL.md

ci-fix

Skill9 starsChanged 7 months agoApache-2.0View on GitHub

Auto-fix CI failures (lint, format, type errors). Diagnoses, fixes, commits and pushes.

  • Commits and pushes

8 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use pr-review.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MicrosoftSkill

    pr-review

    Verify the technical accuracy of a vscode-docs pull request against the VS Code source code in microsoft/vscode. Use when reviewing a docs PR for factual correctness: setting names, command IDs, default values, API shapes, keybindings, versioned availability, and described behavior.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 6 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If workflow run URL or ID:

    line 26
  2. Distinctive:

    If the failure is NOT auto-fixable, report what you found and stop.

    line 63
  3. Distinctive:

    Run the appropriate fix command from the table above.

    line 67
  4. Very specific:

    NEVER: use --force push

    line 133
  5. Very specific:

    NEVER: use --no-verify on commits

    line 134
  6. Distinctive:

    If the fix changes behavior (not just formatting), STOP and report

    line 136
  7. Distinctive:

    If unsure whether a fix is safe, STOP and report

    line 137
  8. Distinctive:

    Always verify the fix locally before pushing

    line 138

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

CI Fix — Auto-remediate CI Failures

Context dynamique

  • Branch courante: !git branch --show-current
  • Checks PR en cours: !gh pr checks 2>/dev/null | head -20
  • Workflows recents: !gh run list --limit 5 --json name,status,conclusion,headBranch --template '{{range .}}{{.name}} | {{.status}} | {{.conclusion}} | {{.headBranch}}{{"\n"}}{{end}}' 2>/dev/null

Instructions

Auto-fix CI failure for: $ARGUMENTS

Step 1: Identify failing checks

If PR number:

gh pr checks $ARGUMENTS
gh run list --branch $(gh pr view $ARGUMENTS --json headRefName -q .headRefName) --limit 3

If workflow run URL or ID:

gh run view $ARGUMENTS --log-failed

Step 2: Read error logs

# Get the failed run ID, then read logs
gh run view <run-id> --log-failed 2>&1 | head -200

Step 3: Classify — auto-fixable or manual?

Auto-fixable (proceed to Step 4):

CheckError patternFix command
Python lint (ruff)Found N errorscd <component> && ruff check --fix .
Python format (black)would reformatcd <component> && black .
Python import orderI001cd <component> && ruff check --fix --select I .
TS/JS lint (eslint)N problems (N errors, N warnings)cd <component> && npm run lint -- --fix
TS/JS format (prettier)Code style issuescd <component> && npx prettier --write .
Rust formatDiff incd stoa-gateway && cargo fmt
Rust clippy (simple)warning: with help: ... suggestioncd stoa-gateway && cargo clippy --fix --allow-dirty

NOT auto-fixable (report and STOP):

CategoryExamples
Logic errorsTest assertions failing, wrong behavior
Test failuresvitest/pytest/cargo test failures
Security issuesGitleaks, Bandit findings, SAST violations
Type errors (complex)Missing interfaces, wrong generics
Build errorsMissing dependencies, Docker build failures
InfrastructureK8s deploy, ArgoCD, Helm issues

If the failure is NOT auto-fixable, report what you found and stop. Do NOT attempt manual fixes.

Step 4: Apply fix

Run the appropriate fix command from the table above. Then verify locally:

Python:

cd <component> && ruff check . && black --check .

TypeScript:

cd <component> && npm run lint && npm run format:check

Rust:

cd stoa-gateway && cargo fmt --check && RUSTFLAGS=-Dwarnings cargo clippy --all-targets --all-features -- -D warnings

Step 5: Commit and push

GUARDRAILS (mandatory checks before any git operation):

# Verify we are NOT on main
BRANCH=$(git branch --show-current)
if [ "$BRANCH" = "main" ] || [ "$BRANCH" = "master" ]; then
  echo "ABORT: Cannot push CI fixes to main. Checkout the feature branch first."
  exit 1
fi

Then commit and push:

git add <only-fixed-files>
git commit -m "fix(ci): auto-fix <check-name> lint/format issues"
git push

Step 6: Report

## CI Fix: [check-name] on [branch]

### Fixed
- **Check**: [failing check name]
- **Error**: [error summary]
- **Fix**: [command run]
- **Files**: [list of modified files]

### Verification
- Local check: PASS/FAIL
- Pushed to: [branch]

### Not Fixed (if any)
- [check]: [reason — requires manual intervention]

Append metrics entry:

Append to ~/.claude/projects/.../memory/metrics.log:
YYYY-MM-DDTHH:MM | CI-FIX | task=<current-task> check=<check-name> auto_fixed=true|false

Rules

  • NEVER fix logic errors, test failures, or security issues — only format/lint/type
  • NEVER push to main — always verify branch name first
  • NEVER use --force push
  • NEVER use --no-verify on commits
  • NEVER modify test expectations to make them pass
  • If the fix changes behavior (not just formatting), STOP and report
  • If unsure whether a fix is safe, STOP and report
  • Always verify the fix locally before pushing

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.