{"owner":"motiondivision","repo":"motion","hasSkills":true,"totalSkillsCount":57,"totalTokensCount":24274,"categories":["claude-rule","anthropic-skill","root-instruction","cursor-rule","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md",".agents/skills/improve/SKILL.md","AGENTS.md","packages/config/package.json",".cursorrules",".agents/skills/fix/SKILL.md","packages/framer-motion/LICENSE.md","packages/framer-motion/cypress.html.json","packages/config/tsconfig.json","packages/framer-motion/README.md","packages/framer-motion/cypress.json","packages/framer-motion/cypress.react-19.json","packages/framer-motion/cypress.rsc.json","packages/framer-motion/jest.config.json","packages/framer-motion/jest.config.ssr.json","packages/framer-motion/package.json","packages/framer-motion/tsconfig.json","packages/framer-motion/tsconfig.test.json","packages/motion-dom/LICENSE.md","packages/motion-dom/jest.config.json","packages/motion-dom/package.json","packages/motion-dom/tsconfig.json","packages/motion-dom/tsconfig.test.json","packages/motion-utils/LICENSE.md","packages/motion-utils/jest.config.json","packages/motion-utils/package.json","packages/motion-utils/tsconfig.json","packages/motion-utils/tsconfig.test.json","packages/motion/LICENSE.md","packages/motion/README.md","packages/motion/jest.config.json","packages/motion/package.json","packages/motion/tsconfig.json","packages/motion/tsconfig.test.json","packages/framer-motion/animate-view/package.json","packages/framer-motion/client/README.md","packages/framer-motion/client/package.json","packages/framer-motion/cypress/tsconfig.json","packages/framer-motion/debug/README.md","packages/framer-motion/debug/package.json","packages/framer-motion/dom/README.md","packages/framer-motion/dom/package.json","packages/framer-motion/m/package.json","packages/framer-motion/mini/package.json","packages/motion/debug/package.json","packages/motion/mini/package.json","packages/motion/react-animate-view/package.json","packages/motion/react-client/package.json","packages/motion/react-m/package.json","packages/motion/react/package.json",".agents/skills/improve/references/audit-playbook.md",".agents/skills/improve/references/closing-the-loop.md",".agents/skills/improve/references/plan-template.md","packages/framer-motion/cypress/fixtures/animate-layout-tests.json","packages/framer-motion/cypress/fixtures/appear-tests.json","packages/framer-motion/cypress/fixtures/projection-tests.json","packages/framer-motion/dom/mini/package.json"],"skills":{"CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Build & Development Commands\n\n```bash\n# Install dependencies (use make bootstrap for first-time setup)\nmake bootstrap\n\n# Build all packages (ALWAYS run from repo root, not from individual packages)\nyarn build # or: make build\n\n# Watch mode for development\nyarn watch # or: make watch\n\n# Run tests\nyarn test # Unit tests (Jest) for all packages, then type-checks src + tests\nyarn test-playwright # Playwright E2E tests\n\n# Run tests for a specific package\ncd packages/framer-motion && yarn test-client # Client-side Jest tests\ncd packages/framer-motion && yarn test-server # SSR Jest tests\n\n# Run E2E tests\nmake test-e2e # Runs all E2E tests (Next.js, HTML, React, React 19, Playwright)\nmake test-single # Run a single Cypress test (edit spec path in Makefile)\n```\n\n## Package Architecture\n\nThis is a Yarn workspaces monorepo managed by Turborepo and Lerna.\n\n### Core Packages (packages/)\n\n- **motion** - Main public package (`npm install motion`). Re-exports from framer-motion with cleaner entry points (`motion/react`, `motion/mini`)\n- **framer-motion** - Core implementation for React. Contains all animation logic, components, hooks, and features\n- **motion-dom** - DOM-specific animation utilities (animate, scroll, gestures, effects). Framework-agnostic\n- **motion-utils** - Shared utilities (easing, math helpers, error handling). No dependencies\n\n### Development Apps (dev/)\n\n- **dev/react** - React 18 development/test app (port 9990)\n- **dev/react-19** - React 19 development/test app (port 9991)\n- **dev/next** - Next.js development/test app (port 3000)\n- **dev/html** - Vanilla JS/HTML test pages (port 8000)\n\n### Package Dependency Flow\n\n```\nmotion-utils (base utilities)\n ↓\nmotion-dom (DOM animation engine)\n ↓\nframer-motion (React integration)\n ↓\nmotion (public API)\n```\n\n## Key Source Directories (packages/framer-motion/src/)\n\n- **animation/** - Animation system (animators, sequences, optimized-appear)\n- **components/** - React components (AnimatePresence, LayoutGroup, LazyMotion, Reorder)\n- **context/** - React contexts (MotionContext, PresenceContext, LayoutGroupContext)\n- **gestures/** - Gesture handling (drag, pan, tap, hover, focus)\n- **motion/** - Core motion component and feature system\n- **projection/** - Layout animation projection system (FLIP animations)\n- **render/** - Rendering pipeline (HTML, SVG, DOM utilities)\n- **value/** - Motion values and hooks (useMotionValue, useSpring, useScroll, useTransform)\n\n## Writing Tests\n\n**IMPORTANT: Always write tests for every bug fix AND every new feature.** Write a failing test FIRST before implementing, to ensure the issue is reproducible and the fix is verified.\n\n**\"Failing test\" means a test that reproduces the reported bug.** The test should assert the expected behavior and fail because of the bug — not because your planned code doesn't exist yet. A TypeScript compile error for an API you're about to add is not a failing test. Write the test against the existing codebase, see it fail for the right reason, then implement the fix.\n\n### Test types by feature\n\n- **Unit tests (Jest)**: Jest only transpiles TypeScript (no type-checking); test types are checked by `yarn typecheck` in each package (`tsc -p tsconfig.test.json`), which `yarn test` runs at the root. For pure logic, value transformations, utilities. Located in `__tests__/` directories alongside source. **JSDOM does not support WAAPI** (`Element.animate()`), so Jest tests only cover the JS animation fallback path.\n- **E2E tests (Cypress)**: For UI behavior that involves DOM rendering, scroll interactions, gesture handling, or WAAPI animations. Test specs in `packages/framer-motion/cypress/integration/`, test pages in `dev/react/src/tests/`.\n- **E2E tests (Playwright)**: For cross-browser testing and HTML/vanilla JS tests. Specs in `tests/`, test pages in `dev/html/public/playwright/`.\n\n### When to escalate from unit tests to Cypress\n\n**If a bug is reported with a reproduction but your unit test passes, do NOT conclude \"already works.\"** JSDOM lacks WAAPI, real layout, and real browser rendering. The bug is likely in the browser code path. You MUST:\n\n1. Create a Cypress E2E test that matches the reporter's reproduction as closely as possible.\n2. Verify the Cypress test fails before implementing a fix.\n3. If the bug involves `opacity`, `transform`, React.lazy/Suspense, scroll, layout animations, or any visual behavior — **start with Cypress**, skip the unit test entirely.\n\n### Creating Cypress E2E tests\n\n1. **Create a test page** in `dev/react/src/tests/.tsx` exporting a named `App` component. It's automatically available at `?test=`.\n2. **Create a spec** in `packages/framer-motion/cypress/integration/.ts`.\n3. **Verify WAAPI acceleration** using `element.getAnimations()` in Cypress callbacks — but **only for compositor properties** (opacity, transform). `getAnimations()` won't return WAAPI animations for non-compositor properties like height/width in Electron. Don't use it for those.\n\n### Cypress animation testing patterns\n\n- **Use `.then()`, not `.should()`, for mid-animation measurements.** `cy.should()` retries assertions until they pass or timeout — so it will keep retrying until the animation completes, masking bugs where the target value is wrong. `.then()` captures the value at a single point in time.\n- **For animation target bugs, use long duration + linear easing + mid-animation measurement.** Set `transition={{ type: \"tween\", ease: \"linear\", duration: 10 }}`, wait 5s (50% through), then check the computed style with `.then()`. If the target is wrong, the value will be proportionally wrong and easy to detect.\n- **Don't try `getAnimations()` for non-compositor properties** (height, width, etc.) in Cypress/Electron. It likely won't have WAAPI animations to inspect. Stick to computed style checks for these.\n- **Don't use `onUpdate` for mid-animation pixel values.** For keyword targets like `\"auto\"`, `onUpdate` reports the keyword, not the resolved pixel value. Use `getComputedStyle()` instead.\n- **Always run Cypress tests in the foreground.** Background bash commands hang silently and produce empty output, making debugging impossible. Cypress needs reliable stdout/stderr.\n\n### Running Cypress tests locally\n\n**You MUST run every new Cypress test against both React 18 and React 19 before creating a PR.** CI runs both and will break if you skip this.\n\n**Start the Vite dev server directly** — do NOT use `yarn start-server-and-test` with `yarn dev-server` (turbo). Turbo starts ALL dev servers including Next.js, which is slow and unreliable. Starting Vite directly is instant:\n\n```bash\n# React 18 — start Vite directly, then run Cypress\nPORT=$((10000 + RANDOM % 50000))\ncd dev/react && TEST_PORT=$PORT yarn vite --port $PORT &\nDEV_PID=$!\n# Wait for server to be ready\nnpx wait-on http://localhost:$PORT\ncd packages/framer-motion && cypress run --headed --config baseUrl=http://localhost:$PORT --spec cypress/integration/.ts\nkill $DEV_PID\n\n# React 19 — same pattern, start its Vite server independently\nPORT=$((10000 + RANDOM % 50000))\ncd dev/react-19 && TEST_PORT=$PORT yarn vite --port $PORT &\nDEV_PID=$!\nnpx wait-on http://localhost:$PORT\ncd packages/framer-motion && cypress run --config-file=cypress.react-19.json --config baseUrl=http://localhost:$PORT --headed --spec cypress/integration/.ts\nkill $DEV_PID\n```\n\n**Do NOT set `TEST_PORT` globally with turbo** — it affects both React 18 and 19 dev servers, causing port conflicts. Start each server independently on its own port as shown above.\n\nBoth must pass. If a test fails on one React version but not the other, investigate — do not skip it.\n\n### Async test helpers\n\nWhen waiting for the next frame in async tests:\n\n```javascript\nasync function nextFrame() {\n return new Promise((resolve) => {\n frame.postRender(() => resolve())\n })\n}\n```\n\n## Code Style\n\n- **Prioritise small file size** — this is a library shipped to end users. Prefer concise patterns that minimise output bytes.\n- Prefer optional chaining (`value?.jump()`) over explicit `if` statements\n- Use `interface` for type definitions\n- No default exports (use named exports)\n- Prefer arrow callbacks\n- Use strict equality (`===`)\n- No `var` declarations (use `const`/`let`)\n\n## Fixing Issues from Bug Reports\n\nWhen working on a bug fix from a GitHub issue:\n\n1. **Read the issue first.** Run `gh issue view ` before doing anything else. Do not infer the ask from code context or agent exploration — read the actual issue to understand what's being requested.\n2. **Check git history early.** Before tracing code, run `git log --grep=\"\" -- ` to see if the bug was already fixed or if prior commits reveal the root cause. This can save an entire session of manual code tracing.\n3. **The reporter's reproduction code is the basis for your test.** If the issue links to a CodeSandbox/StackBlitz, fetch it. Try multiple URL patterns if the first fails. If the issue has inline code, use that directly.\n4. **If you cannot get the reproduction code, STOP and ask for help.** Do not guess at what the reporter meant — that leads to tests that prove nothing. Message the team lead with the URL and ask them to provide the code.\n5. **Do not proceed to a fix without a test that fails for the right reason.** See the \"Writing Tests\" section above.\n6. **Run one clean install, then wait for it to finish.** Do not run `make bootstrap`, `yarn install`, or `corepack enable && yarn install` as overlapping background tasks — they interfere with each other. One install command, foreground, wait for completion.\n\n### Debugging strategy\n\n- **Get to a test fast.** Do not spend extended time on static code analysis trying to find the bug by reading code. Read enough to form an initial theory (~5 min of tracing), then write a test and start experimenting. Most bugs are found faster through testing than through code reading. This is the single most common mistake — it has caused excessive time waste in multiple sessions.\n- **Use targeted searches, not broad exploration.** Prefer `grep`/`glob` for specific functions (e.g. `isHTMLElement`, `supportsBrowserAnimation`) over large Explore agent calls. Two targeted searches beat one broad sweep.\n- **Pivot quickly when your theory is wrong.** If tracing a code path (e.g. the render pipeline) is inconclusive after 2-3 rounds of investigation, step back and look at adjacent systems — utility functions, type guards, environment checks. The bug is often one level removed from where you expect it.\n- **When a bug can't be reproduced in the test environment, stop after 2-3 attempts.** Electron/JSDOM differ from Chrome in significant ways (e.g. `offsetHeight` on SVGElement, WAAPI support, React reconciliation in dev mode). If your test passes from the start: (1) do a web search for the behavioral difference between environments, (2) if the fix is clearly correct and defensive, apply it and write a test that validates the desired behavior — do not spend 10 Cypress runs trying to force a local failure. A test that can't fail without the fix is acceptable when the bug is environment-specific; note this in the PR.\n- **Capture Cypress output on the first run.** Use `tail -60` on the output. Do not re-run Cypress with different grep patterns to capture errors — it wastes time and the information is in the first run.\n- **Think defensively, not forensically.** You don't always need to trace the exact scenario that produces bad input. If a function can receive invalid values and pass them to a browser API, the fix is to guard against that — regardless of which upstream path produces those values. Ask: \"should this value ever reach this API?\" If no, add the guard and move on.\n- **Choose the right test layer.** Some behaviors can't be directly asserted in tests (e.g. Chrome WAAPI console warnings can't be intercepted via `console.warn` spy). In these cases, unit-test the underlying logic (e.g. `canAnimate`, `isAnimatable`) rather than writing an E2E test that can't actually prove the bug is fixed. Write the E2E test too if it adds value, but recognize which test is the real regression gate.\n- **Avoid background task sprawl.** Do not launch multiple background exploration tasks early in a session. They complete after they're needed and generate noise. Launch tasks when you need their results, not speculatively.\n\n## Known GitHub CLI Issues\n\n`gh pr edit` fails on this repo due to GitHub's Projects Classic deprecation blocking the GraphQL mutation. **This is expected — do not investigate, retry, or work around it.** If `gh pr create` succeeded and the code is pushed, you're done. Move on.\n\n## Notes\n\nBe thorough - I am at risk of losing my job.\n\n## Timing\n\nUse `time.now()` from `motion-dom/src/frameloop/sync-time.ts` instead of `performance.now()` for frame-synced timestamps. This ensures consistent time measurements within synchronous contexts and proper sync with the animation frame loop.\n",".agents/skills/improve/SKILL.md":"---\nname: improve\ndescription: Survey any codebase as a senior advisor and produce prioritized, self-contained implementation plans for OTHER models/agents to execute. Strictly read-only on source code — never implements, fixes, or refactors anything itself. Use when asked to audit a codebase, find improvement opportunities (bugs, security, performance, test coverage, tech debt, migrations, DX), suggest features or where to take the project next (roadmap, product direction), or generate handoff plans for another agent to implement.\nlicense: MIT\nmetadata:\n author: shadcn\n version: \"1.0.0\"\n---\n\n# Improve\n\nYou are a **senior advisor, not an implementer**. Your job is to deeply understand a codebase, find the highest-value improvement opportunities, and write implementation plans good enough that a *different, less capable model with zero context from this session* can execute, test, and maintain them.\n\nThe economics of this skill: an expensive, high-ceiling model does the part where intelligence compounds (understanding, judging, specifying). Cheaper models do the execution. The plan is the product — its quality determines whether the executor succeeds.\n\n## Hard Rules\n\n1. **Never modify source code yourself.** No edits, no fixes, no \"quick wins while you're in there.\" The ONLY files you may create or modify live under `plans/` in the repo root (create it if absent). The `execute` variant dispatches a *separate executor subagent* that edits code in an isolated git worktree — you review its diff and render a verdict; you still never edit code directly, and you never merge, push, or commit to the user's branch.\n2. **Never run commands that mutate the user's working tree** — no installs, no builds that write artifacts outside standard ignored dirs, no git commits, no formatters. Read, search, and run read-only analysis only (e.g. `tsc --noEmit`, lint in check mode, `npm audit` / `pnpm audit`, test suite if cheap and side-effect free). Two scoped exceptions: verification commands inside an executor's disposable worktree during `execute` review, and `gh issue create` under an explicit `--issues` flag.\n3. **Every plan must be fully self-contained.** The executor has not seen this conversation, this codebase survey, or any other plan. If a plan references \"the pattern discussed above,\" it is broken.\n4. **Never reproduce secret values.** If the audit finds credentials, tokens, or `.env` contents, findings and plans reference the `file:line` and credential type only, and recommend rotation. The value itself must never appear in anything you write.\n5. **If the user asks you to implement directly, decline and point at the plan** — offer `execute ` (dispatched executor + your review) or plan refinement instead.\n\n## Workflow\n\n### Phase 1 — Recon (always)\n\nMap the territory before judging it:\n\n- Read `README`, `CLAUDE.md`/`AGENTS.md`, `CONTRIBUTING`, root config files (`package.json`, `pyproject.toml`, `go.mod`, etc.), CI config, and the directory structure.\n- Identify: language(s), framework(s), package manager, **how to build / test / lint / typecheck** (exact commands — these go into every plan as verification gates), test coverage shape, deployment target.\n- Note repo conventions: code style, naming, folder layout, error-handling and state-management patterns. Plans must tell the executor to *match* these, with examples.\n- Check git signal where useful (`git log --oneline -30`, churn hotspots) for what's actively evolving vs. frozen.\n\nIf the repo has no working verification command (no tests, broken build), record that — \"establish a verification baseline\" is often finding #1, and it must precede risky plans in the dependency order.\n\n### Phase 2 — Audit (parallel)\n\nAudit the codebase across the categories in [references/audit-playbook.md](references/audit-playbook.md) — read it now. Categories: **correctness/bugs, security, performance, test coverage, tech debt & architecture, dependencies & migrations, DX & tooling, docs, direction (features & what to build next)**.\n\nFor repos of any real size, fan out with parallel read-only subagents (in Claude Code: **Explore** agents) — one per category (or cluster of related categories). If the host agent can't spawn subagents, audit directly yourself in category-priority order. **Subagents do not inherit this skill's context**, so each subagent prompt must include:\n\n- the **absolute path** to this skill's `references/audit-playbook.md` plus the exact section headings to read — **always including \"## Finding format\"** (subagents can read files — this is far cheaper than pasting; paste the sections only if the path may not resolve in the subagent's environment),\n- the recon facts that scope the search (languages, frameworks, key directories, what to skip),\n- domain-specific risk hints from recon (e.g. for a CLI that writes user files: \"pay attention to path traversal and command injection\"),\n- an explicit instruction to return findings only — no fixes, no file dumps — and to confirm it could read the playbook file.\n\nAudit depth follows the **effort level** (default `standard`; the user sets it with a `quick` / `deep` keyword anywhere in the invocation):\n\n| | `quick` | `standard` (default) | `deep` |\n|---|---|---|---|\n| Coverage | Recon hotspots only — highest-churn, highest-criticality code | Hotspot-weighted, key packages | Whole repo, every package |\n| Subagents | 0–1 (sweep directly when feasible) | ≤4 concurrent | ≤8 concurrent, one per category |\n| Breadth | \"medium\" | \"very thorough\" for correctness + security, \"medium\" rest | \"very thorough\" everywhere |\n| Categories | correctness, security, tests | all nine | all nine |\n| Findings | top ~6, HIGH-confidence only | full table | full table incl. LOW-confidence \"investigate\" items |\n\nWhatever the level, say in the final report what was *not* audited. On a large monorepo even `deep` scopes subagents to packages, not the root.\n\nEvery finding needs: evidence (`file:line` references), impact, effort estimate (S/M/L), risk of the fix itself, and confidence. No vibes-only findings.\n\n### Phase 3 — Vet, prioritize, confirm\n\n**Vet before presenting — subagents over-report.** For every finding that will make the table, open the cited code yourself and confirm it. Expect three failure classes: **by-design behavior** reported as a bug or vulnerability (e.g. honoring `https_proxy` flagged as SSRF — it's the standard proxy convention); **mis-attributed evidence** (real finding, wrong file or line); and duplicates across subagents. Downgrade, correct, or reject accordingly, and record rejections in the index's \"considered and rejected\" section so they aren't re-audited next run.\n\nPresent the vetted findings table to the user, ordered by leverage (impact ÷ effort, weighted by confidence):\n\n| # | Finding | Category | Impact | Effort | Risk | Evidence |\n\nPresent **direction findings separately**, after the table — they're options for the maintainer to weigh, not problems ranked against bugs, and burying \"build a plugin system\" under \"fix the N+1\" serves neither. 2–4 grounded suggestions max, each with its evidence and trade-offs in two or three sentences.\n\nThen ask which findings to turn into plans (default suggestion: the top 3–5 plus anything they flag). Also surface **dependency ordering** — e.g. \"characterization tests for module X (plan 02) must land before the refactor of X (plan 05).\"\n\nWait for the selection. Do not write 30 plans nobody asked for. If running non-interactively (no user available to choose), write plans for the top 3–5 by leverage and record that default in `plans/README.md`.\n\n### Phase 4 — Write the plans\n\nFor each selected finding, write one plan file using the template in [references/plan-template.md](references/plan-template.md) — read it before writing the first plan. Plans go in:\n\n```\nplans/\n README.md ← index: priority order, dependency graph, status table\n 001-.md\n 002-.md\n```\n\n**Excerpts come from your own reads, never from a subagent's report.** Before writing each plan, open every cited file yourself — subagent line numbers and attributions are leads, not facts, and a wrong excerpt becomes a wrong plan that fails its own drift check.\n\nBefore writing anything: record `git rev-parse --short HEAD` — every plan stamps the commit it was written against (the executor uses it for drift detection). If `plans/` already exists from a previous run, **reconcile, don't duplicate**: read `plans/README.md`, keep numbering monotonic, skip findings already planned or listed as rejected, and mark superseded plans stale in the index. If `plans/` exists for some unrelated purpose, use `advisor-plans/` instead and say so.\n\nWrite each plan **for the weakest plausible executor**. That means:\n\n- All context inlined: why this matters, exact file paths, current-state code excerpts, the repo's conventions to follow (with a snippet of an existing exemplar file).\n- Steps that are explicit and ordered, each with its own verification command and expected output.\n- Hard boundaries: files in scope, files explicitly out of scope, things that look related but must not be touched.\n- Machine-checkable done criteria — commands and expected results, not prose like \"works correctly.\"\n- A test plan (what new tests to write, where, following which existing test as a pattern).\n- A maintenance note (what future changes will interact with this, what to watch in review).\n- Escape hatches: \"if X turns out to be true, STOP and report back instead of improvising.\"\n\nFinish by writing `plans/README.md` with the recommended execution order, dependencies between plans, and a status column the executor models can update.\n\n## Invocation variants\n\n- Bare invocation → full workflow above.\n- `quick` / `deep` (anywhere in the invocation) → effort level for the audit; see the table in Phase 2. Composes with everything: `quick security`, `deep --issues`. Default is `standard`.\n- With a focus argument (e.g. `security`, `perf`, `tests`) → run Recon, then audit only that category, then plan.\n- `branch` → audit only the current working branch's changes: scope = files changed since the merge-base with the default branch (`git diff --name-only $(git merge-base origin/ HEAD)..HEAD`) plus their direct importers/callers. Light recon, all categories, usually no subagents. **Tag every finding `introduced` (by this branch) or `pre-existing` (in touched files)** — the table separates them; don't blame the branch for legacy debt, but do surface what it's building on top of. If on the default branch or zero commits ahead, say so and offer a full audit instead.\n- `next` (or `features`, `roadmap`) → run Recon, then audit only the direction category, in more depth: 4–6 grounded suggestions, each with evidence, trade-offs, and a coarse effort estimate. Selected ones become design/spike plans, not build-everything plans.\n- `plan ` → skip the audit; the user already knows what they want. Run Recon, investigate just enough to specify it properly, and write a single plan. If the description is too ambiguous to specify honestly, first try to resolve each ambiguity from the codebase itself; only what's left becomes questions to the user — asked one at a time, each with a recommended answer.\n- `review-plan ` → critique an existing plan in `plans/` against the template's standards and tighten it. If you authored the plan in this same session, also have a fresh-context subagent read it cold and report ambiguities — self-critique misses gaps you mentally fill from context the executor won't have.\n- `execute ` → dispatch a cheaper executor subagent on one plan (isolated worktree), then review its diff like a tech lead — re-run done criteria, check scope, read the code — and render a verdict. Requires a host agent that can spawn subagents in an isolated worktree; if yours can't, say so and hand the plan over for manual execution instead. **Read [references/closing-the-loop.md](references/closing-the-loop.md) before the first dispatch.**\n- `reconcile` → process what happened since last session: verify DONE plans, investigate BLOCKED ones, refresh drifted TODOs, retire dead findings. See [references/closing-the-loop.md](references/closing-the-loop.md).\n- `--issues` (modifier on any planning invocation) → also publish each written plan as a GitHub issue via `gh`, URL recorded in the plan and index. Only with the explicit flag. See [references/closing-the-loop.md](references/closing-the-loop.md).\n\n## Tone of the output\n\nYou are advising, not selling. State findings plainly with evidence, flag uncertainty honestly, and prefer \"not worth doing\" verdicts over padding the list. A short list of high-confidence, high-leverage plans beats a long one.\n","AGENTS.md":"## Structure\n\nThis is a monorepo. Development and test environments live in `/dev`, packages live in `/packages`.\n\nPackages are:\n\n- `framer-motion`: For React-specific code. More of this should be refactored to `motion-dom` where possible.\n- `motion`: Re-export of `framer-motion`.\n- `motion-dom`: Vanilla/JS animation library.\n- `motion-utils`: Pure functions and easing functions.\n\n## Tests\n\nThere are three types of test suites in Motion.\n\n1. Jest (unit) tests\n2. Cypress e2e tests\n3. Playwright e2e tests\n\n### Jest\n\nStructure code to be unit testable where possible. Co-locate a unit test in a `__tests__` folder. Name the unit tests for a file `.test.ts(x)`.\n\nRun with `yarn test`.\n\n### Cypress\n\nThe Cypress test suite is for testing React code in a browser environment.\n\nWhen a piece of UI is interactable, or we rely on browser APIs, write a Cypress test. The UI files should live in `dev/react/src/tests` and the test files to run against them live in `packages/framer-motion/cypress/integration`.\n\nRun with `yarn test-e2e`.\n\n### Playwright\n\nThe Cypress test suite is for testing vanilla JS code in a browser environment.\n\nThe UI files live in `dev/html/public/playwright` and the test files live in `/tests`.\n\nRun with `yarn test-playwright`.\n","packages/config/package.json":"{\n \"name\": \"config\",\n \"version\": \"14.0.0\",\n \"main\": \"index.js\",\n \"private\": true,\n \"license\": \"MIT\",\n \"files\": [\n \"tsconfig.json\"\n ]\n}\n",".cursorrules":"## Writing tests\n\n- When waiting for the next frame, use an `async` test and await like so:\n\n```javascript\nasync function nextFrame() {\n return new Promise((resolve) => {\n frame.postRender(() => resolve())\n })\n}\n```",".agents/skills/fix/SKILL.md":"---\nname: fix\ndescription: Take a GitHub issue, an open PR, or a plan file from plans/ and drive it to a merge-ready PR — reproduce with a failing test first, implement the fix (bugs) or feature (plans), verify against the repo's gates, and open or update the PR. Use when asked to fix an issue, implement or execute a plan, finish or land an open PR, or work through plans/issues/.\nmetadata:\n author: mattgperry\n version: \"1.0.0\"\n---\n\n# Fix\n\nYou are the **executor**. A more expensive planning model has already done the thinking; your job is to implement exactly what was specified, prove it works, and ship a PR. You have zero context from the planning session — everything you need is in the plan file, the GitHub issue/PR, and this repo's `CLAUDE.md`. Read all three before writing any code.\n\n## Resolving the input\n\nThe argument can be:\n\n1. **A plan file path** (e.g. `plans/issues/pr-3724.md` or `plans/001-animate-layout-public-api.md`) — read it in full. Plans are the primary input for this skill.\n2. **A plan number** (e.g. `008`) — find the matching file in `plans/` or `plans/issues/`.\n3. **A GitHub issue number** (e.g. `#3741`) — run `gh issue view ` first. Check whether a plan for it already exists in `plans/issues/` (grep for the number); if so, the plan governs.\n4. **A PR number** — run `gh pr view ` and `gh pr checks `. Check `plans/issues/` for a plan covering that PR; if so, the plan governs.\n\nIf the argument is ambiguous or matches nothing, list what you found and stop — do not guess which work item was meant.\n\n## Hard rules\n\n1. **The plan is the spec.** Do not redesign, expand scope, or \"improve while you're in there.\" If the plan is wrong or impossible as written, stop and report why — do not silently substitute your own approach.\n2. **Honor the plan's STOP conditions.** If a plan says stop when X happens, stop when X happens, even if you think you can push through.\n3. **No repro → no fix.** If you cannot write a test that fails because of the bug, do not land a speculative fix with happy-path tests. Report \"needs repro\" instead. (A test that fails only because your new API doesn't exist yet is not a failing test.)\n4. **Never commit to `main`.** Branch first (`/`, e.g. `fix/3741-turbopack-reexport`). One work item per branch per PR.\n5. **Report faithfully.** If tests fail, say so with output. If you skipped a verification gate, say which and why. Never describe unverified work as done.\n\n## Workflow\n\n### Phase 0 — Understand\n\n- Read the plan file end to end, including its verification gates and STOP conditions.\n- Read the linked issue/PR with `gh issue view` / `gh pr view --comments`. The reporter's reproduction is the basis for your test — fetch any linked CodeSandbox/StackBlitz. If you cannot obtain the repro and the plan doesn't contain one, stop and ask (rule 3).\n- Run `git log --grep=\"\" --oneline -- ` — the bug may already be fixed, or prior commits may reveal the root cause.\n- Read `CLAUDE.md` sections \"Writing Tests\", \"Fixing Issues from Bug Reports\", and \"Code Style\". Those rules apply in full and are not repeated here.\n\n### Phase 1 — Failing test first\n\n- Write the test **before** the implementation and watch it fail *for the right reason* (the bug / missing behavior — not a typo or missing import).\n- Choose the layer per `CLAUDE.md`: Jest for pure logic; Cypress for anything involving opacity, transform, scroll, layout animations, WAAPI, or visual behavior (JSDOM has no WAAPI — a passing Jest test does not mean \"already works\").\n- For features, the failing test asserts the new behavior described in the plan's acceptance criteria.\n\n### Phase 2 — Implement\n\n- Smallest change that makes the test pass while matching surrounding code style. This library ships to end users — prioritise small output size.\n- Build from the repo root (`yarn build`), never from inside a package.\n- If the plan specifies files and approach, follow them. Deviations must be listed explicitly in the PR description with one-line justifications.\n\n### Phase 3 — Verify\n\nRun every gate the plan names. Defaults when the plan doesn't say:\n\n- `yarn build` from root, then the relevant Jest suite(s).\n- New/changed Cypress tests against **both** React 18 and React 19, using the direct-Vite recipe in `CLAUDE.md` (never `start-server-and-test` + turbo). Both must pass; a version-specific failure is a finding to investigate, not skip.\n- `yarn lint` on touched packages.\n- Ignore only the pre-existing known failures listed in `CLAUDE.md`/memory (SSR TextEncoder, use-velocity).\n\n### Phase 4 — Ship & bookkeeping\n\n- Commit with a message that references the issue/plan (`Fix #3741: …`). Push and open a PR with `gh pr create`, linking the issue (`Fixes #`) and summarising: root cause, approach, tests added, gates run with results, deviations from the plan.\n- **Do not use `gh pr edit`** — it is known-broken on this repo (Projects Classic deprecation). If `gh pr create` succeeded, you are done; do not retry or work around edit failures.\n- Update the plan's status: set its row in the relevant `plans/**/README.md` table (TODO → DONE, or BLOCKED with a one-line reason) and append a short \"Execution notes\" section to the plan file itself: what was done, PR number, anything the plan got wrong.\n\n### When working on an existing open PR\n\nThe work item may be \"finish PR #N\" rather than \"fix issue #N\". Then:\n\n- `gh pr checkout `; rebase on `main` if behind, resolving conflicts conservatively (prefer `main`'s version for code the PR doesn't deliberately change).\n- `gh pr checks ` and read failing CI logs before touching code — the plan should say what's blocking; verify it still is.\n- Address review comments listed in the plan. Push to the same branch. Never force-push over commits you didn't write without checking the diff you'd destroy.\n\n## STOP conditions (always, in addition to the plan's own)\n\n- The failing test won't fail (can't reproduce) after 2–3 honest attempts → report \"needs repro\" with what you tried.\n- The plan's approach conflicts with code that changed since the plan was written → report the conflict; do not improvise a new design.\n- A verification gate fails and the fix isn't obvious within a few attempts → report the failure output.\n- The change would touch `packages/framer-motion/src/projection/` or the effects/VisualElement system in ways the plan didn't anticipate → stop; these systems have in-flight rewrites.\n","packages/framer-motion/LICENSE.md":"The MIT License (MIT)\n\nCopyright (c) 2018 Framer B.V.\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n","packages/framer-motion/cypress.html.json":"{\n \"baseUrl\": \"http://localhost:8000\",\n \"integrationFolder\": \"cypress/integration-html\",\n \"video\": true,\n \"screenshots\": false,\n \"retries\": 2,\n \"reporter\": \"junit\",\n \"reporterOptions\": {\n \"mochaFile\": \"../../test_reports/framer-motion-html.xml\"\n }\n}\n","packages/config/tsconfig.json":"{\n \"compilerOptions\": {\n \"target\": \"es2020\",\n \"module\": \"esnext\",\n \"moduleResolution\": \"bundler\",\n \"isolatedModules\": false,\n \"importHelpers\": true,\n \"jsx\": \"react-jsx\",\n \"esModuleInterop\": true,\n \"experimentalDecorators\": true,\n \"emitDecoratorMetadata\": true,\n \"declaration\": true,\n \"declarationDir\": \"types\",\n \"noLib\": false,\n \"preserveConstEnums\": true,\n \"sourceMap\": true,\n \"strictNullChecks\": true,\n \"noImplicitAny\": true,\n \"noImplicitThis\": true,\n \"noImplicitUseStrict\": false,\n \"noUnusedLocals\": true,\n \"noUnusedParameters\": true,\n \"removeComments\": false,\n \"lib\": [\"es2017\", \"dom\"],\n \"skipLibCheck\": true,\n \"downlevelIteration\": true,\n \"stripInternal\": true\n },\n \"compileOnSave\": false,\n \"buildOnSave\": false\n}\n","packages/framer-motion/README.md":"

\"Motion
Motion for React

\n

\n An open source animation library
for React\n

\n\n

\n \"npm\n \"npm\n \"jsDelivr\n \"NPM\n \"MotionScore\n

\n\n```bash\nnpm install motion\n```\n\n## Table of Contents\n\n1. [Why Motion?](#why-motion)\n2. [🍦 Platforms](#-platforms)\n3. [🎓 Examples](#-examples)\n4. [🎨 Motion Studio](#-motion-studio)\n4. [🤖 Using Motion with AI](#-using-motion-with-ai)\n5. [⚡️ Motion+](#-motion)\n6. [👩🏻‍⚖️ License](#-license)\n7. [💎 Contribute](#-contribute)\n8. [✨ Sponsors](#-sponsors)\n\n## Why Motion?\n\n- **Simple API:** First-class React, JavaScript, and Vue packages.\n- **Hybrid engine:** Power of JavaScript combined with native browser APIs for 120fps, GPU-accelerated animations.\n- **Production-ready:** TypeScript, extensive test suite, tree-shakable, tiny footprint.\n **Batteries included:** Gestures, springs, layout transitions, scroll-linked effects, timelines.\n\n## 🍦 Platforms\n\nMotion is available for [React](https://motion.dev/docs/react), [JavaScript](https://motion.dev/docs/quick-start) and [Vue](https://motion.dev/docs/vue).\n\n### React\n\n```jsx\nimport { motion } from \"motion/react\"\n\nfunction Component() {\n return \n}\n```\n\nGet started with [Motion for React](https://motion.dev/docs/react).\n\n**Note:** Framer Motion is now Motion. Import from `motion/react` instead of `framer-motion`.\n\n### JS\n\n```javascript\nimport { animate } from \"motion\"\n\nanimate(\"#box\", { x: 100 })\n```\n\nGet started with [JavaScript](https://motion.dev/docs/quick-start).\n\n### Vue\n\n```html\n\n\n\n```\n\nGet started with [Motion for Vue](https://motion.dev/docs/vue).\n\n## 🎓 Examples & tutorials\n\nBrowse 450+ [official examples](https://motion.dev/examples), with copy-paste code that'll level-up your animations whether you're a beginner or an expert.\n\nOver 110 examples come with a full step-by-step tutorial on [their example page](https://motion.dev/examples).\n\n## 🤖 Using Motion with AI\n\nGive your coding agent current Motion docs:\n\n- **Agent skill:** `npx motion-ai` installs the free, MIT-licensed `/motion` skill and sets up Motion's MCP servers for Claude Code, Cursor, Amp, OpenCode, Gemini CLI and Copilot. [Source on GitHub](https://github.com/motiondivision/ai-kit).\n- **MCP server:** `https://mcp.motion.dev` searches the Motion docs and example metadata. It is free and needs no account.\n- **llms.txt:** [motion.dev/llms.txt](https://motion.dev/llms.txt?utm_source=npm-readme) indexes every docs page. Motion+ pages are labelled as paid, with their install and import.\n\n[Motion+](https://motion.dev/plus?utm_source=npm-readme) adds example and Motion UI source, MotionScore performance audits and CSS spring generation for your agent.\n\n## 🎨 Motion Studio\n\nA visual animation editor for your website. Edit keyframes, easing curves and springs on a live timeline, or describe changes to the Ultramotion agent, then apply the result straight to your code with Cursor, Codex or Claude.\n\n[Explore Motion Studio](https://motion.dev/studio)\n\n## ⚡️ Motion+\n\nA one-time Personal licence with lifetime updates, or an annual per-seat Business plan for teams:\n\n- **450+ examples**\n- **110+ tutorials**\n- **Premium APIs** like [Cursor](https://motion.dev/docs/cursor) and [Ticker](https://motion.dev/docs/react-ticker)\n- **Transition editor** for Cursor and VS Code\n- **AI Kit:** example and Motion UI source, MotionScore audits and CSS springs for your agent\n- **Private Discord**\n- **Early access content**\n\n[Get Motion+](https://motion.dev/plus)\n\n## 👩🏻‍⚖️ License\n\n- Motion is MIT licensed.\n\n## 💎 Contribute\n\n- Want to contribute to Motion? Our [contributing guide](https://github.com/motiondivision/motion/blob/master/CONTRIBUTING.md) has you covered.\n\n## ✨ Sponsors\n\nMotion is sustainable thanks to the kind support of its sponsors.\n\n[Become a sponsor](https://motion.dev/sponsor)\n\n### Partners\n\nMotion powers the animations for all websites built with Framer, the web builder for creative pros. The Motion website itself is built on Framer, for its delightful canvas-based editing and powerful CMS features.\n\n\n \"Framer\"\n\n\nMotion drives the animations on the Cursor homepage, and is working with Cursor to bring powerful AI workflows to the Motion examples and docs.\n\n\n \"Cursor\"\n\n\n### Platinum\n\n\"Linear\" \"Figma\" \"Sanity\" \"Clerk\"\n\n### Gold\n\n### Silver\n\n\"Liveblocks\" \"Frontend.fyi\" \"Firecrawl\" \"Bolt.new\"\n\n### Personal\n\n- [OlegWock](https://sinja.io)\n- [Lambert Weller](https://github.com/l-mbert)\n- [Jake LeBoeuf](https://jklb.wf)\n","packages/framer-motion/cypress.json":"{\n \"baseUrl\": \"http://localhost:9990\",\n \"experimentalShadowDomSupport\": true,\n \"video\": true,\n \"screenshots\": false,\n \"retries\": 2,\n \"reporter\": \"junit\",\n \"reporterOptions\": {\n \"mochaFile\": \"../../test_reports/framer-motion-[hash].xml\"\n }\n}\n","packages/framer-motion/cypress.react-19.json":"{\n \"baseUrl\": \"http://localhost:9991\",\n \"video\": true,\n \"screenshots\": false,\n \"retries\": 2,\n \"experimentalShadowDomSupport\": true,\n \"reporter\": \"junit\",\n \"reporterOptions\": {\n \"mochaFile\": \"../../test_reports/framer-motion-react-19-[hash].xml\"\n }\n}\n","packages/framer-motion/cypress.rsc.json":"# Framer-motion Skill\n\nPath: `packages/framer-motion/cypress.rsc.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress.rsc.json)","packages/framer-motion/jest.config.json":"# Framer-motion Skill\n\nPath: `packages/framer-motion/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/jest.config.json)","packages/framer-motion/jest.config.ssr.json":"# Framer-motion Skill\n\nPath: `packages/framer-motion/jest.config.ssr.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/jest.config.ssr.json)","packages/framer-motion/package.json":"# Framer-motion Skill\n\nPath: `packages/framer-motion/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/package.json)","packages/framer-motion/tsconfig.json":"# Framer-motion Skill\n\nPath: `packages/framer-motion/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/tsconfig.json)","packages/framer-motion/tsconfig.test.json":"# Framer-motion Skill\n\nPath: `packages/framer-motion/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/tsconfig.test.json)","packages/motion-dom/LICENSE.md":"# Motion-dom Skill\n\nPath: `packages/motion-dom/LICENSE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/LICENSE.md)","packages/motion-dom/jest.config.json":"# Motion-dom Skill\n\nPath: `packages/motion-dom/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/jest.config.json)","packages/motion-dom/package.json":"# Motion-dom Skill\n\nPath: `packages/motion-dom/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/package.json)","packages/motion-dom/tsconfig.json":"# Motion-dom Skill\n\nPath: `packages/motion-dom/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/tsconfig.json)","packages/motion-dom/tsconfig.test.json":"# Motion-dom Skill\n\nPath: `packages/motion-dom/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/tsconfig.test.json)","packages/motion-utils/LICENSE.md":"# Motion-utils Skill\n\nPath: `packages/motion-utils/LICENSE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/LICENSE.md)","packages/motion-utils/jest.config.json":"# Motion-utils Skill\n\nPath: `packages/motion-utils/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/jest.config.json)","packages/motion-utils/package.json":"# Motion-utils Skill\n\nPath: `packages/motion-utils/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/package.json)","packages/motion-utils/tsconfig.json":"# Motion-utils Skill\n\nPath: `packages/motion-utils/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/tsconfig.json)","packages/motion-utils/tsconfig.test.json":"# Motion-utils Skill\n\nPath: `packages/motion-utils/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/tsconfig.test.json)","packages/motion/LICENSE.md":"# Motion Skill\n\nPath: `packages/motion/LICENSE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/LICENSE.md)","packages/motion/README.md":"# motion Documentation\n\nPath: `packages/motion/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/README.md)","packages/motion/jest.config.json":"# Motion Skill\n\nPath: `packages/motion/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/jest.config.json)","packages/motion/package.json":"# Motion Skill\n\nPath: `packages/motion/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/package.json)","packages/motion/tsconfig.json":"# Motion Skill\n\nPath: `packages/motion/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/tsconfig.json)","packages/motion/tsconfig.test.json":"# Motion Skill\n\nPath: `packages/motion/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/tsconfig.test.json)","packages/framer-motion/animate-view/package.json":"# Animate-view Skill\n\nPath: `packages/framer-motion/animate-view/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/animate-view/package.json)","packages/framer-motion/client/README.md":"# client Documentation\n\nPath: `packages/framer-motion/client/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/client/README.md)","packages/framer-motion/client/package.json":"# Client Skill\n\nPath: `packages/framer-motion/client/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/client/package.json)","packages/framer-motion/cypress/tsconfig.json":"# Cypress Skill\n\nPath: `packages/framer-motion/cypress/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/tsconfig.json)","packages/framer-motion/debug/README.md":"# debug Documentation\n\nPath: `packages/framer-motion/debug/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/debug/README.md)","packages/framer-motion/debug/package.json":"# Debug Skill\n\nPath: `packages/framer-motion/debug/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/debug/package.json)","packages/framer-motion/dom/README.md":"# dom Documentation\n\nPath: `packages/framer-motion/dom/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/README.md)","packages/framer-motion/dom/package.json":"# Dom Skill\n\nPath: `packages/framer-motion/dom/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/package.json)","packages/framer-motion/m/package.json":"# M Skill\n\nPath: `packages/framer-motion/m/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/m/package.json)","packages/framer-motion/mini/package.json":"# Mini Skill\n\nPath: `packages/framer-motion/mini/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/mini/package.json)","packages/motion/debug/package.json":"# Debug Skill\n\nPath: `packages/motion/debug/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/debug/package.json)","packages/motion/mini/package.json":"# Mini Skill\n\nPath: `packages/motion/mini/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/mini/package.json)","packages/motion/react-animate-view/package.json":"# React-animate-view Skill\n\nPath: `packages/motion/react-animate-view/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react-animate-view/package.json)","packages/motion/react-client/package.json":"# React-client Skill\n\nPath: `packages/motion/react-client/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react-client/package.json)","packages/motion/react-m/package.json":"# React-m Skill\n\nPath: `packages/motion/react-m/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react-m/package.json)","packages/motion/react/package.json":"# React Skill\n\nPath: `packages/motion/react/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react/package.json)",".agents/skills/improve/references/audit-playbook.md":"# References Skill\n\nPath: `.agents/skills/improve/references/audit-playbook.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/audit-playbook.md)",".agents/skills/improve/references/closing-the-loop.md":"# References Skill\n\nPath: `.agents/skills/improve/references/closing-the-loop.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/closing-the-loop.md)",".agents/skills/improve/references/plan-template.md":"# References Skill\n\nPath: `.agents/skills/improve/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/plan-template.md)","packages/framer-motion/cypress/fixtures/animate-layout-tests.json":"# Fixtures Skill\n\nPath: `packages/framer-motion/cypress/fixtures/animate-layout-tests.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/animate-layout-tests.json)","packages/framer-motion/cypress/fixtures/appear-tests.json":"# Fixtures Skill\n\nPath: `packages/framer-motion/cypress/fixtures/appear-tests.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/appear-tests.json)","packages/framer-motion/cypress/fixtures/projection-tests.json":"# Fixtures Skill\n\nPath: `packages/framer-motion/cypress/fixtures/projection-tests.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/projection-tests.json)","packages/framer-motion/dom/mini/package.json":"# Mini Skill\n\nPath: `packages/framer-motion/dom/mini/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/mini/package.json)"},"files":{"CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Build & Development Commands\n\n```bash\n# Install dependencies (use make bootstrap for first-time setup)\nmake bootstrap\n\n# Build all packages (ALWAYS run from repo root, not from individual packages)\nyarn build # or: make build\n\n# Watch mode for development\nyarn watch # or: make watch\n\n# Run tests\nyarn test # Unit tests (Jest) for all packages, then type-checks src + tests\nyarn test-playwright # Playwright E2E tests\n\n# Run tests for a specific package\ncd packages/framer-motion && yarn test-client # Client-side Jest tests\ncd packages/framer-motion && yarn test-server # SSR Jest tests\n\n# Run E2E tests\nmake test-e2e # Runs all E2E tests (Next.js, HTML, React, React 19, Playwright)\nmake test-single # Run a single Cypress test (edit spec path in Makefile)\n```\n\n## Package Architecture\n\nThis is a Yarn workspaces monorepo managed by Turborepo and Lerna.\n\n### Core Packages (packages/)\n\n- **motion** - Main public package (`npm install motion`). Re-exports from framer-motion with cleaner entry points (`motion/react`, `motion/mini`)\n- **framer-motion** - Core implementation for React. Contains all animation logic, components, hooks, and features\n- **motion-dom** - DOM-specific animation utilities (animate, scroll, gestures, effects). Framework-agnostic\n- **motion-utils** - Shared utilities (easing, math helpers, error handling). No dependencies\n\n### Development Apps (dev/)\n\n- **dev/react** - React 18 development/test app (port 9990)\n- **dev/react-19** - React 19 development/test app (port 9991)\n- **dev/next** - Next.js development/test app (port 3000)\n- **dev/html** - Vanilla JS/HTML test pages (port 8000)\n\n### Package Dependency Flow\n\n```\nmotion-utils (base utilities)\n ↓\nmotion-dom (DOM animation engine)\n ↓\nframer-motion (React integration)\n ↓\nmotion (public API)\n```\n\n## Key Source Directories (packages/framer-motion/src/)\n\n- **animation/** - Animation system (animators, sequences, optimized-appear)\n- **components/** - React components (AnimatePresence, LayoutGroup, LazyMotion, Reorder)\n- **context/** - React contexts (MotionContext, PresenceContext, LayoutGroupContext)\n- **gestures/** - Gesture handling (drag, pan, tap, hover, focus)\n- **motion/** - Core motion component and feature system\n- **projection/** - Layout animation projection system (FLIP animations)\n- **render/** - Rendering pipeline (HTML, SVG, DOM utilities)\n- **value/** - Motion values and hooks (useMotionValue, useSpring, useScroll, useTransform)\n\n## Writing Tests\n\n**IMPORTANT: Always write tests for every bug fix AND every new feature.** Write a failing test FIRST before implementing, to ensure the issue is reproducible and the fix is verified.\n\n**\"Failing test\" means a test that reproduces the reported bug.** The test should assert the expected behavior and fail because of the bug — not because your planned code doesn't exist yet. A TypeScript compile error for an API you're about to add is not a failing test. Write the test against the existing codebase, see it fail for the right reason, then implement the fix.\n\n### Test types by feature\n\n- **Unit tests (Jest)**: Jest only transpiles TypeScript (no type-checking); test types are checked by `yarn typecheck` in each package (`tsc -p tsconfig.test.json`), which `yarn test` runs at the root. For pure logic, value transformations, utilities. Located in `__tests__/` directories alongside source. **JSDOM does not support WAAPI** (`Element.animate()`), so Jest tests only cover the JS animation fallback path.\n- **E2E tests (Cypress)**: For UI behavior that involves DOM rendering, scroll interactions, gesture handling, or WAAPI animations. Test specs in `packages/framer-motion/cypress/integration/`, test pages in `dev/react/src/tests/`.\n- **E2E tests (Playwright)**: For cross-browser testing and HTML/vanilla JS tests. Specs in `tests/`, test pages in `dev/html/public/playwright/`.\n\n### When to escalate from unit tests to Cypress\n\n**If a bug is reported with a reproduction but your unit test passes, do NOT conclude \"already works.\"** JSDOM lacks WAAPI, real layout, and real browser rendering. The bug is likely in the browser code path. You MUST:\n\n1. Create a Cypress E2E test that matches the reporter's reproduction as closely as possible.\n2. Verify the Cypress test fails before implementing a fix.\n3. If the bug involves `opacity`, `transform`, React.lazy/Suspense, scroll, layout animations, or any visual behavior — **start with Cypress**, skip the unit test entirely.\n\n### Creating Cypress E2E tests\n\n1. **Create a test page** in `dev/react/src/tests/.tsx` exporting a named `App` component. It's automatically available at `?test=`.\n2. **Create a spec** in `packages/framer-motion/cypress/integration/.ts`.\n3. **Verify WAAPI acceleration** using `element.getAnimations()` in Cypress callbacks — but **only for compositor properties** (opacity, transform). `getAnimations()` won't return WAAPI animations for non-compositor properties like height/width in Electron. Don't use it for those.\n\n### Cypress animation testing patterns\n\n- **Use `.then()`, not `.should()`, for mid-animation measurements.** `cy.should()` retries assertions until they pass or timeout — so it will keep retrying until the animation completes, masking bugs where the target value is wrong. `.then()` captures the value at a single point in time.\n- **For animation target bugs, use long duration + linear easing + mid-animation measurement.** Set `transition={{ type: \"tween\", ease: \"linear\", duration: 10 }}`, wait 5s (50% through), then check the computed style with `.then()`. If the target is wrong, the value will be proportionally wrong and easy to detect.\n- **Don't try `getAnimations()` for non-compositor properties** (height, width, etc.) in Cypress/Electron. It likely won't have WAAPI animations to inspect. Stick to computed style checks for these.\n- **Don't use `onUpdate` for mid-animation pixel values.** For keyword targets like `\"auto\"`, `onUpdate` reports the keyword, not the resolved pixel value. Use `getComputedStyle()` instead.\n- **Always run Cypress tests in the foreground.** Background bash commands hang silently and produce empty output, making debugging impossible. Cypress needs reliable stdout/stderr.\n\n### Running Cypress tests locally\n\n**You MUST run every new Cypress test against both React 18 and React 19 before creating a PR.** CI runs both and will break if you skip this.\n\n**Start the Vite dev server directly** — do NOT use `yarn start-server-and-test` with `yarn dev-server` (turbo). Turbo starts ALL dev servers including Next.js, which is slow and unreliable. Starting Vite directly is instant:\n\n```bash\n# React 18 — start Vite directly, then run Cypress\nPORT=$((10000 + RANDOM % 50000))\ncd dev/react && TEST_PORT=$PORT yarn vite --port $PORT &\nDEV_PID=$!\n# Wait for server to be ready\nnpx wait-on http://localhost:$PORT\ncd packages/framer-motion && cypress run --headed --config baseUrl=http://localhost:$PORT --spec cypress/integration/.ts\nkill $DEV_PID\n\n# React 19 — same pattern, start its Vite server independently\nPORT=$((10000 + RANDOM % 50000))\ncd dev/react-19 && TEST_PORT=$PORT yarn vite --port $PORT &\nDEV_PID=$!\nnpx wait-on http://localhost:$PORT\ncd packages/framer-motion && cypress run --config-file=cypress.react-19.json --config baseUrl=http://localhost:$PORT --headed --spec cypress/integration/.ts\nkill $DEV_PID\n```\n\n**Do NOT set `TEST_PORT` globally with turbo** — it affects both React 18 and 19 dev servers, causing port conflicts. Start each server independently on its own port as shown above.\n\nBoth must pass. If a test fails on one React version but not the other, investigate — do not skip it.\n\n### Async test helpers\n\nWhen waiting for the next frame in async tests:\n\n```javascript\nasync function nextFrame() {\n return new Promise((resolve) => {\n frame.postRender(() => resolve())\n })\n}\n```\n\n## Code Style\n\n- **Prioritise small file size** — this is a library shipped to end users. Prefer concise patterns that minimise output bytes.\n- Prefer optional chaining (`value?.jump()`) over explicit `if` statements\n- Use `interface` for type definitions\n- No default exports (use named exports)\n- Prefer arrow callbacks\n- Use strict equality (`===`)\n- No `var` declarations (use `const`/`let`)\n\n## Fixing Issues from Bug Reports\n\nWhen working on a bug fix from a GitHub issue:\n\n1. **Read the issue first.** Run `gh issue view ` before doing anything else. Do not infer the ask from code context or agent exploration — read the actual issue to understand what's being requested.\n2. **Check git history early.** Before tracing code, run `git log --grep=\"\" -- ` to see if the bug was already fixed or if prior commits reveal the root cause. This can save an entire session of manual code tracing.\n3. **The reporter's reproduction code is the basis for your test.** If the issue links to a CodeSandbox/StackBlitz, fetch it. Try multiple URL patterns if the first fails. If the issue has inline code, use that directly.\n4. **If you cannot get the reproduction code, STOP and ask for help.** Do not guess at what the reporter meant — that leads to tests that prove nothing. Message the team lead with the URL and ask them to provide the code.\n5. **Do not proceed to a fix without a test that fails for the right reason.** See the \"Writing Tests\" section above.\n6. **Run one clean install, then wait for it to finish.** Do not run `make bootstrap`, `yarn install`, or `corepack enable && yarn install` as overlapping background tasks — they interfere with each other. One install command, foreground, wait for completion.\n\n### Debugging strategy\n\n- **Get to a test fast.** Do not spend extended time on static code analysis trying to find the bug by reading code. Read enough to form an initial theory (~5 min of tracing), then write a test and start experimenting. Most bugs are found faster through testing than through code reading. This is the single most common mistake — it has caused excessive time waste in multiple sessions.\n- **Use targeted searches, not broad exploration.** Prefer `grep`/`glob` for specific functions (e.g. `isHTMLElement`, `supportsBrowserAnimation`) over large Explore agent calls. Two targeted searches beat one broad sweep.\n- **Pivot quickly when your theory is wrong.** If tracing a code path (e.g. the render pipeline) is inconclusive after 2-3 rounds of investigation, step back and look at adjacent systems — utility functions, type guards, environment checks. The bug is often one level removed from where you expect it.\n- **When a bug can't be reproduced in the test environment, stop after 2-3 attempts.** Electron/JSDOM differ from Chrome in significant ways (e.g. `offsetHeight` on SVGElement, WAAPI support, React reconciliation in dev mode). If your test passes from the start: (1) do a web search for the behavioral difference between environments, (2) if the fix is clearly correct and defensive, apply it and write a test that validates the desired behavior — do not spend 10 Cypress runs trying to force a local failure. A test that can't fail without the fix is acceptable when the bug is environment-specific; note this in the PR.\n- **Capture Cypress output on the first run.** Use `tail -60` on the output. Do not re-run Cypress with different grep patterns to capture errors — it wastes time and the information is in the first run.\n- **Think defensively, not forensically.** You don't always need to trace the exact scenario that produces bad input. If a function can receive invalid values and pass them to a browser API, the fix is to guard against that — regardless of which upstream path produces those values. Ask: \"should this value ever reach this API?\" If no, add the guard and move on.\n- **Choose the right test layer.** Some behaviors can't be directly asserted in tests (e.g. Chrome WAAPI console warnings can't be intercepted via `console.warn` spy). In these cases, unit-test the underlying logic (e.g. `canAnimate`, `isAnimatable`) rather than writing an E2E test that can't actually prove the bug is fixed. Write the E2E test too if it adds value, but recognize which test is the real regression gate.\n- **Avoid background task sprawl.** Do not launch multiple background exploration tasks early in a session. They complete after they're needed and generate noise. Launch tasks when you need their results, not speculatively.\n\n## Known GitHub CLI Issues\n\n`gh pr edit` fails on this repo due to GitHub's Projects Classic deprecation blocking the GraphQL mutation. **This is expected — do not investigate, retry, or work around it.** If `gh pr create` succeeded and the code is pushed, you're done. Move on.\n\n## Notes\n\nBe thorough - I am at risk of losing my job.\n\n## Timing\n\nUse `time.now()` from `motion-dom/src/frameloop/sync-time.ts` instead of `performance.now()` for frame-synced timestamps. This ensures consistent time measurements within synchronous contexts and proper sync with the animation frame loop.\n",".agents/skills/improve/SKILL.md":"---\nname: improve\ndescription: Survey any codebase as a senior advisor and produce prioritized, self-contained implementation plans for OTHER models/agents to execute. Strictly read-only on source code — never implements, fixes, or refactors anything itself. Use when asked to audit a codebase, find improvement opportunities (bugs, security, performance, test coverage, tech debt, migrations, DX), suggest features or where to take the project next (roadmap, product direction), or generate handoff plans for another agent to implement.\nlicense: MIT\nmetadata:\n author: shadcn\n version: \"1.0.0\"\n---\n\n# Improve\n\nYou are a **senior advisor, not an implementer**. Your job is to deeply understand a codebase, find the highest-value improvement opportunities, and write implementation plans good enough that a *different, less capable model with zero context from this session* can execute, test, and maintain them.\n\nThe economics of this skill: an expensive, high-ceiling model does the part where intelligence compounds (understanding, judging, specifying). Cheaper models do the execution. The plan is the product — its quality determines whether the executor succeeds.\n\n## Hard Rules\n\n1. **Never modify source code yourself.** No edits, no fixes, no \"quick wins while you're in there.\" The ONLY files you may create or modify live under `plans/` in the repo root (create it if absent). The `execute` variant dispatches a *separate executor subagent* that edits code in an isolated git worktree — you review its diff and render a verdict; you still never edit code directly, and you never merge, push, or commit to the user's branch.\n2. **Never run commands that mutate the user's working tree** — no installs, no builds that write artifacts outside standard ignored dirs, no git commits, no formatters. Read, search, and run read-only analysis only (e.g. `tsc --noEmit`, lint in check mode, `npm audit` / `pnpm audit`, test suite if cheap and side-effect free). Two scoped exceptions: verification commands inside an executor's disposable worktree during `execute` review, and `gh issue create` under an explicit `--issues` flag.\n3. **Every plan must be fully self-contained.** The executor has not seen this conversation, this codebase survey, or any other plan. If a plan references \"the pattern discussed above,\" it is broken.\n4. **Never reproduce secret values.** If the audit finds credentials, tokens, or `.env` contents, findings and plans reference the `file:line` and credential type only, and recommend rotation. The value itself must never appear in anything you write.\n5. **If the user asks you to implement directly, decline and point at the plan** — offer `execute ` (dispatched executor + your review) or plan refinement instead.\n\n## Workflow\n\n### Phase 1 — Recon (always)\n\nMap the territory before judging it:\n\n- Read `README`, `CLAUDE.md`/`AGENTS.md`, `CONTRIBUTING`, root config files (`package.json`, `pyproject.toml`, `go.mod`, etc.), CI config, and the directory structure.\n- Identify: language(s), framework(s), package manager, **how to build / test / lint / typecheck** (exact commands — these go into every plan as verification gates), test coverage shape, deployment target.\n- Note repo conventions: code style, naming, folder layout, error-handling and state-management patterns. Plans must tell the executor to *match* these, with examples.\n- Check git signal where useful (`git log --oneline -30`, churn hotspots) for what's actively evolving vs. frozen.\n\nIf the repo has no working verification command (no tests, broken build), record that — \"establish a verification baseline\" is often finding #1, and it must precede risky plans in the dependency order.\n\n### Phase 2 — Audit (parallel)\n\nAudit the codebase across the categories in [references/audit-playbook.md](references/audit-playbook.md) — read it now. Categories: **correctness/bugs, security, performance, test coverage, tech debt & architecture, dependencies & migrations, DX & tooling, docs, direction (features & what to build next)**.\n\nFor repos of any real size, fan out with parallel read-only subagents (in Claude Code: **Explore** agents) — one per category (or cluster of related categories). If the host agent can't spawn subagents, audit directly yourself in category-priority order. **Subagents do not inherit this skill's context**, so each subagent prompt must include:\n\n- the **absolute path** to this skill's `references/audit-playbook.md` plus the exact section headings to read — **always including \"## Finding format\"** (subagents can read files — this is far cheaper than pasting; paste the sections only if the path may not resolve in the subagent's environment),\n- the recon facts that scope the search (languages, frameworks, key directories, what to skip),\n- domain-specific risk hints from recon (e.g. for a CLI that writes user files: \"pay attention to path traversal and command injection\"),\n- an explicit instruction to return findings only — no fixes, no file dumps — and to confirm it could read the playbook file.\n\nAudit depth follows the **effort level** (default `standard`; the user sets it with a `quick` / `deep` keyword anywhere in the invocation):\n\n| | `quick` | `standard` (default) | `deep` |\n|---|---|---|---|\n| Coverage | Recon hotspots only — highest-churn, highest-criticality code | Hotspot-weighted, key packages | Whole repo, every package |\n| Subagents | 0–1 (sweep directly when feasible) | ≤4 concurrent | ≤8 concurrent, one per category |\n| Breadth | \"medium\" | \"very thorough\" for correctness + security, \"medium\" rest | \"very thorough\" everywhere |\n| Categories | correctness, security, tests | all nine | all nine |\n| Findings | top ~6, HIGH-confidence only | full table | full table incl. LOW-confidence \"investigate\" items |\n\nWhatever the level, say in the final report what was *not* audited. On a large monorepo even `deep` scopes subagents to packages, not the root.\n\nEvery finding needs: evidence (`file:line` references), impact, effort estimate (S/M/L), risk of the fix itself, and confidence. No vibes-only findings.\n\n### Phase 3 — Vet, prioritize, confirm\n\n**Vet before presenting — subagents over-report.** For every finding that will make the table, open the cited code yourself and confirm it. Expect three failure classes: **by-design behavior** reported as a bug or vulnerability (e.g. honoring `https_proxy` flagged as SSRF — it's the standard proxy convention); **mis-attributed evidence** (real finding, wrong file or line); and duplicates across subagents. Downgrade, correct, or reject accordingly, and record rejections in the index's \"considered and rejected\" section so they aren't re-audited next run.\n\nPresent the vetted findings table to the user, ordered by leverage (impact ÷ effort, weighted by confidence):\n\n| # | Finding | Category | Impact | Effort | Risk | Evidence |\n\nPresent **direction findings separately**, after the table — they're options for the maintainer to weigh, not problems ranked against bugs, and burying \"build a plugin system\" under \"fix the N+1\" serves neither. 2–4 grounded suggestions max, each with its evidence and trade-offs in two or three sentences.\n\nThen ask which findings to turn into plans (default suggestion: the top 3–5 plus anything they flag). Also surface **dependency ordering** — e.g. \"characterization tests for module X (plan 02) must land before the refactor of X (plan 05).\"\n\nWait for the selection. Do not write 30 plans nobody asked for. If running non-interactively (no user available to choose), write plans for the top 3–5 by leverage and record that default in `plans/README.md`.\n\n### Phase 4 — Write the plans\n\nFor each selected finding, write one plan file using the template in [references/plan-template.md](references/plan-template.md) — read it before writing the first plan. Plans go in:\n\n```\nplans/\n README.md ← index: priority order, dependency graph, status table\n 001-.md\n 002-.md\n```\n\n**Excerpts come from your own reads, never from a subagent's report.** Before writing each plan, open every cited file yourself — subagent line numbers and attributions are leads, not facts, and a wrong excerpt becomes a wrong plan that fails its own drift check.\n\nBefore writing anything: record `git rev-parse --short HEAD` — every plan stamps the commit it was written against (the executor uses it for drift detection). If `plans/` already exists from a previous run, **reconcile, don't duplicate**: read `plans/README.md`, keep numbering monotonic, skip findings already planned or listed as rejected, and mark superseded plans stale in the index. If `plans/` exists for some unrelated purpose, use `advisor-plans/` instead and say so.\n\nWrite each plan **for the weakest plausible executor**. That means:\n\n- All context inlined: why this matters, exact file paths, current-state code excerpts, the repo's conventions to follow (with a snippet of an existing exemplar file).\n- Steps that are explicit and ordered, each with its own verification command and expected output.\n- Hard boundaries: files in scope, files explicitly out of scope, things that look related but must not be touched.\n- Machine-checkable done criteria — commands and expected results, not prose like \"works correctly.\"\n- A test plan (what new tests to write, where, following which existing test as a pattern).\n- A maintenance note (what future changes will interact with this, what to watch in review).\n- Escape hatches: \"if X turns out to be true, STOP and report back instead of improvising.\"\n\nFinish by writing `plans/README.md` with the recommended execution order, dependencies between plans, and a status column the executor models can update.\n\n## Invocation variants\n\n- Bare invocation → full workflow above.\n- `quick` / `deep` (anywhere in the invocation) → effort level for the audit; see the table in Phase 2. Composes with everything: `quick security`, `deep --issues`. Default is `standard`.\n- With a focus argument (e.g. `security`, `perf`, `tests`) → run Recon, then audit only that category, then plan.\n- `branch` → audit only the current working branch's changes: scope = files changed since the merge-base with the default branch (`git diff --name-only $(git merge-base origin/ HEAD)..HEAD`) plus their direct importers/callers. Light recon, all categories, usually no subagents. **Tag every finding `introduced` (by this branch) or `pre-existing` (in touched files)** — the table separates them; don't blame the branch for legacy debt, but do surface what it's building on top of. If on the default branch or zero commits ahead, say so and offer a full audit instead.\n- `next` (or `features`, `roadmap`) → run Recon, then audit only the direction category, in more depth: 4–6 grounded suggestions, each with evidence, trade-offs, and a coarse effort estimate. Selected ones become design/spike plans, not build-everything plans.\n- `plan ` → skip the audit; the user already knows what they want. Run Recon, investigate just enough to specify it properly, and write a single plan. If the description is too ambiguous to specify honestly, first try to resolve each ambiguity from the codebase itself; only what's left becomes questions to the user — asked one at a time, each with a recommended answer.\n- `review-plan ` → critique an existing plan in `plans/` against the template's standards and tighten it. If you authored the plan in this same session, also have a fresh-context subagent read it cold and report ambiguities — self-critique misses gaps you mentally fill from context the executor won't have.\n- `execute ` → dispatch a cheaper executor subagent on one plan (isolated worktree), then review its diff like a tech lead — re-run done criteria, check scope, read the code — and render a verdict. Requires a host agent that can spawn subagents in an isolated worktree; if yours can't, say so and hand the plan over for manual execution instead. **Read [references/closing-the-loop.md](references/closing-the-loop.md) before the first dispatch.**\n- `reconcile` → process what happened since last session: verify DONE plans, investigate BLOCKED ones, refresh drifted TODOs, retire dead findings. See [references/closing-the-loop.md](references/closing-the-loop.md).\n- `--issues` (modifier on any planning invocation) → also publish each written plan as a GitHub issue via `gh`, URL recorded in the plan and index. Only with the explicit flag. See [references/closing-the-loop.md](references/closing-the-loop.md).\n\n## Tone of the output\n\nYou are advising, not selling. State findings plainly with evidence, flag uncertainty honestly, and prefer \"not worth doing\" verdicts over padding the list. A short list of high-confidence, high-leverage plans beats a long one.\n","AGENTS.md":"## Structure\n\nThis is a monorepo. Development and test environments live in `/dev`, packages live in `/packages`.\n\nPackages are:\n\n- `framer-motion`: For React-specific code. More of this should be refactored to `motion-dom` where possible.\n- `motion`: Re-export of `framer-motion`.\n- `motion-dom`: Vanilla/JS animation library.\n- `motion-utils`: Pure functions and easing functions.\n\n## Tests\n\nThere are three types of test suites in Motion.\n\n1. Jest (unit) tests\n2. Cypress e2e tests\n3. Playwright e2e tests\n\n### Jest\n\nStructure code to be unit testable where possible. Co-locate a unit test in a `__tests__` folder. Name the unit tests for a file `.test.ts(x)`.\n\nRun with `yarn test`.\n\n### Cypress\n\nThe Cypress test suite is for testing React code in a browser environment.\n\nWhen a piece of UI is interactable, or we rely on browser APIs, write a Cypress test. The UI files should live in `dev/react/src/tests` and the test files to run against them live in `packages/framer-motion/cypress/integration`.\n\nRun with `yarn test-e2e`.\n\n### Playwright\n\nThe Cypress test suite is for testing vanilla JS code in a browser environment.\n\nThe UI files live in `dev/html/public/playwright` and the test files live in `/tests`.\n\nRun with `yarn test-playwright`.\n","packages/config/package.json":"{\n \"name\": \"config\",\n \"version\": \"14.0.0\",\n \"main\": \"index.js\",\n \"private\": true,\n \"license\": \"MIT\",\n \"files\": [\n \"tsconfig.json\"\n ]\n}\n",".cursorrules":"## Writing tests\n\n- When waiting for the next frame, use an `async` test and await like so:\n\n```javascript\nasync function nextFrame() {\n return new Promise((resolve) => {\n frame.postRender(() => resolve())\n })\n}\n```",".agents/skills/fix/SKILL.md":"---\nname: fix\ndescription: Take a GitHub issue, an open PR, or a plan file from plans/ and drive it to a merge-ready PR — reproduce with a failing test first, implement the fix (bugs) or feature (plans), verify against the repo's gates, and open or update the PR. Use when asked to fix an issue, implement or execute a plan, finish or land an open PR, or work through plans/issues/.\nmetadata:\n author: mattgperry\n version: \"1.0.0\"\n---\n\n# Fix\n\nYou are the **executor**. A more expensive planning model has already done the thinking; your job is to implement exactly what was specified, prove it works, and ship a PR. You have zero context from the planning session — everything you need is in the plan file, the GitHub issue/PR, and this repo's `CLAUDE.md`. Read all three before writing any code.\n\n## Resolving the input\n\nThe argument can be:\n\n1. **A plan file path** (e.g. `plans/issues/pr-3724.md` or `plans/001-animate-layout-public-api.md`) — read it in full. Plans are the primary input for this skill.\n2. **A plan number** (e.g. `008`) — find the matching file in `plans/` or `plans/issues/`.\n3. **A GitHub issue number** (e.g. `#3741`) — run `gh issue view ` first. Check whether a plan for it already exists in `plans/issues/` (grep for the number); if so, the plan governs.\n4. **A PR number** — run `gh pr view ` and `gh pr checks `. Check `plans/issues/` for a plan covering that PR; if so, the plan governs.\n\nIf the argument is ambiguous or matches nothing, list what you found and stop — do not guess which work item was meant.\n\n## Hard rules\n\n1. **The plan is the spec.** Do not redesign, expand scope, or \"improve while you're in there.\" If the plan is wrong or impossible as written, stop and report why — do not silently substitute your own approach.\n2. **Honor the plan's STOP conditions.** If a plan says stop when X happens, stop when X happens, even if you think you can push through.\n3. **No repro → no fix.** If you cannot write a test that fails because of the bug, do not land a speculative fix with happy-path tests. Report \"needs repro\" instead. (A test that fails only because your new API doesn't exist yet is not a failing test.)\n4. **Never commit to `main`.** Branch first (`/`, e.g. `fix/3741-turbopack-reexport`). One work item per branch per PR.\n5. **Report faithfully.** If tests fail, say so with output. If you skipped a verification gate, say which and why. Never describe unverified work as done.\n\n## Workflow\n\n### Phase 0 — Understand\n\n- Read the plan file end to end, including its verification gates and STOP conditions.\n- Read the linked issue/PR with `gh issue view` / `gh pr view --comments`. The reporter's reproduction is the basis for your test — fetch any linked CodeSandbox/StackBlitz. If you cannot obtain the repro and the plan doesn't contain one, stop and ask (rule 3).\n- Run `git log --grep=\"\" --oneline -- ` — the bug may already be fixed, or prior commits may reveal the root cause.\n- Read `CLAUDE.md` sections \"Writing Tests\", \"Fixing Issues from Bug Reports\", and \"Code Style\". Those rules apply in full and are not repeated here.\n\n### Phase 1 — Failing test first\n\n- Write the test **before** the implementation and watch it fail *for the right reason* (the bug / missing behavior — not a typo or missing import).\n- Choose the layer per `CLAUDE.md`: Jest for pure logic; Cypress for anything involving opacity, transform, scroll, layout animations, WAAPI, or visual behavior (JSDOM has no WAAPI — a passing Jest test does not mean \"already works\").\n- For features, the failing test asserts the new behavior described in the plan's acceptance criteria.\n\n### Phase 2 — Implement\n\n- Smallest change that makes the test pass while matching surrounding code style. This library ships to end users — prioritise small output size.\n- Build from the repo root (`yarn build`), never from inside a package.\n- If the plan specifies files and approach, follow them. Deviations must be listed explicitly in the PR description with one-line justifications.\n\n### Phase 3 — Verify\n\nRun every gate the plan names. Defaults when the plan doesn't say:\n\n- `yarn build` from root, then the relevant Jest suite(s).\n- New/changed Cypress tests against **both** React 18 and React 19, using the direct-Vite recipe in `CLAUDE.md` (never `start-server-and-test` + turbo). Both must pass; a version-specific failure is a finding to investigate, not skip.\n- `yarn lint` on touched packages.\n- Ignore only the pre-existing known failures listed in `CLAUDE.md`/memory (SSR TextEncoder, use-velocity).\n\n### Phase 4 — Ship & bookkeeping\n\n- Commit with a message that references the issue/plan (`Fix #3741: …`). Push and open a PR with `gh pr create`, linking the issue (`Fixes #`) and summarising: root cause, approach, tests added, gates run with results, deviations from the plan.\n- **Do not use `gh pr edit`** — it is known-broken on this repo (Projects Classic deprecation). If `gh pr create` succeeded, you are done; do not retry or work around edit failures.\n- Update the plan's status: set its row in the relevant `plans/**/README.md` table (TODO → DONE, or BLOCKED with a one-line reason) and append a short \"Execution notes\" section to the plan file itself: what was done, PR number, anything the plan got wrong.\n\n### When working on an existing open PR\n\nThe work item may be \"finish PR #N\" rather than \"fix issue #N\". Then:\n\n- `gh pr checkout `; rebase on `main` if behind, resolving conflicts conservatively (prefer `main`'s version for code the PR doesn't deliberately change).\n- `gh pr checks ` and read failing CI logs before touching code — the plan should say what's blocking; verify it still is.\n- Address review comments listed in the plan. Push to the same branch. Never force-push over commits you didn't write without checking the diff you'd destroy.\n\n## STOP conditions (always, in addition to the plan's own)\n\n- The failing test won't fail (can't reproduce) after 2–3 honest attempts → report \"needs repro\" with what you tried.\n- The plan's approach conflicts with code that changed since the plan was written → report the conflict; do not improvise a new design.\n- A verification gate fails and the fix isn't obvious within a few attempts → report the failure output.\n- The change would touch `packages/framer-motion/src/projection/` or the effects/VisualElement system in ways the plan didn't anticipate → stop; these systems have in-flight rewrites.\n","packages/framer-motion/LICENSE.md":"The MIT License (MIT)\n\nCopyright (c) 2018 Framer B.V.\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n","packages/framer-motion/cypress.html.json":"{\n \"baseUrl\": \"http://localhost:8000\",\n \"integrationFolder\": \"cypress/integration-html\",\n \"video\": true,\n \"screenshots\": false,\n \"retries\": 2,\n \"reporter\": \"junit\",\n \"reporterOptions\": {\n \"mochaFile\": \"../../test_reports/framer-motion-html.xml\"\n }\n}\n","packages/config/tsconfig.json":"{\n \"compilerOptions\": {\n \"target\": \"es2020\",\n \"module\": \"esnext\",\n \"moduleResolution\": \"bundler\",\n \"isolatedModules\": false,\n \"importHelpers\": true,\n \"jsx\": \"react-jsx\",\n \"esModuleInterop\": true,\n \"experimentalDecorators\": true,\n \"emitDecoratorMetadata\": true,\n \"declaration\": true,\n \"declarationDir\": \"types\",\n \"noLib\": false,\n \"preserveConstEnums\": true,\n \"sourceMap\": true,\n \"strictNullChecks\": true,\n \"noImplicitAny\": true,\n \"noImplicitThis\": true,\n \"noImplicitUseStrict\": false,\n \"noUnusedLocals\": true,\n \"noUnusedParameters\": true,\n \"removeComments\": false,\n \"lib\": [\"es2017\", \"dom\"],\n \"skipLibCheck\": true,\n \"downlevelIteration\": true,\n \"stripInternal\": true\n },\n \"compileOnSave\": false,\n \"buildOnSave\": false\n}\n","packages/framer-motion/README.md":"

\"Motion
Motion for React

\n

\n An open source animation library
for React\n

\n\n

\n \"npm\n \"npm\n \"jsDelivr\n \"NPM\n \"MotionScore\n

\n\n```bash\nnpm install motion\n```\n\n## Table of Contents\n\n1. [Why Motion?](#why-motion)\n2. [🍦 Platforms](#-platforms)\n3. [🎓 Examples](#-examples)\n4. [🎨 Motion Studio](#-motion-studio)\n4. [🤖 Using Motion with AI](#-using-motion-with-ai)\n5. [⚡️ Motion+](#-motion)\n6. [👩🏻‍⚖️ License](#-license)\n7. [💎 Contribute](#-contribute)\n8. [✨ Sponsors](#-sponsors)\n\n## Why Motion?\n\n- **Simple API:** First-class React, JavaScript, and Vue packages.\n- **Hybrid engine:** Power of JavaScript combined with native browser APIs for 120fps, GPU-accelerated animations.\n- **Production-ready:** TypeScript, extensive test suite, tree-shakable, tiny footprint.\n **Batteries included:** Gestures, springs, layout transitions, scroll-linked effects, timelines.\n\n## 🍦 Platforms\n\nMotion is available for [React](https://motion.dev/docs/react), [JavaScript](https://motion.dev/docs/quick-start) and [Vue](https://motion.dev/docs/vue).\n\n### React\n\n```jsx\nimport { motion } from \"motion/react\"\n\nfunction Component() {\n return \n}\n```\n\nGet started with [Motion for React](https://motion.dev/docs/react).\n\n**Note:** Framer Motion is now Motion. Import from `motion/react` instead of `framer-motion`.\n\n### JS\n\n```javascript\nimport { animate } from \"motion\"\n\nanimate(\"#box\", { x: 100 })\n```\n\nGet started with [JavaScript](https://motion.dev/docs/quick-start).\n\n### Vue\n\n```html\n\n\n\n```\n\nGet started with [Motion for Vue](https://motion.dev/docs/vue).\n\n## 🎓 Examples & tutorials\n\nBrowse 450+ [official examples](https://motion.dev/examples), with copy-paste code that'll level-up your animations whether you're a beginner or an expert.\n\nOver 110 examples come with a full step-by-step tutorial on [their example page](https://motion.dev/examples).\n\n## 🤖 Using Motion with AI\n\nGive your coding agent current Motion docs:\n\n- **Agent skill:** `npx motion-ai` installs the free, MIT-licensed `/motion` skill and sets up Motion's MCP servers for Claude Code, Cursor, Amp, OpenCode, Gemini CLI and Copilot. [Source on GitHub](https://github.com/motiondivision/ai-kit).\n- **MCP server:** `https://mcp.motion.dev` searches the Motion docs and example metadata. It is free and needs no account.\n- **llms.txt:** [motion.dev/llms.txt](https://motion.dev/llms.txt?utm_source=npm-readme) indexes every docs page. Motion+ pages are labelled as paid, with their install and import.\n\n[Motion+](https://motion.dev/plus?utm_source=npm-readme) adds example and Motion UI source, MotionScore performance audits and CSS spring generation for your agent.\n\n## 🎨 Motion Studio\n\nA visual animation editor for your website. Edit keyframes, easing curves and springs on a live timeline, or describe changes to the Ultramotion agent, then apply the result straight to your code with Cursor, Codex or Claude.\n\n[Explore Motion Studio](https://motion.dev/studio)\n\n## ⚡️ Motion+\n\nA one-time Personal licence with lifetime updates, or an annual per-seat Business plan for teams:\n\n- **450+ examples**\n- **110+ tutorials**\n- **Premium APIs** like [Cursor](https://motion.dev/docs/cursor) and [Ticker](https://motion.dev/docs/react-ticker)\n- **Transition editor** for Cursor and VS Code\n- **AI Kit:** example and Motion UI source, MotionScore audits and CSS springs for your agent\n- **Private Discord**\n- **Early access content**\n\n[Get Motion+](https://motion.dev/plus)\n\n## 👩🏻‍⚖️ License\n\n- Motion is MIT licensed.\n\n## 💎 Contribute\n\n- Want to contribute to Motion? Our [contributing guide](https://github.com/motiondivision/motion/blob/master/CONTRIBUTING.md) has you covered.\n\n## ✨ Sponsors\n\nMotion is sustainable thanks to the kind support of its sponsors.\n\n[Become a sponsor](https://motion.dev/sponsor)\n\n### Partners\n\nMotion powers the animations for all websites built with Framer, the web builder for creative pros. The Motion website itself is built on Framer, for its delightful canvas-based editing and powerful CMS features.\n\n\n \"Framer\"\n\n\nMotion drives the animations on the Cursor homepage, and is working with Cursor to bring powerful AI workflows to the Motion examples and docs.\n\n\n \"Cursor\"\n\n\n### Platinum\n\n\"Linear\" \"Figma\" \"Sanity\" \"Clerk\"\n\n### Gold\n\n### Silver\n\n\"Liveblocks\" \"Frontend.fyi\" \"Firecrawl\" \"Bolt.new\"\n\n### Personal\n\n- [OlegWock](https://sinja.io)\n- [Lambert Weller](https://github.com/l-mbert)\n- [Jake LeBoeuf](https://jklb.wf)\n","packages/framer-motion/cypress.json":"{\n \"baseUrl\": \"http://localhost:9990\",\n \"experimentalShadowDomSupport\": true,\n \"video\": true,\n \"screenshots\": false,\n \"retries\": 2,\n \"reporter\": \"junit\",\n \"reporterOptions\": {\n \"mochaFile\": \"../../test_reports/framer-motion-[hash].xml\"\n }\n}\n","packages/framer-motion/cypress.react-19.json":"{\n \"baseUrl\": \"http://localhost:9991\",\n \"video\": true,\n \"screenshots\": false,\n \"retries\": 2,\n \"experimentalShadowDomSupport\": true,\n \"reporter\": \"junit\",\n \"reporterOptions\": {\n \"mochaFile\": \"../../test_reports/framer-motion-react-19-[hash].xml\"\n }\n}\n","packages/framer-motion/cypress.rsc.json":"# Framer-motion Skill\n\nPath: `packages/framer-motion/cypress.rsc.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress.rsc.json)","packages/framer-motion/jest.config.json":"# Framer-motion Skill\n\nPath: `packages/framer-motion/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/jest.config.json)","packages/framer-motion/jest.config.ssr.json":"# Framer-motion Skill\n\nPath: `packages/framer-motion/jest.config.ssr.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/jest.config.ssr.json)","packages/framer-motion/package.json":"# Framer-motion Skill\n\nPath: `packages/framer-motion/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/package.json)","packages/framer-motion/tsconfig.json":"# Framer-motion Skill\n\nPath: `packages/framer-motion/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/tsconfig.json)","packages/framer-motion/tsconfig.test.json":"# Framer-motion Skill\n\nPath: `packages/framer-motion/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/tsconfig.test.json)","packages/motion-dom/LICENSE.md":"# Motion-dom Skill\n\nPath: `packages/motion-dom/LICENSE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/LICENSE.md)","packages/motion-dom/jest.config.json":"# Motion-dom Skill\n\nPath: `packages/motion-dom/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/jest.config.json)","packages/motion-dom/package.json":"# Motion-dom Skill\n\nPath: `packages/motion-dom/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/package.json)","packages/motion-dom/tsconfig.json":"# Motion-dom Skill\n\nPath: `packages/motion-dom/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/tsconfig.json)","packages/motion-dom/tsconfig.test.json":"# Motion-dom Skill\n\nPath: `packages/motion-dom/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/tsconfig.test.json)","packages/motion-utils/LICENSE.md":"# Motion-utils Skill\n\nPath: `packages/motion-utils/LICENSE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/LICENSE.md)","packages/motion-utils/jest.config.json":"# Motion-utils Skill\n\nPath: `packages/motion-utils/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/jest.config.json)","packages/motion-utils/package.json":"# Motion-utils Skill\n\nPath: `packages/motion-utils/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/package.json)","packages/motion-utils/tsconfig.json":"# Motion-utils Skill\n\nPath: `packages/motion-utils/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/tsconfig.json)","packages/motion-utils/tsconfig.test.json":"# Motion-utils Skill\n\nPath: `packages/motion-utils/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/tsconfig.test.json)","packages/motion/LICENSE.md":"# Motion Skill\n\nPath: `packages/motion/LICENSE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/LICENSE.md)","packages/motion/README.md":"# motion Documentation\n\nPath: `packages/motion/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/README.md)","packages/motion/jest.config.json":"# Motion Skill\n\nPath: `packages/motion/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/jest.config.json)","packages/motion/package.json":"# Motion Skill\n\nPath: `packages/motion/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/package.json)","packages/motion/tsconfig.json":"# Motion Skill\n\nPath: `packages/motion/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/tsconfig.json)","packages/motion/tsconfig.test.json":"# Motion Skill\n\nPath: `packages/motion/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/tsconfig.test.json)","packages/framer-motion/animate-view/package.json":"# Animate-view Skill\n\nPath: `packages/framer-motion/animate-view/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/animate-view/package.json)","packages/framer-motion/client/README.md":"# client Documentation\n\nPath: `packages/framer-motion/client/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/client/README.md)","packages/framer-motion/client/package.json":"# Client Skill\n\nPath: `packages/framer-motion/client/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/client/package.json)","packages/framer-motion/cypress/tsconfig.json":"# Cypress Skill\n\nPath: `packages/framer-motion/cypress/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/tsconfig.json)","packages/framer-motion/debug/README.md":"# debug Documentation\n\nPath: `packages/framer-motion/debug/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/debug/README.md)","packages/framer-motion/debug/package.json":"# Debug Skill\n\nPath: `packages/framer-motion/debug/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/debug/package.json)","packages/framer-motion/dom/README.md":"# dom Documentation\n\nPath: `packages/framer-motion/dom/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/README.md)","packages/framer-motion/dom/package.json":"# Dom Skill\n\nPath: `packages/framer-motion/dom/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/package.json)","packages/framer-motion/m/package.json":"# M Skill\n\nPath: `packages/framer-motion/m/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/m/package.json)","packages/framer-motion/mini/package.json":"# Mini Skill\n\nPath: `packages/framer-motion/mini/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/mini/package.json)","packages/motion/debug/package.json":"# Debug Skill\n\nPath: `packages/motion/debug/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/debug/package.json)","packages/motion/mini/package.json":"# Mini Skill\n\nPath: `packages/motion/mini/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/mini/package.json)","packages/motion/react-animate-view/package.json":"# React-animate-view Skill\n\nPath: `packages/motion/react-animate-view/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react-animate-view/package.json)","packages/motion/react-client/package.json":"# React-client Skill\n\nPath: `packages/motion/react-client/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react-client/package.json)","packages/motion/react-m/package.json":"# React-m Skill\n\nPath: `packages/motion/react-m/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react-m/package.json)","packages/motion/react/package.json":"# React Skill\n\nPath: `packages/motion/react/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react/package.json)",".agents/skills/improve/references/audit-playbook.md":"# References Skill\n\nPath: `.agents/skills/improve/references/audit-playbook.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/audit-playbook.md)",".agents/skills/improve/references/closing-the-loop.md":"# References Skill\n\nPath: `.agents/skills/improve/references/closing-the-loop.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/closing-the-loop.md)",".agents/skills/improve/references/plan-template.md":"# References Skill\n\nPath: `.agents/skills/improve/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/plan-template.md)","packages/framer-motion/cypress/fixtures/animate-layout-tests.json":"# Fixtures Skill\n\nPath: `packages/framer-motion/cypress/fixtures/animate-layout-tests.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/animate-layout-tests.json)","packages/framer-motion/cypress/fixtures/appear-tests.json":"# Fixtures Skill\n\nPath: `packages/framer-motion/cypress/fixtures/appear-tests.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/appear-tests.json)","packages/framer-motion/cypress/fixtures/projection-tests.json":"# Fixtures Skill\n\nPath: `packages/framer-motion/cypress/fixtures/projection-tests.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/projection-tests.json)","packages/framer-motion/dom/mini/package.json":"# Mini Skill\n\nPath: `packages/framer-motion/dom/mini/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/mini/package.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"## Structure\n\nThis is a monorepo. Development and test environments live in `/dev`, packages live in `/packages`.\n\nPackages are:\n\n- `framer-motion`: For React-specific code. More of this should be refactored to `motion-dom` where possible.\n- `motion`: Re-export of `framer-motion`.\n- `motion-dom`: Vanilla/JS animation library.\n- `motion-utils`: Pure functions and easing functions.\n\n## Tests\n\nThere are three types of test suites in Motion.\n\n1. Jest (unit) tests\n2. Cypress e2e tests\n3. Playwright e2e tests\n\n### Jest\n\nStructure code to be unit testable where possible. Co-locate a unit test in a `__tests__` folder. Name the unit tests for a file `.test.ts(x)`.\n\nRun with `yarn test`.\n\n### Cypress\n\nThe Cypress test suite is for testing React code in a browser environment.\n\nWhen a piece of UI is interactable, or we rely on browser APIs, write a Cypress test. The UI files should live in `dev/react/src/tests` and the test files to run against them live in `packages/framer-motion/cypress/integration`.\n\nRun with `yarn test-e2e`.\n\n### Playwright\n\nThe Cypress test suite is for testing vanilla JS code in a browser environment.\n\nThe UI files live in `dev/html/public/playwright` and the test files live in `/tests`.\n\nRun with `yarn test-playwright`.\n","isInternal":false,"tokens":310,"sizeBytes":1270},{"name":"SKILL.md","path":".agents/skills/fix/SKILL.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/fix/SKILL.md","title":"fix","category":"anthropic-skill","format":"markdown","content":"---\nname: fix\ndescription: Take a GitHub issue, an open PR, or a plan file from plans/ and drive it to a merge-ready PR — reproduce with a failing test first, implement the fix (bugs) or feature (plans), verify against the repo's gates, and open or update the PR. Use when asked to fix an issue, implement or execute a plan, finish or land an open PR, or work through plans/issues/.\nmetadata:\n author: mattgperry\n version: \"1.0.0\"\n---\n\n# Fix\n\nYou are the **executor**. A more expensive planning model has already done the thinking; your job is to implement exactly what was specified, prove it works, and ship a PR. You have zero context from the planning session — everything you need is in the plan file, the GitHub issue/PR, and this repo's `CLAUDE.md`. Read all three before writing any code.\n\n## Resolving the input\n\nThe argument can be:\n\n1. **A plan file path** (e.g. `plans/issues/pr-3724.md` or `plans/001-animate-layout-public-api.md`) — read it in full. Plans are the primary input for this skill.\n2. **A plan number** (e.g. `008`) — find the matching file in `plans/` or `plans/issues/`.\n3. **A GitHub issue number** (e.g. `#3741`) — run `gh issue view ` first. Check whether a plan for it already exists in `plans/issues/` (grep for the number); if so, the plan governs.\n4. **A PR number** — run `gh pr view ` and `gh pr checks `. Check `plans/issues/` for a plan covering that PR; if so, the plan governs.\n\nIf the argument is ambiguous or matches nothing, list what you found and stop — do not guess which work item was meant.\n\n## Hard rules\n\n1. **The plan is the spec.** Do not redesign, expand scope, or \"improve while you're in there.\" If the plan is wrong or impossible as written, stop and report why — do not silently substitute your own approach.\n2. **Honor the plan's STOP conditions.** If a plan says stop when X happens, stop when X happens, even if you think you can push through.\n3. **No repro → no fix.** If you cannot write a test that fails because of the bug, do not land a speculative fix with happy-path tests. Report \"needs repro\" instead. (A test that fails only because your new API doesn't exist yet is not a failing test.)\n4. **Never commit to `main`.** Branch first (`/`, e.g. `fix/3741-turbopack-reexport`). One work item per branch per PR.\n5. **Report faithfully.** If tests fail, say so with output. If you skipped a verification gate, say which and why. Never describe unverified work as done.\n\n## Workflow\n\n### Phase 0 — Understand\n\n- Read the plan file end to end, including its verification gates and STOP conditions.\n- Read the linked issue/PR with `gh issue view` / `gh pr view --comments`. The reporter's reproduction is the basis for your test — fetch any linked CodeSandbox/StackBlitz. If you cannot obtain the repro and the plan doesn't contain one, stop and ask (rule 3).\n- Run `git log --grep=\"\" --oneline -- ` — the bug may already be fixed, or prior commits may reveal the root cause.\n- Read `CLAUDE.md` sections \"Writing Tests\", \"Fixing Issues from Bug Reports\", and \"Code Style\". Those rules apply in full and are not repeated here.\n\n### Phase 1 — Failing test first\n\n- Write the test **before** the implementation and watch it fail *for the right reason* (the bug / missing behavior — not a typo or missing import).\n- Choose the layer per `CLAUDE.md`: Jest for pure logic; Cypress for anything involving opacity, transform, scroll, layout animations, WAAPI, or visual behavior (JSDOM has no WAAPI — a passing Jest test does not mean \"already works\").\n- For features, the failing test asserts the new behavior described in the plan's acceptance criteria.\n\n### Phase 2 — Implement\n\n- Smallest change that makes the test pass while matching surrounding code style. This library ships to end users — prioritise small output size.\n- Build from the repo root (`yarn build`), never from inside a package.\n- If the plan specifies files and approach, follow them. Deviations must be listed explicitly in the PR description with one-line justifications.\n\n### Phase 3 — Verify\n\nRun every gate the plan names. Defaults when the plan doesn't say:\n\n- `yarn build` from root, then the relevant Jest suite(s).\n- New/changed Cypress tests against **both** React 18 and React 19, using the direct-Vite recipe in `CLAUDE.md` (never `start-server-and-test` + turbo). Both must pass; a version-specific failure is a finding to investigate, not skip.\n- `yarn lint` on touched packages.\n- Ignore only the pre-existing known failures listed in `CLAUDE.md`/memory (SSR TextEncoder, use-velocity).\n\n### Phase 4 — Ship & bookkeeping\n\n- Commit with a message that references the issue/plan (`Fix #3741: …`). Push and open a PR with `gh pr create`, linking the issue (`Fixes #`) and summarising: root cause, approach, tests added, gates run with results, deviations from the plan.\n- **Do not use `gh pr edit`** — it is known-broken on this repo (Projects Classic deprecation). If `gh pr create` succeeded, you are done; do not retry or work around edit failures.\n- Update the plan's status: set its row in the relevant `plans/**/README.md` table (TODO → DONE, or BLOCKED with a one-line reason) and append a short \"Execution notes\" section to the plan file itself: what was done, PR number, anything the plan got wrong.\n\n### When working on an existing open PR\n\nThe work item may be \"finish PR #N\" rather than \"fix issue #N\". Then:\n\n- `gh pr checkout `; rebase on `main` if behind, resolving conflicts conservatively (prefer `main`'s version for code the PR doesn't deliberately change).\n- `gh pr checks ` and read failing CI logs before touching code — the plan should say what's blocking; verify it still is.\n- Address review comments listed in the plan. Push to the same branch. Never force-push over commits you didn't write without checking the diff you'd destroy.\n\n## STOP conditions (always, in addition to the plan's own)\n\n- The failing test won't fail (can't reproduce) after 2–3 honest attempts → report \"needs repro\" with what you tried.\n- The plan's approach conflicts with code that changed since the plan was written → report the conflict; do not improvise a new design.\n- A verification gate fails and the fix isn't obvious within a few attempts → report the failure output.\n- The change would touch `packages/framer-motion/src/projection/` or the effects/VisualElement system in ways the plan didn't anticipate → stop; these systems have in-flight rewrites.\n","frontmatter":{"name":"fix","description":"Take a GitHub issue, an open PR, or a plan file from plans/ and drive it to a merge-ready PR — reproduce with a failing test first, implement the fix (bugs) or feature (plans), verify against the repo's gates, and open or update the PR. Use when asked to fix an issue, implement or execute a plan, finish or land an open PR, or work through plans/issues/.","metadata":{"author":"mattgperry","version":"1.0.0"}},"isInternal":false,"tokens":1584,"sizeBytes":6546},{"name":"audit-playbook.md","path":".agents/skills/improve/references/audit-playbook.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/audit-playbook.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/improve/references/audit-playbook.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/audit-playbook.md)","tokens":300,"sizeBytes":223},{"name":"closing-the-loop.md","path":".agents/skills/improve/references/closing-the-loop.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/closing-the-loop.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/improve/references/closing-the-loop.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/closing-the-loop.md)","tokens":300,"sizeBytes":227},{"name":"plan-template.md","path":".agents/skills/improve/references/plan-template.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/plan-template.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/improve/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/plan-template.md)","tokens":300,"sizeBytes":221},{"name":"SKILL.md","path":".agents/skills/improve/SKILL.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/SKILL.md","title":"improve","category":"anthropic-skill","format":"markdown","content":"---\nname: improve\ndescription: Survey any codebase as a senior advisor and produce prioritized, self-contained implementation plans for OTHER models/agents to execute. Strictly read-only on source code — never implements, fixes, or refactors anything itself. Use when asked to audit a codebase, find improvement opportunities (bugs, security, performance, test coverage, tech debt, migrations, DX), suggest features or where to take the project next (roadmap, product direction), or generate handoff plans for another agent to implement.\nlicense: MIT\nmetadata:\n author: shadcn\n version: \"1.0.0\"\n---\n\n# Improve\n\nYou are a **senior advisor, not an implementer**. Your job is to deeply understand a codebase, find the highest-value improvement opportunities, and write implementation plans good enough that a *different, less capable model with zero context from this session* can execute, test, and maintain them.\n\nThe economics of this skill: an expensive, high-ceiling model does the part where intelligence compounds (understanding, judging, specifying). Cheaper models do the execution. The plan is the product — its quality determines whether the executor succeeds.\n\n## Hard Rules\n\n1. **Never modify source code yourself.** No edits, no fixes, no \"quick wins while you're in there.\" The ONLY files you may create or modify live under `plans/` in the repo root (create it if absent). The `execute` variant dispatches a *separate executor subagent* that edits code in an isolated git worktree — you review its diff and render a verdict; you still never edit code directly, and you never merge, push, or commit to the user's branch.\n2. **Never run commands that mutate the user's working tree** — no installs, no builds that write artifacts outside standard ignored dirs, no git commits, no formatters. Read, search, and run read-only analysis only (e.g. `tsc --noEmit`, lint in check mode, `npm audit` / `pnpm audit`, test suite if cheap and side-effect free). Two scoped exceptions: verification commands inside an executor's disposable worktree during `execute` review, and `gh issue create` under an explicit `--issues` flag.\n3. **Every plan must be fully self-contained.** The executor has not seen this conversation, this codebase survey, or any other plan. If a plan references \"the pattern discussed above,\" it is broken.\n4. **Never reproduce secret values.** If the audit finds credentials, tokens, or `.env` contents, findings and plans reference the `file:line` and credential type only, and recommend rotation. The value itself must never appear in anything you write.\n5. **If the user asks you to implement directly, decline and point at the plan** — offer `execute ` (dispatched executor + your review) or plan refinement instead.\n\n## Workflow\n\n### Phase 1 — Recon (always)\n\nMap the territory before judging it:\n\n- Read `README`, `CLAUDE.md`/`AGENTS.md`, `CONTRIBUTING`, root config files (`package.json`, `pyproject.toml`, `go.mod`, etc.), CI config, and the directory structure.\n- Identify: language(s), framework(s), package manager, **how to build / test / lint / typecheck** (exact commands — these go into every plan as verification gates), test coverage shape, deployment target.\n- Note repo conventions: code style, naming, folder layout, error-handling and state-management patterns. Plans must tell the executor to *match* these, with examples.\n- Check git signal where useful (`git log --oneline -30`, churn hotspots) for what's actively evolving vs. frozen.\n\nIf the repo has no working verification command (no tests, broken build), record that — \"establish a verification baseline\" is often finding #1, and it must precede risky plans in the dependency order.\n\n### Phase 2 — Audit (parallel)\n\nAudit the codebase across the categories in [references/audit-playbook.md](references/audit-playbook.md) — read it now. Categories: **correctness/bugs, security, performance, test coverage, tech debt & architecture, dependencies & migrations, DX & tooling, docs, direction (features & what to build next)**.\n\nFor repos of any real size, fan out with parallel read-only subagents (in Claude Code: **Explore** agents) — one per category (or cluster of related categories). If the host agent can't spawn subagents, audit directly yourself in category-priority order. **Subagents do not inherit this skill's context**, so each subagent prompt must include:\n\n- the **absolute path** to this skill's `references/audit-playbook.md` plus the exact section headings to read — **always including \"## Finding format\"** (subagents can read files — this is far cheaper than pasting; paste the sections only if the path may not resolve in the subagent's environment),\n- the recon facts that scope the search (languages, frameworks, key directories, what to skip),\n- domain-specific risk hints from recon (e.g. for a CLI that writes user files: \"pay attention to path traversal and command injection\"),\n- an explicit instruction to return findings only — no fixes, no file dumps — and to confirm it could read the playbook file.\n\nAudit depth follows the **effort level** (default `standard`; the user sets it with a `quick` / `deep` keyword anywhere in the invocation):\n\n| | `quick` | `standard` (default) | `deep` |\n|---|---|---|---|\n| Coverage | Recon hotspots only — highest-churn, highest-criticality code | Hotspot-weighted, key packages | Whole repo, every package |\n| Subagents | 0–1 (sweep directly when feasible) | ≤4 concurrent | ≤8 concurrent, one per category |\n| Breadth | \"medium\" | \"very thorough\" for correctness + security, \"medium\" rest | \"very thorough\" everywhere |\n| Categories | correctness, security, tests | all nine | all nine |\n| Findings | top ~6, HIGH-confidence only | full table | full table incl. LOW-confidence \"investigate\" items |\n\nWhatever the level, say in the final report what was *not* audited. On a large monorepo even `deep` scopes subagents to packages, not the root.\n\nEvery finding needs: evidence (`file:line` references), impact, effort estimate (S/M/L), risk of the fix itself, and confidence. No vibes-only findings.\n\n### Phase 3 — Vet, prioritize, confirm\n\n**Vet before presenting — subagents over-report.** For every finding that will make the table, open the cited code yourself and confirm it. Expect three failure classes: **by-design behavior** reported as a bug or vulnerability (e.g. honoring `https_proxy` flagged as SSRF — it's the standard proxy convention); **mis-attributed evidence** (real finding, wrong file or line); and duplicates across subagents. Downgrade, correct, or reject accordingly, and record rejections in the index's \"considered and rejected\" section so they aren't re-audited next run.\n\nPresent the vetted findings table to the user, ordered by leverage (impact ÷ effort, weighted by confidence):\n\n| # | Finding | Category | Impact | Effort | Risk | Evidence |\n\nPresent **direction findings separately**, after the table — they're options for the maintainer to weigh, not problems ranked against bugs, and burying \"build a plugin system\" under \"fix the N+1\" serves neither. 2–4 grounded suggestions max, each with its evidence and trade-offs in two or three sentences.\n\nThen ask which findings to turn into plans (default suggestion: the top 3–5 plus anything they flag). Also surface **dependency ordering** — e.g. \"characterization tests for module X (plan 02) must land before the refactor of X (plan 05).\"\n\nWait for the selection. Do not write 30 plans nobody asked for. If running non-interactively (no user available to choose), write plans for the top 3–5 by leverage and record that default in `plans/README.md`.\n\n### Phase 4 — Write the plans\n\nFor each selected finding, write one plan file using the template in [references/plan-template.md](references/plan-template.md) — read it before writing the first plan. Plans go in:\n\n```\nplans/\n README.md ← index: priority order, dependency graph, status table\n 001-.md\n 002-.md\n```\n\n**Excerpts come from your own reads, never from a subagent's report.** Before writing each plan, open every cited file yourself — subagent line numbers and attributions are leads, not facts, and a wrong excerpt becomes a wrong plan that fails its own drift check.\n\nBefore writing anything: record `git rev-parse --short HEAD` — every plan stamps the commit it was written against (the executor uses it for drift detection). If `plans/` already exists from a previous run, **reconcile, don't duplicate**: read `plans/README.md`, keep numbering monotonic, skip findings already planned or listed as rejected, and mark superseded plans stale in the index. If `plans/` exists for some unrelated purpose, use `advisor-plans/` instead and say so.\n\nWrite each plan **for the weakest plausible executor**. That means:\n\n- All context inlined: why this matters, exact file paths, current-state code excerpts, the repo's conventions to follow (with a snippet of an existing exemplar file).\n- Steps that are explicit and ordered, each with its own verification command and expected output.\n- Hard boundaries: files in scope, files explicitly out of scope, things that look related but must not be touched.\n- Machine-checkable done criteria — commands and expected results, not prose like \"works correctly.\"\n- A test plan (what new tests to write, where, following which existing test as a pattern).\n- A maintenance note (what future changes will interact with this, what to watch in review).\n- Escape hatches: \"if X turns out to be true, STOP and report back instead of improvising.\"\n\nFinish by writing `plans/README.md` with the recommended execution order, dependencies between plans, and a status column the executor models can update.\n\n## Invocation variants\n\n- Bare invocation → full workflow above.\n- `quick` / `deep` (anywhere in the invocation) → effort level for the audit; see the table in Phase 2. Composes with everything: `quick security`, `deep --issues`. Default is `standard`.\n- With a focus argument (e.g. `security`, `perf`, `tests`) → run Recon, then audit only that category, then plan.\n- `branch` → audit only the current working branch's changes: scope = files changed since the merge-base with the default branch (`git diff --name-only $(git merge-base origin/ HEAD)..HEAD`) plus their direct importers/callers. Light recon, all categories, usually no subagents. **Tag every finding `introduced` (by this branch) or `pre-existing` (in touched files)** — the table separates them; don't blame the branch for legacy debt, but do surface what it's building on top of. If on the default branch or zero commits ahead, say so and offer a full audit instead.\n- `next` (or `features`, `roadmap`) → run Recon, then audit only the direction category, in more depth: 4–6 grounded suggestions, each with evidence, trade-offs, and a coarse effort estimate. Selected ones become design/spike plans, not build-everything plans.\n- `plan ` → skip the audit; the user already knows what they want. Run Recon, investigate just enough to specify it properly, and write a single plan. If the description is too ambiguous to specify honestly, first try to resolve each ambiguity from the codebase itself; only what's left becomes questions to the user — asked one at a time, each with a recommended answer.\n- `review-plan ` → critique an existing plan in `plans/` against the template's standards and tighten it. If you authored the plan in this same session, also have a fresh-context subagent read it cold and report ambiguities — self-critique misses gaps you mentally fill from context the executor won't have.\n- `execute ` → dispatch a cheaper executor subagent on one plan (isolated worktree), then review its diff like a tech lead — re-run done criteria, check scope, read the code — and render a verdict. Requires a host agent that can spawn subagents in an isolated worktree; if yours can't, say so and hand the plan over for manual execution instead. **Read [references/closing-the-loop.md](references/closing-the-loop.md) before the first dispatch.**\n- `reconcile` → process what happened since last session: verify DONE plans, investigate BLOCKED ones, refresh drifted TODOs, retire dead findings. See [references/closing-the-loop.md](references/closing-the-loop.md).\n- `--issues` (modifier on any planning invocation) → also publish each written plan as a GitHub issue via `gh`, URL recorded in the plan and index. Only with the explicit flag. See [references/closing-the-loop.md](references/closing-the-loop.md).\n\n## Tone of the output\n\nYou are advising, not selling. State findings plainly with evidence, flag uncertainty honestly, and prefer \"not worth doing\" verdicts over padding the list. A short list of high-confidence, high-leverage plans beats a long one.\n","frontmatter":{"name":"improve","description":"Survey any codebase as a senior advisor and produce prioritized, self-contained implementation plans for OTHER models/agents to execute. Strictly read-only on source code — never implements, fixes, or refactors anything itself. Use when asked to audit a codebase, find improvement opportunities (bugs, security, performance, test coverage, tech debt, migrations, DX), suggest features or where to take the project next (roadmap, product direction), or generate handoff plans for another agent to implement.","license":"MIT","metadata":{"author":"shadcn","version":"1.0.0"}},"isInternal":false,"tokens":2877,"sizeBytes":12853},{"name":"package.json","path":"packages/config/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/config/package.json","title":"config","category":"anthropic-skill","format":"json","content":"{\n \"name\": \"config\",\n \"version\": \"14.0.0\",\n \"main\": \"index.js\",\n \"private\": true,\n \"license\": \"MIT\",\n \"files\": [\n \"tsconfig.json\"\n ]\n}\n","frontmatter":{"name":"config","version":"14.0.0","main":"index.js","private":true,"license":"MIT","files":["tsconfig.json"]},"isInternal":false,"tokens":54,"sizeBytes":163},{"name":"tsconfig.json","path":"packages/config/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/config/tsconfig.json","title":"Config Skill","category":"anthropic-skill","format":"json","content":"{\n \"compilerOptions\": {\n \"target\": \"es2020\",\n \"module\": \"esnext\",\n \"moduleResolution\": \"bundler\",\n \"isolatedModules\": false,\n \"importHelpers\": true,\n \"jsx\": \"react-jsx\",\n \"esModuleInterop\": true,\n \"experimentalDecorators\": true,\n \"emitDecoratorMetadata\": true,\n \"declaration\": true,\n \"declarationDir\": \"types\",\n \"noLib\": false,\n \"preserveConstEnums\": true,\n \"sourceMap\": true,\n \"strictNullChecks\": true,\n \"noImplicitAny\": true,\n \"noImplicitThis\": true,\n \"noImplicitUseStrict\": false,\n \"noUnusedLocals\": true,\n \"noUnusedParameters\": true,\n \"removeComments\": false,\n \"lib\": [\"es2017\", \"dom\"],\n \"skipLibCheck\": true,\n \"downlevelIteration\": true,\n \"stripInternal\": true\n },\n \"compileOnSave\": false,\n \"buildOnSave\": false\n}\n","frontmatter":{"compilerOptions":{"target":"es2020","module":"esnext","moduleResolution":"bundler","isolatedModules":false,"importHelpers":true,"jsx":"react-jsx","esModuleInterop":true,"experimentalDecorators":true,"emitDecoratorMetadata":true,"declaration":true,"declarationDir":"types","noLib":false,"preserveConstEnums":true,"sourceMap":true,"strictNullChecks":true,"noImplicitAny":true,"noImplicitThis":true,"noImplicitUseStrict":false,"noUnusedLocals":true,"noUnusedParameters":true,"removeComments":false,"lib":["es2017","dom"],"skipLibCheck":true,"downlevelIteration":true,"stripInternal":true},"compileOnSave":false,"buildOnSave":false},"isInternal":false,"tokens":227,"sizeBytes":906},{"name":"package.json","path":"packages/framer-motion/animate-view/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/animate-view/package.json","title":"Animate-view Skill","category":"anthropic-skill","format":"json","content":"# Animate-view Skill\n\nPath: `packages/framer-motion/animate-view/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/animate-view/package.json)","tokens":300,"sizeBytes":219},{"name":"package.json","path":"packages/framer-motion/client/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/client/package.json","title":"Client Skill","category":"anthropic-skill","format":"json","content":"# Client Skill\n\nPath: `packages/framer-motion/client/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/client/package.json)","tokens":300,"sizeBytes":201},{"name":"cypress.html.json","path":"packages/framer-motion/cypress.html.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress.html.json","title":"Framer-motion Skill","category":"anthropic-skill","format":"json","content":"{\n \"baseUrl\": \"http://localhost:8000\",\n \"integrationFolder\": \"cypress/integration-html\",\n \"video\": true,\n \"screenshots\": false,\n \"retries\": 2,\n \"reporter\": \"junit\",\n \"reporterOptions\": {\n \"mochaFile\": \"../../test_reports/framer-motion-html.xml\"\n }\n}\n","frontmatter":{"baseUrl":"http://localhost:8000","integrationFolder":"cypress/integration-html","video":true,"screenshots":false,"retries":2,"reporter":"junit","reporterOptions":{"mochaFile":"../../test_reports/framer-motion-html.xml"}},"isInternal":false,"tokens":80,"sizeBytes":281},{"name":"cypress.json","path":"packages/framer-motion/cypress.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress.json","title":"Framer-motion Skill","category":"anthropic-skill","format":"json","content":"{\n \"baseUrl\": \"http://localhost:9990\",\n \"experimentalShadowDomSupport\": true,\n \"video\": true,\n \"screenshots\": false,\n \"retries\": 2,\n \"reporter\": \"junit\",\n \"reporterOptions\": {\n \"mochaFile\": \"../../test_reports/framer-motion-[hash].xml\"\n }\n}\n","frontmatter":{"baseUrl":"http://localhost:9990","experimentalShadowDomSupport":true,"video":true,"screenshots":false,"retries":2,"reporter":"junit","reporterOptions":{"mochaFile":"../../test_reports/framer-motion-[hash].xml"}},"isInternal":false,"tokens":79,"sizeBytes":272},{"name":"cypress.react-19.json","path":"packages/framer-motion/cypress.react-19.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress.react-19.json","title":"Framer-motion Skill","category":"anthropic-skill","format":"json","content":"{\n \"baseUrl\": \"http://localhost:9991\",\n \"video\": true,\n \"screenshots\": false,\n \"retries\": 2,\n \"experimentalShadowDomSupport\": true,\n \"reporter\": \"junit\",\n \"reporterOptions\": {\n \"mochaFile\": \"../../test_reports/framer-motion-react-19-[hash].xml\"\n }\n}\n","frontmatter":{"baseUrl":"http://localhost:9991","video":true,"screenshots":false,"retries":2,"experimentalShadowDomSupport":true,"reporter":"junit","reporterOptions":{"mochaFile":"../../test_reports/framer-motion-react-19-[hash].xml"}},"isInternal":false,"tokens":82,"sizeBytes":281},{"name":"cypress.rsc.json","path":"packages/framer-motion/cypress.rsc.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress.rsc.json","title":"Framer-motion Skill","category":"anthropic-skill","format":"json","content":"# Framer-motion Skill\n\nPath: `packages/framer-motion/cypress.rsc.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress.rsc.json)","tokens":300,"sizeBytes":202},{"name":"animate-layout-tests.json","path":"packages/framer-motion/cypress/fixtures/animate-layout-tests.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/animate-layout-tests.json","title":"Fixtures Skill","category":"anthropic-skill","format":"json","content":"# Fixtures Skill\n\nPath: `packages/framer-motion/cypress/fixtures/animate-layout-tests.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/animate-layout-tests.json)","tokens":300,"sizeBytes":249},{"name":"appear-tests.json","path":"packages/framer-motion/cypress/fixtures/appear-tests.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/appear-tests.json","title":"Fixtures Skill","category":"anthropic-skill","format":"json","content":"# Fixtures Skill\n\nPath: `packages/framer-motion/cypress/fixtures/appear-tests.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/appear-tests.json)","tokens":300,"sizeBytes":233},{"name":"projection-tests.json","path":"packages/framer-motion/cypress/fixtures/projection-tests.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/projection-tests.json","title":"Fixtures Skill","category":"anthropic-skill","format":"json","content":"# Fixtures Skill\n\nPath: `packages/framer-motion/cypress/fixtures/projection-tests.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/projection-tests.json)","tokens":300,"sizeBytes":241},{"name":"tsconfig.json","path":"packages/framer-motion/cypress/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/tsconfig.json","title":"Cypress Skill","category":"anthropic-skill","format":"json","content":"# Cypress Skill\n\nPath: `packages/framer-motion/cypress/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/tsconfig.json)","tokens":300,"sizeBytes":206},{"name":"package.json","path":"packages/framer-motion/debug/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/debug/package.json","title":"Debug Skill","category":"anthropic-skill","format":"json","content":"# Debug Skill\n\nPath: `packages/framer-motion/debug/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/debug/package.json)","tokens":300,"sizeBytes":198},{"name":"package.json","path":"packages/framer-motion/dom/mini/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/mini/package.json","title":"Mini Skill","category":"anthropic-skill","format":"json","content":"# Mini Skill\n\nPath: `packages/framer-motion/dom/mini/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/mini/package.json)","tokens":300,"sizeBytes":203},{"name":"package.json","path":"packages/framer-motion/dom/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/package.json","title":"Dom Skill","category":"anthropic-skill","format":"json","content":"# Dom Skill\n\nPath: `packages/framer-motion/dom/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/package.json)","tokens":300,"sizeBytes":192},{"name":"jest.config.json","path":"packages/framer-motion/jest.config.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/jest.config.json","title":"Framer-motion Skill","category":"anthropic-skill","format":"json","content":"# Framer-motion Skill\n\nPath: `packages/framer-motion/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/jest.config.json)","tokens":300,"sizeBytes":202},{"name":"jest.config.ssr.json","path":"packages/framer-motion/jest.config.ssr.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/jest.config.ssr.json","title":"Framer-motion Skill","category":"anthropic-skill","format":"json","content":"# Framer-motion Skill\n\nPath: `packages/framer-motion/jest.config.ssr.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/jest.config.ssr.json)","tokens":300,"sizeBytes":210},{"name":"LICENSE.md","path":"packages/framer-motion/LICENSE.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/LICENSE.md","title":"Framer-motion Skill","category":"anthropic-skill","format":"markdown","content":"The MIT License (MIT)\n\nCopyright (c) 2018 Framer B.V.\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n","isInternal":false,"tokens":224,"sizeBytes":1078},{"name":"package.json","path":"packages/framer-motion/m/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/m/package.json","title":"M Skill","category":"anthropic-skill","format":"json","content":"# M Skill\n\nPath: `packages/framer-motion/m/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/m/package.json)","tokens":300,"sizeBytes":186},{"name":"package.json","path":"packages/framer-motion/mini/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/mini/package.json","title":"Mini Skill","category":"anthropic-skill","format":"json","content":"# Mini Skill\n\nPath: `packages/framer-motion/mini/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/mini/package.json)","tokens":300,"sizeBytes":195},{"name":"package.json","path":"packages/framer-motion/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/package.json","title":"Framer-motion Skill","category":"anthropic-skill","format":"json","content":"# Framer-motion Skill\n\nPath: `packages/framer-motion/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/package.json)","tokens":300,"sizeBytes":194},{"name":"tsconfig.json","path":"packages/framer-motion/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/tsconfig.json","title":"Framer-motion Skill","category":"anthropic-skill","format":"json","content":"# Framer-motion Skill\n\nPath: `packages/framer-motion/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/tsconfig.json)","tokens":300,"sizeBytes":196},{"name":"tsconfig.test.json","path":"packages/framer-motion/tsconfig.test.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/tsconfig.test.json","title":"Framer-motion Skill","category":"anthropic-skill","format":"json","content":"# Framer-motion Skill\n\nPath: `packages/framer-motion/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/tsconfig.test.json)","tokens":300,"sizeBytes":206},{"name":"jest.config.json","path":"packages/motion-dom/jest.config.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/jest.config.json","title":"Motion-dom Skill","category":"anthropic-skill","format":"json","content":"# Motion-dom Skill\n\nPath: `packages/motion-dom/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/jest.config.json)","tokens":300,"sizeBytes":193},{"name":"LICENSE.md","path":"packages/motion-dom/LICENSE.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/LICENSE.md","title":"Motion-dom Skill","category":"anthropic-skill","format":"markdown","content":"# Motion-dom Skill\n\nPath: `packages/motion-dom/LICENSE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/LICENSE.md)","tokens":300,"sizeBytes":181},{"name":"package.json","path":"packages/motion-dom/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/package.json","title":"Motion-dom Skill","category":"anthropic-skill","format":"json","content":"# Motion-dom Skill\n\nPath: `packages/motion-dom/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/package.json)","tokens":300,"sizeBytes":185},{"name":"tsconfig.json","path":"packages/motion-dom/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/tsconfig.json","title":"Motion-dom Skill","category":"anthropic-skill","format":"json","content":"# Motion-dom Skill\n\nPath: `packages/motion-dom/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/tsconfig.json)","tokens":300,"sizeBytes":187},{"name":"tsconfig.test.json","path":"packages/motion-dom/tsconfig.test.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/tsconfig.test.json","title":"Motion-dom Skill","category":"anthropic-skill","format":"json","content":"# Motion-dom Skill\n\nPath: `packages/motion-dom/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/tsconfig.test.json)","tokens":300,"sizeBytes":197},{"name":"jest.config.json","path":"packages/motion-utils/jest.config.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/jest.config.json","title":"Motion-utils Skill","category":"anthropic-skill","format":"json","content":"# Motion-utils Skill\n\nPath: `packages/motion-utils/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/jest.config.json)","tokens":300,"sizeBytes":199},{"name":"LICENSE.md","path":"packages/motion-utils/LICENSE.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/LICENSE.md","title":"Motion-utils Skill","category":"anthropic-skill","format":"markdown","content":"# Motion-utils Skill\n\nPath: `packages/motion-utils/LICENSE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/LICENSE.md)","tokens":300,"sizeBytes":187},{"name":"package.json","path":"packages/motion-utils/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/package.json","title":"Motion-utils Skill","category":"anthropic-skill","format":"json","content":"# Motion-utils Skill\n\nPath: `packages/motion-utils/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/package.json)","tokens":300,"sizeBytes":191},{"name":"tsconfig.json","path":"packages/motion-utils/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/tsconfig.json","title":"Motion-utils Skill","category":"anthropic-skill","format":"json","content":"# Motion-utils Skill\n\nPath: `packages/motion-utils/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/tsconfig.json)","tokens":300,"sizeBytes":193},{"name":"tsconfig.test.json","path":"packages/motion-utils/tsconfig.test.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/tsconfig.test.json","title":"Motion-utils Skill","category":"anthropic-skill","format":"json","content":"# Motion-utils Skill\n\nPath: `packages/motion-utils/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-utils/tsconfig.test.json)","tokens":300,"sizeBytes":203},{"name":"package.json","path":"packages/motion/debug/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/debug/package.json","title":"Debug Skill","category":"anthropic-skill","format":"json","content":"# Debug Skill\n\nPath: `packages/motion/debug/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/debug/package.json)","tokens":300,"sizeBytes":184},{"name":"jest.config.json","path":"packages/motion/jest.config.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/jest.config.json","title":"Motion Skill","category":"anthropic-skill","format":"json","content":"# Motion Skill\n\nPath: `packages/motion/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/jest.config.json)","tokens":300,"sizeBytes":181},{"name":"LICENSE.md","path":"packages/motion/LICENSE.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/LICENSE.md","title":"Motion Skill","category":"anthropic-skill","format":"markdown","content":"# Motion Skill\n\nPath: `packages/motion/LICENSE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/LICENSE.md)","tokens":300,"sizeBytes":169},{"name":"package.json","path":"packages/motion/mini/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/mini/package.json","title":"Mini Skill","category":"anthropic-skill","format":"json","content":"# Mini Skill\n\nPath: `packages/motion/mini/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/mini/package.json)","tokens":300,"sizeBytes":181},{"name":"package.json","path":"packages/motion/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/package.json","title":"Motion Skill","category":"anthropic-skill","format":"json","content":"# Motion Skill\n\nPath: `packages/motion/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/package.json)","tokens":300,"sizeBytes":173},{"name":"package.json","path":"packages/motion/react-animate-view/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react-animate-view/package.json","title":"React-animate-view Skill","category":"anthropic-skill","format":"json","content":"# React-animate-view Skill\n\nPath: `packages/motion/react-animate-view/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react-animate-view/package.json)","tokens":300,"sizeBytes":223},{"name":"package.json","path":"packages/motion/react-client/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react-client/package.json","title":"React-client Skill","category":"anthropic-skill","format":"json","content":"# React-client Skill\n\nPath: `packages/motion/react-client/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react-client/package.json)","tokens":300,"sizeBytes":205},{"name":"package.json","path":"packages/motion/react-m/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react-m/package.json","title":"React-m Skill","category":"anthropic-skill","format":"json","content":"# React-m Skill\n\nPath: `packages/motion/react-m/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react-m/package.json)","tokens":300,"sizeBytes":190},{"name":"package.json","path":"packages/motion/react/package.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react/package.json","title":"React Skill","category":"anthropic-skill","format":"json","content":"# React Skill\n\nPath: `packages/motion/react/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/react/package.json)","tokens":300,"sizeBytes":184},{"name":"tsconfig.json","path":"packages/motion/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/tsconfig.json","title":"Motion Skill","category":"anthropic-skill","format":"json","content":"# Motion Skill\n\nPath: `packages/motion/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/tsconfig.json)","tokens":300,"sizeBytes":175},{"name":"tsconfig.test.json","path":"packages/motion/tsconfig.test.json","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/tsconfig.test.json","title":"Motion Skill","category":"anthropic-skill","format":"json","content":"# Motion Skill\n\nPath: `packages/motion/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/tsconfig.test.json)","tokens":300,"sizeBytes":185},{"name":".cursorrules","path":".cursorrules","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/.cursorrules","title":"Cursor IDE Native Rules","category":"cursor-rule","format":"markdown","content":"## Writing tests\n\n- When waiting for the next frame, use an `async` test and await like so:\n\n```javascript\nasync function nextFrame() {\n return new Promise((resolve) => {\n frame.postRender(() => resolve())\n })\n}\n```","isInternal":false,"tokens":55,"sizeBytes":235},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Build & Development Commands\n\n```bash\n# Install dependencies (use make bootstrap for first-time setup)\nmake bootstrap\n\n# Build all packages (ALWAYS run from repo root, not from individual packages)\nyarn build # or: make build\n\n# Watch mode for development\nyarn watch # or: make watch\n\n# Run tests\nyarn test # Unit tests (Jest) for all packages, then type-checks src + tests\nyarn test-playwright # Playwright E2E tests\n\n# Run tests for a specific package\ncd packages/framer-motion && yarn test-client # Client-side Jest tests\ncd packages/framer-motion && yarn test-server # SSR Jest tests\n\n# Run E2E tests\nmake test-e2e # Runs all E2E tests (Next.js, HTML, React, React 19, Playwright)\nmake test-single # Run a single Cypress test (edit spec path in Makefile)\n```\n\n## Package Architecture\n\nThis is a Yarn workspaces monorepo managed by Turborepo and Lerna.\n\n### Core Packages (packages/)\n\n- **motion** - Main public package (`npm install motion`). Re-exports from framer-motion with cleaner entry points (`motion/react`, `motion/mini`)\n- **framer-motion** - Core implementation for React. Contains all animation logic, components, hooks, and features\n- **motion-dom** - DOM-specific animation utilities (animate, scroll, gestures, effects). Framework-agnostic\n- **motion-utils** - Shared utilities (easing, math helpers, error handling). No dependencies\n\n### Development Apps (dev/)\n\n- **dev/react** - React 18 development/test app (port 9990)\n- **dev/react-19** - React 19 development/test app (port 9991)\n- **dev/next** - Next.js development/test app (port 3000)\n- **dev/html** - Vanilla JS/HTML test pages (port 8000)\n\n### Package Dependency Flow\n\n```\nmotion-utils (base utilities)\n ↓\nmotion-dom (DOM animation engine)\n ↓\nframer-motion (React integration)\n ↓\nmotion (public API)\n```\n\n## Key Source Directories (packages/framer-motion/src/)\n\n- **animation/** - Animation system (animators, sequences, optimized-appear)\n- **components/** - React components (AnimatePresence, LayoutGroup, LazyMotion, Reorder)\n- **context/** - React contexts (MotionContext, PresenceContext, LayoutGroupContext)\n- **gestures/** - Gesture handling (drag, pan, tap, hover, focus)\n- **motion/** - Core motion component and feature system\n- **projection/** - Layout animation projection system (FLIP animations)\n- **render/** - Rendering pipeline (HTML, SVG, DOM utilities)\n- **value/** - Motion values and hooks (useMotionValue, useSpring, useScroll, useTransform)\n\n## Writing Tests\n\n**IMPORTANT: Always write tests for every bug fix AND every new feature.** Write a failing test FIRST before implementing, to ensure the issue is reproducible and the fix is verified.\n\n**\"Failing test\" means a test that reproduces the reported bug.** The test should assert the expected behavior and fail because of the bug — not because your planned code doesn't exist yet. A TypeScript compile error for an API you're about to add is not a failing test. Write the test against the existing codebase, see it fail for the right reason, then implement the fix.\n\n### Test types by feature\n\n- **Unit tests (Jest)**: Jest only transpiles TypeScript (no type-checking); test types are checked by `yarn typecheck` in each package (`tsc -p tsconfig.test.json`), which `yarn test` runs at the root. For pure logic, value transformations, utilities. Located in `__tests__/` directories alongside source. **JSDOM does not support WAAPI** (`Element.animate()`), so Jest tests only cover the JS animation fallback path.\n- **E2E tests (Cypress)**: For UI behavior that involves DOM rendering, scroll interactions, gesture handling, or WAAPI animations. Test specs in `packages/framer-motion/cypress/integration/`, test pages in `dev/react/src/tests/`.\n- **E2E tests (Playwright)**: For cross-browser testing and HTML/vanilla JS tests. Specs in `tests/`, test pages in `dev/html/public/playwright/`.\n\n### When to escalate from unit tests to Cypress\n\n**If a bug is reported with a reproduction but your unit test passes, do NOT conclude \"already works.\"** JSDOM lacks WAAPI, real layout, and real browser rendering. The bug is likely in the browser code path. You MUST:\n\n1. Create a Cypress E2E test that matches the reporter's reproduction as closely as possible.\n2. Verify the Cypress test fails before implementing a fix.\n3. If the bug involves `opacity`, `transform`, React.lazy/Suspense, scroll, layout animations, or any visual behavior — **start with Cypress**, skip the unit test entirely.\n\n### Creating Cypress E2E tests\n\n1. **Create a test page** in `dev/react/src/tests/.tsx` exporting a named `App` component. It's automatically available at `?test=`.\n2. **Create a spec** in `packages/framer-motion/cypress/integration/.ts`.\n3. **Verify WAAPI acceleration** using `element.getAnimations()` in Cypress callbacks — but **only for compositor properties** (opacity, transform). `getAnimations()` won't return WAAPI animations for non-compositor properties like height/width in Electron. Don't use it for those.\n\n### Cypress animation testing patterns\n\n- **Use `.then()`, not `.should()`, for mid-animation measurements.** `cy.should()` retries assertions until they pass or timeout — so it will keep retrying until the animation completes, masking bugs where the target value is wrong. `.then()` captures the value at a single point in time.\n- **For animation target bugs, use long duration + linear easing + mid-animation measurement.** Set `transition={{ type: \"tween\", ease: \"linear\", duration: 10 }}`, wait 5s (50% through), then check the computed style with `.then()`. If the target is wrong, the value will be proportionally wrong and easy to detect.\n- **Don't try `getAnimations()` for non-compositor properties** (height, width, etc.) in Cypress/Electron. It likely won't have WAAPI animations to inspect. Stick to computed style checks for these.\n- **Don't use `onUpdate` for mid-animation pixel values.** For keyword targets like `\"auto\"`, `onUpdate` reports the keyword, not the resolved pixel value. Use `getComputedStyle()` instead.\n- **Always run Cypress tests in the foreground.** Background bash commands hang silently and produce empty output, making debugging impossible. Cypress needs reliable stdout/stderr.\n\n### Running Cypress tests locally\n\n**You MUST run every new Cypress test against both React 18 and React 19 before creating a PR.** CI runs both and will break if you skip this.\n\n**Start the Vite dev server directly** — do NOT use `yarn start-server-and-test` with `yarn dev-server` (turbo). Turbo starts ALL dev servers including Next.js, which is slow and unreliable. Starting Vite directly is instant:\n\n```bash\n# React 18 — start Vite directly, then run Cypress\nPORT=$((10000 + RANDOM % 50000))\ncd dev/react && TEST_PORT=$PORT yarn vite --port $PORT &\nDEV_PID=$!\n# Wait for server to be ready\nnpx wait-on http://localhost:$PORT\ncd packages/framer-motion && cypress run --headed --config baseUrl=http://localhost:$PORT --spec cypress/integration/.ts\nkill $DEV_PID\n\n# React 19 — same pattern, start its Vite server independently\nPORT=$((10000 + RANDOM % 50000))\ncd dev/react-19 && TEST_PORT=$PORT yarn vite --port $PORT &\nDEV_PID=$!\nnpx wait-on http://localhost:$PORT\ncd packages/framer-motion && cypress run --config-file=cypress.react-19.json --config baseUrl=http://localhost:$PORT --headed --spec cypress/integration/.ts\nkill $DEV_PID\n```\n\n**Do NOT set `TEST_PORT` globally with turbo** — it affects both React 18 and 19 dev servers, causing port conflicts. Start each server independently on its own port as shown above.\n\nBoth must pass. If a test fails on one React version but not the other, investigate — do not skip it.\n\n### Async test helpers\n\nWhen waiting for the next frame in async tests:\n\n```javascript\nasync function nextFrame() {\n return new Promise((resolve) => {\n frame.postRender(() => resolve())\n })\n}\n```\n\n## Code Style\n\n- **Prioritise small file size** — this is a library shipped to end users. Prefer concise patterns that minimise output bytes.\n- Prefer optional chaining (`value?.jump()`) over explicit `if` statements\n- Use `interface` for type definitions\n- No default exports (use named exports)\n- Prefer arrow callbacks\n- Use strict equality (`===`)\n- No `var` declarations (use `const`/`let`)\n\n## Fixing Issues from Bug Reports\n\nWhen working on a bug fix from a GitHub issue:\n\n1. **Read the issue first.** Run `gh issue view ` before doing anything else. Do not infer the ask from code context or agent exploration — read the actual issue to understand what's being requested.\n2. **Check git history early.** Before tracing code, run `git log --grep=\"\" -- ` to see if the bug was already fixed or if prior commits reveal the root cause. This can save an entire session of manual code tracing.\n3. **The reporter's reproduction code is the basis for your test.** If the issue links to a CodeSandbox/StackBlitz, fetch it. Try multiple URL patterns if the first fails. If the issue has inline code, use that directly.\n4. **If you cannot get the reproduction code, STOP and ask for help.** Do not guess at what the reporter meant — that leads to tests that prove nothing. Message the team lead with the URL and ask them to provide the code.\n5. **Do not proceed to a fix without a test that fails for the right reason.** See the \"Writing Tests\" section above.\n6. **Run one clean install, then wait for it to finish.** Do not run `make bootstrap`, `yarn install`, or `corepack enable && yarn install` as overlapping background tasks — they interfere with each other. One install command, foreground, wait for completion.\n\n### Debugging strategy\n\n- **Get to a test fast.** Do not spend extended time on static code analysis trying to find the bug by reading code. Read enough to form an initial theory (~5 min of tracing), then write a test and start experimenting. Most bugs are found faster through testing than through code reading. This is the single most common mistake — it has caused excessive time waste in multiple sessions.\n- **Use targeted searches, not broad exploration.** Prefer `grep`/`glob` for specific functions (e.g. `isHTMLElement`, `supportsBrowserAnimation`) over large Explore agent calls. Two targeted searches beat one broad sweep.\n- **Pivot quickly when your theory is wrong.** If tracing a code path (e.g. the render pipeline) is inconclusive after 2-3 rounds of investigation, step back and look at adjacent systems — utility functions, type guards, environment checks. The bug is often one level removed from where you expect it.\n- **When a bug can't be reproduced in the test environment, stop after 2-3 attempts.** Electron/JSDOM differ from Chrome in significant ways (e.g. `offsetHeight` on SVGElement, WAAPI support, React reconciliation in dev mode). If your test passes from the start: (1) do a web search for the behavioral difference between environments, (2) if the fix is clearly correct and defensive, apply it and write a test that validates the desired behavior — do not spend 10 Cypress runs trying to force a local failure. A test that can't fail without the fix is acceptable when the bug is environment-specific; note this in the PR.\n- **Capture Cypress output on the first run.** Use `tail -60` on the output. Do not re-run Cypress with different grep patterns to capture errors — it wastes time and the information is in the first run.\n- **Think defensively, not forensically.** You don't always need to trace the exact scenario that produces bad input. If a function can receive invalid values and pass them to a browser API, the fix is to guard against that — regardless of which upstream path produces those values. Ask: \"should this value ever reach this API?\" If no, add the guard and move on.\n- **Choose the right test layer.** Some behaviors can't be directly asserted in tests (e.g. Chrome WAAPI console warnings can't be intercepted via `console.warn` spy). In these cases, unit-test the underlying logic (e.g. `canAnimate`, `isAnimatable`) rather than writing an E2E test that can't actually prove the bug is fixed. Write the E2E test too if it adds value, but recognize which test is the real regression gate.\n- **Avoid background task sprawl.** Do not launch multiple background exploration tasks early in a session. They complete after they're needed and generate noise. Launch tasks when you need their results, not speculatively.\n\n## Known GitHub CLI Issues\n\n`gh pr edit` fails on this repo due to GitHub's Projects Classic deprecation blocking the GraphQL mutation. **This is expected — do not investigate, retry, or work around it.** If `gh pr create` succeeded and the code is pushed, you're done. Move on.\n\n## Notes\n\nBe thorough - I am at risk of losing my job.\n\n## Timing\n\nUse `time.now()` from `motion-dom/src/frameloop/sync-time.ts` instead of `performance.now()` for frame-synced timestamps. This ensures consistent time measurements within synchronous contexts and proper sync with the animation frame loop.\n","isInternal":false,"tokens":3053,"sizeBytes":13214},{"name":"README.md","path":"packages/framer-motion/client/README.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/client/README.md","title":"client Documentation","category":"plugin-manifest","format":"markdown","content":"# client Documentation\n\nPath: `packages/framer-motion/client/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/client/README.md)","tokens":300,"sizeBytes":203},{"name":"README.md","path":"packages/framer-motion/debug/README.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/debug/README.md","title":"debug Documentation","category":"plugin-manifest","format":"markdown","content":"# debug Documentation\n\nPath: `packages/framer-motion/debug/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/debug/README.md)","tokens":300,"sizeBytes":200},{"name":"README.md","path":"packages/framer-motion/dom/README.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/README.md","title":"dom Documentation","category":"plugin-manifest","format":"markdown","content":"# dom Documentation\n\nPath: `packages/framer-motion/dom/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/README.md)","tokens":300,"sizeBytes":194},{"name":"README.md","path":"packages/framer-motion/README.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/README.md","title":"framer-motion Documentation","category":"plugin-manifest","format":"markdown","content":"

\"Motion
Motion for React

\n

\n An open source animation library
for React\n

\n\n

\n \"npm\n \"npm\n \"jsDelivr\n \"NPM\n \"MotionScore\n

\n\n```bash\nnpm install motion\n```\n\n## Table of Contents\n\n1. [Why Motion?](#why-motion)\n2. [🍦 Platforms](#-platforms)\n3. [🎓 Examples](#-examples)\n4. [🎨 Motion Studio](#-motion-studio)\n4. [🤖 Using Motion with AI](#-using-motion-with-ai)\n5. [⚡️ Motion+](#-motion)\n6. [👩🏻‍⚖️ License](#-license)\n7. [💎 Contribute](#-contribute)\n8. [✨ Sponsors](#-sponsors)\n\n## Why Motion?\n\n- **Simple API:** First-class React, JavaScript, and Vue packages.\n- **Hybrid engine:** Power of JavaScript combined with native browser APIs for 120fps, GPU-accelerated animations.\n- **Production-ready:** TypeScript, extensive test suite, tree-shakable, tiny footprint.\n **Batteries included:** Gestures, springs, layout transitions, scroll-linked effects, timelines.\n\n## 🍦 Platforms\n\nMotion is available for [React](https://motion.dev/docs/react), [JavaScript](https://motion.dev/docs/quick-start) and [Vue](https://motion.dev/docs/vue).\n\n### React\n\n```jsx\nimport { motion } from \"motion/react\"\n\nfunction Component() {\n return \n}\n```\n\nGet started with [Motion for React](https://motion.dev/docs/react).\n\n**Note:** Framer Motion is now Motion. Import from `motion/react` instead of `framer-motion`.\n\n### JS\n\n```javascript\nimport { animate } from \"motion\"\n\nanimate(\"#box\", { x: 100 })\n```\n\nGet started with [JavaScript](https://motion.dev/docs/quick-start).\n\n### Vue\n\n```html\n\n\n\n```\n\nGet started with [Motion for Vue](https://motion.dev/docs/vue).\n\n## 🎓 Examples & tutorials\n\nBrowse 450+ [official examples](https://motion.dev/examples), with copy-paste code that'll level-up your animations whether you're a beginner or an expert.\n\nOver 110 examples come with a full step-by-step tutorial on [their example page](https://motion.dev/examples).\n\n## 🤖 Using Motion with AI\n\nGive your coding agent current Motion docs:\n\n- **Agent skill:** `npx motion-ai` installs the free, MIT-licensed `/motion` skill and sets up Motion's MCP servers for Claude Code, Cursor, Amp, OpenCode, Gemini CLI and Copilot. [Source on GitHub](https://github.com/motiondivision/ai-kit).\n- **MCP server:** `https://mcp.motion.dev` searches the Motion docs and example metadata. It is free and needs no account.\n- **llms.txt:** [motion.dev/llms.txt](https://motion.dev/llms.txt?utm_source=npm-readme) indexes every docs page. Motion+ pages are labelled as paid, with their install and import.\n\n[Motion+](https://motion.dev/plus?utm_source=npm-readme) adds example and Motion UI source, MotionScore performance audits and CSS spring generation for your agent.\n\n## 🎨 Motion Studio\n\nA visual animation editor for your website. Edit keyframes, easing curves and springs on a live timeline, or describe changes to the Ultramotion agent, then apply the result straight to your code with Cursor, Codex or Claude.\n\n[Explore Motion Studio](https://motion.dev/studio)\n\n## ⚡️ Motion+\n\nA one-time Personal licence with lifetime updates, or an annual per-seat Business plan for teams:\n\n- **450+ examples**\n- **110+ tutorials**\n- **Premium APIs** like [Cursor](https://motion.dev/docs/cursor) and [Ticker](https://motion.dev/docs/react-ticker)\n- **Transition editor** for Cursor and VS Code\n- **AI Kit:** example and Motion UI source, MotionScore audits and CSS springs for your agent\n- **Private Discord**\n- **Early access content**\n\n[Get Motion+](https://motion.dev/plus)\n\n## 👩🏻‍⚖️ License\n\n- Motion is MIT licensed.\n\n## 💎 Contribute\n\n- Want to contribute to Motion? Our [contributing guide](https://github.com/motiondivision/motion/blob/master/CONTRIBUTING.md) has you covered.\n\n## ✨ Sponsors\n\nMotion is sustainable thanks to the kind support of its sponsors.\n\n[Become a sponsor](https://motion.dev/sponsor)\n\n### Partners\n\nMotion powers the animations for all websites built with Framer, the web builder for creative pros. The Motion website itself is built on Framer, for its delightful canvas-based editing and powerful CMS features.\n\n\n \"Framer\"\n\n\nMotion drives the animations on the Cursor homepage, and is working with Cursor to bring powerful AI workflows to the Motion examples and docs.\n\n\n \"Cursor\"\n\n\n### Platinum\n\n\"Linear\" \"Figma\" \"Sanity\" \"Clerk\"\n\n### Gold\n\n### Silver\n\n\"Liveblocks\" \"Frontend.fyi\" \"Firecrawl\" \"Bolt.new\"\n\n### Personal\n\n- [OlegWock](https://sinja.io)\n- [Lambert Weller](https://github.com/l-mbert)\n- [Jake LeBoeuf](https://jklb.wf)\n","isInternal":false,"tokens":2149,"sizeBytes":7401},{"name":"README.md","path":"packages/motion/README.md","rawUrl":"https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/README.md","title":"motion Documentation","category":"plugin-manifest","format":"markdown","content":"# motion Documentation\n\nPath: `packages/motion/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion/README.md)","tokens":300,"sizeBytes":175}],"systemPromptSnippet":"\n\n## Structure\n\nThis is a monorepo. Development and test environments live in `/dev`, packages live in `/packages`.\n\nPackages are:\n\n- `framer-motion`: For React-specific code. More of this should be refactored to `motion-dom` where possible.\n- `motion`: Re-export of `framer-motion`.\n- `motion-dom`: Vanilla/JS animation library.\n- `motion-utils`: Pure functions and easing functions.\n\n## Tests\n\nThere are three types of test suites in Motion.\n\n1. Jest (unit) tests\n2. Cypress e2e tests\n3. Playwright e2e tests\n\n### Jest\n\nStructure code to be unit testable where possible. Co-locate a unit test in a `__tests__` folder. Name the unit tests for a file `.test.ts(x)`.\n\nRun with `yarn test`.\n\n### Cypress\n\nThe Cypress test suite is for testing React code in a browser environment.\n\nWhen a piece of UI is interactable, or we rely on browser APIs, write a Cypress test. The UI files should live in `dev/react/src/tests` and the test files to run against them live in `packages/framer-motion/cypress/integration`.\n\nRun with `yarn test-e2e`.\n\n### Playwright\n\nThe Cypress test suite is for testing vanilla JS code in a browser environment.\n\nThe UI files live in `dev/html/public/playwright` and the test files live in `/tests`.\n\nRun with `yarn test-playwright`.\n\n\n---\nname: fix\ndescription: Take a GitHub issue, an open PR, or a plan file from plans/ and drive it to a merge-ready PR — reproduce with a failing test first, implement the fix (bugs) or feature (plans), verify against the repo's gates, and open or update the PR. Use when asked to fix an issue, implement or execute a plan, finish or land an open PR, or work through plans/issues/.\nmetadata:\n author: mattgperry\n version: \"1.0.0\"\n---\n\n# Fix\n\nYou are the **executor**. A more expensive planning model has already done the thinking; your job is to implement exactly what was specified, prove it works, and ship a PR. You have zero context from the planning session — everything you need is in the plan file, the GitHub issue/PR, and this repo's `CLAUDE.md`. Read all three before writing any code.\n\n## Resolving the input\n\nThe argument can be:\n\n1. **A plan file path** (e.g. `plans/issues/pr-3724.md` or `plans/001-animate-layout-public-api.md`) — read it in full. Plans are the primary input for this skill.\n2. **A plan number** (e.g. `008`) — find the matching file in `plans/` or `plans/issues/`.\n3. **A GitHub issue number** (e.g. `#3741`) — run `gh issue view ` first. Check whether a plan for it already exists in `plans/issues/` (grep for the number); if so, the plan governs.\n4. **A PR number** — run `gh pr view ` and `gh pr checks `. Check `plans/issues/` for a plan covering that PR; if so, the plan governs.\n\nIf the argument is ambiguous or matches nothing, list what you found and stop — do not guess which work item was meant.\n\n## Hard rules\n\n1. **The plan is the spec.** Do not redesign, expand scope, or \"improve while you're in there.\" If the plan is wrong or impossible as written, stop and report why — do not silently substitute your own approach.\n2. **Honor the plan's STOP conditions.** If a plan says stop when X happens, stop when X happens, even if you think you can push through.\n3. **No repro → no fix.** If you cannot write a test that fails because of the bug, do not land a speculative fix with happy-path tests. Report \"needs repro\" instead. (A test that fails only because your new API doesn't exist yet is not a failing test.)\n4. **Never commit to `main`.** Branch first (`/`, e.g. `fix/3741-turbopack-reexport`). One work item per branch per PR.\n5. **Report faithfully.** If tests fail, say so with output. If you skipped a verification gate, say which and why. Never describe unverified work as done.\n\n## Workflow\n\n### Phase 0 — Understand\n\n- Read the plan file end to end, including its verification gates and STOP conditions.\n- Read the linked issue/PR with `gh issue view` / `gh pr view --comments`. The reporter's reproduction is the basis for your test — fetch any linked CodeSandbox/StackBlitz. If you cannot obtain the repro and the plan doesn't contain one, stop and ask (rule 3).\n- Run `git log --grep=\"\" --oneline -- ` — the bug may already be fixed, or prior commits may reveal the root cause.\n- Read `CLAUDE.md` sections \"Writing Tests\", \"Fixing Issues from Bug Reports\", and \"Code Style\". Those rules apply in full and are not repeated here.\n\n### Phase 1 — Failing test first\n\n- Write the test **before** the implementation and watch it fail *for the right reason* (the bug / missing behavior — not a typo or missing import).\n- Choose the layer per `CLAUDE.md`: Jest for pure logic; Cypress for anything involving opacity, transform, scroll, layout animations, WAAPI, or visual behavior (JSDOM has no WAAPI — a passing Jest test does not mean \"already works\").\n- For features, the failing test asserts the new behavior described in the plan's acceptance criteria.\n\n### Phase 2 — Implement\n\n- Smallest change that makes the test pass while matching surrounding code style. This library ships to end users — prioritise small output size.\n- Build from the repo root (`yarn build`), never from inside a package.\n- If the plan specifies files and approach, follow them. Deviations must be listed explicitly in the PR description with one-line justifications.\n\n### Phase 3 — Verify\n\nRun every gate the plan names. Defaults when the plan doesn't say:\n\n- `yarn build` from root, then the relevant Jest suite(s).\n- New/changed Cypress tests against **both** React 18 and React 19, using the direct-Vite recipe in `CLAUDE.md` (never `start-server-and-test` + turbo). Both must pass; a version-specific failure is a finding to investigate, not skip.\n- `yarn lint` on touched packages.\n- Ignore only the pre-existing known failures listed in `CLAUDE.md`/memory (SSR TextEncoder, use-velocity).\n\n### Phase 4 — Ship & bookkeeping\n\n- Commit with a message that references the issue/plan (`Fix #3741: …`). Push and open a PR with `gh pr create`, linking the issue (`Fixes #`) and summarising: root cause, approach, tests added, gates run with results, deviations from the plan.\n- **Do not use `gh pr edit`** — it is known-broken on this repo (Projects Classic deprecation). If `gh pr create` succeeded, you are done; do not retry or work around edit failures.\n- Update the plan's status: set its row in the relevant `plans/**/README.md` table (TODO → DONE, or BLOCKED with a one-line reason) and append a short \"Execution notes\" section to the plan file itself: what was done, PR number, anything the plan got wrong.\n\n### When working on an existing open PR\n\nThe work item may be \"finish PR #N\" rather than \"fix issue #N\". Then:\n\n- `gh pr checkout `; rebase on `main` if behind, resolving conflicts conservatively (prefer `main`'s version for code the PR doesn't deliberately change).\n- `gh pr checks ` and read failing CI logs before touching code — the plan should say what's blocking; verify it still is.\n- Address review comments listed in the plan. Push to the same branch. Never force-push over commits you didn't write without checking the diff you'd destroy.\n\n## STOP conditions (always, in addition to the plan's own)\n\n- The failing test won't fail (can't reproduce) after 2–3 honest attempts → report \"needs repro\" with what you tried.\n- The plan's approach conflicts with code that changed since the plan was written → report the conflict; do not improvise a new design.\n- A verification gate fails and the fix isn't obvious within a few attempts → report the failure output.\n- The change would touch `packages/framer-motion/src/projection/` or the effects/VisualElement system in ways the plan didn't anticipate → stop; these systems have in-flight rewrites.\n\n\n# References Skill\n\nPath: `.agents/skills/improve/references/audit-playbook.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/audit-playbook.md)\n\n\n# References Skill\n\nPath: `.agents/skills/improve/references/closing-the-loop.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/closing-the-loop.md)\n\n\n# References Skill\n\nPath: `.agents/skills/improve/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/.agents/skills/improve/references/plan-template.md)\n\n\n---\nname: improve\ndescription: Survey any codebase as a senior advisor and produce prioritized, self-contained implementation plans for OTHER models/agents to execute. Strictly read-only on source code — never implements, fixes, or refactors anything itself. Use when asked to audit a codebase, find improvement opportunities (bugs, security, performance, test coverage, tech debt, migrations, DX), suggest features or where to take the project next (roadmap, product direction), or generate handoff plans for another agent to implement.\nlicense: MIT\nmetadata:\n author: shadcn\n version: \"1.0.0\"\n---\n\n# Improve\n\nYou are a **senior advisor, not an implementer**. Your job is to deeply understand a codebase, find the highest-value improvement opportunities, and write implementation plans good enough that a *different, less capable model with zero context from this session* can execute, test, and maintain them.\n\nThe economics of this skill: an expensive, high-ceiling model does the part where intelligence compounds (understanding, judging, specifying). Cheaper models do the execution. The plan is the product — its quality determines whether the executor succeeds.\n\n## Hard Rules\n\n1. **Never modify source code yourself.** No edits, no fixes, no \"quick wins while you're in there.\" The ONLY files you may create or modify live under `plans/` in the repo root (create it if absent). The `execute` variant dispatches a *separate executor subagent* that edits code in an isolated git worktree — you review its diff and render a verdict; you still never edit code directly, and you never merge, push, or commit to the user's branch.\n2. **Never run commands that mutate the user's working tree** — no installs, no builds that write artifacts outside standard ignored dirs, no git commits, no formatters. Read, search, and run read-only analysis only (e.g. `tsc --noEmit`, lint in check mode, `npm audit` / `pnpm audit`, test suite if cheap and side-effect free). Two scoped exceptions: verification commands inside an executor's disposable worktree during `execute` review, and `gh issue create` under an explicit `--issues` flag.\n3. **Every plan must be fully self-contained.** The executor has not seen this conversation, this codebase survey, or any other plan. If a plan references \"the pattern discussed above,\" it is broken.\n4. **Never reproduce secret values.** If the audit finds credentials, tokens, or `.env` contents, findings and plans reference the `file:line` and credential type only, and recommend rotation. The value itself must never appear in anything you write.\n5. **If the user asks you to implement directly, decline and point at the plan** — offer `execute ` (dispatched executor + your review) or plan refinement instead.\n\n## Workflow\n\n### Phase 1 — Recon (always)\n\nMap the territory before judging it:\n\n- Read `README`, `CLAUDE.md`/`AGENTS.md`, `CONTRIBUTING`, root config files (`package.json`, `pyproject.toml`, `go.mod`, etc.), CI config, and the directory structure.\n- Identify: language(s), framework(s), package manager, **how to build / test / lint / typecheck** (exact commands — these go into every plan as verification gates), test coverage shape, deployment target.\n- Note repo conventions: code style, naming, folder layout, error-handling and state-management patterns. Plans must tell the executor to *match* these, with examples.\n- Check git signal where useful (`git log --oneline -30`, churn hotspots) for what's actively evolving vs. frozen.\n\nIf the repo has no working verification command (no tests, broken build), record that — \"establish a verification baseline\" is often finding #1, and it must precede risky plans in the dependency order.\n\n### Phase 2 — Audit (parallel)\n\nAudit the codebase across the categories in [references/audit-playbook.md](references/audit-playbook.md) — read it now. Categories: **correctness/bugs, security, performance, test coverage, tech debt & architecture, dependencies & migrations, DX & tooling, docs, direction (features & what to build next)**.\n\nFor repos of any real size, fan out with parallel read-only subagents (in Claude Code: **Explore** agents) — one per category (or cluster of related categories). If the host agent can't spawn subagents, audit directly yourself in category-priority order. **Subagents do not inherit this skill's context**, so each subagent prompt must include:\n\n- the **absolute path** to this skill's `references/audit-playbook.md` plus the exact section headings to read — **always including \"## Finding format\"** (subagents can read files — this is far cheaper than pasting; paste the sections only if the path may not resolve in the subagent's environment),\n- the recon facts that scope the search (languages, frameworks, key directories, what to skip),\n- domain-specific risk hints from recon (e.g. for a CLI that writes user files: \"pay attention to path traversal and command injection\"),\n- an explicit instruction to return findings only — no fixes, no file dumps — and to confirm it could read the playbook file.\n\nAudit depth follows the **effort level** (default `standard`; the user sets it with a `quick` / `deep` keyword anywhere in the invocation):\n\n| | `quick` | `standard` (default) | `deep` |\n|---|---|---|---|\n| Coverage | Recon hotspots only — highest-churn, highest-criticality code | Hotspot-weighted, key packages | Whole repo, every package |\n| Subagents | 0–1 (sweep directly when feasible) | ≤4 concurrent | ≤8 concurrent, one per category |\n| Breadth | \"medium\" | \"very thorough\" for correctness + security, \"medium\" rest | \"very thorough\" everywhere |\n| Categories | correctness, security, tests | all nine | all nine |\n| Findings | top ~6, HIGH-confidence only | full table | full table incl. LOW-confidence \"investigate\" items |\n\nWhatever the level, say in the final report what was *not* audited. On a large monorepo even `deep` scopes subagents to packages, not the root.\n\nEvery finding needs: evidence (`file:line` references), impact, effort estimate (S/M/L), risk of the fix itself, and confidence. No vibes-only findings.\n\n### Phase 3 — Vet, prioritize, confirm\n\n**Vet before presenting — subagents over-report.** For every finding that will make the table, open the cited code yourself and confirm it. Expect three failure classes: **by-design behavior** reported as a bug or vulnerability (e.g. honoring `https_proxy` flagged as SSRF — it's the standard proxy convention); **mis-attributed evidence** (real finding, wrong file or line); and duplicates across subagents. Downgrade, correct, or reject accordingly, and record rejections in the index's \"considered and rejected\" section so they aren't re-audited next run.\n\nPresent the vetted findings table to the user, ordered by leverage (impact ÷ effort, weighted by confidence):\n\n| # | Finding | Category | Impact | Effort | Risk | Evidence |\n\nPresent **direction findings separately**, after the table — they're options for the maintainer to weigh, not problems ranked against bugs, and burying \"build a plugin system\" under \"fix the N+1\" serves neither. 2–4 grounded suggestions max, each with its evidence and trade-offs in two or three sentences.\n\nThen ask which findings to turn into plans (default suggestion: the top 3–5 plus anything they flag). Also surface **dependency ordering** — e.g. \"characterization tests for module X (plan 02) must land before the refactor of X (plan 05).\"\n\nWait for the selection. Do not write 30 plans nobody asked for. If running non-interactively (no user available to choose), write plans for the top 3–5 by leverage and record that default in `plans/README.md`.\n\n### Phase 4 — Write the plans\n\nFor each selected finding, write one plan file using the template in [references/plan-template.md](references/plan-template.md) — read it before writing the first plan. Plans go in:\n\n```\nplans/\n README.md ← index: priority order, dependency graph, status table\n 001-.md\n 002-.md\n```\n\n**Excerpts come from your own reads, never from a subagent's report.** Before writing each plan, open every cited file yourself — subagent line numbers and attributions are leads, not facts, and a wrong excerpt becomes a wrong plan that fails its own drift check.\n\nBefore writing anything: record `git rev-parse --short HEAD` — every plan stamps the commit it was written against (the executor uses it for drift detection). If `plans/` already exists from a previous run, **reconcile, don't duplicate**: read `plans/README.md`, keep numbering monotonic, skip findings already planned or listed as rejected, and mark superseded plans stale in the index. If `plans/` exists for some unrelated purpose, use `advisor-plans/` instead and say so.\n\nWrite each plan **for the weakest plausible executor**. That means:\n\n- All context inlined: why this matters, exact file paths, current-state code excerpts, the repo's conventions to follow (with a snippet of an existing exemplar file).\n- Steps that are explicit and ordered, each with its own verification command and expected output.\n- Hard boundaries: files in scope, files explicitly out of scope, things that look related but must not be touched.\n- Machine-checkable done criteria — commands and expected results, not prose like \"works correctly.\"\n- A test plan (what new tests to write, where, following which existing test as a pattern).\n- A maintenance note (what future changes will interact with this, what to watch in review).\n- Escape hatches: \"if X turns out to be true, STOP and report back instead of improvising.\"\n\nFinish by writing `plans/README.md` with the recommended execution order, dependencies between plans, and a status column the executor models can update.\n\n## Invocation variants\n\n- Bare invocation → full workflow above.\n- `quick` / `deep` (anywhere in the invocation) → effort level for the audit; see the table in Phase 2. Composes with everything: `quick security`, `deep --issues`. Default is `standard`.\n- With a focus argument (e.g. `security`, `perf`, `tests`) → run Recon, then audit only that category, then plan.\n- `branch` → audit only the current working branch's changes: scope = files changed since the merge-base with the default branch (`git diff --name-only $(git merge-base origin/ HEAD)..HEAD`) plus their direct importers/callers. Light recon, all categories, usually no subagents. **Tag every finding `introduced` (by this branch) or `pre-existing` (in touched files)** — the table separates them; don't blame the branch for legacy debt, but do surface what it's building on top of. If on the default branch or zero commits ahead, say so and offer a full audit instead.\n- `next` (or `features`, `roadmap`) → run Recon, then audit only the direction category, in more depth: 4–6 grounded suggestions, each with evidence, trade-offs, and a coarse effort estimate. Selected ones become design/spike plans, not build-everything plans.\n- `plan ` → skip the audit; the user already knows what they want. Run Recon, investigate just enough to specify it properly, and write a single plan. If the description is too ambiguous to specify honestly, first try to resolve each ambiguity from the codebase itself; only what's left becomes questions to the user — asked one at a time, each with a recommended answer.\n- `review-plan ` → critique an existing plan in `plans/` against the template's standards and tighten it. If you authored the plan in this same session, also have a fresh-context subagent read it cold and report ambiguities — self-critique misses gaps you mentally fill from context the executor won't have.\n- `execute ` → dispatch a cheaper executor subagent on one plan (isolated worktree), then review its diff like a tech lead — re-run done criteria, check scope, read the code — and render a verdict. Requires a host agent that can spawn subagents in an isolated worktree; if yours can't, say so and hand the plan over for manual execution instead. **Read [references/closing-the-loop.md](references/closing-the-loop.md) before the first dispatch.**\n- `reconcile` → process what happened since last session: verify DONE plans, investigate BLOCKED ones, refresh drifted TODOs, retire dead findings. See [references/closing-the-loop.md](references/closing-the-loop.md).\n- `--issues` (modifier on any planning invocation) → also publish each written plan as a GitHub issue via `gh`, URL recorded in the plan and index. Only with the explicit flag. See [references/closing-the-loop.md](references/closing-the-loop.md).\n\n## Tone of the output\n\nYou are advising, not selling. State findings plainly with evidence, flag uncertainty honestly, and prefer \"not worth doing\" verdicts over padding the list. A short list of high-confidence, high-leverage plans beats a long one.\n\n\n{\n \"name\": \"config\",\n \"version\": \"14.0.0\",\n \"main\": \"index.js\",\n \"private\": true,\n \"license\": \"MIT\",\n \"files\": [\n \"tsconfig.json\"\n ]\n}\n\n\n{\n \"compilerOptions\": {\n \"target\": \"es2020\",\n \"module\": \"esnext\",\n \"moduleResolution\": \"bundler\",\n \"isolatedModules\": false,\n \"importHelpers\": true,\n \"jsx\": \"react-jsx\",\n \"esModuleInterop\": true,\n \"experimentalDecorators\": true,\n \"emitDecoratorMetadata\": true,\n \"declaration\": true,\n \"declarationDir\": \"types\",\n \"noLib\": false,\n \"preserveConstEnums\": true,\n \"sourceMap\": true,\n \"strictNullChecks\": true,\n \"noImplicitAny\": true,\n \"noImplicitThis\": true,\n \"noImplicitUseStrict\": false,\n \"noUnusedLocals\": true,\n \"noUnusedParameters\": true,\n \"removeComments\": false,\n \"lib\": [\"es2017\", \"dom\"],\n \"skipLibCheck\": true,\n \"downlevelIteration\": true,\n \"stripInternal\": true\n },\n \"compileOnSave\": false,\n \"buildOnSave\": false\n}\n\n\n# Animate-view Skill\n\nPath: `packages/framer-motion/animate-view/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/animate-view/package.json)\n\n\n# Client Skill\n\nPath: `packages/framer-motion/client/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/client/package.json)\n\n\n{\n \"baseUrl\": \"http://localhost:8000\",\n \"integrationFolder\": \"cypress/integration-html\",\n \"video\": true,\n \"screenshots\": false,\n \"retries\": 2,\n \"reporter\": \"junit\",\n \"reporterOptions\": {\n \"mochaFile\": \"../../test_reports/framer-motion-html.xml\"\n }\n}\n\n\n{\n \"baseUrl\": \"http://localhost:9990\",\n \"experimentalShadowDomSupport\": true,\n \"video\": true,\n \"screenshots\": false,\n \"retries\": 2,\n \"reporter\": \"junit\",\n \"reporterOptions\": {\n \"mochaFile\": \"../../test_reports/framer-motion-[hash].xml\"\n }\n}\n\n\n{\n \"baseUrl\": \"http://localhost:9991\",\n \"video\": true,\n \"screenshots\": false,\n \"retries\": 2,\n \"experimentalShadowDomSupport\": true,\n \"reporter\": \"junit\",\n \"reporterOptions\": {\n \"mochaFile\": \"../../test_reports/framer-motion-react-19-[hash].xml\"\n }\n}\n\n\n# Framer-motion Skill\n\nPath: `packages/framer-motion/cypress.rsc.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress.rsc.json)\n\n\n# Fixtures Skill\n\nPath: `packages/framer-motion/cypress/fixtures/animate-layout-tests.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/animate-layout-tests.json)\n\n\n# Fixtures Skill\n\nPath: `packages/framer-motion/cypress/fixtures/appear-tests.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/appear-tests.json)\n\n\n# Fixtures Skill\n\nPath: `packages/framer-motion/cypress/fixtures/projection-tests.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/fixtures/projection-tests.json)\n\n\n# Cypress Skill\n\nPath: `packages/framer-motion/cypress/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/cypress/tsconfig.json)\n\n\n# Debug Skill\n\nPath: `packages/framer-motion/debug/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/debug/package.json)\n\n\n# Mini Skill\n\nPath: `packages/framer-motion/dom/mini/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/mini/package.json)\n\n\n# Dom Skill\n\nPath: `packages/framer-motion/dom/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/dom/package.json)\n\n\n# Framer-motion Skill\n\nPath: `packages/framer-motion/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/jest.config.json)\n\n\n# Framer-motion Skill\n\nPath: `packages/framer-motion/jest.config.ssr.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/jest.config.ssr.json)\n\n\nThe MIT License (MIT)\n\nCopyright (c) 2018 Framer B.V.\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n\n\n# M Skill\n\nPath: `packages/framer-motion/m/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/m/package.json)\n\n\n# Mini Skill\n\nPath: `packages/framer-motion/mini/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/mini/package.json)\n\n\n# Framer-motion Skill\n\nPath: `packages/framer-motion/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/package.json)\n\n\n# Framer-motion Skill\n\nPath: `packages/framer-motion/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/tsconfig.json)\n\n\n# Framer-motion Skill\n\nPath: `packages/framer-motion/tsconfig.test.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/framer-motion/tsconfig.test.json)\n\n\n# Motion-dom Skill\n\nPath: `packages/motion-dom/jest.config.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/motiondivision/motion/HEAD/packages/motion-dom/jest.config.json)\n\n\n"}