| name | github-actions |
| description | Load when the user asks to push — watch GitHub Actions and auto-fix failures until green. |
Push & GitHub Actions Monitoring
Load this skill only when the user explicitly asks to push (e.g., "push", "faça o push", "push and open the PR"). Do not trigger on commits alone — a commit is not a push.
Preconditions (check in order, stop if any fails)
gh auth status succeeds → the GitHub CLI is configured and authenticated.- The repo has at least one workflow:
.github/workflows/*.yml or *.yaml exists. Use the cached ci_cd_detected field in .dev-team-agents/user-data/preferences.json instead of re-scanning every time:
true → trust it, skip the scan.null or false → scan .github/workflows/*.yml/*.yaml, then write the result back to ci_cd_detected. A cached false is always rechecked (cheap, and workflows get added over time); a cached true never is.
If gh is not configured → push normally and skip the rest of this skill (do not attempt to install or configure gh).
If there are no workflow files → push normally and tell the user in one line there are no Actions to watch.
Flow
0. Ask how to proceed (quiz)
Both preconditions passed — CI/CD is configured for this repo. Before pushing, load skills/shared/interaction-patterns/SKILL.md and ask with AskUserQuestion (single-select, options in the user's language from preferences.json):
"This project has GitHub Actions configured. How would you like to proceed?"
- Executar
git push + acompanhar CI (recomendado) — push, then watch the triggered run and auto-fix on failure (continue to step 1)
- Somente git push — push and stop; do not watch Actions
- ("Other" is offered automatically by
AskUserQuestion for free-text answers — interpret it as the user's intent, e.g. asking to also open a PR, and act on it instead of guessing.)
If the user picks Somente git push, run the push and stop — skip steps 2–4 below entirely.
This quiz applies both when the user asks to push directly and when a push happens as part of opening a PR (gh pr create) — see commands/pr.md.
1. Push
Run the push the user asked for. Capture the branch name.
2. Watch the run
Tell the user you are watching the triggered Actions run, then start watching:
gh run list --branch "<branch>" --limit 1 --json databaseId,status,workflowName
gh run watch <run-id> --exit-status
--exit-status makes gh run watch exit non-zero if the run concludes in failure — use that as the trigger for the fix loop.- If no run appears within a reasonable poll window, report that no Actions run was triggered by the push and stop.
3. On failure — diagnose → fix → re-push (capped loop)
When the run fails, enter the auto-fix loop. Maximum 3 attempts.
Each attempt:
- Read the failure:
gh run view <run-id> --log-failed
- Diagnose the root cause from the failed job logs (lint error, failing test, type error, missing dependency, bad config, etc.).
- Apply the fix in the working tree. Only fix what the logs point to — do not refactor beyond the failing cause.
- Commit the fix following the project's commit convention (load
skills/shared/conventional-commits/SKILL.md if drafting a Conventional Commit; never add AI attribution).
- Push again and watch the new run (step 2).
Give the user a one-line summary after every attempt, e.g.:
⚙️ Actions failed on test job — UserService null check. Fixed and re-pushed (attempt 1/3), watching the new run.
4. Stop conditions
Stop the loop and report to the user when any of these is true:
- Green — the run concludes successfully. Report:
✅ Actions passing on <branch> (run <id>).
- Cap reached — 3 attempts made without going green. Stop, summarize what was tried and the remaining failure, and hand control back to the user. Do not push a 4th time.
- Non-auto-fixable failure — the cause is outside the code you can safely change (e.g., missing repository secret, external service down, required approval, infra/permissions). Do not guess or push blindly. Report the specific blocker and what the user must do.
Rules
- Never disable, delete, or skip a failing workflow to make it "pass" (no
continue-on-error, no removing the job, no [skip ci] to dodge the gate).
- Never weaken a test or assertion to make it green — fix the cause.
- Keep the user informed with a short summary per cycle; do not dump full logs unless asked.
- Respect the project's commit convention for every fix commit.
- One push per attempt; always watch the run you just triggered before deciding the next action.
