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/OpenCode: /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 involving model/scene structure, physics behavior, or GUI output,
use dart-verify-sim to reproduce the claim with text and assessed visual
evidence. Document a visual exception when the relevant renderer is unavailable
or not applicable.

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:

   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:

   git fetch origin <RELEASE_BRANCH>
   git checkout -B fix/<issue>-<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:

   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