DART is an open-source C++23 physics engine that simulates the movement and interactions of articulated rigid-body systems for robotics, animation, and machine learning. Researchers and developers use it for kinematics, dynamics, collision handling, constraints, and loading robot models, with C++ and Python interfaces. The catalogue add-ons support workflows built around this engine.
Borrowing it
Nothing to install: this file belongs to dartsim/dart. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/dartsim/dart/main/.claude/commands/dart-changelog.mdgit clone --depth 1 https://github.com/dartsim/dartWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/dartsim/dart/dart-changelog)<a href="https://agentmods.dev/commands/dartsim/dart/dart-changelog"><img src="https://agentmods.dev/badge/commands/dartsim/dart/dart-changelog/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/dartsim/dart/dart-changelog"><img src="https://agentmods.dev/badge/commands/dartsim/dart/dart-changelog.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00014 | $0.01482 |
| Opus 5 | $0.00007 | $0.00741 |
| Sonnet 5 | $0.00003 | $0.00296 |
| Haiku 4.5 | $0.00001 | $0.00148 |
Grade A, and why
dart-changelog scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 140 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Maintain DART changelog entries: $ARGUMENTS
Purpose
dart-changelog is the reusable changelog decision and writing routine. It is
usually invoked by other DART workflows when they reach a changelog decision,
not directly by users.
Use it to decide whether CHANGELOG.md needs an entry, draft an entry at the
right level of detail, add a PR link after publication, or audit a release
section for missing or over-detailed entries. Keep style, placement, evidence,
and release-note density aligned with docs/onboarding/changelog.md.
Required Reading
@AGENTS.md @docs/onboarding/changelog.md @docs/onboarding/release-roadmap.md @docs/onboarding/release-management.md
Modes
Interpret $ARGUMENTS as one of these modes when present:
decide: determine whether the current change needs a changelog entry and record the reason for the PR checklist/body when no entry is needed.draft: write or revise the entry before a PR number exists.finalize: add the PR link or adjust the entry after a PR exists, keeping the follow-up local until explicit maintainer/user approval permits a push.audit: scan a release section or PR set for missing, duplicate, over-detailed, misplaced, or stale entries.release-audit: alias forauditwhen the caller is finalizing a release section throughdart-release-packaging.
If no mode is given, infer the smallest mode that satisfies the caller's need.
Output Contract
Every run must leave the caller with a concise, pasteable decision note. Use this shape in the response or handoff text. The PR body/checklist needs only the relevant decision, no-entry reason, or unresolved follow-up, not this full note:
Changelog decision:
- Mode: decide | draft | finalize | audit | release-audit
- Base evidence: <base ref or PR/release inspected>
- Scope evidence: <diff, PR, issue, or release section inspected>
- Decision: entry required | no entry required | entry deferred | audit only
- Target section: <release/category, or N/A>
- Entry text: <final or draft bullet, or N/A>
- PR-body note: <exact no-entry reason or follow-up, or N/A>
- Follow-up: <PR link, maintainer approval, release audit, or none>
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago Changed 5f940ffc2fe0
- 7d ago First seen · 140 lines · 14 tokens per session scan A 516bc02c0e5a
dart-changelog is a command published in the GitHub repository dartsim/dart (1,204 stars, last pushed 2d ago), licensed BSD-2-Clause. It adds 14 tokens to every session and 1,482 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-01.
Other commands, from other repositories
land
Cadence-tick autonomous PR babysitter (CI-fix, resolve, converge, merge, close, release).
release-notes
Generate consistent, well-structured release notes from git history. Triggered on release tags following semver patterns (v..) to produce categorized changelog with breaking changes, features, fixes, and contributor attribution.
ship
Ship is the operational release-prep flow for a connected project repo.
release-plan
A release-planning command for a software change. It documents the release scope, rollback plan, gradual or full rollout, and monitoring before waiting for human approval.
release
Standalone SDK release command for the BUILD repo. Not a workspace phase — runs independently after any number of implement/redteam cycles. Handles PyPI publishing, documentation deployment, and CI management for the kailash Python SDK and its framework packages.
doc-changelog
Generation and maintenance of the project changelog.