Dart Fix CI

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:

   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:

   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:

   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