ci-feedback-loop
Skill3 starsChanged 3 months agoMITView on GitHub
Monitor PR check status after push, auto-fix CI failures, and escalate when unable to fix. Use when an agent has pushed commits to a PR and needs to ensure checks pass before continuing.
In this repository41 other files it gives its agents.
- cadence-goalsSkill
- compoundSkill
- decision-rights-doctrineSkill
- diataxisSkill
- dispatch-gateSkill
- drift-checkSkill
- family-checkSkill
- fix-then-re-review-ladderSkill
- github-projectsSkill
- gitSkill
- goal-treeSkill
- handoffSkill
- improvement-loopSkill
- kb-captureSkill
- kb-compileSkill
- kb-coreSkill
- kb-lessons-bridgeSkill
- kb-lintSkill
- l1-supervisorSkill
- l2-supervisorSkill
- lessons-learnedSkill
- lN-lifecycle-doctrineSkill
- lN-review-doctrineSkill
- medical-recordsSkill
- operator-interview-doctrineSkill
- operator-interviewSkill
- operator-reviewSkill
- planning-workflowSkill
- pr-review-fanoutSkill
- pull-taskSkill
- ralph-wiggumSkill
- reviewSkill
- root-cause-depthSkill
- scan-documentSkill
- self-improvementSkill
- self-verifySkill
- skillifySkill
- task-workflowSkill
- testing-without-mocksSkill
- vault-cloudSkill
- verify-inherited-premiseSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
After pushing commits to a PR branch, monitor check status, diagnose failures, attempt fixes, and escalate if unable to resolve.
- Distinctive: line 21
After pushing commits to a PR branch in the auto-advance loop
- Distinctive: line 22
When a user asks to monitor and fix CI failures on a PR
- Distinctive: line 23
When CI checks fail and the agent should attempt automated remediation
- Distinctive: line 72
When: After any push to the PR branch (initial or fix attempt).
- Distinctive: line 98
When invoked, run operations sequentially in a loop:
- Distinctive: line 125
Success: All checks passed (possibly after fixes).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
CI Feedback Loop
After pushing commits to a PR branch, monitor check status, diagnose failures, attempt fixes, and escalate if unable to resolve.
When to Use
- After pushing commits to a PR branch in the auto-advance loop
- When a user asks to monitor and fix CI failures on a PR
- When CI checks fail and the agent should attempt automated remediation
Prerequisites
ghCLI installed and authenticated withreposcope- A PR exists with check runs (GitHub Actions, external CI, etc.)
Configuration
| Parameter | Default | Description |
max_retries | 3 | Maximum fix attempts before escalating |
poll_interval | 30 | Initial polling interval in seconds |
max_wait | 1800 | Maximum wait time for checks in seconds (30 min) |
Overview
The skill runs a monitor-diagnose-fix loop:
Push to PR branch
│
▼
Poll checks ◄──────────────┐
│ │
┌───┴───┐ │
│Result?│ │
└───┬───┘ │
│ │
pass → Done │
pending → Wait (backoff) ───┘
fail → Retrieve logs
│
▼
Analyze failure
│
┌────┴────┐
│Fixable? │
└────┬────┘
│
yes → Attempt fix → Push → Re-poll
no → Retries left?
yes → Re-trigger (flaky)
no → Escalate (PR comment)Operations
1. Poll Checks
When: After any push to the PR branch (initial or fix attempt).
Implementation: Load operations/poll-checks.md
Quick summary: Polls gh pr checks --json with exponential backoff until all checks resolve or timeout.
2. Retrieve Logs
When: One or more checks have failed.
Implementation: Load operations/retrieve-logs.md
Quick summary: Fetches failure logs via gh run view --log-failed with API fallback.
3. Analyze Failure
When: Failure logs have been retrieved.
Implementation: Load operations/analyze-failure.md
Quick summary: Classifies failure type (code error, flaky/infra, configuration) and extracts actionable context.
4. Attempt Fix
When: Failure is classified as fixable and retries remain.
Implementation: Load operations/attempt-fix.md
Quick summary: Agent applies fix, pushes to PR branch, decrements retry counter, re-enters poll loop.
5. Escalate
When: Retry limit reached, timeout exceeded, or failure classified as unfixable.
Implementation: Load operations/escalate.md
Quick summary: Posts structured PR comment with failure summary, attempted fixes, and next steps for human.
End-to-End Flow
When invoked, run operations sequentially in a loop:
Input
pr_number(required): PR number to monitorrepo(optional): Repository inowner/repoformat. Defaults to current repo.
Loop
1. poll-checks(pr_number) → status
2. if status == "pass" → return success
3. if status == "timeout" → escalate("Checks timed out")
4. if status == "fail":
a. retrieve-logs(failed_checks) → logs
b. analyze-failure(logs) → diagnosis
c. if diagnosis.fixable AND retries > 0:
- attempt-fix(diagnosis) → push
- retries -= 1
- goto 1
d. if NOT diagnosis.fixable OR retries == 0:
- escalate(diagnosis, attempts)
- return failureOutput
- Success: All checks passed (possibly after fixes). Agent can continue auto-advance.
- Failure: Escalation comment posted on PR. Agent should stop auto-advance and wait for human.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

