Agent-Skills.md

Agent Skills: dart-mechanical-refactor

DART Mechanical Refactor: perform a behavior-preserving mechanical refactor

UncategorizedID: dartsim/dart/dart-mechanical-refactor

Repository

dartsim/dart
dartsimLicense: BSD-2-Clause
1,212304

Install this agent skill to your local

pnpm dlx add-skill https://github.com/dartsim/dart/tree/HEAD/.agents/skills/dart-mechanical-refactor

Skill Files

Browse the full folder contents for dart-mechanical-refactor.

Download Skill

Loading file tree…

.agents/skills/dart-mechanical-refactor/SKILL.md

Skill Metadata

Name
dart-mechanical-refactor
Description
"DART Mechanical Refactor: perform a behavior-preserving mechanical refactor"
<!-- AUTO-GENERATED FILE - DO NOT EDIT MANUALLY --> <!-- Source: .claude/commands/dart-mechanical-refactor.md --> <!-- Sync script: scripts/sync_ai_commands.py --> <!-- Run `pixi run sync-ai-commands` to update -->

dart-mechanical-refactor

Use this skill in Codex to run the DART dart-mechanical-refactor workflow. The editable workflow source currently lives in .claude/commands/, and this generated Codex skill is a first-class Codex entrypoint.

Invocation

  • Claude Code/OpenCode: /dart-mechanical-refactor <arguments>
  • Codex: $dart-mechanical-refactor <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

Perform mechanical refactor: $ARGUMENTS

Required Reading

@AGENTS.md @CONTRIBUTING.md @docs/onboarding/code-style.md

Workflow

  1. Define the exact transformation and scope before editing.
  2. Create a topic branch from the target branch, for example git switch --no-track -c refactor/<topic> origin/release-6.20.
  3. Prefer scriptable or automated edits when the transformation is repetitive.
  4. Keep behavior unchanged; do not mix in feature work or cleanup outside scope.
  5. If reorganizing files, update CMake, pixi tasks, generated indexes, and docs.
  6. Run focused checks first, then broader checks according to risk:
    • pixi run lint
    • pixi run build
    • pixi run test
    • pixi run test-all when feasible
    • pixi run -e gazebo test-gz when package, collision, constraint, or downstream Gazebo/gz-physics compatibility could be affected
  7. Ask for explicit maintainer/user approval before pushing or opening a PR. After approval, open a PR with a clear scope statement and no behavior-change claim unless tested.

Output

  • Transformation summary
  • Files or areas changed
  • Verification run
  • Any residual risk