animaxxing-skills
AGENTS.md22 starsChanged 50 days agoMITView on GitHub
This repository contains Animaxxing skills in three families. Framework skills (gsap-<framework>) cover page transition and component lifecycle guidance for GSAP in specific frameworks; each sits above the official GSAP skills, which cover the GSAP API itself. Motion skills (the core animaxxing skill) supply reusable vanilla TypeScript and GSAP effects, technical requirements, and effect checks without prescribing a brand. Style skills (style-<name>) carry one art direction: design tokens, typography and layout grammar, and a curated selection and configuration of motion recipes.…
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,700 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository13 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- skills/llms.txtllms.txt
- animaxxingSkill
- animaxxing-webglSkill
- gsap-astroSkill
- gsap-nextjsSkill
- gsap-nuxtSkill
- gsap-react-routerSkill
- gsap-sveltekitSkill
- gsap-tanstack-routerSkill
- gsap-vanillaSkill
- style-animaxxingSkill
The file
We split this AGENTS.md into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 9
Skill directory name: must exactly match the name in that skill's frontmatter (e.g.
- Very specific: line 10
Do not vendor the official gsap-* skills here.
- Distinctive: line 25
Write descriptions in third person (e.g.
- Distinctive: line 28
Keep framework skills portable: no project-specific design, naming, or file layout.
- Distinctive: line 42
Every new or changed motion recipe builder ships with specs in the same session: visible behavior, touch or pointer filtering where it …
- Distinctive: line 46
Commit the skills change and its tests together in both repos.
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.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
Guidance for AI Agents Working in This Repo
This repository contains Animaxxing skills in three families. Framework skills (gsap-<framework>) cover page transition and component lifecycle guidance for GSAP in specific frameworks; each sits above the official GSAP skills, which cover the GSAP API itself. Motion skills (the core animaxxing skill) supply reusable vanilla TypeScript and GSAP effects, technical requirements, and effect checks without prescribing a brand. Style skills (style-<name>) carry one art direction: design tokens, typography and layout grammar, and a curated selection and configuration of motion recipes. The framework owns when effects run; motion owns their implementation; the style owns the look and selects the treatment. When editing or adding skills, follow these rules.
Repo structure
- skills/ — Each subdirectory is one skill. The CLI and agents discover skills by scanning
skills/for directories that containSKILL.md. - skills/llms.txt — Index of skills with summaries and trigger terms. Update it whenever a skill is added or its scope changes.
- Skill directory name must exactly match the
namein that skill's frontmatter (e.g.skills/gsap-nextjs/↔name: gsap-nextjs). - Do not vendor the official
gsap-*skills here. Reference them by name and tell users to install both repos.
SKILL.md requirements
- Frontmatter (YAML):
name(required): lowercase, hyphens only, max 64 chars, must match parent directory name.description(required): what the skill does, when to use it, and when not to. Include trigger terms so agents know when to apply it. Max 1024 chars.license(required here):MIT.metadata(optional): string-to-string map. Useshort-descriptionfor a one-line summary shown by agent UIs.
- Body: Markdown instructions. Keep under ~500 lines; put long reference material in
references/and link from SKILL.md so agents load only what they need. - agents/openai.yaml (optional): Codex display name, short description, and default prompt.
Conventions
- Every framework skill uses the same lifecycle: mount → initial state → intro → settled → outro → end state → unmount. Reuse the wording from
gsap-nextjs. Motion skills name that lifecycle as the framework skill's and map their builders onto its phases. Styles select the treatment for those phases without owning execution timing. - Write descriptions in third person (e.g. "Use when…" not "You can use when…").
- Be concise; do not restate the GSAP API or the framework's docs. Focus on how the framework's routing, rendering, and cleanup change what GSAP code must do.
- Gate advice on framework versions. Tell the agent to read the installed version and bundled docs before trusting memory.
- Keep framework skills portable: no project-specific design, naming, or file layout.
- Motion skills must be framework-free (vanilla TypeScript and GSAP; no React, Next.js, Vue, or Svelte constructs). They preserve existing fonts, colors, and layout. Express requirements as capabilities, such as a variable weight axis, and expose or document how to adapt example values. Do not require a style skill to use an effect.
- Style skills are the deliberate exception on design: their tokens, typography, layout, and motion selection are specific by design. Keep reusable effect code and technical text-stability guidance in motion skills. A static restyle must remain usable without a motion skill or GSAP; the full treatment composes the matching framework and motion skills.
- Neither motion nor style skills own lifecycle: no routing, mounting, cleanup timing, or navigation rules. Motion recipes expose builders and cleanup handles for the framework controller to call; styles select and configure them. Name the framework skill family as the lifecycle owner. Tailwind class strings need a plain-CSS equivalent.
- Cross-skill composition names the required installed skill and its references; do not assume independently installed skill folders are siblings. Keep each motion skill's recipe dependencies and technical references within that skill.
- Shared framework guidance lives in
shared/; runscripts/sync_initialization.pyto package it into eachgsap-*/references/. Keep framework-specific guidance local. - Core motion skill layout:
skills/animaxxing/SKILL.md,agents/openai.yaml,references/motion-vocabulary.md,text-stability.mdwhen relevant,verification.md, andreferences/recipes/*.md, one self-contained module per recipe with its lifecycle contract stated at the top. - Style skill layout:
skills/style-<name>/SKILL.md,agents/openai.yaml,references/tokens.md,typography-and-layout.md,motion-vocabulary.mdfor art direction and surface choices, andverification.mdfor design checks. - When adding a new skill: create
skills/<skill-name>/SKILL.md, then updateskills/llms.txtand the README "Skills" and "Structure" sections. For a framework skill, add a matching framework directory to the animaxxing-skills-test repository (starter, TASK.md, reference app, specs) so the skill can be verified. For a motion skill, add its recipes to the test repository'smotion/suite (see Testing below) and record its checks inreferences/verification.md. For a style skill, record how it is verified in itsreferences/verification.mdand point at the demo that exercises it until a style suite exists. Motion verification also checks reuse without the demo's branding.
Testing
Tests live in animaxxing-skills-test, checked out beside this repo as ../animaxxing-skills-test on branch main. Its motion/build.mjs reads recipes from ../animaxxing-skills unless SKILLS_REPO points elsewhere. Its CLAUDE.md holds the step-by-step checklist and test-writing tips.
- Every new or changed motion recipe builder ships with specs in the same session: visible behavior, touch or pointer filtering where it applies, reduced motion, and teardown that restores markup and inline styles exactly. A bug fix gets a spec that fails without it.
- A new recipe file also needs entries in
motion/build.mjs(RECIPES,ENTRIES,ENTRY_RECIPES), a fixture, and a spec. - Type-check and run only what changed with
MOTION_ONLY=<recipe> node motion/build.mjs, thennpx playwright test -c motion/playwright.config.ts <specs> --repeat-each=3. Finish with the fullpnpm test:motion. - Framework skill changes run that framework's suite, such as
pnpm test:nextjs. - Commit the skills change and its tests together in both repos; report which checks ran in a browser.
References
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.

