openmotion
CLAUDE.md10k starsChanged 3 days agoApache-2.0View on GitHub
Read and follow AGENTS.md before working in this repository. It is the shared source of instructions for all Agents. Branch new work from the latest main and target all pull requests at main. Merge reviewed changes directly into main when authorized; do not use feature/motion as an intermediate integration branch. Follow the mandatory shared design system rules for every style-related change. Read packages/design-system/README.md, reuse its tokens, styles and assets, and extend the package before adding a missing reusable visual role.…
In this repository8 other files it gives its agents.
- AGENTS.mdAGENTS.md
- add-byok-providerSkill
- openmotion-directorSkill
- openmotion-productionSkill
- openmotion-recreateSkill
- openmotion-reference-videoSkill
- openmotion-template-to-videoSkill
- openmotion-video-to-templateSkill
The file
We split this CLAUDE.md into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 3
Read and follow AGENTS.md before working in this repository.
- Distinctive: line 32
Follow MCP onboarding and capability maintenance.
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Claude Code
Read and follow AGENTS.md before working in this repository. It is the shared source of instructions for all Agents.
Branch workflow
Branch new work from the latest main and target all pull requests at main. Merge reviewed changes directly into main when authorized; do not use feature/motion as an intermediate integration branch.
Interface styling
Follow the mandatory shared design system rules for every style-related change. Read packages/design-system/README.md, reuse its tokens, styles and assets, and extend the package before adding a missing reusable visual role. Feature modules must reference this source rather than maintain independent palettes or copied styles. Apply the same rule when delegating or reviewing work; authored video and domain geometry retain their own styling boundary. For CI scope and local validation, follow Local validation, including the presentation-document allowlist and the full product-content gate.
Candidate and publication controls
Follow the release workflow manual: separate manual candidate-build and npm-publication entries, plus snapshot-only recovery. Select main for all entries; other execution refs are rejected for new release work. Select test (default, DEV templates) or stable (prod templates). Blank test versions use short workflow-counter test.N numbering; stable requires an explicit new MAJOR.MINOR.PATCH. Keep full run/source identities in the records. Use candidate-install.md for local testing and keep results private. The publication operator enters the exact version and starts the manual workflow; no acceptance checkbox or independent approval environment is enabled. Public candidates must use an exact reviewed source SHA integrated into main. Scan tracked source plus the outer npm tgz and inner application; preserve the positive distribution list and licenses. Keep candidate, native registry installation, real Agent creation and human acceptance evidence separate.
Publication uses the accepted candidate bytes, never a rebuild. Test publishes under candidate, promotes test after registry propagation, archives and updates the DEV guide, then runs non-blocking Mac/Windows cold installs. Stable publishes publicly under stage, requires both exact prod cold installs to pass, then promotes latest, archives and updates the stable guide last; it preserves test. A stage tag does not make the package private. The existing motion-publish-test.yml filename remains the npm Trusted Publisher identity for both channels. Only separately authorized manual publication/recovery may receive npm OIDC or R2 credentials; consumer jobs receive neither. Archive-only work must not publish npm, move tags or access default entries. The read-only Motion installation check can recheck an exact public test or stable version independently. Never overwrite published versions, put private template payloads/internal acceptance material into public artifacts, or infer merge/publication authorization from green CI. Real prod template, Agent and audiovisual acceptance remain release responsibilities; hosted installation checks do not establish them. Skills marketplace publication, main registration, npm trust, main cutover and repository rename remain separate operations.
UI design system and interaction feedback
Follow the shared UI rules and the design-system interaction contract. Transient operation results use useToast and StudioToastViewport on the floating feedback layer, including inside native dialogs; never insert success or failure notices into the content flow. Reuse semantic light/dark tokens, non-modal dropdowns (immediate quick filters; grouped draft selections with live counts and in-panel Apply), padded rounded hover states, one visible focus treatment, and shared loading/fallback geometry. Verify the actual opened states in the browser without shifting or blocking the working area.
Product documentation
Follow the README writing and acknowledgements rule for every README, alternative draft and translation. Keep the main narrative, headings and showcase copy focused on OpenMotion and what each example demonstrates. Put other-product comparisons, inspiration, source-product labels and upstream acknowledgements only in the final Acknowledgements section; do not use headings such as "From MotionGit". Preserve licenses and provenance, and keep required setup identifiers, supported agent/model names and explicitly requested example brand names accurate. Verify this placement before finishing README edits.
The design-system workbench is an independent package-owned editing surface. Keep it free of Studio and business-module imports; UI edits and Agent edits update the same design-system source. Run npm run design:dev to open it and npm run design:test for its save/conflict/independence checks.
MCP onboarding
Follow MCP onboarding and capability maintenance. Changes to local MCP, media generation, Agent adapters, templates or optional presentation must keep the Studio connection page, capability descriptions, setup instructions and compatibility boundaries current in the same change.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

