# Dart Fix CI

> DART Fix CI: debug and fix failing CI checks on any base branch

- Skill: `dartsim/dart-fix-ci` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dartsim/dart-fix-ci`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dartsim/dart-fix-ci/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dartsim (https://skillmd.com/u/dartsim)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dartsim/dart-fix-ci

---


<!-- AUTO-GENERATED FILE - DO NOT EDIT MANUALLY -->
<!-- Source: .claude/commands/dart-fix-ci.md -->
<!-- Sync script: scripts/sync_ai_commands.py -->
<!-- Run `pixi run sync-ai-commands` to update -->

# dart-fix-ci

Use this skill in Codex to run the DART `dart-fix-ci` workflow. The editable
workflow source lives in `.claude/commands/`; this file is its generated adapter
in the shared `.agents/skills/` catalog.

## Invocation

- Claude Code: `/dart-fix-ci <arguments>`
- Codex: `$dart-fix-ci <arguments>`

Treat the text after the skill name as `$ARGUMENTS`. When the workflow
references `$1`, `$2`, etc., map those to the positional values supplied by the
user.

## Command Body

Fix CI failure: $ARGUMENTS

## Required Reading

@AGENTS.md
@docs/onboarding/ci-cd.md
@docs/onboarding/release-management.md

## Workflow

For a failure that depends on 3D structure or behavior, use `dart-verify-sim`
to reproduce the claim with text and assessed visual evidence, or record why
the renderer is unavailable.

1. Identify the base branch. Default to `main`; use `base=<branch>` from
   `$ARGUMENTS` or the PR's own base when it is a `release-*` branch. For a
   `release-*` base, also read `docs/onboarding/release-management.md` and apply
   the release caveats called out below.
2. Identify failing checks: `gh pr checks <PR_NUMBER>` or `gh run view <RUN_ID>`.
3. Inspect the first real failure:
   ```bash
   gh run view <RUN_ID> --log-failed
   gh run view <RUN_ID> --job <JOB_ID> --log
   ```
4. If a job is still in progress, wait for logs instead of guessing.
5. Choose where to fix. Check whether an equivalent fix already exists on
   `main`. If continuing an existing PR, fetch and check out that PR branch
   instead of creating a new one. For a `release-*` base, branch from the
   release branch and prefer cherry-picking the proven `main` fix; keep any new
   fix release-scoped and minimal. Create a uniquely named branch. If the intended
   branch exists, inspect and resume it within the requested scope or choose a
   fresh name; do not reset it:
   ```bash
   git fetch origin <RELEASE_BRANCH>
   git switch --no-track -c fix/<unique-topic>-<release-branch> origin/<RELEASE_BRANCH>
   ```
6. Reproduce locally with the smallest relevant command:
   - formatting: `pixi run lint`
   - tests: `pixi run test`, `pixi run test-unit`, or another existing
     focused `pixi run ...` test task
   - coverage: add targeted tests for uncovered changed lines
7. Fix the root cause with minimal scope. Explain why the failure was not caught
   earlier and whether workflow coverage should change.
8. If the failure is infrastructure-only, ask for explicit maintainer/user
   approval before rerunning the failed job or running:
   ```bash
   gh run rerun <RUN_ID> --failed
   ```
9. Ask for explicit maintainer/user approval before pushing, CI re-triggers, or
   other GitHub mutations; after approval, push and watch CI until green. For a
   `release-*` base, use the current release milestone and the PR template when
   creating or updating the release-branch PR.

## Output

- Root cause
- Fix or rerun action
- Commands run
- PR URL, when a PR was created or updated
- Current CI status
- Prevention recommendation, if any