CI Watch & Auto-Fix
After Shep pushes the branch and opens the PR, it doesn’t walk away. Shep watches your CI pipeline. If checks fail, the agent reads the logs, diagnoses the problem, and pushes a fix.

How it works
Push → GitHub Actions starts → Shep watches checks
│
┌───────────────┴───────────────┐
│ │
Pass Fail
│ │
PR ready for review Agent reads logs
│
Pushes a fix
│
▼
(loop, up to retry limit)Shep polls GitHub for check status. When a check fails:
- Shep fetches the run logs.
- Shep extracts the relevant error output (failing test name, lint error, build error).
- Shep gives this to the agent along with the original feature context.
- The agent makes a fix in the same worktree.
- Shep commits the fix and pushes again.
- CI runs again. If it passes, you’re done. If it fails again, repeat.
Retry limits
By default Shep retries up to 3 times per failure mode. After that the feature enters Blocked state and waits for you. You’ll see it highlighted in the dashboard.
Override the retry count globally:
shep settings workflow
# answer the "How many CI fix retries before pausing?" questionOr in .shep/config.json:
{
"agents": {
"retryAttempts": 5
}
}What CI Shep can fix
It works best when CI errors are clear and reproducible. In practice:
- Failing tests — usually fixable, especially when the test message names what failed.
- Lint / format errors — almost always fixable.
- Type errors — usually fixable.
- Build errors — usually fixable.
- Flaky tests — Shep retries once. If the test passes, great. If it consistently fails, the feature pauses.
- Infra / network errors — Shep is not a CI debugging tool. Repeated infra failures pause the feature.
The agent only sees the logs Shep can fetch. If your CI hides errors behind a “private” job or a custom dashboard, Shep can’t help with those — fix the visibility first.
Disabling CI watch
If you want CI to be entirely your responsibility:
shep settings workflow
# answer the "Watch CI after push?" question with "no"Or per-feature: there isn’t a --no-ci-watch flag, but you can stop CI watch by stopping the agent (shep agent stop <id>) once the PR is open. The PR stays in draft for you to handle.
Inspecting what Shep is doing
In the dashboard, the activity log shows every CI poll, every retry, every fix attempt:
14:32:01 push feat/add-health-endpoint
14:32:18 ci-start check_run_id=8294
14:33:42 ci-fail jobs.test failed: "expected 200 but got 500"
14:33:43 agent-fix reading logs, asking agent for fix
14:34:09 push fix(test): handle missing version env var
14:34:25 ci-pass all checks green
14:34:25 pr-ready shep-ai/my-app#142shep feat logs <id> shows the same stream from the terminal.
Tuning your project for auto-fix
A few things make Shep’s auto-fix more reliable:
- Clear error output. Tests that report what failed and why are easier to fix than tests that just say “FAIL”.
- Fast CI. Each retry is one CI run. If your CI takes 15 minutes, three retries is 45 minutes. Optimize CI speed.
- One concern per check. A single check with 50 unrelated tests is harder to fix than smaller checks with focused responsibilities.
- Deterministic tests. Flaky tests confuse the agent — it’ll fix the wrong thing.
What happens after auto-fix succeeds
Same as a manual fix push: CI passes, the PR is ready for review, and Shep moves the feature to the Review phase.
If you set --allow-merge, Shep merges the PR automatically once CI is green. Otherwise the PR sits in draft for you to mark ready and merge.