{"owner":"remix-run","repo":"react-router","hasSkills":true,"totalSkillsCount":28,"totalTokensCount":17550,"categories":["anthropic-skill","root-instruction","claude-rule","plugin-manifest","cursor-rule"],"hasMcp":false,"mcpConfig":null,"found":[".agents/skills/create-pr/SKILL.md",".agents/skills/finish-line/SKILL.md",".agents/skills/fix-bug/SKILL.md",".agents/skills/implement-rfc/SKILL.md",".agents/skills/prepare-release-notes/SKILL.md",".agents/skills/prepare-release-notes/agents/openai.yaml",".agents/skills/prepare-release-notes/references/whats-changed.md",".agents/skills/react-router/SKILL.md",".agents/skills/react-router/references/data-mode.md",".agents/skills/react-router/references/declarative-mode.md",".agents/skills/react-router/references/framework-mode.md",".agents/skills/react-router/references/rsc.md",".agents/skills/sc-summary/SKILL.md",".agents/skills/sc-summary/agents/openai.yaml",".github/skills/agentic-workflows/SKILL.md","AGENTS.md","CLAUDE.md","packages/create-react-router/README.md","packages/react-router-architect/README.md","packages/react-router-cloudflare/README.md","packages/react-router-dev/README.md","packages/react-router-express/README.md","packages/react-router-fs-routes/README.md","packages/react-router-node/README.md","packages/react-router-remix-routes-option-adapter/README.md","packages/react-router-serve/README.md","packages/react-router/README.md",".cursorrules (react-router-v7.mdc)"],"skills":{".agents/skills/create-pr/SKILL.md":"---\nname: create-pr\ndescription: Create and package React Router pull requests. Use when the user asks to create, open, prepare, or finish a PR for this repository, including branch/commit/push handoff, draft PR creation, PR body writing, and applying GitHub labels such as pkg:*, feat:*, docs, github-actions, or dependencies.\n---\n\n# Create React Router PR\n\nCreate the pull request handoff for completed React Router work. Default to a draft PR targeting `main` unless the user explicitly asks for a ready PR or a different base branch.\n\n## Preconditions\n\n- Inspect `git status --short --branch` and `git branch --show-current`.\n- Do not include unrelated dirty files. If unrelated changes are present, leave them unstaged and mention them.\n- If the worktree is detached, create a branch from the current `HEAD` before committing. Use the branch name requested by the user, an existing repository convention, or `/` when no stronger convention is available.\n- If already on a suitable named branch, use it.\n- Confirm appropriate automated coverage exists or was added. Do not list routine CI-covered checks in the PR body.\n- If user-facing functionality is being updated, check that the appropriate package has a change file under `packages//.changes/`. This is not necessary for docs-only, GitHub Actions/workflow-only, or dependency-maintenance PRs unless the dependency change itself has user-facing impact.\n\n## Context\n\n- Capture what changed, why it changed, and who it affects.\n- Find related issues, discussions, or PRs and include links when relevant.\n- Prefer `git diff --stat` plus focused `git diff` over broad repo archaeology when the change is small.\n- If the user supplies a report, issue, discussion, or related PR, treat that as the primary context source.\n- For new feature work, include a concise usage snippet. If the feature replaces or improves an older approach, include before/after examples when they help reviewers.\n\n## Commit and Push\n\n1. Review the diff with `git diff --stat` and focused `git diff` as needed.\n2. Stage only the intended files.\n3. Commit with a concise imperative subject.\n4. Push the branch before creating the PR.\n\n## PR Creation\n\nSave the PR body to a temporary file, then use `gh pr create` with:\n\n```sh\ngh pr create --draft --base main --head --title \"\" --body-file <file>\n```\n\n- Omit `--draft` only when the user explicitly asks for a ready PR.\n- Change `--base` only when the user explicitly requests a different base branch.\n- Keep shell quoting simple. Prefer a body file if the body contains backticks, quotes, or multiple paragraphs.\n- Include issue/discussion links when known. Use `Closes #NNNN` for bug fixes the PR should close; use `Implements #NNNN` or a plain link for RFCs/discussions when closing semantics are not appropriate.\n- Include testing notes only for manual checks, unusual verification, skipped non-CI checks, or failures that reviewers should know about.\n- If `gh pr create` fails, leave the branch pushed when possible and give the user a ready-to-open compare URL plus the prepared title and body.\n\nRecommended PR body shape:\n\n````markdown\nThis change ...\n\n- Optional extra detail when useful.\n\n```tsx\n// Optional feature usage example\n```\n````\n\n```tsx\n// Optional before/after example\n```\n\n**Testing**\n\n- Optional manual or non-CI verification notes only.\n\n````\n\n- Do not use a `## Summary` heading. Start with one or two short sentences explaining what the change accomplishes.\n- Add bullets after the opening only when more detail is useful.\n- Include usage examples for new features, and before/after examples for replacements or improvements, when they help reviewers understand the change.\n- Add `**Testing**` with bullets below the description only when there are manual checks, unusual verification steps, skipped non-CI checks, or failures reviewers should know about. Omit it for routine automated coverage.\n\n## Testing Notes\n\n- Do not list linting, typechecking, unit test, or integration test commands in the PR body, even if they were run locally. CI runs these automatically.\n- Do not say that CI will run routine linting, typechecking, unit tests, or integration tests. That is assumed for every PR.\n- Do not add manual testing instructions by default.\n- Add manual testing instructions only when necessary, such as visual/UI behavior that needs human review, environment-specific behavior not covered by CI, release/publish dry-run steps, external service integration, or a reproduction that cannot be expressed reliably in automated tests.\n- When manual testing is necessary, keep the instructions minimal and directly tied to the uncovered risk.\n\n## Labels\n\nApply labels after the PR exists. Rely on the stable labels listed in this skill for normal PRs.\n\nApply labels with:\n\n```sh\ngh pr edit <number-or-url> --add-label \"<label>\"\n````\n\nIf `gh pr edit --add-label` fails because the specified label is invalid or missing, run:\n\n```sh\ngh label list --limit 200\n```\n\nThen choose the correct label from the live list and update this skill in place so the stable label guidance stays current. Use real labels only. If the right label does not exist, do not invent one; mention the missing label.\n\n### Package Labels\n\nAdd every applicable `pkg:*` label based on touched package paths:\n\n| Touched path | Label |\n| ---------------------------------------------------- | ----------------------------------------------- |\n| `packages/react-router/` | `pkg:react-router` |\n| `packages/react-router-dev/` | `pkg:@react-router/dev` |\n| `packages/create-react-router/` | `pkg:create-react-router` |\n| `packages/react-router-architect/` | `pkg:@react-router/architect` |\n| `packages/react-router-cloudflare/` | `pkg:@react-router/cloudflare` |\n| `packages/react-router-node/` | `pkg:@react-router/node` |\n| `packages/react-router-serve/` | `pkg:@react-router/serve` |\n| `packages/react-router-express/` | `pkg:@react-router/express` |\n| `packages/react-router-fs-routes/` | `pkg:@react-router/fs-routes` |\n| `packages/react-router-remix-routes-option-adapter/` | `pkg:@react-router/remix-routes-option-adapter` |\n\nIf a package path is unclear, inspect its `package.json` `name` and use `pkg:<name>` when that label exists. If a change touches generated artifacts or integration tests only, infer the package label from the runtime/tooling area being tested. For example, Vite plugin or prerender integration coverage usually maps to `pkg:@react-router/dev`.\n\n### Feature Labels\n\nAdd applicable `feat:*` labels for the behavior area being changed. Common labels include:\n\n| Behavior area | Label |\n| --------------------------------------------------------------------------------- | --------------------------- |\n| Core navigation, loaders/actions, fetchers, redirects, matching, and router state | `feat:router` |\n| Route config APIs and `routes.ts` | `feat:routes.ts` |\n| Vite plugin and build pipeline behavior | `feat:vite` |\n| SPA mode | `feat:spa-mode` |\n| Prerendering | `feat:prerender` |\n| Lazy route discovery | `feat:lazy-route-discovery` |\n| Hydration and hydration fallback behavior | `feat:hydration` |\n| View transition APIs | `feat:view-transitions` |\n| Middleware behavior | `feat:middleware` |\n| Split route module behavior | `feat:split-route-modules` |\n| Streaming behavior | `feat:streaming` |\n| CSS handling | `feat:css` |\n| Windows-specific fixes | `feat:windows` |\n| RSC Data or RSC Framework behavior | `feat:rsc` |\n| Path matching semantics | `feat:path-matching` |\n| Single fetch behavior | `feat:single-fetch` |\n| Types, typegen, and TypeScript behavior | `feat:typescript` |\n\nMultiple feature labels are fine when the diff truly spans multiple areas. Prefer the most specific label that exists.\n\n### Non-Package Labels\n\nSome PRs do not need package or feature labels:\n\n- Add `docs` for documentation-only changes.\n- Add `github-actions` for `.github/workflows/` or Actions infrastructure changes.\n- Add `dependencies` for dependency or lockfile-only maintenance.\n- Add version labels such as `v6`, `v7`, or `v8` only when the PR is intentionally scoped to that release line or the user asks for it.\n\n## Final Report\n\nReport:\n\n- Branch name.\n- Commit hash.\n- PR URL and whether it is draft or ready.\n- Base branch.\n- Labels applied.\n- Verification performed or skipped.\n",".agents/skills/finish-line/SKILL.md":"---\nname: finish-line\ndescription: Bring a blocked React Router community pull request across the finish line. Use when the user invokes `/finish-line` or `$finish-line`, provides a PR number or URL, and asks Codex to resolve merge blockers such as a missing change file, missing documentation, missing tests, or stale contributor follow-up. Handles evaluating the blocker and pushing small maintainer fixes onto a contributor PR branch when authorized.\n---\n\n# Finish Line\n\n## Overview\n\nFinish blocked community PRs in `remix-run/react-router` while respecting contributor ownership and the repo's PR packaging conventions.\n\nTreat the PR number or URL in `$ARGUMENTS` as the target PR. If no target is provided, ask for it before doing anything.\n\n## Triage\n\n1. Inspect local state with `git status --short --branch`. If unrelated dirty files exist, do not overwrite or stage them.\n2. Fetch current main before making branch decisions:\n\n```sh\ngit fetch origin main\n```\n\n3. Gather PR context:\n\n```sh\ngh pr view <pr> --repo remix-run/react-router --json number,title,body,state,isDraft,author,baseRefName,headRefName,headRepository,headRepositoryOwner,maintainerCanModify,mergeStateStatus,reviewDecision,labels,files,commits,statusCheckRollup,url\ngh pr checks <pr> --repo remix-run/react-router\ngh pr diff <pr> --repo remix-run/react-router --stat\ngh pr view <pr> --repo remix-run/react-router --comments\n```\n\n4. Identify merge blockers. In particular:\n\n- If the PR only needs repo-maintainer additions such as tests, a change file, or docs, use the contributor-branch workflow.\n- If the contributor branch cannot be modified, summarize the evidence and ask the user whether to wait for the contributor or recreate the work on a maintainer branch.\n- If the blocker is unclear, summarize the evidence and ask the user which path to take.\n\n5. Evaluate test coverage before deciding the finish-line changes:\n - Inspect the PR diff, changed files, existing nearby tests, review comments, and failed checks for test expectations.\n - If the PR changes runtime behavior, build/plugin behavior, routing semantics, generated types, RSC behavior, docs rendering, or any bug/feature surface that can regress, add or preserve a focused test unless equivalent coverage already exists.\n - If tests are already included, verify they exercise the changed behavior and cover the affected React Router mode(s): Declarative, Data, Framework, RSC Data, and/or RSC Framework.\n - If tests are not needed because the change is documentation-only, packaging-only, a change file, or otherwise not executable behavior, note that rationale in the final report.\n - If a useful test is required but too large or risky for the finish-line scope, stop and ask the user before broadening the PR.\n\n## Contributor-Branch Workflow\n\nUse this path when the missing work is a small maintainer follow-up, such as tests, a change file, or docs, and the contributor branch can be modified.\n\n1. Check out the PR branch:\n\n```sh\ngh pr checkout <pr-number> --repo remix-run/react-router\n```\n\n2. Confirm the branch and local state:\n\n```sh\ngit status --short --branch\ngit branch --show-current\n```\n\n3. Make only the missing finish-line changes, including focused tests when the coverage evaluation requires them. Do not refactor the contributor's work unless it is necessary to unblock mergeability and the user agrees.\n4. Validate the exact content with the user before pushing:\n - For a change file, show the package path, file name, change type, and full markdown contents.\n - For docs, show the affected files and the relevant prose/API snippets.\n - For tests, show the test file path, the behavior covered, and the mode(s) covered.\n - Ask explicitly for approval to commit and push back to the PR branch.\n5. After approval, run focused validation when appropriate, commit the maintainer follow-up, and push to the PR branch. If `git push` fails because the contributor branch cannot be modified, stop and report the failure instead of opening a replacement PR unless the user approves that pivot.\n\n## Change Files\n\nCreate change files under the affected package:\n\n```text\npackages/<package>/.changes/<type>.<unique-meaningful-name>.md\n```\n\nUse `patch`, `minor`, `major`, or `unstable` for `<type>`. For bug fixes and narrow behavior fixes, default to `patch`. Keep the content concise:\n\n```markdown\nBrief description of the user-facing change\n```\n\nIf the PR spans multiple packages, prefer the package with the direct user-facing API or runtime behavior. Ask the user when the package or change type is not obvious.\n\n## Documentation\n\nDo not add documentation by default for ordinary bug fixes. Add docs when the PR changes a documented API, introduces new behavior users need to discover, changes examples, or the user/reviewer explicitly requested docs.\n\nFollow repo docs rules:\n\n- Edit source docs or JSDoc, not generated `docs/api/` output.\n- Include mode context when adding docs for React Router behavior: Declarative, Data, Framework, RSC Data, or RSC Framework.\n- For API docs generated from JSDoc, edit `packages/react-router/lib/` comments and note that `pnpm run docs` may be required.\n\n## Final Report\n\nReport the path taken and the current PR state:\n\n- Original PR number and blocker.\n- Whether changes were pushed to the contributor branch or a replacement PR was opened.\n- Branch, commit hash, and PR URL when applicable.\n- Any old-PR comment/close action taken.\n- Validation performed or skipped.\n- Test coverage decision: added, already present, or intentionally omitted with rationale.\n",".agents/skills/fix-bug/SKILL.md":"---\nname: fix-bug\ndescription: \"Fix a reported bug in React Router from a GitHub issue. Use when the user provides a GitHub issue URL and asks to fix a bug, investigate an issue, or reproduce a problem. Handles the full workflow: fetching the issue, finding the reproduction, writing a failing test, and implementing the fix.\"\ndisable-model-invocation: true\n---\n\n# Fix React Router Bug\n\nFix the bug reported in the following GitHub issue: $ARGUMENTS\n\n## Branching\n\nBug fixes should start from a clean working tree. If there are changes, prompt me to resolve them before continuing.\n\nBugs should be fixed from the `main` branch in a new branch using the format `{author}/{semantic-branch-name}` (i.e., `brophdawg11/fix-navigation`):\n\n```sh\ngit branch {author}/{semantic-branch-name} main\ngit checkout {author}/{semantic-branch-name}\n```\n\n## Workflow\n\n### 1. Fetch and Understand the Issue\n\nUse `gh issue view <number> --repo remix-run/react-router` or `WebFetch` to read the full issue.\n\nExtract:\n\n- Bug description and expected vs actual behavior\n- React Router version and mode (Declarative / Data / Framework / RSC)\n- Any code snippets in the issue\n- Links to reproductions (StackBlitz, CodeSandbox, GitHub repo, etc.)\n\n### 2. Validate the Reproduction\n\n**If there's a StackBlitz/CodeSandbox/online sandbox link:**\n\n- Use `WebFetch` to read the sandbox URL and extract the relevant code\n- Identify the exact sequence of events that triggers the bug\n\n**If there's a GitHub repository link:**\n\n- Use `WebFetch` to read key files (`package.json`, relevant source files) from the raw GitHub URL\n- Identify the route configuration, loaders, actions, or components involved\n\n**If no reproduction link exists:**\n\n- Search the issue comments with `gh issue view <number> --repo remix-run/react-router --comments`\n- Look for code snippets in comments\n- Ask the user: \"No reproduction was provided. Can you share a minimal reproduction or paste the relevant code?\"\n\n### 3. Identify the Affected Code\n\nBased on the bug, locate the relevant source files. Consult the key file map:\n\n| Area | Files |\n| ---------------------- | ----------------------------------------------------------- |\n| Core router logic | `packages/react-router/lib/router/router.ts` |\n| React components/hooks | `packages/react-router/lib/components.tsx`, `lib/hooks.tsx` |\n| DOM utilities | `packages/react-router/lib/dom/` |\n| Vite/Framework plugin | `packages/react-router-dev/vite/plugin.ts` |\n| RSC | `packages/react-router/lib/rsc/` |\n\nUse `Grep` and `Glob` to trace the relevant code paths.\n\n### 4. Write a Failing Test\n\n**Unit test** (for router logic, hooks, pure component behavior — no build needed):\n\n- Location: `packages/react-router/__tests__/`\n- Use Jest; run with: `pnpm test packages/react-router/__tests__/<file>`\n- Match the style of nearby test files (describe/it blocks, `createStaticHandler`, `createMemoryRouter`, `render`, `screen`, etc.)\n\n**Integration test** (for Vite plugin, SSR, hydration, Framework Mode):\n\n- Location: `integration/`\n- Use Playwright with `createFixture()` → `createAppFixture()` → `PlaywrightFixture`\n- Run with: `pnpm test:integration:run --project chromium integration/<file>`\n- Build first if needed: `pnpm test:integration --project chromium`\n\nWrite the test to **reproduce the bug exactly** — it must fail before the fix.\n\nRun it and confirm it fails:\n\n```bash\npnpm test packages/react-router/__tests__/<file> # unit\n# or\npnpm test:integration:run --project chromium integration/<file> # integration\n```\n\n### 5. Implement the Fix\n\n- Make the minimal change needed to fix the bug\n- Do not refactor unrelated code\n- Confirm the fix addresses the root cause, not just the symptom\n- Consider all five modes: does this fix break anything in Declarative / Data / Framework / RSC?\n\nRun the failing test again — it must now pass:\n\n```bash\npnpm test packages/react-router/__tests__/<file>\n```\n\nRun the broader test suite to check for regressions:\n\n```bash\npnpm test packages/react-router/\n```\n\nIf the fix touches Framework/Vite code, run integration tests too:\n\n```bash\npnpm test:integration:run --project chromium\n```\n\nConfirm linting and typechecking pass:\n\n```bash\npnpm lint\npnpm typecheck\n```\n\n### 6. Create a Change file\n\nCreate a change file at `packages/<package>/.changes/<type>.<unique-meaningful-name>.md`. `<type>` should be either `patch`, `minor`, `major` or `unstable` to indicate the type of API change being made.\n\nFormat:\n\n```markdown\nfix: <brief description of what was fixed>\n```\n\n### 7. Report Results\n\nSummarize:\n\n- What the bug was and why it happened\n- What code was changed and why\n- That the test now passes\n- Any edge cases or related issues noticed\n\nAsk me to review the changes and iterate based on any feedback.\n\n### 8. Open PR\n\nOnce I approve the fix, commit the changes and open a PR to `main`. Include a `Closes #NNNN` in the description to link the PR to the original issue. Also link the issue in the `Development` sidebar\n",".agents/skills/implement-rfc/SKILL.md":"---\nname: implement-rfc\ndescription: Implement a React Router RFC from a GitHub discussion URL. Fetches the proposal, evaluates community feedback, resolves outstanding questions interactively, then implements the feature with tests, future flags (if breaking), and a changeset.\ndisable-model-invocation: true\n---\n\n# Implement React Router RFC\n\nImplement the RFC from the following GitHub discussion: $ARGUMENTS\n\n## Branching\n\nRFC implementations should start from a clean working tree. If there are uncommitted changes, stop and ask me to resolve them before continuing.\n\n- If you are already on a named branch that is at the same HEAD as `main`, use that branch.\n- Otherwise, create a branch from `main` using the format `{author}/rfc-{semantic-name}`:\n ```sh\n git branch {author}/rfc-{semantic-name} main\n git checkout {author}/rfc-{semantic-name}\n ```\n\n## Workflow\n\n### 1. Fetch and Understand the RFC\n\nUse `WebFetch` to read the discussion URL. If a GitHub discussion number is given instead of a URL, construct:\n`https://github.com/remix-run/react-router/discussions/<number>`\n\nExtract:\n\n- **Problem being solved**: what pain point does this RFC address?\n- **Proposed API**: exact function signatures, hook names, types, option shapes\n- **Affected modes**: Declarative / Data / Framework / RSC Data / RSC Framework\n- **Breaking changes**: does this change or remove existing public API?\n- **Open questions**: anything explicitly marked as unresolved, \"TBD\", or asked as a question in the proposal\n- **Status**: are there linked tracking issues? Look for links to other github issues and read them to see if there is additional context.\n\n ```sh\n gh issue view <number> --repo remix-run/react-router\n ```\n\n### 2. Evaluate Community Feedback\n\nFetch all comments from the discussion:\n\nUse `WebFetch` on `https://github.com/remix-run/react-router/discussions/<number>` and scroll through the full thread. Look for:\n\n- **Concerns or objections** raised by community members or maintainers\n- **Alternative proposals** or API shape suggestions\n- **Edge cases** raised that the proposal does not address\n- **Positive signals** — repeated praise for a specific approach signals it's the right direction\n- **Maintainer responses** — Ryan Florence, Michael Jackson, or other core team members clarifying intent\n\nSummarize the community sentiment into:\n\n- Points of consensus (safe to proceed)\n- Points of contention (need resolution before implementing)\n- Unanswered questions from the original proposal\n\n### 3. Resolve Outstanding Questions\n\nBefore writing any code, present me with a numbered list of every unresolved question — from both the RFC itself and from community feedback. For each question:\n\n- State the question clearly\n- Summarize relevant community input\n- Offer a recommended answer with reasoning\n\nAsk me to confirm, override, or skip each question. Do not proceed to implementation until all questions are either answered or explicitly deferred.\n\nExample format:\n\n```\n## Unresolved Questions\n\n1. **Should `useRouterState()` accept a path argument for scoped matching?**\n Community feedback: 3 comments in favor, 1 against (concerns about complexity).\n Recommendation: Yes — scoped matching improves type safety for nested routes.\n → Your decision: [confirm / override / defer]\n\n2. **What should happen when the path doesn't match the current location?**\n Recommendation: Return `null` for active state (consistent with `useMatch()`).\n → Your decision: [confirm / override / defer]\n```\n\nSave the resolved decisions to a scratch file at `tasks/rfc-decisions.md` for reference during implementation.\n\n### 4. Plan the Implementation\n\nBefore writing code, produce a concise implementation plan covering:\n\n- New types/interfaces to add\n- New functions/hooks to implement and their file locations\n- Existing APIs to deprecate (mark with `@deprecated` JSDoc + console warning in dev)\n- Whether a future flag is needed (see §5 below)\n- Test files to create or extend (unit and/or integration)\n- Changeset bump level (`minor` for new features, `major` for breaking changes behind a future flag that is now defaulted on)\n\nPresent the plan to me and wait for approval before implementing.\n\n### 5. Future Flags for Breaking Changes\n\nIf the RFC changes or removes existing public API behavior, it **must** ship behind a future flag which will start with an `unstable_` prefix.\n\n**Future flag pattern:**\n\n1. Add the flag to `FutureConfig` in `packages/react-router/lib/router/utils.ts`:\n\n ```ts\n export interface FutureConfig {\n // existing flags...\n unstable_myNewBehavior: boolean;\n }\n ```\n\n2. Gate the new behavior on the flag:\n\n ```ts\n if (router.future.unstable_myNewBehavior) {\n // new behavior\n } else {\n // legacy behavior\n }\n ```\n\n3. Document the flag in `docs/upgrading/future-flags.md` if it exists.\n\nNew additive APIs (no behavior change to existing code) do **not** need a future flag.\n\n### 6. Key File Locations\n\n| Area | Files |\n| --------------------- | -------------------------------------------- |\n| Core router logic | `packages/react-router/lib/router/router.ts` |\n| Router types/utils | `packages/react-router/lib/router/utils.ts` |\n| React components | `packages/react-router/lib/components.tsx` |\n| React hooks | `packages/react-router/lib/hooks.tsx` |\n| Public exports | `packages/react-router/index.ts` |\n| DOM utilities | `packages/react-router/lib/dom/` |\n| Framework/Vite plugin | `packages/react-router-dev/vite/plugin.ts` |\n| RSC runtime | `packages/react-router/lib/rsc/` |\n| Unit tests | `packages/react-router/__tests__/` |\n| Integration tests | `integration/` |\n| Future flags doc | `docs/upgrading/future-flags.md` |\n\nConfirm existing patterns before writing new code - prefer using the LSP but `Grep`/`Glob` also work. Match naming conventions and code style exactly.\n\n### 7. Implement the Feature\n\nFollow the approved plan. For each logical unit of work:\n\n1. Write the implementation\n2. Export from the appropriate public entry point (`packages/react-router/index.ts`)\n3. Add `@deprecated` JSDoc to any APIs being superseded\n4. Run typecheck to catch type errors early:\n ```sh\n pnpm typecheck\n ```\n\nKeep changes minimal and focused. Do not refactor unrelated code. Commit as often as needed.\n\n### 8. Write Tests\n\n**Unit tests** (for hooks, pure router logic, component behavior — no build):\n\n- Location: `packages/react-router/__tests__/`\n- Runner: Jest → `pnpm test packages/react-router/__tests__/<file>`\n- Cover: happy path, edge cases identified in RFC/community feedback, future flag gating (if applicable), deprecation warnings\n\n**Integration tests** (for Vite/Framework Mode, SSR, hydration):\n\n- Location: `integration/`\n- Runner: Playwright → `pnpm test:integration:run --project chromium integration/<file>`\n- Required if the RFC touches Framework Mode, file-system routing, or SSR behavior\n\nRun all tests and confirm they pass:\n\n```sh\npnpm test packages/react-router/\npnpm test:integration:run --project chromium # only if integration tests were added/changed\n```\n\n### 9. Lint and Typecheck\n\n```sh\npnpm lint\npnpm typecheck\n```\n\nFix all errors before proceeding.\n\n### 10. Create a Change File\n\nCreate `packages/<package>/.changes/<bump-level>.<descriptive-name>.md`. Use the RFC title or tracking issue as the description:\n\n```markdown\nfeat: <brief description matching the RFC title>\n\nImplements the `useRouterState()` RFC (#12358). Deprecates `useLocation`,\n`useParams`, `useSearchParams`, `useNavigation`, `useMatches`, `useMatch`,\n`useNavigationType`, and `useViewTransitionState` in favor of a unified API.\n\nEnable the `unstable_consolidatedRouterState` future flag to opt in.\n```\n\nBump levels:\n\n- `patch` — bug-adjacent fix only\n- `minor` — new additive API (no breaking changes)\n- `major` — breaking change (should be rare; most breaking changes go behind a future flag as `minor` first)\n- `unstable` — new API that is not yet stable (e.g. added in a future flag, or an experimental API that may be removed without a major bump)\n\n### 11. Report and Review\n\nSummarize:\n\n- What RFC was implemented and which decisions were made\n- New public APIs added (with brief usage example)\n- APIs deprecated and the migration path\n- Future flag name (if applicable) and how to opt in\n- Test coverage added\n- Anything deferred or explicitly out of scope\n\nAsk me to review and iterate before opening a PR.\n\n### 12. Commit\n\nOnce I approve, commit and open a PR to `main`:\n\n```sh\ngh pr create --base main --title \"feat: <RFC title>\" --body \"...\"\n```\n\nPR body should include:\n\n- Link to the RFC discussion (Closes or Implements #NNNN)\n- Summary of what was implemented\n- Future flag instructions if applicable\n- Testing notes\n- Any decisions that deviated from the original proposal and why\n",".agents/skills/prepare-release-notes/SKILL.md":"---\nname: prepare-release-notes\ndescription: Prepare React Router release notes before running the changes/versioning scripts. Use when asked to review, polish, normalize, or prepare pending change files under packages/*/.changes, remove semantic commit prefixes from release bullets, enforce imperative tense, decide whether a manual scripts/changes/whats-changed.md section is warranted, or draft long-form release notes for new features, stable future flags, or unstable flags.\n---\n\n# Prepare Release Notes\n\nPolish pending React Router change files and add manual release notes only when the release needs narrative context beyond the generated change lists.\n\n## Workflow\n\n1. Inspect local state:\n\n```sh\ngit status --short\nfind packages -path '*/.changes/*.md' -not -name README.md -not -name .gitkeep -print | sort\n```\n\n2. Read every pending change file. Do not edit generated changelogs or released notes directly.\n\n3. Normalize each change file:\n - Remove `feat:`, `feat(...)`, `fix:`, and `fix(...)` semantic-commit prefixes from prose\n - Use present or imperative tense for the first line and top-level release bullets: prefer `Add`, `Fix`, `Remove`, `Support`, `Stabilize`, `Preserve`, `Update`, `Avoid`, `Prevent`, `Throw`, `Warn`, `Expose`\n - Nested detail bullets can stay explanatory when they expand on the parent bullet; do not rewrite them solely to force present or imperative tense\n - Remove terminal sentence periods from bullet items because release generation appends PR/commit links after the first bullet line\n - Remove terminal sentence periods from nested bullet items too, unless the punctuation is part of code, a URL, an abbreviation, a version number, or another token where removing it would be wrong\n - If one bullet contains multiple sentences, split it into a shorter parent bullet plus nested bullet items\n - Keep the first line concise and user-facing; use nested bullets for details or migration notes\n\n4. Review whether `scripts/changes/whats-changed.md` is needed:\n - Read `CHANGELOG.md` examples or `references/whats-changed.md` when uncertain\n - Add `scripts/changes/whats-changed.md` only for features, future flag stabilizations, unstable flags, migration guidance, breaking bug fixes, or complex behavior that needs long-form text or examples\n - Do not add it for ordinary bug fixes, dependency cleanup, internal refactors, or release bullets that are already clear\n - If adding it, write the body only; the release script adds `### What's Changed` when missing\n\n5. Validate:\n\n```sh\npnpm changes:validate\npnpm changes:preview\n```\n\nUse `changes:preview` to inspect the generated root release notes and confirm the PR/commit link placement, section ordering, and any manual What's Changed placement. If dependencies are missing or the command is too expensive for the context, state what was skipped.\n\n## Change File Style\n\nSingle-line entries should read well with an auto-appended PR link:\n\n```markdown\nFix `href()` to stringify and URL-encode param values like `generatePath()`\n```\n\nUse nested bullets for additional sentences:\n\n```markdown\nFix route ranking for dynamic parameters with static extension suffixes\n\n- Identify `/:name.xml` as a dynamic segment instead of a static segment\n- Preserve static route priority for paths like `/sitemap.xml`\n```\n\nAvoid semantic commit prefixes:\n\n```markdown\nAdd support for nub as a package manager\n```\n\nnot:\n\n```markdown\nfeat: add support for nub as a package manager.\n```\n\n## What's Changed Guidance\n\nUse `scripts/changes/whats-changed.md` for release-level narrative, not package-specific bullets. Good candidates include:\n\n- A new user-facing API or feature that benefits from example code\n- Stabilization or renaming of unstable APIs/flags, especially when adopters must migrate\n- A stable future flag that changes behavior and needs adoption guidance\n- A breaking bug fix or adapter/runtime behavior change that may require deployment checks\n- A cluster of related changes whose combined effect matters more than the individual bullet list\n\nKeep the tone direct and practical. Prefer headings under the generated `### What's Changed` section:\n\n````markdown\n#### Feature Name\n\nExplain what changed, who it affects, and how to adopt it.\n\n```ts\n// Optional short example\n```\n````\n\nDo not duplicate every bullet from Minor/Patch/Unstable Changes. Let generated change files carry ordinary PR-level details.\n\nSee `references/whats-changed.md` for examples distilled from the existing changelog.\n",".agents/skills/prepare-release-notes/agents/openai.yaml":"interface:\n display_name: \"Prepare Release Notes\"\n short_description: \"Polish React Router release notes\"\n default_prompt: \"Use $prepare-release-notes to review pending React Router change files and draft any needed What's Changed notes.\"\n",".agents/skills/prepare-release-notes/references/whats-changed.md":"# What's Changed Reference\n\nLoad this when deciding whether a React Router release needs `scripts/changes/whats-changed.md`.\n\n## Include A Manual Section For\n\n- Major releases with baseline changes, removed packages, removed deprecated APIs, new runtime requirements, or migration guidance\n- Stabilizations and flag renames where adopters of unstable APIs need explicit before/after guidance\n- New APIs or flags that deserve a narrative introduction or usage example\n- Cross-cutting performance or behavior work where several bullets form one user-facing story\n- Breaking bug fixes, deployment-sensitive fixes, or adapter/runtime behavior changes where users may need to test or update config\n\n## Usually Do Not Include One For\n\n- Straightforward bug fixes\n- Dependency removals or upgrades where the bullet is sufficient\n- Internal refactors with no public API change\n- A minor feature that is fully understandable from one concise bullet and nested detail bullets\n- Releases where the only content is a normal patch list\n\n## Existing Changelog Patterns\n\n- `v8.1.0`: Uses headings for agent skill installation and observability metadata, including an instrumentation code example. The generated minor bullets still carry the per-package details.\n- `v8.0.0`: Uses long-form migration notes for a major release: baseline support, adopted future flags, removed packages/APIs, and behavior changes.\n- `v7.18.0`: Explains a CSRF check fix that may be a breaking bug fix for reverse-proxy deployments and tells users what to test.\n- `v7.15.0`: Groups several unstable-to-stable API renames and route matching optimizations into narrative sections before listing individual minor bullets.\n- `v7.15.1`: Uses a \"What's New\" style section for an unstable hook with a code example. For new release notes, prefer the current `What's Changed` file path; the generated heading will be `### What's Changed`.\n\n## Drafting Tips\n\n- Use `####` headings inside `scripts/changes/whats-changed.md`; the release script wraps the file in `### What's Changed` if needed\n- Mention applicable React Router modes when the distinction matters: Declarative, Data, Framework, RSC Data, or RSC Framework\n- Keep examples short and directly tied to adoption\n- Avoid repeating the package prefix and PR-link details already provided by generated change sections\n- If unsure, run `pnpm changes:preview` with and without the manual section and keep it only if the generated notes are meaningfully clearer with the narrative\n",".agents/skills/react-router/SKILL.md":"---\nname: react-router\ndescription: Build applications with React Router in Framework, Data, Declarative, and unstable RSC modes. Use when configuring routes, route modules, loaders, actions, forms, fetchers, navigation, pending UI, SSR/SPA/pre-rendering, middleware, URL params/search params, or React Router upgrades.\nlicense: MIT\n---\n\n# React Router\n\nReact Router is mode-specific. Before changing an app, identify the mode, load the matching reference, then read the installed docs for the installed package version.\n\n## Identify the Mode\n\nDo not apply Framework/Data patterns to a Declarative app unless you are intentionally migrating modes.\n\n### Framework Mode\n\nUse Framework Mode guidance when you see:\n\n- `@react-router/dev` in dependencies\n- `react-router.config.ts`\n- `app/routes.ts`\n- `app/entry.server.tsx` and/or `app/entry.client.tsx` files\n- route modules under `app/routes/`\n- route exports like `loader`, `action`, `clientLoader`, `clientAction`, `ErrorBoundary`, `meta`, `links`, or `headers`\n- imports from `./+types/...`\n- the React Router Vite plugin from `@react-router/dev/vite`\n\nFramework examples usually use the default `app/` directory, but check `react-router.config.ts` for a custom `appDirectory` before assuming exact paths.\n\nThen read `references/framework-mode.md`.\n\n### Data Mode\n\nUse Data Mode guidance when you see:\n\n- `createBrowserRouter`, `createHashRouter`, `createMemoryRouter`, or `createStaticRouter`\n- `<RouterProvider router={router}>`\n- route objects with properties like `path`, `children`, `loader`, `action`, `Component`, `ErrorBoundary`, or `lazy`\n- data APIs without the Framework Vite plugin\n\nThen read `references/data-mode.md`.\n\n### Declarative Mode\n\nUse Declarative Mode guidance when you see:\n\n- `<BrowserRouter>`, `<HashRouter>`, or `<MemoryRouter>`\n- `<Routes>` and `<Route>` JSX route configuration\n- route components passed with `element={<Component />}`\n- no data router, no route module convention, and no loaders/actions\n\nThen read `references/declarative-mode.md`.\n\n### RSC Framework and RSC Data Modes\n\nReact Server Components support is unstable and exists in both Framework and Data variants. Use RSC guidance when you see:\n\n- `unstable_reactRouterRSC`\n- `@vitejs/plugin-rsc`\n- `unstable_RSCRouteConfig`\n- RSC entry files such as `entry.rsc`\n- `ServerComponent`, `ServerErrorBoundary`, `ServerLayout`, or `ServerHydrateFallback`\n- React directives or boundary packages such as `\"use client\"`, `\"server-only\"`, or `\"client-only\"`\n\nFor RSC Framework, read both `references/framework-mode.md` and `references/rsc.md`.\nFor RSC Data, read both `references/data-mode.md` and `references/rsc.md`.\n\n## Use Installed Docs as Source of Truth\n\nReact Router ships markdown docs in the package so guidance can match the installed version:\n\n```txt\nnode_modules/react-router/docs/\n```\n\nKey docs paths:\n\n```txt\nnode_modules/react-router/docs/index.md\nnode_modules/react-router/docs/start/\nnode_modules/react-router/docs/how-to/\nnode_modules/react-router/docs/explanation/\nnode_modules/react-router/docs/upgrading/\n```\n\nWhen this skill references `react-router/docs/...`, read the matching file under `node_modules/react-router/docs/`. If the installed version does not include local docs, use the repo `docs/` directory when working inside the React Router repository; in a consuming app, fall back to version-matched website docs.\n\nMost docs include a mode marker near the top:\n\n```txt\n[MODES: framework, data, declarative]\n```\n\nOnly apply a doc when its mode marker matches the app mode. If a task spans modes, prefer the section or file that matches the current app.\n\nRSC is documented primarily in:\n\n```txt\nnode_modules/react-router/docs/how-to/react-server-components.md\n```\n\n## Skill References\n\nLoad the relevant reference after identifying the mode:\n\n| Reference | Use When |\n| -------------------------------- | --------------------------------------------- |\n| `references/framework-mode.md` | Framework Mode or RSC Framework base behavior |\n| `references/data-mode.md` | Data Mode or RSC Data base behavior |\n| `references/declarative-mode.md` | Declarative Mode |\n| `references/rsc.md` | Any unstable RSC app |\n\n## Mode Migration Doc Index\n\nIf the user explicitly asks to switch modes, read the target mode reference plus the migration-relevant docs:\n\n| Migration | Docs to read |\n| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Declarative → Data | `react-router/docs/start/modes.md`, `react-router/docs/start/data/routing.md`, `react-router/docs/start/data/data-loading.md`, `react-router/docs/start/data/actions.md` |\n| Declarative/Data → Framework | `react-router/docs/start/modes.md`, `react-router/docs/start/framework/routing.md`, `react-router/docs/start/framework/route-module.md`, `react-router/docs/how-to/route-module-type-safety.md` |\n| Framework SPA/SSR/pre-render changes | `react-router/docs/start/framework/rendering.md`, `react-router/docs/how-to/spa.md`, `react-router/docs/how-to/pre-rendering.md`, `react-router/docs/start/framework/data-loading.md`, `react-router/docs/start/framework/actions.md` |\n| Future flags/upgrades | `react-router/docs/upgrading/future.md` and relevant files under `react-router/docs/upgrading/` |\n",".agents/skills/react-router/references/data-mode.md":"# Data Mode\n\nData Mode uses data routers such as `createBrowserRouter` and renders with `<RouterProvider>`. It gives an app route objects, loaders, actions, pending UI, fetchers, and SSR primitives without adopting the Framework Vite plugin or route-module file conventions.\n\nUse this reference after the main skill identifies a Data Mode app.\n\n## Read the Local Docs by Mode\n\nStart with:\n\n```txt\nreact-router/docs/start/modes.md\nreact-router/docs/start/data/index.md\n```\n\nThen use the Data docs under:\n\n```txt\nreact-router/docs/start/data/\n```\n\nThose files cover installation, route objects, routing, data loading, actions, navigation, pending UI, and testing. For task-specific details, read relevant files in:\n\n```txt\nreact-router/docs/how-to/\nreact-router/docs/explanation/\n```\n\nAlways check the `[MODES: data, ...]` marker in a doc before applying it.\n\n## Data Router Shape\n\nTypical setup:\n\n```tsx\nimport { createBrowserRouter, RouterProvider } from \"react-router\";\n\nconst router = createBrowserRouter([\n {\n path: \"/\",\n Component: Root,\n loader: rootLoader,\n children: [\n { index: true, Component: Home },\n {\n path: \"projects/:projectId\",\n Component: Project,\n loader: projectLoader,\n },\n ],\n },\n]);\n\nroot.render(<RouterProvider router={router} />);\n```\n\nLook for route object arrays and APIs such as:\n\n- `createBrowserRouter`\n- `createHashRouter`\n- `createMemoryRouter`\n- `RouterProvider`\n- `loader`\n- `action`\n- `Component`\n- `ErrorBoundary`\n- `lazy`\n- `children`\n\n## Route Objects and Routing\n\nBefore editing route configuration, read:\n\n```txt\nreact-router/docs/start/data/routing.md\nreact-router/docs/start/data/route-object.md\n```\n\nRules:\n\n- Keep route objects outside render when possible.\n- Use nested routes for shared layouts and data boundaries.\n- Use index routes for default child content.\n- Use dynamic segments and splats according to route-object docs.\n- Prefer `Component`/`ErrorBoundary` route object properties in Data Mode examples unless the existing app uses `element` consistently.\n\n## Data and Mutations\n\nBefore working on data loading or mutations, read:\n\n```txt\nreact-router/docs/start/data/data-loading.md\nreact-router/docs/start/data/actions.md\n```\n\nRules:\n\n- Load route data with route `loader` functions.\n- Mutate route data with route `action` functions.\n- Prefer loaders/actions over route-level `useEffect` fetching.\n- Use `request`, `params`, and returned/throwable Responses as described in the docs.\n- Let React Router revalidate after actions unless there is a documented reason to customize revalidation.\n\nCommon patterns:\n\n- Validation failure from an action: return `data({ errors, values }, { status: 400 })`, then render errors with `useActionData()` or `fetcher.data`.\n- Missing record in a loader: throw `data(\"Not Found\", { status: 404 })` and render the route `ErrorBoundary`.\n- Search/filter data: parse `new URL(request.url).searchParams` in the loader so the URL is shareable and bookmarkable.\n\n## Forms, Fetchers, and Pending UI\n\nFor forms and pending UI, read:\n\n```txt\nreact-router/docs/start/data/actions.md\nreact-router/docs/start/data/pending-ui.md\nreact-router/docs/how-to/fetchers.md\nreact-router/docs/explanation/form-vs-fetcher.md\n```\n\nRules of thumb:\n\n- Search/filter form that updates the URL: `<Form method=\"get\">`.\n- Mutation that should change URL/history or redirect after completion: `<Form method=\"post\">`.\n- Mutation that should keep the user on the same page: `useFetcher` / `<fetcher.Form>`.\n- Optimistic UI: derive from `fetcher.formData` or `navigation.formData`.\n\n## Navigation and URL State\n\nBefore changing navigation or search params, read:\n\n```txt\nreact-router/docs/start/data/navigating.md\nreact-router/docs/how-to/search-params.md\nreact-router/docs/explanation/location.md\n```\n\nRules:\n\n- Use `<Link>`/`<NavLink>` for user-initiated internal navigation.\n- Use `redirect` in loaders/actions when navigation follows data loading or mutations.\n- Use `useNavigate` for imperative client-side event navigation.\n- Treat URL params as strings and validate/parse them.\n- Preserve unrelated search params unless intentionally resetting them.\n\n## SSR in Data Mode\n\nData Mode SSR is manual and lower-level than Framework Mode. Before implementing or changing SSR, read the Data Mode custom/SSR docs and match existing server abstractions.\n\nStart with:\n\n```txt\nreact-router/docs/start/data/custom.md\n```\n\nLook for APIs like `createStaticHandler`, `createStaticRouter`, `StaticRouterProvider`, and hydration data handling in the current app before changing anything.\n\n## RSC Data\n\nIf this Data Mode app uses `unstable_RSCRouteConfig`, RSC route config, or low-level RSC server APIs, also read:\n\n```txt\nreferences/rsc.md\nreact-router/docs/how-to/react-server-components.md\n```\n",".agents/skills/react-router/references/declarative-mode.md":"# Declarative Mode\n\nDeclarative Mode is React Router's simplest mode. It uses router components like `<BrowserRouter>` and JSX routes with `<Routes>`/`<Route>`. It does not provide loaders, actions, fetchers, or data-router pending UI.\n\nUse this reference after the main skill identifies a Declarative Mode app.\n\n## Read the Local Docs by Mode\n\nStart with:\n\n```txt\nreact-router/docs/start/modes.md\nreact-router/docs/start/declarative/index.md\n```\n\nThen use the Declarative docs under:\n\n```txt\nreact-router/docs/start/declarative/\n```\n\nThose files cover installation, routing, navigation, and URL values. For conceptual details, read relevant files in:\n\n```txt\nreact-router/docs/explanation/\n```\n\nAlways check the `[MODES: declarative, ...]` marker in a doc before applying it.\n\n## Declarative Router Shape\n\nTypical setup:\n\n```tsx\nimport { BrowserRouter, Routes, Route } from \"react-router\";\n\nfunction App() {\n return (\n <BrowserRouter>\n <Routes>\n <Route path=\"/\" element={<Home />} />\n <Route path=\"about\" element={<About />} />\n <Route path=\"dashboard\" element={<DashboardLayout />}>\n <Route index element={<DashboardHome />} />\n <Route path=\"settings\" element={<Settings />} />\n </Route>\n </Routes>\n </BrowserRouter>\n );\n}\n```\n\nLook for APIs such as:\n\n- `<BrowserRouter>`\n- `<HashRouter>`\n- `<MemoryRouter>`\n- `<Routes>`\n- `<Route>`\n- `element={<Component />}`\n- `useRoutes`\n\n## Routing\n\nBefore editing routes, read:\n\n```txt\nreact-router/docs/start/declarative/routing.md\n```\n\nRules:\n\n- Use `<Routes>` and `<Route>` for route configuration.\n- Use nested routes with `<Outlet>` for shared layout.\n- Use index routes for default child UI.\n- Use route params and splats according to the declarative routing docs.\n- Do not add route object loaders/actions to a Declarative router.\n\n## Navigation\n\nBefore changing navigation, read:\n\n```txt\nreact-router/docs/start/declarative/navigating.md\n```\n\nRules:\n\n- Use `<Link>` or `<NavLink>` for user-initiated internal navigation.\n- Use `NavLink` when active styling matters.\n- Use `useNavigate` for imperative navigation from event handlers or effects.\n- Do not use plain `<a href>` for internal navigation unless intentionally forcing a full document navigation.\n\n## URL Values\n\nBefore changing params, search params, or location state, read:\n\n```txt\nreact-router/docs/start/declarative/url-values.md\nreact-router/docs/explanation/location.md\n```\n\nRules:\n\n- Use `useParams` for dynamic route params.\n- Use `useSearchParams` for query string state.\n- Use `useLocation` for the current location object and navigation state.\n- Validate and parse URL params; they are strings and can be absent.\n- Preserve unrelated search params unless intentionally resetting them.\n\n## Mode Boundary\n\nDeclarative Mode does not have Data/Framework APIs such as:\n\n- `loader`\n- `action`\n- `<Form>`\n- `useFetcher`\n- `useNavigation`\n- route module exports\n- generated `./+types` route types\n\nIf the user asks for route data loading, DB/API-backed data, CRUD, form mutations, validation returned from submissions, revalidation, pending UI, optimistic UI, or fetchers, recommend Data Mode or Framework Mode depending on how much structure they want. Ask before migrating unless they already requested it.\n",".agents/skills/react-router/references/framework-mode.md":"# Framework Mode\n\nFramework Mode is React Router's full-stack mode. It uses the React Router Vite plugin, route config in `app/routes.ts`, route modules, generated route types, and rendering strategies such as SSR, SPA mode, and pre-rendering.\n\nUse this reference after the main skill identifies a Framework Mode app.\n\n## Read the Local Docs by Mode\n\nStart with:\n\n```txt\nreact-router/docs/start/modes.md\nreact-router/docs/start/framework/index.md\n```\n\nThen use the Framework docs under:\n\n```txt\nreact-router/docs/start/framework/\n```\n\nThose files cover installation, routing, route modules, data loading, actions, navigation, pending UI, rendering, deploying, and testing. For task-specific details, read relevant files in:\n\n```txt\nreact-router/docs/how-to/\nreact-router/docs/explanation/\n```\n\nAlways check the `[MODES: framework, ...]` marker in a doc before applying it.\n\n## Framework Shape\n\nExamples usually assume the default `appDirectory` of `app`. Check `react-router.config.ts` before assuming exact paths.\n\nLook for these files and conventions:\n\n```txt\nreact-router.config.ts\napp/root.tsx\napp/routes.ts\napp/routes/**/*.tsx\nroute modules importing from ./+types/...\n```\n\nTypical route module:\n\n```tsx\nimport type { Route } from \"./+types/product\";\n\nexport async function loader({ params }: Route.LoaderArgs) {\n return { product: await getProduct(params.productId) };\n}\n\nexport default function Product({ loaderData }: Route.ComponentProps) {\n return <h1>{loaderData.product.name}</h1>;\n}\n```\n\n## Route Configuration\n\nFramework apps use `app/routes.ts`. Many apps use file-system routing via `flatRoutes()`, but manual route config is also supported.\n\nBefore editing routes, read:\n\n```txt\nreact-router/docs/start/framework/routing.md\n```\n\nIf the app uses file-route conventions, read:\n\n```txt\nreact-router/docs/how-to/file-route-conventions.md\n```\n\n## Route Modules\n\nRoute modules are the main unit of Framework Mode. Before adding or changing route exports, read:\n\n```txt\nreact-router/docs/start/framework/route-module.md\n```\n\nCommon exports include:\n\n| Export | Use |\n| --------------------------------- | ------------------------------------------------------------------- |\n| `default` | Route component rendered for the match |\n| `loader` | Server data loading for SSR/pre-rendering/server data requests |\n| `clientLoader` | Browser-only data loading or supplementing server loader data |\n| `action` | Server mutation called by `<Form>`, `useSubmit`, or fetchers |\n| `clientAction` | Browser-only mutation or client-side wrapper around a server action |\n| `ErrorBoundary` | UI for errors thrown by this route's loaders/actions/component |\n| `HydrateFallback` | Initial fallback while client loader hydration runs |\n| `links` / `meta` | Route document links and metadata |\n| `handle` | Arbitrary route metadata consumed via `useMatches` |\n| `shouldRevalidate` | Overrides default loader revalidation behavior |\n| `middleware` / `clientMiddleware` | Server/client request pipeline hooks when enabled |\n\nUse generated `Route.*` types from `./+types/<route>` for route module args and props.\n\n## Layout and Root Route Rules\n\n- `app/root.tsx` is the root route and should contain global document/app shell concerns.\n- Put global providers, app-wide nav, app-wide footer, scripts/meta/links, and document structure in `root.tsx` when appropriate.\n- Use nested routes/layout routes for section-specific layouts.\n- Do not flatten routes that should share UI or data boundaries.\n\nUseful docs:\n\n```txt\nreact-router/docs/explanation/special-files.md\nreact-router/docs/start/framework/routing.md\n```\n\n## Data and Mutations\n\nBefore working on route data:\n\n```txt\nreact-router/docs/start/framework/data-loading.md\nreact-router/docs/start/framework/actions.md\n```\n\nFramework rules:\n\n- Load route data with `loader` or `clientLoader`.\n- Mutate route data with `action` or `clientAction`.\n- Prefer route loaders/actions over ad hoc `useEffect` fetching for route data.\n- Use `data()`/Responses and redirects according to the docs.\n- Let React Router revalidate after actions unless the docs point you to `shouldRevalidate`.\n- In SSR/server data routes, keep Node-only/database code in server-only modules and call it from `loader`/`action`, not from browser-rendered component code.\n\nCommon patterns:\n\n- Validation failure from an action: return `data({ errors, values }, { status: 400 })`, then render errors from `Route.ComponentProps[\"actionData\"]` or `fetcher.data`.\n- Missing record in a loader: throw `data(\"Not Found\", { status: 404 })` and render the route `ErrorBoundary`.\n- Search/filter data: parse the route request URL/search params in the loader so the URL is shareable and bookmarkable.\n\n## Forms, Fetchers, and Pending UI\n\nFor forms and pending UI, read:\n\n```txt\nreact-router/docs/start/framework/actions.md\nreact-router/docs/start/framework/pending-ui.md\nreact-router/docs/how-to/fetchers.md\nreact-router/docs/explanation/form-vs-fetcher.md\n```\n\nRules of thumb:\n\n- Search/filter form that updates the URL: `<Form method=\"get\">`.\n- Mutation that should change URL/history or redirect after completion: `<Form method=\"post\">`.\n- Mutation that should keep the user on the same page: `useFetcher` / `<fetcher.Form>`.\n- Optimistic UI: derive from `fetcher.formData` or `navigation.formData`.\n\n## Type Safety\n\nBefore changing generated route types or typed URL behavior, read:\n\n```txt\nreact-router/docs/how-to/route-module-type-safety.md\nreact-router/docs/explanation/type-safety.md\n```\n\nRules:\n\n- Import types from `./+types/<route>`.\n- Use `Route.LoaderArgs`, `Route.ActionArgs`, `Route.ComponentProps`, etc.\n- Use type-only imports where appropriate.\n- Do not edit generated `.react-router/types` files.\n\n## Metadata\n\nBefore changing `meta`, read:\n\n```txt\nreact-router/docs/how-to/meta.md\nreact-router/docs/start/framework/route-module.md\n```\n\nImportant: `meta` receives `loaderData`; do not use deprecated `data` args.\n\n## Rendering Strategy\n\nFramework Mode can be SSR, SPA, pre-rendered, or mixed depending on config and route behavior. Before changing rendering behavior, read:\n\n```txt\nreact-router/docs/start/framework/rendering.md\nreact-router/docs/how-to/spa.md\nreact-router/docs/how-to/pre-rendering.md\nreact-router/docs/explanation/hydration.md\n```\n\n## Middleware, Sessions, and Auth\n\nBefore implementing middleware or auth/session flows, read:\n\n```txt\nreact-router/docs/how-to/middleware.md\nreact-router/docs/explanation/sessions-and-cookies.md\n```\n\nMiddleware and context APIs are version/config sensitive. Check the installed React Router version and the app's `react-router.config.ts` before implementing.\n\n## RSC Framework\n\nIf this Framework app uses `unstable_reactRouterRSC` or `@vitejs/plugin-rsc`, also read:\n\n```txt\nreferences/rsc.md\nreact-router/docs/how-to/react-server-components.md\n```\n",".agents/skills/react-router/references/rsc.md":"# React Server Components (RSC)\n\nReact Router's RSC support is unstable and exists in two variants:\n\n- **RSC Framework Mode**: Framework Mode with the unstable RSC Vite plugin.\n- **RSC Data Mode**: lower-level RSC runtime APIs and manual bundler/server integration.\n\nUse this reference in addition to `framework-mode.md` or `data-mode.md` after the main skill identifies an RSC app.\n\n## Read the Local RSC Docs\n\nStart with:\n\n```txt\nreact-router/docs/how-to/react-server-components.md\n```\n\nThen read the relevant base mode docs:\n\n```txt\nreact-router/docs/start/framework/\nreact-router/docs/start/data/\n```\n\nRSC docs may describe differences from non-RSC mode rather than repeating every Framework/Data concept, so keep both layers in mind.\n\n## Detect RSC Framework Mode\n\nLook for:\n\n- `unstable_reactRouterRSC` imported from `@react-router/dev/vite`\n- `@vitejs/plugin-rsc`\n- `vite.config.ts` with `plugins: [reactRouterRSC(), rsc()]`\n- Framework route modules plus RSC route exports\n- RSC entry files such as `entry.rsc`\n\nRSC Framework Mode uses a different Vite plugin from non-RSC Framework Mode. Do not swap it for the regular `reactRouter()` plugin.\n\n## Detect RSC Data Mode\n\nLook for:\n\n- `unstable_RSCRouteConfig`\n- route config passed to lower-level RSC APIs\n- APIs such as `unstable_matchRSCServerRequest`, `unstable_routeRSCServerRequest`, `unstable_RSCHydratedRouter`, or `unstable_RSCStaticRouter`\n- custom bundler/server setup around RSC\n\nRSC Data Mode is more manual than RSC Framework Mode. Match the app's bundler and server abstractions before changing routes or entries.\n\n## RSC Route Module Differences\n\nIn RSC Framework Mode, many normal Framework Mode concepts still apply, but routes can use server component exports.\n\nImportant route-module concepts from the RSC docs include:\n\n- `ServerComponent` instead of the usual client `default` component\n- `ServerErrorBoundary` paired with `ErrorBoundary`\n- `ServerLayout` paired with `Layout`\n- `ServerHydrateFallback` paired with `HydrateFallback`\n- server-rendered React elements returned from loaders/actions\n\nA route module cannot export both the normal client component and its server component counterpart for the same role. Read the RSC docs before adding these exports.\n\n## Client/Server Boundaries\n\nRSC code must respect React's client/server split:\n\n- Use `\"use client\"` for components that need hooks, browser APIs, or event handlers.\n- Use server-only modules for server data access and secrets.\n- In RSC Framework Mode, prefer the `server-only` and `client-only` boundary imports described in the docs.\n- Do not assume `.server`/`.client` file naming works the same way in RSC Framework Mode; read the RSC docs before relying on those conventions.\n\n## Data Loading in RSC\n\nRSC changes where data can be loaded:\n\n- Server Components can fetch data directly on the server.\n- Loaders/actions may still exist and can have RSC-specific behavior.\n- Client components still need client-safe data and cannot directly access server-only modules.\n\nWhen choosing between a server component fetch, a loader, and a client loader/action, follow the RSC docs and match existing app patterns.\n\n## Stability\n\nRSC APIs are explicitly unstable. Before implementing or refactoring RSC code:\n\n- Check the installed React Router version.\n- Check the installed `@vitejs/plugin-rsc` version.\n- Read the app's existing RSC entry/config files.\n- Prefer minimal changes that match current patterns.\n",".agents/skills/sc-summary/SKILL.md":"---\nname: sc-summary\ndescription: Summarize React Router Steering Committee meeting notes from a user-provided location in GOVERNANCE.md. Use when asked to add or revise Steering Committee meeting summaries.\n---\n\n# Steering Committee Meeting Summaries\n\nUse the notes folder or files the user supplies in the request or current conversation. If no source location is available, ask for it. Write to the repository's `GOVERNANCE.md`, under **Meeting Notes**.\n\n1. Read the existing Meeting Notes entries and list the files at the supplied location. Summarize the requested dates or files. If the user gives no date or quantity, choose the earliest meeting without an entry and do one meeting for review. Do not duplicate an existing entry unless asked to revise it.\n2. Read each entire source note, especially the details. Resolve repeated or inconsistent points before writing. Treat proposed ideas, decisions, and suggested next steps distinctly; do not present an unconfirmed proposal as an agreed decision.\n3. Write a public-facing, high-level summary of React Router discussion only. Omit unrelated conversation and banter. Refer to participants by first name. Follow the existing `<details>` format and prose in `GOVERNANCE.md`; use short topical headings when useful. Match the depth of existing entries, adjusted to how much substantive discussion occurred.\n4. Insert each entry near the other meeting dates, preserve unrelated content, then review the diff against the source and run `git diff --check`. Show the new or revised entries to the user. Do not post them to GitHub, commit, or publish unless requested.\n",".agents/skills/sc-summary/agents/openai.yaml":"interface:\n display_name: \"SC Summary\"\n short_description: \"Summarize React Router Steering Committee meetings\"\n default_prompt: \"Use $sc-summary with the meeting notes location I provide to update GOVERNANCE.md.\"\n",".github/skills/agentic-workflows/SKILL.md":"---\nname: agentic-workflows\ndescription: Route gh-aw workflow design/create/debug/upgrade requests to the right prompts.\n---\n\n# Agentic Workflows Router\n\nUse this skill when a user asks to design, create, update, debug, or upgrade GitHub Agentic Workflows in this repository.\n\nThis skill is a dispatcher: identify the task type, load the matching workflow prompt/skill file, and follow it directly. Keep responses concise and ask a clarifying question if the correct prompt is unclear.\n\nRepository overlay (optional):\n\n- If `.github/aw/instructions.md` exists, load it with `@.github/aw/instructions.md` after loading the matched prompt/skill.\n- Precedence: repository overlay instructions override upstream defaults when they conflict.\n\nRead only the files you need:\nLoad these files from `github/gh-aw` (they are not available locally).\n\n- `.github/aw/action-container-substitutions.md`\n- `.github/aw/agent-runtime-instructions.md`\n- `.github/aw/agentic-chat.md`\n- `.github/aw/agentic-workflows-mcp.md`\n- `.github/aw/asciicharts.md`\n- `.github/aw/campaign.md`\n- `.github/aw/charts-trending.md`\n- `.github/aw/charts.md`\n- `.github/aw/cli-commands.md`\n- `.github/aw/configure-agentic-engine.md`\n- `.github/aw/context.md`\n- `.github/aw/create-agentic-workflow-trigger-details.md`\n- `.github/aw/create-agentic-workflow.md`\n- `.github/aw/create-shared-agentic-workflow.md`\n- `.github/aw/debug-agentic-workflow.md`\n- `.github/aw/dependabot.md`\n- `.github/aw/deployment-status.md`\n- `.github/aw/designer-mappings.md`\n- `.github/aw/designer.md`\n- `.github/aw/evals.md`\n- `.github/aw/experiments.md`\n- `.github/aw/github-agentic-workflows.md`\n- `.github/aw/github-mcp-server-pagination.md`\n- `.github/aw/github-mcp-server.md`\n- `.github/aw/instructions.md`\n- `.github/aw/linter-workflows.md`\n- `.github/aw/llms.md`\n- `.github/aw/loop.md`\n- `.github/aw/lsp.md`\n- `.github/aw/maintainer.md`\n- `.github/aw/mcp-clis.md`\n- `.github/aw/memory-stateful-patterns.md`\n- `.github/aw/memory.md`\n- `.github/aw/messages.md`\n- `.github/aw/multi-agent-research.md`\n- `.github/aw/network.md`\n- `.github/aw/optimize-agentic-workflow.md`\n- `.github/aw/patterns.md`\n- `.github/aw/pr-reviewer.md`\n- `.github/aw/release-workflow.md`\n- `.github/aw/report.md`\n- `.github/aw/reuse.md`\n- `.github/aw/safe-outputs-automation.md`\n- `.github/aw/safe-outputs-content.md`\n- `.github/aw/safe-outputs-management.md`\n- `.github/aw/safe-outputs-runtime.md`\n- `.github/aw/safe-outputs.md`\n- `.github/aw/serena-tool.md`\n- `.github/aw/shared-safe-jobs.md`\n- `.github/aw/skills.md`\n- `.github/aw/subagents.md`\n- `.github/aw/syntax-agentic.md`\n- `.github/aw/syntax-core.md`\n- `.github/aw/syntax-engine.md`\n- `.github/aw/syntax-tools-imports.md`\n- `.github/aw/syntax.md`\n- `.github/aw/test-coverage.md`\n- `.github/aw/test-expression.md`\n- `.github/aw/token-optimization-caching-budgets.md`\n- `.github/aw/token-optimization-observability.md`\n- `.github/aw/token-optimization.md`\n- `.github/aw/triggers.md`\n- `.github/aw/update-agentic-workflow.md`\n- `.github/aw/upgrade-agentic-workflows.md`\n- `.github/aw/visual-regression.md`\n- `.github/aw/workflow-constraints.md`\n- `.github/aw/workflow-editing.md`\n- `.github/aw/workflow-patterns.md`\n\nAfter loading the matching workflow prompt or skill, follow it directly:\n\n- Design workflows from scratch via interview: `.github/aw/designer.md`\n- Create new workflows: `.github/aw/create-agentic-workflow.md`\n- Configure or add declarative engines: `.github/aw/configure-agentic-engine.md`\n- Update existing workflows: `.github/aw/update-agentic-workflow.md`\n- Debug, audit, or investigate workflows: `.github/aw/debug-agentic-workflow.md`\n- Upgrade workflows and fix deprecations: `.github/aw/upgrade-agentic-workflows.md`\n- Create shared components or MCP wrappers: `.github/aw/create-shared-agentic-workflow.md`\n- Create report-generating workflows: `.github/aw/report.md`\n- Fix Dependabot manifest PRs: `.github/aw/dependabot.md`\n- Analyze coverage workflows: `.github/aw/test-coverage.md`\n- Render compact markdown charts: `.github/aw/asciicharts.md`\n- Map CLI commands to MCP usage: `.github/aw/cli-commands.md`\n- Choose workflow architecture and patterns: `.github/aw/patterns.md`\n- Optimize token usage and cost: `.github/aw/token-optimization.md`\n- Design long-running multi-agent research workflows: `.github/aw/multi-agent-research.md`\n\nWhen the task involves OTEL, OTLP, traces, observability backends, or telemetry-driven analysis, also read and follow `skills/otel-queries/SKILL.md` after loading the matching workflow prompt or skill.\n","AGENTS.md":"# React Router Development Guide\n\n## Commands\n\n- **Build**: `pnpm build` (all packages) or `pnpm run --filter <package> build` (single package)\n- **Test (Jest)**: `pnpm test` (all packages), `pnpm test packages/<package>/` (single package), `pnpm test packages/react-router/__tests__/router/fetchers-test.ts` (single file), or `pnpm test -- -t \"action fetch\"` (tests matching name)\n- **Integration tests (Playwright)**: `pnpm test:integration --project chromium` (build + test all), `pnpm test:integration:run --project chromium` (test only, all), `pnpm test:integration:run integration/middleware-test.ts --project chromium` (single file), or `pnpm test:integration:run --project chromium -g \"middleware\"` (tests matching name)\n- **Typecheck**: `pnpm run typecheck`\n- **Lint**: `pnpm run lint`\n- **Docs generation**: `pnpm run docs` (regenerates API docs from JSDoc)\n- **Type generation**: `pnpm run typegen` (Framework Mode only)\n- **Clean**: `pnpm run clean` (git clean -fdX)\n\n## Modes\n\n**Five distinct modes**: Declarative, Data, Framework, RSC Data (unstable), RSC Framework (unstable). **Always identify which mode(s) a feature applies to.**\n\n1. **Declarative**: `<BrowserRouter>`, `<Routes>`, `<Route>`\n2. **Data**: `createBrowserRouter()` with `loader`/`action`, `<RouterProvider>`\n3. **Framework**: Vite plugin + `routes.ts` + Route Module API (route exports like `loader`, `action`, `default`) + type generation + SSR/SPA\n4. **RSC Data** (unstable): RSC runtime APIs, manual bundler setup, runtime route config\n5. **RSC Framework** (unstable): Framework Mode with `unstable_reactRouterRSC` Vite plugin\n\n**RSC mode differences:**\n\n- **RSC Framework**: `unstable_reactRouterRSC` plugin, `@vitejs/plugin-rsc`, different entry points/format\n- **RSC Data**: Manual bundler, runtime route config typically in `src/routes.ts`, `unstable_RSCRouteConfig`, different runtime APIs, `setupRscTest` in `integration/rsc/`\n\n## Architecture\n\n- **Monorepo**: pnpm workspace, packages in `packages/`\n- **Key packages**:\n - `react-router`: Core (all modes) - `lib/components.tsx`, `lib/hooks.tsx`, `lib/router/`, `lib/dom/`, `lib/rsc/`\n - `@react-router/dev`: Framework tooling - `vite/plugin.ts` (Framework), `vite/rsc/plugin.ts` (RSC Framework), `typegen/`\n - `@react-router/node`, `@react-router/cloudflare`, `@react-router/express`: Server adapters\n - `@react-router/serve`: Minimal server for Framework Mode\n - `@react-router/fs-routes`: File-system routing (`flatRoutes()`)\n\n## Testing\n\n### Unit Tests (`packages/react-router/__tests__/`)\n\nUse Jest for pure routing logic, pure server runtime behavior, router state, React component behavior. No build required.\n\n```bash\npnpm test # All packages\npnpm test packages/react-router/ # Single package\npnpm test packages/react-router/__tests__/router/fetchers-test.ts # Single file\npnpm test -- -t \"action fetch\" # Tests matching name\n```\n\n### Integration Tests (`integration/`)\n\nUse Playwright for Vite plugin, build pipeline, SSR/hydration, RSC, type generation.\n\n```bash\npnpm test:integration --project chromium # Build + test all\npnpm test:integration:run --project chromium # Test only, all\npnpm test:integration:run integration/middleware-test.ts --project chromium # Single file\npnpm test:integration:run --project chromium -g \"middleware\" # Tests matching name\n```\n\n**Project**: Always use `chromium` for integration tests, unless explicitly stated otherwise.\n\n**Rebuild when**: First run, after changing `packages/` (not needed for test-only changes)\n\n**Organization**: Use `createFixture()` → `createAppFixture()` → `PlaywrightFixture`. Templates available: `vite-6-template/`, `rsc-vite-framework/`, etc. Test all applicable modes (iterate over template array when behavior should work across modes). Test both states when introducing future flags (one test with flag on, one with flag off).\n\n**RSC testing**:\n\n- **RSC Framework**: Use `createFixture` with `rsc-vite-framework/` template\n- **RSC Data**: Use `setupRscTest` in `integration/rsc/`\n\nTest shared behavior across multiple templates (e.g., `[\"vite-5-template\", \"rsc-vite-framework\"]`). Test RSC-specific features against RSC template.\n\n## routes.ts\n\nFramework Mode uses `routes.ts` in `app/`. Most tests use `flatRoutes()` for file-system routing:\n\n```ts\n// app/routes.ts\nimport { type RouteConfig } from \"@react-router/dev/routes\";\nimport { flatRoutes } from \"@react-router/fs-routes\";\n\nexport default flatRoutes() satisfies RouteConfig;\n```\n\n**File-system conventions** (`app/routes/`):\n\n- `_index.tsx` → `/` (index route)\n- `about.tsx` → `/about`\n- `blog.$slug.tsx` → `/blog/:slug` (URL param)\n- `settings.profile.tsx` → `/settings/profile` (`.` creates nesting)\n- `_layout.tsx` → pathless layout route\n\n**Manual config alternative**:\n\n```ts\nimport { index, route, layout } from \"@react-router/dev/routes\";\nexport default [\n index(\"./home.tsx\"),\n route(\"about\", \"./about.tsx\"),\n layout(\"./auth-layout.tsx\", [route(\"login\", \"./login.tsx\")]),\n];\n```\n\n## Documentation\n\n**Don't edit generated files**: `docs/api/` (from JSDoc), `.react-router/types/` (from typegen)\n\n**Mode indicators**: Every doc needs `[MODES: framework, data, declarative]`\n\n**API docs**: Edit JSDoc in `packages/react-router/lib/`, run `pnpm docs`\n\n**Unstable features**: Prefix `unstable_`, add `unstable: true` to frontmatter, include warning block\n\n## Future Flags\n\n- **Future flags** (`vX_*`): Stable breaking changes for next major\n- **Unstable flags** (`unstable_*`): Experimental, may change\n\nTest both states (on/off) for future flags. Don't break existing behavior without a flag.\n\n## License\n\nBy contributing to React Router, you agree that your contributions will be licensed under the [MIT License](./LICENSE.md).\n\n## Change Files\n\nWhen making changes that affect users, create a change file at `packages/<package>/.changes/<type>.<unique-meaningful-name>.md`. `<type>` should be either `patch`, `minor`, `major` or `unstable` to indicate the type of API change being made. If iterating on a change that hasn't shipped yet, update the existing change file instead of creating a new one.\n\nFormat:\n\n```markdown\nBrief description of the change\n\n- Additional details if needed\n```\n\n## Branching\n\n- **`main`**: Active Development\n- **`v7`**: v7.x maintenance\n- **`v6`**: v6.x maintenance\n- Branch from `main` for code and docs changes\n\n## Key Files\n\n| Purpose | Location |\n| ----------------- | ----------------------------------------------------------- |\n| Router | `packages/react-router/lib/router/router.ts` |\n| React API | `packages/react-router/lib/components.tsx`, `lib/hooks.tsx` |\n| Vite plugin | `packages/react-router-dev/vite/plugin.ts` |\n| RSC Vite plugin | `packages/react-router-dev/vite/rsc/plugin.ts` |\n| Type generation | `packages/react-router-dev/typegen/` |\n| Unit tests | `packages/react-router/__tests__/` |\n| Integration tests | `integration/` |\n| Decision docs | `decisions/` |\n","CLAUDE.md":"# React Router Project Instructions\n\n## Session Start\n\n**REQUIRED**: Read [./AGENTS.md](./AGENTS.md) at the start of every session. It contains:\n\n- Project architecture and key files\n- React Router modes (Declarative, Data, Framework, RSC)\n- Build/test commands (Jest unit tests, Playwright integration tests with `--project chromium`)\n- Testing patterns and conventions\n- Documentation guidelines\n\n### Skills\n\nIf there is an [`.agents/skills`](.agents/skills) directory in the repository, symlink those skills to `.claude/skills` to make sure they are made available to Claude. Refresh you list of available skills if needed. This is a git ignored directory because we want to keep the canonical skills in `.agents/skills`.\n\n## During Work\n\n**Always consult AGENTS.md** when you need to:\n\n- Run tests or builds\n- Understand which mode(s) a feature applies to\n- Find key file locations\n- Understand testing patterns\n\nDo not guess at commands - reference AGENTS.md for the correct syntax.\n","packages/create-react-router/README.md":"Create a new React Router app.\n\n```sh\nnpm create react-router\n```\n","packages/react-router-architect/README.md":"[Architect](https://arc.codes) server request handler for React Router.\n\n```bash\nnpm install @react-router/architect\n```\n","packages/react-router-cloudflare/README.md":"Cloudflare platform abstractions for React Router\n\n```bash\nnpm install @react-router/cloudflare @cloudflare/workers-types\n```\n","packages/react-router-dev/README.md":"Dev tools and CLI for React Router that enables framework features through bundler integration like server rendering, code splitting, HMR, etc.\n\n```sh\nnpm install @react-router/dev --save-dev\n```\n","packages/react-router-express/README.md":"[Express](https://expressjs.com) server request handler for React Router.\n\n```sh\nnpm install @react-router/express\n```\n","packages/react-router-fs-routes/README.md":"File system routing conventions for React Router\n\n```sh\nnpm install @react-router/fs-routes\n```\n","packages/react-router-node/README.md":"Node.js platform abstractions for React Router\n\n```sh\nnpm install @react-router/node\n```\n","packages/react-router-remix-routes-option-adapter/README.md":"# @react-router/remix-routes-option-adapter\n\nAdapter for [Remix's](https://remix.run) `routes` config option, for use within `routes.ts`.\n\n```sh\nnpm install @react-router/remix-routes-option-adapter\n```\n","packages/react-router-serve/README.md":"Node.js application server for React Router\n\n```sh\nnpm install @react-router/serve\n```\n","packages/react-router/README.md":"`react-router` is the primary package in the React Router project.\n\n## Installation\n\n```sh\nnpm i react-router\n```\n",".cursorrules (react-router-v7.mdc)":"# React Router v7 Rules\n\n## Route Modules\n\n- Use route modules as the boundary for route UI, loader data, actions, metadata, and error boundaries.\n- Keep route modules small; move shared UI to components and reusable data access to services.\n- Prefer file-based routing in framework mode when the project is configured for it.\n- Use nested routes for shared layouts and progressive disclosure.\n- Export route-specific `ErrorBoundary` components for recoverable route failures.\n\n## Data Loading\n\n- Use loaders for route data that should be available before render.\n- Keep loaders deterministic and side-effect free.\n- Validate params and search params at the loader boundary.\n- Return typed data and consume it through route hooks rather than duplicating fetch logic in components.\n- Use deferred or streaming patterns only when they improve perceived performance.\n\n## Mutations\n\n- Use actions for route mutations and form submissions.\n- Prefer `Form`, `useFetcher`, and `useSubmit` for progressive enhancement.\n- Revalidate affected loader data after mutations.\n- Handle validation errors as typed action data instead of generic exceptions.\n- Keep server-only secrets and privileged operations out of client actions.\n\n## Navigation and State\n\n- Store shareable state in URL params or search params.\n- Keep ephemeral UI state local to components.\n- Use pending navigation state to show optimistic or loading UI.\n- Avoid global state for data that belongs to route loaders.\n\n## TypeScript and Testing\n\n- Type loader and action return values.\n- Add tests for route loaders, actions, validation failures, and error boundaries.\n- Use integration tests for critical form and navigation flows.\n- Mock network and persistence at the route-service boundary.\n\n## Common Mistakes\n\n- Do not duplicate loader fetches in `useEffect`.\n- Do not mutate data in loaders.\n- Do not hide route errors behind a single generic app-level catch-all.\n- Do not put auth checks only in components when loader data is protected."},"files":{".agents/skills/create-pr/SKILL.md":"---\nname: create-pr\ndescription: Create and package React Router pull requests. Use when the user asks to create, open, prepare, or finish a PR for this repository, including branch/commit/push handoff, draft PR creation, PR body writing, and applying GitHub labels such as pkg:*, feat:*, docs, github-actions, or dependencies.\n---\n\n# Create React Router PR\n\nCreate the pull request handoff for completed React Router work. Default to a draft PR targeting `main` unless the user explicitly asks for a ready PR or a different base branch.\n\n## Preconditions\n\n- Inspect `git status --short --branch` and `git branch --show-current`.\n- Do not include unrelated dirty files. If unrelated changes are present, leave them unstaged and mention them.\n- If the worktree is detached, create a branch from the current `HEAD` before committing. Use the branch name requested by the user, an existing repository convention, or `<author>/<semantic-name>` when no stronger convention is available.\n- If already on a suitable named branch, use it.\n- Confirm appropriate automated coverage exists or was added. Do not list routine CI-covered checks in the PR body.\n- If user-facing functionality is being updated, check that the appropriate package has a change file under `packages/<package>/.changes/`. This is not necessary for docs-only, GitHub Actions/workflow-only, or dependency-maintenance PRs unless the dependency change itself has user-facing impact.\n\n## Context\n\n- Capture what changed, why it changed, and who it affects.\n- Find related issues, discussions, or PRs and include links when relevant.\n- Prefer `git diff --stat` plus focused `git diff` over broad repo archaeology when the change is small.\n- If the user supplies a report, issue, discussion, or related PR, treat that as the primary context source.\n- For new feature work, include a concise usage snippet. If the feature replaces or improves an older approach, include before/after examples when they help reviewers.\n\n## Commit and Push\n\n1. Review the diff with `git diff --stat` and focused `git diff` as needed.\n2. Stage only the intended files.\n3. Commit with a concise imperative subject.\n4. Push the branch before creating the PR.\n\n## PR Creation\n\nSave the PR body to a temporary file, then use `gh pr create` with:\n\n```sh\ngh pr create --draft --base main --head <branch> --title \"<title>\" --body-file <file>\n```\n\n- Omit `--draft` only when the user explicitly asks for a ready PR.\n- Change `--base` only when the user explicitly requests a different base branch.\n- Keep shell quoting simple. Prefer a body file if the body contains backticks, quotes, or multiple paragraphs.\n- Include issue/discussion links when known. Use `Closes #NNNN` for bug fixes the PR should close; use `Implements #NNNN` or a plain link for RFCs/discussions when closing semantics are not appropriate.\n- Include testing notes only for manual checks, unusual verification, skipped non-CI checks, or failures that reviewers should know about.\n- If `gh pr create` fails, leave the branch pushed when possible and give the user a ready-to-open compare URL plus the prepared title and body.\n\nRecommended PR body shape:\n\n````markdown\nThis change ...\n\n- Optional extra detail when useful.\n\n```tsx\n// Optional feature usage example\n```\n````\n\n```tsx\n// Optional before/after example\n```\n\n**Testing**\n\n- Optional manual or non-CI verification notes only.\n\n````\n\n- Do not use a `## Summary` heading. Start with one or two short sentences explaining what the change accomplishes.\n- Add bullets after the opening only when more detail is useful.\n- Include usage examples for new features, and before/after examples for replacements or improvements, when they help reviewers understand the change.\n- Add `**Testing**` with bullets below the description only when there are manual checks, unusual verification steps, skipped non-CI checks, or failures reviewers should know about. Omit it for routine automated coverage.\n\n## Testing Notes\n\n- Do not list linting, typechecking, unit test, or integration test commands in the PR body, even if they were run locally. CI runs these automatically.\n- Do not say that CI will run routine linting, typechecking, unit tests, or integration tests. That is assumed for every PR.\n- Do not add manual testing instructions by default.\n- Add manual testing instructions only when necessary, such as visual/UI behavior that needs human review, environment-specific behavior not covered by CI, release/publish dry-run steps, external service integration, or a reproduction that cannot be expressed reliably in automated tests.\n- When manual testing is necessary, keep the instructions minimal and directly tied to the uncovered risk.\n\n## Labels\n\nApply labels after the PR exists. Rely on the stable labels listed in this skill for normal PRs.\n\nApply labels with:\n\n```sh\ngh pr edit <number-or-url> --add-label \"<label>\"\n````\n\nIf `gh pr edit --add-label` fails because the specified label is invalid or missing, run:\n\n```sh\ngh label list --limit 200\n```\n\nThen choose the correct label from the live list and update this skill in place so the stable label guidance stays current. Use real labels only. If the right label does not exist, do not invent one; mention the missing label.\n\n### Package Labels\n\nAdd every applicable `pkg:*` label based on touched package paths:\n\n| Touched path | Label |\n| ---------------------------------------------------- | ----------------------------------------------- |\n| `packages/react-router/` | `pkg:react-router` |\n| `packages/react-router-dev/` | `pkg:@react-router/dev` |\n| `packages/create-react-router/` | `pkg:create-react-router` |\n| `packages/react-router-architect/` | `pkg:@react-router/architect` |\n| `packages/react-router-cloudflare/` | `pkg:@react-router/cloudflare` |\n| `packages/react-router-node/` | `pkg:@react-router/node` |\n| `packages/react-router-serve/` | `pkg:@react-router/serve` |\n| `packages/react-router-express/` | `pkg:@react-router/express` |\n| `packages/react-router-fs-routes/` | `pkg:@react-router/fs-routes` |\n| `packages/react-router-remix-routes-option-adapter/` | `pkg:@react-router/remix-routes-option-adapter` |\n\nIf a package path is unclear, inspect its `package.json` `name` and use `pkg:<name>` when that label exists. If a change touches generated artifacts or integration tests only, infer the package label from the runtime/tooling area being tested. For example, Vite plugin or prerender integration coverage usually maps to `pkg:@react-router/dev`.\n\n### Feature Labels\n\nAdd applicable `feat:*` labels for the behavior area being changed. Common labels include:\n\n| Behavior area | Label |\n| --------------------------------------------------------------------------------- | --------------------------- |\n| Core navigation, loaders/actions, fetchers, redirects, matching, and router state | `feat:router` |\n| Route config APIs and `routes.ts` | `feat:routes.ts` |\n| Vite plugin and build pipeline behavior | `feat:vite` |\n| SPA mode | `feat:spa-mode` |\n| Prerendering | `feat:prerender` |\n| Lazy route discovery | `feat:lazy-route-discovery` |\n| Hydration and hydration fallback behavior | `feat:hydration` |\n| View transition APIs | `feat:view-transitions` |\n| Middleware behavior | `feat:middleware` |\n| Split route module behavior | `feat:split-route-modules` |\n| Streaming behavior | `feat:streaming` |\n| CSS handling | `feat:css` |\n| Windows-specific fixes | `feat:windows` |\n| RSC Data or RSC Framework behavior | `feat:rsc` |\n| Path matching semantics | `feat:path-matching` |\n| Single fetch behavior | `feat:single-fetch` |\n| Types, typegen, and TypeScript behavior | `feat:typescript` |\n\nMultiple feature labels are fine when the diff truly spans multiple areas. Prefer the most specific label that exists.\n\n### Non-Package Labels\n\nSome PRs do not need package or feature labels:\n\n- Add `docs` for documentation-only changes.\n- Add `github-actions` for `.github/workflows/` or Actions infrastructure changes.\n- Add `dependencies` for dependency or lockfile-only maintenance.\n- Add version labels such as `v6`, `v7`, or `v8` only when the PR is intentionally scoped to that release line or the user asks for it.\n\n## Final Report\n\nReport:\n\n- Branch name.\n- Commit hash.\n- PR URL and whether it is draft or ready.\n- Base branch.\n- Labels applied.\n- Verification performed or skipped.\n",".agents/skills/finish-line/SKILL.md":"---\nname: finish-line\ndescription: Bring a blocked React Router community pull request across the finish line. Use when the user invokes `/finish-line` or `$finish-line`, provides a PR number or URL, and asks Codex to resolve merge blockers such as a missing change file, missing documentation, missing tests, or stale contributor follow-up. Handles evaluating the blocker and pushing small maintainer fixes onto a contributor PR branch when authorized.\n---\n\n# Finish Line\n\n## Overview\n\nFinish blocked community PRs in `remix-run/react-router` while respecting contributor ownership and the repo's PR packaging conventions.\n\nTreat the PR number or URL in `$ARGUMENTS` as the target PR. If no target is provided, ask for it before doing anything.\n\n## Triage\n\n1. Inspect local state with `git status --short --branch`. If unrelated dirty files exist, do not overwrite or stage them.\n2. Fetch current main before making branch decisions:\n\n```sh\ngit fetch origin main\n```\n\n3. Gather PR context:\n\n```sh\ngh pr view <pr> --repo remix-run/react-router --json number,title,body,state,isDraft,author,baseRefName,headRefName,headRepository,headRepositoryOwner,maintainerCanModify,mergeStateStatus,reviewDecision,labels,files,commits,statusCheckRollup,url\ngh pr checks <pr> --repo remix-run/react-router\ngh pr diff <pr> --repo remix-run/react-router --stat\ngh pr view <pr> --repo remix-run/react-router --comments\n```\n\n4. Identify merge blockers. In particular:\n\n- If the PR only needs repo-maintainer additions such as tests, a change file, or docs, use the contributor-branch workflow.\n- If the contributor branch cannot be modified, summarize the evidence and ask the user whether to wait for the contributor or recreate the work on a maintainer branch.\n- If the blocker is unclear, summarize the evidence and ask the user which path to take.\n\n5. Evaluate test coverage before deciding the finish-line changes:\n - Inspect the PR diff, changed files, existing nearby tests, review comments, and failed checks for test expectations.\n - If the PR changes runtime behavior, build/plugin behavior, routing semantics, generated types, RSC behavior, docs rendering, or any bug/feature surface that can regress, add or preserve a focused test unless equivalent coverage already exists.\n - If tests are already included, verify they exercise the changed behavior and cover the affected React Router mode(s): Declarative, Data, Framework, RSC Data, and/or RSC Framework.\n - If tests are not needed because the change is documentation-only, packaging-only, a change file, or otherwise not executable behavior, note that rationale in the final report.\n - If a useful test is required but too large or risky for the finish-line scope, stop and ask the user before broadening the PR.\n\n## Contributor-Branch Workflow\n\nUse this path when the missing work is a small maintainer follow-up, such as tests, a change file, or docs, and the contributor branch can be modified.\n\n1. Check out the PR branch:\n\n```sh\ngh pr checkout <pr-number> --repo remix-run/react-router\n```\n\n2. Confirm the branch and local state:\n\n```sh\ngit status --short --branch\ngit branch --show-current\n```\n\n3. Make only the missing finish-line changes, including focused tests when the coverage evaluation requires them. Do not refactor the contributor's work unless it is necessary to unblock mergeability and the user agrees.\n4. Validate the exact content with the user before pushing:\n - For a change file, show the package path, file name, change type, and full markdown contents.\n - For docs, show the affected files and the relevant prose/API snippets.\n - For tests, show the test file path, the behavior covered, and the mode(s) covered.\n - Ask explicitly for approval to commit and push back to the PR branch.\n5. After approval, run focused validation when appropriate, commit the maintainer follow-up, and push to the PR branch. If `git push` fails because the contributor branch cannot be modified, stop and report the failure instead of opening a replacement PR unless the user approves that pivot.\n\n## Change Files\n\nCreate change files under the affected package:\n\n```text\npackages/<package>/.changes/<type>.<unique-meaningful-name>.md\n```\n\nUse `patch`, `minor`, `major`, or `unstable` for `<type>`. For bug fixes and narrow behavior fixes, default to `patch`. Keep the content concise:\n\n```markdown\nBrief description of the user-facing change\n```\n\nIf the PR spans multiple packages, prefer the package with the direct user-facing API or runtime behavior. Ask the user when the package or change type is not obvious.\n\n## Documentation\n\nDo not add documentation by default for ordinary bug fixes. Add docs when the PR changes a documented API, introduces new behavior users need to discover, changes examples, or the user/reviewer explicitly requested docs.\n\nFollow repo docs rules:\n\n- Edit source docs or JSDoc, not generated `docs/api/` output.\n- Include mode context when adding docs for React Router behavior: Declarative, Data, Framework, RSC Data, or RSC Framework.\n- For API docs generated from JSDoc, edit `packages/react-router/lib/` comments and note that `pnpm run docs` may be required.\n\n## Final Report\n\nReport the path taken and the current PR state:\n\n- Original PR number and blocker.\n- Whether changes were pushed to the contributor branch or a replacement PR was opened.\n- Branch, commit hash, and PR URL when applicable.\n- Any old-PR comment/close action taken.\n- Validation performed or skipped.\n- Test coverage decision: added, already present, or intentionally omitted with rationale.\n",".agents/skills/fix-bug/SKILL.md":"---\nname: fix-bug\ndescription: \"Fix a reported bug in React Router from a GitHub issue. Use when the user provides a GitHub issue URL and asks to fix a bug, investigate an issue, or reproduce a problem. Handles the full workflow: fetching the issue, finding the reproduction, writing a failing test, and implementing the fix.\"\ndisable-model-invocation: true\n---\n\n# Fix React Router Bug\n\nFix the bug reported in the following GitHub issue: $ARGUMENTS\n\n## Branching\n\nBug fixes should start from a clean working tree. If there are changes, prompt me to resolve them before continuing.\n\nBugs should be fixed from the `main` branch in a new branch using the format `{author}/{semantic-branch-name}` (i.e., `brophdawg11/fix-navigation`):\n\n```sh\ngit branch {author}/{semantic-branch-name} main\ngit checkout {author}/{semantic-branch-name}\n```\n\n## Workflow\n\n### 1. Fetch and Understand the Issue\n\nUse `gh issue view <number> --repo remix-run/react-router` or `WebFetch` to read the full issue.\n\nExtract:\n\n- Bug description and expected vs actual behavior\n- React Router version and mode (Declarative / Data / Framework / RSC)\n- Any code snippets in the issue\n- Links to reproductions (StackBlitz, CodeSandbox, GitHub repo, etc.)\n\n### 2. Validate the Reproduction\n\n**If there's a StackBlitz/CodeSandbox/online sandbox link:**\n\n- Use `WebFetch` to read the sandbox URL and extract the relevant code\n- Identify the exact sequence of events that triggers the bug\n\n**If there's a GitHub repository link:**\n\n- Use `WebFetch` to read key files (`package.json`, relevant source files) from the raw GitHub URL\n- Identify the route configuration, loaders, actions, or components involved\n\n**If no reproduction link exists:**\n\n- Search the issue comments with `gh issue view <number> --repo remix-run/react-router --comments`\n- Look for code snippets in comments\n- Ask the user: \"No reproduction was provided. Can you share a minimal reproduction or paste the relevant code?\"\n\n### 3. Identify the Affected Code\n\nBased on the bug, locate the relevant source files. Consult the key file map:\n\n| Area | Files |\n| ---------------------- | ----------------------------------------------------------- |\n| Core router logic | `packages/react-router/lib/router/router.ts` |\n| React components/hooks | `packages/react-router/lib/components.tsx`, `lib/hooks.tsx` |\n| DOM utilities | `packages/react-router/lib/dom/` |\n| Vite/Framework plugin | `packages/react-router-dev/vite/plugin.ts` |\n| RSC | `packages/react-router/lib/rsc/` |\n\nUse `Grep` and `Glob` to trace the relevant code paths.\n\n### 4. Write a Failing Test\n\n**Unit test** (for router logic, hooks, pure component behavior — no build needed):\n\n- Location: `packages/react-router/__tests__/`\n- Use Jest; run with: `pnpm test packages/react-router/__tests__/<file>`\n- Match the style of nearby test files (describe/it blocks, `createStaticHandler`, `createMemoryRouter`, `render`, `screen`, etc.)\n\n**Integration test** (for Vite plugin, SSR, hydration, Framework Mode):\n\n- Location: `integration/`\n- Use Playwright with `createFixture()` → `createAppFixture()` → `PlaywrightFixture`\n- Run with: `pnpm test:integration:run --project chromium integration/<file>`\n- Build first if needed: `pnpm test:integration --project chromium`\n\nWrite the test to **reproduce the bug exactly** — it must fail before the fix.\n\nRun it and confirm it fails:\n\n```bash\npnpm test packages/react-router/__tests__/<file> # unit\n# or\npnpm test:integration:run --project chromium integration/<file> # integration\n```\n\n### 5. Implement the Fix\n\n- Make the minimal change needed to fix the bug\n- Do not refactor unrelated code\n- Confirm the fix addresses the root cause, not just the symptom\n- Consider all five modes: does this fix break anything in Declarative / Data / Framework / RSC?\n\nRun the failing test again — it must now pass:\n\n```bash\npnpm test packages/react-router/__tests__/<file>\n```\n\nRun the broader test suite to check for regressions:\n\n```bash\npnpm test packages/react-router/\n```\n\nIf the fix touches Framework/Vite code, run integration tests too:\n\n```bash\npnpm test:integration:run --project chromium\n```\n\nConfirm linting and typechecking pass:\n\n```bash\npnpm lint\npnpm typecheck\n```\n\n### 6. Create a Change file\n\nCreate a change file at `packages/<package>/.changes/<type>.<unique-meaningful-name>.md`. `<type>` should be either `patch`, `minor`, `major` or `unstable` to indicate the type of API change being made.\n\nFormat:\n\n```markdown\nfix: <brief description of what was fixed>\n```\n\n### 7. Report Results\n\nSummarize:\n\n- What the bug was and why it happened\n- What code was changed and why\n- That the test now passes\n- Any edge cases or related issues noticed\n\nAsk me to review the changes and iterate based on any feedback.\n\n### 8. Open PR\n\nOnce I approve the fix, commit the changes and open a PR to `main`. Include a `Closes #NNNN` in the description to link the PR to the original issue. Also link the issue in the `Development` sidebar\n",".agents/skills/implement-rfc/SKILL.md":"---\nname: implement-rfc\ndescription: Implement a React Router RFC from a GitHub discussion URL. Fetches the proposal, evaluates community feedback, resolves outstanding questions interactively, then implements the feature with tests, future flags (if breaking), and a changeset.\ndisable-model-invocation: true\n---\n\n# Implement React Router RFC\n\nImplement the RFC from the following GitHub discussion: $ARGUMENTS\n\n## Branching\n\nRFC implementations should start from a clean working tree. If there are uncommitted changes, stop and ask me to resolve them before continuing.\n\n- If you are already on a named branch that is at the same HEAD as `main`, use that branch.\n- Otherwise, create a branch from `main` using the format `{author}/rfc-{semantic-name}`:\n ```sh\n git branch {author}/rfc-{semantic-name} main\n git checkout {author}/rfc-{semantic-name}\n ```\n\n## Workflow\n\n### 1. Fetch and Understand the RFC\n\nUse `WebFetch` to read the discussion URL. If a GitHub discussion number is given instead of a URL, construct:\n`https://github.com/remix-run/react-router/discussions/<number>`\n\nExtract:\n\n- **Problem being solved**: what pain point does this RFC address?\n- **Proposed API**: exact function signatures, hook names, types, option shapes\n- **Affected modes**: Declarative / Data / Framework / RSC Data / RSC Framework\n- **Breaking changes**: does this change or remove existing public API?\n- **Open questions**: anything explicitly marked as unresolved, \"TBD\", or asked as a question in the proposal\n- **Status**: are there linked tracking issues? Look for links to other github issues and read them to see if there is additional context.\n\n ```sh\n gh issue view <number> --repo remix-run/react-router\n ```\n\n### 2. Evaluate Community Feedback\n\nFetch all comments from the discussion:\n\nUse `WebFetch` on `https://github.com/remix-run/react-router/discussions/<number>` and scroll through the full thread. Look for:\n\n- **Concerns or objections** raised by community members or maintainers\n- **Alternative proposals** or API shape suggestions\n- **Edge cases** raised that the proposal does not address\n- **Positive signals** — repeated praise for a specific approach signals it's the right direction\n- **Maintainer responses** — Ryan Florence, Michael Jackson, or other core team members clarifying intent\n\nSummarize the community sentiment into:\n\n- Points of consensus (safe to proceed)\n- Points of contention (need resolution before implementing)\n- Unanswered questions from the original proposal\n\n### 3. Resolve Outstanding Questions\n\nBefore writing any code, present me with a numbered list of every unresolved question — from both the RFC itself and from community feedback. For each question:\n\n- State the question clearly\n- Summarize relevant community input\n- Offer a recommended answer with reasoning\n\nAsk me to confirm, override, or skip each question. Do not proceed to implementation until all questions are either answered or explicitly deferred.\n\nExample format:\n\n```\n## Unresolved Questions\n\n1. **Should `useRouterState()` accept a path argument for scoped matching?**\n Community feedback: 3 comments in favor, 1 against (concerns about complexity).\n Recommendation: Yes — scoped matching improves type safety for nested routes.\n → Your decision: [confirm / override / defer]\n\n2. **What should happen when the path doesn't match the current location?**\n Recommendation: Return `null` for active state (consistent with `useMatch()`).\n → Your decision: [confirm / override / defer]\n```\n\nSave the resolved decisions to a scratch file at `tasks/rfc-decisions.md` for reference during implementation.\n\n### 4. Plan the Implementation\n\nBefore writing code, produce a concise implementation plan covering:\n\n- New types/interfaces to add\n- New functions/hooks to implement and their file locations\n- Existing APIs to deprecate (mark with `@deprecated` JSDoc + console warning in dev)\n- Whether a future flag is needed (see §5 below)\n- Test files to create or extend (unit and/or integration)\n- Changeset bump level (`minor` for new features, `major` for breaking changes behind a future flag that is now defaulted on)\n\nPresent the plan to me and wait for approval before implementing.\n\n### 5. Future Flags for Breaking Changes\n\nIf the RFC changes or removes existing public API behavior, it **must** ship behind a future flag which will start with an `unstable_` prefix.\n\n**Future flag pattern:**\n\n1. Add the flag to `FutureConfig` in `packages/react-router/lib/router/utils.ts`:\n\n ```ts\n export interface FutureConfig {\n // existing flags...\n unstable_myNewBehavior: boolean;\n }\n ```\n\n2. Gate the new behavior on the flag:\n\n ```ts\n if (router.future.unstable_myNewBehavior) {\n // new behavior\n } else {\n // legacy behavior\n }\n ```\n\n3. Document the flag in `docs/upgrading/future-flags.md` if it exists.\n\nNew additive APIs (no behavior change to existing code) do **not** need a future flag.\n\n### 6. Key File Locations\n\n| Area | Files |\n| --------------------- | -------------------------------------------- |\n| Core router logic | `packages/react-router/lib/router/router.ts` |\n| Router types/utils | `packages/react-router/lib/router/utils.ts` |\n| React components | `packages/react-router/lib/components.tsx` |\n| React hooks | `packages/react-router/lib/hooks.tsx` |\n| Public exports | `packages/react-router/index.ts` |\n| DOM utilities | `packages/react-router/lib/dom/` |\n| Framework/Vite plugin | `packages/react-router-dev/vite/plugin.ts` |\n| RSC runtime | `packages/react-router/lib/rsc/` |\n| Unit tests | `packages/react-router/__tests__/` |\n| Integration tests | `integration/` |\n| Future flags doc | `docs/upgrading/future-flags.md` |\n\nConfirm existing patterns before writing new code - prefer using the LSP but `Grep`/`Glob` also work. Match naming conventions and code style exactly.\n\n### 7. Implement the Feature\n\nFollow the approved plan. For each logical unit of work:\n\n1. Write the implementation\n2. Export from the appropriate public entry point (`packages/react-router/index.ts`)\n3. Add `@deprecated` JSDoc to any APIs being superseded\n4. Run typecheck to catch type errors early:\n ```sh\n pnpm typecheck\n ```\n\nKeep changes minimal and focused. Do not refactor unrelated code. Commit as often as needed.\n\n### 8. Write Tests\n\n**Unit tests** (for hooks, pure router logic, component behavior — no build):\n\n- Location: `packages/react-router/__tests__/`\n- Runner: Jest → `pnpm test packages/react-router/__tests__/<file>`\n- Cover: happy path, edge cases identified in RFC/community feedback, future flag gating (if applicable), deprecation warnings\n\n**Integration tests** (for Vite/Framework Mode, SSR, hydration):\n\n- Location: `integration/`\n- Runner: Playwright → `pnpm test:integration:run --project chromium integration/<file>`\n- Required if the RFC touches Framework Mode, file-system routing, or SSR behavior\n\nRun all tests and confirm they pass:\n\n```sh\npnpm test packages/react-router/\npnpm test:integration:run --project chromium # only if integration tests were added/changed\n```\n\n### 9. Lint and Typecheck\n\n```sh\npnpm lint\npnpm typecheck\n```\n\nFix all errors before proceeding.\n\n### 10. Create a Change File\n\nCreate `packages/<package>/.changes/<bump-level>.<descriptive-name>.md`. Use the RFC title or tracking issue as the description:\n\n```markdown\nfeat: <brief description matching the RFC title>\n\nImplements the `useRouterState()` RFC (#12358). Deprecates `useLocation`,\n`useParams`, `useSearchParams`, `useNavigation`, `useMatches`, `useMatch`,\n`useNavigationType`, and `useViewTransitionState` in favor of a unified API.\n\nEnable the `unstable_consolidatedRouterState` future flag to opt in.\n```\n\nBump levels:\n\n- `patch` — bug-adjacent fix only\n- `minor` — new additive API (no breaking changes)\n- `major` — breaking change (should be rare; most breaking changes go behind a future flag as `minor` first)\n- `unstable` — new API that is not yet stable (e.g. added in a future flag, or an experimental API that may be removed without a major bump)\n\n### 11. Report and Review\n\nSummarize:\n\n- What RFC was implemented and which decisions were made\n- New public APIs added (with brief usage example)\n- APIs deprecated and the migration path\n- Future flag name (if applicable) and how to opt in\n- Test coverage added\n- Anything deferred or explicitly out of scope\n\nAsk me to review and iterate before opening a PR.\n\n### 12. Commit\n\nOnce I approve, commit and open a PR to `main`:\n\n```sh\ngh pr create --base main --title \"feat: <RFC title>\" --body \"...\"\n```\n\nPR body should include:\n\n- Link to the RFC discussion (Closes or Implements #NNNN)\n- Summary of what was implemented\n- Future flag instructions if applicable\n- Testing notes\n- Any decisions that deviated from the original proposal and why\n",".agents/skills/prepare-release-notes/SKILL.md":"---\nname: prepare-release-notes\ndescription: Prepare React Router release notes before running the changes/versioning scripts. Use when asked to review, polish, normalize, or prepare pending change files under packages/*/.changes, remove semantic commit prefixes from release bullets, enforce imperative tense, decide whether a manual scripts/changes/whats-changed.md section is warranted, or draft long-form release notes for new features, stable future flags, or unstable flags.\n---\n\n# Prepare Release Notes\n\nPolish pending React Router change files and add manual release notes only when the release needs narrative context beyond the generated change lists.\n\n## Workflow\n\n1. Inspect local state:\n\n```sh\ngit status --short\nfind packages -path '*/.changes/*.md' -not -name README.md -not -name .gitkeep -print | sort\n```\n\n2. Read every pending change file. Do not edit generated changelogs or released notes directly.\n\n3. Normalize each change file:\n - Remove `feat:`, `feat(...)`, `fix:`, and `fix(...)` semantic-commit prefixes from prose\n - Use present or imperative tense for the first line and top-level release bullets: prefer `Add`, `Fix`, `Remove`, `Support`, `Stabilize`, `Preserve`, `Update`, `Avoid`, `Prevent`, `Throw`, `Warn`, `Expose`\n - Nested detail bullets can stay explanatory when they expand on the parent bullet; do not rewrite them solely to force present or imperative tense\n - Remove terminal sentence periods from bullet items because release generation appends PR/commit links after the first bullet line\n - Remove terminal sentence periods from nested bullet items too, unless the punctuation is part of code, a URL, an abbreviation, a version number, or another token where removing it would be wrong\n - If one bullet contains multiple sentences, split it into a shorter parent bullet plus nested bullet items\n - Keep the first line concise and user-facing; use nested bullets for details or migration notes\n\n4. Review whether `scripts/changes/whats-changed.md` is needed:\n - Read `CHANGELOG.md` examples or `references/whats-changed.md` when uncertain\n - Add `scripts/changes/whats-changed.md` only for features, future flag stabilizations, unstable flags, migration guidance, breaking bug fixes, or complex behavior that needs long-form text or examples\n - Do not add it for ordinary bug fixes, dependency cleanup, internal refactors, or release bullets that are already clear\n - If adding it, write the body only; the release script adds `### What's Changed` when missing\n\n5. Validate:\n\n```sh\npnpm changes:validate\npnpm changes:preview\n```\n\nUse `changes:preview` to inspect the generated root release notes and confirm the PR/commit link placement, section ordering, and any manual What's Changed placement. If dependencies are missing or the command is too expensive for the context, state what was skipped.\n\n## Change File Style\n\nSingle-line entries should read well with an auto-appended PR link:\n\n```markdown\nFix `href()` to stringify and URL-encode param values like `generatePath()`\n```\n\nUse nested bullets for additional sentences:\n\n```markdown\nFix route ranking for dynamic parameters with static extension suffixes\n\n- Identify `/:name.xml` as a dynamic segment instead of a static segment\n- Preserve static route priority for paths like `/sitemap.xml`\n```\n\nAvoid semantic commit prefixes:\n\n```markdown\nAdd support for nub as a package manager\n```\n\nnot:\n\n```markdown\nfeat: add support for nub as a package manager.\n```\n\n## What's Changed Guidance\n\nUse `scripts/changes/whats-changed.md` for release-level narrative, not package-specific bullets. Good candidates include:\n\n- A new user-facing API or feature that benefits from example code\n- Stabilization or renaming of unstable APIs/flags, especially when adopters must migrate\n- A stable future flag that changes behavior and needs adoption guidance\n- A breaking bug fix or adapter/runtime behavior change that may require deployment checks\n- A cluster of related changes whose combined effect matters more than the individual bullet list\n\nKeep the tone direct and practical. Prefer headings under the generated `### What's Changed` section:\n\n````markdown\n#### Feature Name\n\nExplain what changed, who it affects, and how to adopt it.\n\n```ts\n// Optional short example\n```\n````\n\nDo not duplicate every bullet from Minor/Patch/Unstable Changes. Let generated change files carry ordinary PR-level details.\n\nSee `references/whats-changed.md` for examples distilled from the existing changelog.\n",".agents/skills/prepare-release-notes/agents/openai.yaml":"interface:\n display_name: \"Prepare Release Notes\"\n short_description: \"Polish React Router release notes\"\n default_prompt: \"Use $prepare-release-notes to review pending React Router change files and draft any needed What's Changed notes.\"\n",".agents/skills/prepare-release-notes/references/whats-changed.md":"# What's Changed Reference\n\nLoad this when deciding whether a React Router release needs `scripts/changes/whats-changed.md`.\n\n## Include A Manual Section For\n\n- Major releases with baseline changes, removed packages, removed deprecated APIs, new runtime requirements, or migration guidance\n- Stabilizations and flag renames where adopters of unstable APIs need explicit before/after guidance\n- New APIs or flags that deserve a narrative introduction or usage example\n- Cross-cutting performance or behavior work where several bullets form one user-facing story\n- Breaking bug fixes, deployment-sensitive fixes, or adapter/runtime behavior changes where users may need to test or update config\n\n## Usually Do Not Include One For\n\n- Straightforward bug fixes\n- Dependency removals or upgrades where the bullet is sufficient\n- Internal refactors with no public API change\n- A minor feature that is fully understandable from one concise bullet and nested detail bullets\n- Releases where the only content is a normal patch list\n\n## Existing Changelog Patterns\n\n- `v8.1.0`: Uses headings for agent skill installation and observability metadata, including an instrumentation code example. The generated minor bullets still carry the per-package details.\n- `v8.0.0`: Uses long-form migration notes for a major release: baseline support, adopted future flags, removed packages/APIs, and behavior changes.\n- `v7.18.0`: Explains a CSRF check fix that may be a breaking bug fix for reverse-proxy deployments and tells users what to test.\n- `v7.15.0`: Groups several unstable-to-stable API renames and route matching optimizations into narrative sections before listing individual minor bullets.\n- `v7.15.1`: Uses a \"What's New\" style section for an unstable hook with a code example. For new release notes, prefer the current `What's Changed` file path; the generated heading will be `### What's Changed`.\n\n## Drafting Tips\n\n- Use `####` headings inside `scripts/changes/whats-changed.md`; the release script wraps the file in `### What's Changed` if needed\n- Mention applicable React Router modes when the distinction matters: Declarative, Data, Framework, RSC Data, or RSC Framework\n- Keep examples short and directly tied to adoption\n- Avoid repeating the package prefix and PR-link details already provided by generated change sections\n- If unsure, run `pnpm changes:preview` with and without the manual section and keep it only if the generated notes are meaningfully clearer with the narrative\n",".agents/skills/react-router/SKILL.md":"---\nname: react-router\ndescription: Build applications with React Router in Framework, Data, Declarative, and unstable RSC modes. Use when configuring routes, route modules, loaders, actions, forms, fetchers, navigation, pending UI, SSR/SPA/pre-rendering, middleware, URL params/search params, or React Router upgrades.\nlicense: MIT\n---\n\n# React Router\n\nReact Router is mode-specific. Before changing an app, identify the mode, load the matching reference, then read the installed docs for the installed package version.\n\n## Identify the Mode\n\nDo not apply Framework/Data patterns to a Declarative app unless you are intentionally migrating modes.\n\n### Framework Mode\n\nUse Framework Mode guidance when you see:\n\n- `@react-router/dev` in dependencies\n- `react-router.config.ts`\n- `app/routes.ts`\n- `app/entry.server.tsx` and/or `app/entry.client.tsx` files\n- route modules under `app/routes/`\n- route exports like `loader`, `action`, `clientLoader`, `clientAction`, `ErrorBoundary`, `meta`, `links`, or `headers`\n- imports from `./+types/...`\n- the React Router Vite plugin from `@react-router/dev/vite`\n\nFramework examples usually use the default `app/` directory, but check `react-router.config.ts` for a custom `appDirectory` before assuming exact paths.\n\nThen read `references/framework-mode.md`.\n\n### Data Mode\n\nUse Data Mode guidance when you see:\n\n- `createBrowserRouter`, `createHashRouter`, `createMemoryRouter`, or `createStaticRouter`\n- `<RouterProvider router={router}>`\n- route objects with properties like `path`, `children`, `loader`, `action`, `Component`, `ErrorBoundary`, or `lazy`\n- data APIs without the Framework Vite plugin\n\nThen read `references/data-mode.md`.\n\n### Declarative Mode\n\nUse Declarative Mode guidance when you see:\n\n- `<BrowserRouter>`, `<HashRouter>`, or `<MemoryRouter>`\n- `<Routes>` and `<Route>` JSX route configuration\n- route components passed with `element={<Component />}`\n- no data router, no route module convention, and no loaders/actions\n\nThen read `references/declarative-mode.md`.\n\n### RSC Framework and RSC Data Modes\n\nReact Server Components support is unstable and exists in both Framework and Data variants. Use RSC guidance when you see:\n\n- `unstable_reactRouterRSC`\n- `@vitejs/plugin-rsc`\n- `unstable_RSCRouteConfig`\n- RSC entry files such as `entry.rsc`\n- `ServerComponent`, `ServerErrorBoundary`, `ServerLayout`, or `ServerHydrateFallback`\n- React directives or boundary packages such as `\"use client\"`, `\"server-only\"`, or `\"client-only\"`\n\nFor RSC Framework, read both `references/framework-mode.md` and `references/rsc.md`.\nFor RSC Data, read both `references/data-mode.md` and `references/rsc.md`.\n\n## Use Installed Docs as Source of Truth\n\nReact Router ships markdown docs in the package so guidance can match the installed version:\n\n```txt\nnode_modules/react-router/docs/\n```\n\nKey docs paths:\n\n```txt\nnode_modules/react-router/docs/index.md\nnode_modules/react-router/docs/start/\nnode_modules/react-router/docs/how-to/\nnode_modules/react-router/docs/explanation/\nnode_modules/react-router/docs/upgrading/\n```\n\nWhen this skill references `react-router/docs/...`, read the matching file under `node_modules/react-router/docs/`. If the installed version does not include local docs, use the repo `docs/` directory when working inside the React Router repository; in a consuming app, fall back to version-matched website docs.\n\nMost docs include a mode marker near the top:\n\n```txt\n[MODES: framework, data, declarative]\n```\n\nOnly apply a doc when its mode marker matches the app mode. If a task spans modes, prefer the section or file that matches the current app.\n\nRSC is documented primarily in:\n\n```txt\nnode_modules/react-router/docs/how-to/react-server-components.md\n```\n\n## Skill References\n\nLoad the relevant reference after identifying the mode:\n\n| Reference | Use When |\n| -------------------------------- | --------------------------------------------- |\n| `references/framework-mode.md` | Framework Mode or RSC Framework base behavior |\n| `references/data-mode.md` | Data Mode or RSC Data base behavior |\n| `references/declarative-mode.md` | Declarative Mode |\n| `references/rsc.md` | Any unstable RSC app |\n\n## Mode Migration Doc Index\n\nIf the user explicitly asks to switch modes, read the target mode reference plus the migration-relevant docs:\n\n| Migration | Docs to read |\n| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Declarative → Data | `react-router/docs/start/modes.md`, `react-router/docs/start/data/routing.md`, `react-router/docs/start/data/data-loading.md`, `react-router/docs/start/data/actions.md` |\n| Declarative/Data → Framework | `react-router/docs/start/modes.md`, `react-router/docs/start/framework/routing.md`, `react-router/docs/start/framework/route-module.md`, `react-router/docs/how-to/route-module-type-safety.md` |\n| Framework SPA/SSR/pre-render changes | `react-router/docs/start/framework/rendering.md`, `react-router/docs/how-to/spa.md`, `react-router/docs/how-to/pre-rendering.md`, `react-router/docs/start/framework/data-loading.md`, `react-router/docs/start/framework/actions.md` |\n| Future flags/upgrades | `react-router/docs/upgrading/future.md` and relevant files under `react-router/docs/upgrading/` |\n",".agents/skills/react-router/references/data-mode.md":"# Data Mode\n\nData Mode uses data routers such as `createBrowserRouter` and renders with `<RouterProvider>`. It gives an app route objects, loaders, actions, pending UI, fetchers, and SSR primitives without adopting the Framework Vite plugin or route-module file conventions.\n\nUse this reference after the main skill identifies a Data Mode app.\n\n## Read the Local Docs by Mode\n\nStart with:\n\n```txt\nreact-router/docs/start/modes.md\nreact-router/docs/start/data/index.md\n```\n\nThen use the Data docs under:\n\n```txt\nreact-router/docs/start/data/\n```\n\nThose files cover installation, route objects, routing, data loading, actions, navigation, pending UI, and testing. For task-specific details, read relevant files in:\n\n```txt\nreact-router/docs/how-to/\nreact-router/docs/explanation/\n```\n\nAlways check the `[MODES: data, ...]` marker in a doc before applying it.\n\n## Data Router Shape\n\nTypical setup:\n\n```tsx\nimport { createBrowserRouter, RouterProvider } from \"react-router\";\n\nconst router = createBrowserRouter([\n {\n path: \"/\",\n Component: Root,\n loader: rootLoader,\n children: [\n { index: true, Component: Home },\n {\n path: \"projects/:projectId\",\n Component: Project,\n loader: projectLoader,\n },\n ],\n },\n]);\n\nroot.render(<RouterProvider router={router} />);\n```\n\nLook for route object arrays and APIs such as:\n\n- `createBrowserRouter`\n- `createHashRouter`\n- `createMemoryRouter`\n- `RouterProvider`\n- `loader`\n- `action`\n- `Component`\n- `ErrorBoundary`\n- `lazy`\n- `children`\n\n## Route Objects and Routing\n\nBefore editing route configuration, read:\n\n```txt\nreact-router/docs/start/data/routing.md\nreact-router/docs/start/data/route-object.md\n```\n\nRules:\n\n- Keep route objects outside render when possible.\n- Use nested routes for shared layouts and data boundaries.\n- Use index routes for default child content.\n- Use dynamic segments and splats according to route-object docs.\n- Prefer `Component`/`ErrorBoundary` route object properties in Data Mode examples unless the existing app uses `element` consistently.\n\n## Data and Mutations\n\nBefore working on data loading or mutations, read:\n\n```txt\nreact-router/docs/start/data/data-loading.md\nreact-router/docs/start/data/actions.md\n```\n\nRules:\n\n- Load route data with route `loader` functions.\n- Mutate route data with route `action` functions.\n- Prefer loaders/actions over route-level `useEffect` fetching.\n- Use `request`, `params`, and returned/throwable Responses as described in the docs.\n- Let React Router revalidate after actions unless there is a documented reason to customize revalidation.\n\nCommon patterns:\n\n- Validation failure from an action: return `data({ errors, values }, { status: 400 })`, then render errors with `useActionData()` or `fetcher.data`.\n- Missing record in a loader: throw `data(\"Not Found\", { status: 404 })` and render the route `ErrorBoundary`.\n- Search/filter data: parse `new URL(request.url).searchParams` in the loader so the URL is shareable and bookmarkable.\n\n## Forms, Fetchers, and Pending UI\n\nFor forms and pending UI, read:\n\n```txt\nreact-router/docs/start/data/actions.md\nreact-router/docs/start/data/pending-ui.md\nreact-router/docs/how-to/fetchers.md\nreact-router/docs/explanation/form-vs-fetcher.md\n```\n\nRules of thumb:\n\n- Search/filter form that updates the URL: `<Form method=\"get\">`.\n- Mutation that should change URL/history or redirect after completion: `<Form method=\"post\">`.\n- Mutation that should keep the user on the same page: `useFetcher` / `<fetcher.Form>`.\n- Optimistic UI: derive from `fetcher.formData` or `navigation.formData`.\n\n## Navigation and URL State\n\nBefore changing navigation or search params, read:\n\n```txt\nreact-router/docs/start/data/navigating.md\nreact-router/docs/how-to/search-params.md\nreact-router/docs/explanation/location.md\n```\n\nRules:\n\n- Use `<Link>`/`<NavLink>` for user-initiated internal navigation.\n- Use `redirect` in loaders/actions when navigation follows data loading or mutations.\n- Use `useNavigate` for imperative client-side event navigation.\n- Treat URL params as strings and validate/parse them.\n- Preserve unrelated search params unless intentionally resetting them.\n\n## SSR in Data Mode\n\nData Mode SSR is manual and lower-level than Framework Mode. Before implementing or changing SSR, read the Data Mode custom/SSR docs and match existing server abstractions.\n\nStart with:\n\n```txt\nreact-router/docs/start/data/custom.md\n```\n\nLook for APIs like `createStaticHandler`, `createStaticRouter`, `StaticRouterProvider`, and hydration data handling in the current app before changing anything.\n\n## RSC Data\n\nIf this Data Mode app uses `unstable_RSCRouteConfig`, RSC route config, or low-level RSC server APIs, also read:\n\n```txt\nreferences/rsc.md\nreact-router/docs/how-to/react-server-components.md\n```\n",".agents/skills/react-router/references/declarative-mode.md":"# Declarative Mode\n\nDeclarative Mode is React Router's simplest mode. It uses router components like `<BrowserRouter>` and JSX routes with `<Routes>`/`<Route>`. It does not provide loaders, actions, fetchers, or data-router pending UI.\n\nUse this reference after the main skill identifies a Declarative Mode app.\n\n## Read the Local Docs by Mode\n\nStart with:\n\n```txt\nreact-router/docs/start/modes.md\nreact-router/docs/start/declarative/index.md\n```\n\nThen use the Declarative docs under:\n\n```txt\nreact-router/docs/start/declarative/\n```\n\nThose files cover installation, routing, navigation, and URL values. For conceptual details, read relevant files in:\n\n```txt\nreact-router/docs/explanation/\n```\n\nAlways check the `[MODES: declarative, ...]` marker in a doc before applying it.\n\n## Declarative Router Shape\n\nTypical setup:\n\n```tsx\nimport { BrowserRouter, Routes, Route } from \"react-router\";\n\nfunction App() {\n return (\n <BrowserRouter>\n <Routes>\n <Route path=\"/\" element={<Home />} />\n <Route path=\"about\" element={<About />} />\n <Route path=\"dashboard\" element={<DashboardLayout />}>\n <Route index element={<DashboardHome />} />\n <Route path=\"settings\" element={<Settings />} />\n </Route>\n </Routes>\n </BrowserRouter>\n );\n}\n```\n\nLook for APIs such as:\n\n- `<BrowserRouter>`\n- `<HashRouter>`\n- `<MemoryRouter>`\n- `<Routes>`\n- `<Route>`\n- `element={<Component />}`\n- `useRoutes`\n\n## Routing\n\nBefore editing routes, read:\n\n```txt\nreact-router/docs/start/declarative/routing.md\n```\n\nRules:\n\n- Use `<Routes>` and `<Route>` for route configuration.\n- Use nested routes with `<Outlet>` for shared layout.\n- Use index routes for default child UI.\n- Use route params and splats according to the declarative routing docs.\n- Do not add route object loaders/actions to a Declarative router.\n\n## Navigation\n\nBefore changing navigation, read:\n\n```txt\nreact-router/docs/start/declarative/navigating.md\n```\n\nRules:\n\n- Use `<Link>` or `<NavLink>` for user-initiated internal navigation.\n- Use `NavLink` when active styling matters.\n- Use `useNavigate` for imperative navigation from event handlers or effects.\n- Do not use plain `<a href>` for internal navigation unless intentionally forcing a full document navigation.\n\n## URL Values\n\nBefore changing params, search params, or location state, read:\n\n```txt\nreact-router/docs/start/declarative/url-values.md\nreact-router/docs/explanation/location.md\n```\n\nRules:\n\n- Use `useParams` for dynamic route params.\n- Use `useSearchParams` for query string state.\n- Use `useLocation` for the current location object and navigation state.\n- Validate and parse URL params; they are strings and can be absent.\n- Preserve unrelated search params unless intentionally resetting them.\n\n## Mode Boundary\n\nDeclarative Mode does not have Data/Framework APIs such as:\n\n- `loader`\n- `action`\n- `<Form>`\n- `useFetcher`\n- `useNavigation`\n- route module exports\n- generated `./+types` route types\n\nIf the user asks for route data loading, DB/API-backed data, CRUD, form mutations, validation returned from submissions, revalidation, pending UI, optimistic UI, or fetchers, recommend Data Mode or Framework Mode depending on how much structure they want. Ask before migrating unless they already requested it.\n",".agents/skills/react-router/references/framework-mode.md":"# Framework Mode\n\nFramework Mode is React Router's full-stack mode. It uses the React Router Vite plugin, route config in `app/routes.ts`, route modules, generated route types, and rendering strategies such as SSR, SPA mode, and pre-rendering.\n\nUse this reference after the main skill identifies a Framework Mode app.\n\n## Read the Local Docs by Mode\n\nStart with:\n\n```txt\nreact-router/docs/start/modes.md\nreact-router/docs/start/framework/index.md\n```\n\nThen use the Framework docs under:\n\n```txt\nreact-router/docs/start/framework/\n```\n\nThose files cover installation, routing, route modules, data loading, actions, navigation, pending UI, rendering, deploying, and testing. For task-specific details, read relevant files in:\n\n```txt\nreact-router/docs/how-to/\nreact-router/docs/explanation/\n```\n\nAlways check the `[MODES: framework, ...]` marker in a doc before applying it.\n\n## Framework Shape\n\nExamples usually assume the default `appDirectory` of `app`. Check `react-router.config.ts` before assuming exact paths.\n\nLook for these files and conventions:\n\n```txt\nreact-router.config.ts\napp/root.tsx\napp/routes.ts\napp/routes/**/*.tsx\nroute modules importing from ./+types/...\n```\n\nTypical route module:\n\n```tsx\nimport type { Route } from \"./+types/product\";\n\nexport async function loader({ params }: Route.LoaderArgs) {\n return { product: await getProduct(params.productId) };\n}\n\nexport default function Product({ loaderData }: Route.ComponentProps) {\n return <h1>{loaderData.product.name}</h1>;\n}\n```\n\n## Route Configuration\n\nFramework apps use `app/routes.ts`. Many apps use file-system routing via `flatRoutes()`, but manual route config is also supported.\n\nBefore editing routes, read:\n\n```txt\nreact-router/docs/start/framework/routing.md\n```\n\nIf the app uses file-route conventions, read:\n\n```txt\nreact-router/docs/how-to/file-route-conventions.md\n```\n\n## Route Modules\n\nRoute modules are the main unit of Framework Mode. Before adding or changing route exports, read:\n\n```txt\nreact-router/docs/start/framework/route-module.md\n```\n\nCommon exports include:\n\n| Export | Use |\n| --------------------------------- | ------------------------------------------------------------------- |\n| `default` | Route component rendered for the match |\n| `loader` | Server data loading for SSR/pre-rendering/server data requests |\n| `clientLoader` | Browser-only data loading or supplementing server loader data |\n| `action` | Server mutation called by `<Form>`, `useSubmit`, or fetchers |\n| `clientAction` | Browser-only mutation or client-side wrapper around a server action |\n| `ErrorBoundary` | UI for errors thrown by this route's loaders/actions/component |\n| `HydrateFallback` | Initial fallback while client loader hydration runs |\n| `links` / `meta` | Route document links and metadata |\n| `handle` | Arbitrary route metadata consumed via `useMatches` |\n| `shouldRevalidate` | Overrides default loader revalidation behavior |\n| `middleware` / `clientMiddleware` | Server/client request pipeline hooks when enabled |\n\nUse generated `Route.*` types from `./+types/<route>` for route module args and props.\n\n## Layout and Root Route Rules\n\n- `app/root.tsx` is the root route and should contain global document/app shell concerns.\n- Put global providers, app-wide nav, app-wide footer, scripts/meta/links, and document structure in `root.tsx` when appropriate.\n- Use nested routes/layout routes for section-specific layouts.\n- Do not flatten routes that should share UI or data boundaries.\n\nUseful docs:\n\n```txt\nreact-router/docs/explanation/special-files.md\nreact-router/docs/start/framework/routing.md\n```\n\n## Data and Mutations\n\nBefore working on route data:\n\n```txt\nreact-router/docs/start/framework/data-loading.md\nreact-router/docs/start/framework/actions.md\n```\n\nFramework rules:\n\n- Load route data with `loader` or `clientLoader`.\n- Mutate route data with `action` or `clientAction`.\n- Prefer route loaders/actions over ad hoc `useEffect` fetching for route data.\n- Use `data()`/Responses and redirects according to the docs.\n- Let React Router revalidate after actions unless the docs point you to `shouldRevalidate`.\n- In SSR/server data routes, keep Node-only/database code in server-only modules and call it from `loader`/`action`, not from browser-rendered component code.\n\nCommon patterns:\n\n- Validation failure from an action: return `data({ errors, values }, { status: 400 })`, then render errors from `Route.ComponentProps[\"actionData\"]` or `fetcher.data`.\n- Missing record in a loader: throw `data(\"Not Found\", { status: 404 })` and render the route `ErrorBoundary`.\n- Search/filter data: parse the route request URL/search params in the loader so the URL is shareable and bookmarkable.\n\n## Forms, Fetchers, and Pending UI\n\nFor forms and pending UI, read:\n\n```txt\nreact-router/docs/start/framework/actions.md\nreact-router/docs/start/framework/pending-ui.md\nreact-router/docs/how-to/fetchers.md\nreact-router/docs/explanation/form-vs-fetcher.md\n```\n\nRules of thumb:\n\n- Search/filter form that updates the URL: `<Form method=\"get\">`.\n- Mutation that should change URL/history or redirect after completion: `<Form method=\"post\">`.\n- Mutation that should keep the user on the same page: `useFetcher` / `<fetcher.Form>`.\n- Optimistic UI: derive from `fetcher.formData` or `navigation.formData`.\n\n## Type Safety\n\nBefore changing generated route types or typed URL behavior, read:\n\n```txt\nreact-router/docs/how-to/route-module-type-safety.md\nreact-router/docs/explanation/type-safety.md\n```\n\nRules:\n\n- Import types from `./+types/<route>`.\n- Use `Route.LoaderArgs`, `Route.ActionArgs`, `Route.ComponentProps`, etc.\n- Use type-only imports where appropriate.\n- Do not edit generated `.react-router/types` files.\n\n## Metadata\n\nBefore changing `meta`, read:\n\n```txt\nreact-router/docs/how-to/meta.md\nreact-router/docs/start/framework/route-module.md\n```\n\nImportant: `meta` receives `loaderData`; do not use deprecated `data` args.\n\n## Rendering Strategy\n\nFramework Mode can be SSR, SPA, pre-rendered, or mixed depending on config and route behavior. Before changing rendering behavior, read:\n\n```txt\nreact-router/docs/start/framework/rendering.md\nreact-router/docs/how-to/spa.md\nreact-router/docs/how-to/pre-rendering.md\nreact-router/docs/explanation/hydration.md\n```\n\n## Middleware, Sessions, and Auth\n\nBefore implementing middleware or auth/session flows, read:\n\n```txt\nreact-router/docs/how-to/middleware.md\nreact-router/docs/explanation/sessions-and-cookies.md\n```\n\nMiddleware and context APIs are version/config sensitive. Check the installed React Router version and the app's `react-router.config.ts` before implementing.\n\n## RSC Framework\n\nIf this Framework app uses `unstable_reactRouterRSC` or `@vitejs/plugin-rsc`, also read:\n\n```txt\nreferences/rsc.md\nreact-router/docs/how-to/react-server-components.md\n```\n",".agents/skills/react-router/references/rsc.md":"# React Server Components (RSC)\n\nReact Router's RSC support is unstable and exists in two variants:\n\n- **RSC Framework Mode**: Framework Mode with the unstable RSC Vite plugin.\n- **RSC Data Mode**: lower-level RSC runtime APIs and manual bundler/server integration.\n\nUse this reference in addition to `framework-mode.md` or `data-mode.md` after the main skill identifies an RSC app.\n\n## Read the Local RSC Docs\n\nStart with:\n\n```txt\nreact-router/docs/how-to/react-server-components.md\n```\n\nThen read the relevant base mode docs:\n\n```txt\nreact-router/docs/start/framework/\nreact-router/docs/start/data/\n```\n\nRSC docs may describe differences from non-RSC mode rather than repeating every Framework/Data concept, so keep both layers in mind.\n\n## Detect RSC Framework Mode\n\nLook for:\n\n- `unstable_reactRouterRSC` imported from `@react-router/dev/vite`\n- `@vitejs/plugin-rsc`\n- `vite.config.ts` with `plugins: [reactRouterRSC(), rsc()]`\n- Framework route modules plus RSC route exports\n- RSC entry files such as `entry.rsc`\n\nRSC Framework Mode uses a different Vite plugin from non-RSC Framework Mode. Do not swap it for the regular `reactRouter()` plugin.\n\n## Detect RSC Data Mode\n\nLook for:\n\n- `unstable_RSCRouteConfig`\n- route config passed to lower-level RSC APIs\n- APIs such as `unstable_matchRSCServerRequest`, `unstable_routeRSCServerRequest`, `unstable_RSCHydratedRouter`, or `unstable_RSCStaticRouter`\n- custom bundler/server setup around RSC\n\nRSC Data Mode is more manual than RSC Framework Mode. Match the app's bundler and server abstractions before changing routes or entries.\n\n## RSC Route Module Differences\n\nIn RSC Framework Mode, many normal Framework Mode concepts still apply, but routes can use server component exports.\n\nImportant route-module concepts from the RSC docs include:\n\n- `ServerComponent` instead of the usual client `default` component\n- `ServerErrorBoundary` paired with `ErrorBoundary`\n- `ServerLayout` paired with `Layout`\n- `ServerHydrateFallback` paired with `HydrateFallback`\n- server-rendered React elements returned from loaders/actions\n\nA route module cannot export both the normal client component and its server component counterpart for the same role. Read the RSC docs before adding these exports.\n\n## Client/Server Boundaries\n\nRSC code must respect React's client/server split:\n\n- Use `\"use client\"` for components that need hooks, browser APIs, or event handlers.\n- Use server-only modules for server data access and secrets.\n- In RSC Framework Mode, prefer the `server-only` and `client-only` boundary imports described in the docs.\n- Do not assume `.server`/`.client` file naming works the same way in RSC Framework Mode; read the RSC docs before relying on those conventions.\n\n## Data Loading in RSC\n\nRSC changes where data can be loaded:\n\n- Server Components can fetch data directly on the server.\n- Loaders/actions may still exist and can have RSC-specific behavior.\n- Client components still need client-safe data and cannot directly access server-only modules.\n\nWhen choosing between a server component fetch, a loader, and a client loader/action, follow the RSC docs and match existing app patterns.\n\n## Stability\n\nRSC APIs are explicitly unstable. Before implementing or refactoring RSC code:\n\n- Check the installed React Router version.\n- Check the installed `@vitejs/plugin-rsc` version.\n- Read the app's existing RSC entry/config files.\n- Prefer minimal changes that match current patterns.\n",".agents/skills/sc-summary/SKILL.md":"---\nname: sc-summary\ndescription: Summarize React Router Steering Committee meeting notes from a user-provided location in GOVERNANCE.md. Use when asked to add or revise Steering Committee meeting summaries.\n---\n\n# Steering Committee Meeting Summaries\n\nUse the notes folder or files the user supplies in the request or current conversation. If no source location is available, ask for it. Write to the repository's `GOVERNANCE.md`, under **Meeting Notes**.\n\n1. Read the existing Meeting Notes entries and list the files at the supplied location. Summarize the requested dates or files. If the user gives no date or quantity, choose the earliest meeting without an entry and do one meeting for review. Do not duplicate an existing entry unless asked to revise it.\n2. Read each entire source note, especially the details. Resolve repeated or inconsistent points before writing. Treat proposed ideas, decisions, and suggested next steps distinctly; do not present an unconfirmed proposal as an agreed decision.\n3. Write a public-facing, high-level summary of React Router discussion only. Omit unrelated conversation and banter. Refer to participants by first name. Follow the existing `<details>` format and prose in `GOVERNANCE.md`; use short topical headings when useful. Match the depth of existing entries, adjusted to how much substantive discussion occurred.\n4. Insert each entry near the other meeting dates, preserve unrelated content, then review the diff against the source and run `git diff --check`. Show the new or revised entries to the user. Do not post them to GitHub, commit, or publish unless requested.\n",".agents/skills/sc-summary/agents/openai.yaml":"interface:\n display_name: \"SC Summary\"\n short_description: \"Summarize React Router Steering Committee meetings\"\n default_prompt: \"Use $sc-summary with the meeting notes location I provide to update GOVERNANCE.md.\"\n",".github/skills/agentic-workflows/SKILL.md":"---\nname: agentic-workflows\ndescription: Route gh-aw workflow design/create/debug/upgrade requests to the right prompts.\n---\n\n# Agentic Workflows Router\n\nUse this skill when a user asks to design, create, update, debug, or upgrade GitHub Agentic Workflows in this repository.\n\nThis skill is a dispatcher: identify the task type, load the matching workflow prompt/skill file, and follow it directly. Keep responses concise and ask a clarifying question if the correct prompt is unclear.\n\nRepository overlay (optional):\n\n- If `.github/aw/instructions.md` exists, load it with `@.github/aw/instructions.md` after loading the matched prompt/skill.\n- Precedence: repository overlay instructions override upstream defaults when they conflict.\n\nRead only the files you need:\nLoad these files from `github/gh-aw` (they are not available locally).\n\n- `.github/aw/action-container-substitutions.md`\n- `.github/aw/agent-runtime-instructions.md`\n- `.github/aw/agentic-chat.md`\n- `.github/aw/agentic-workflows-mcp.md`\n- `.github/aw/asciicharts.md`\n- `.github/aw/campaign.md`\n- `.github/aw/charts-trending.md`\n- `.github/aw/charts.md`\n- `.github/aw/cli-commands.md`\n- `.github/aw/configure-agentic-engine.md`\n- `.github/aw/context.md`\n- `.github/aw/create-agentic-workflow-trigger-details.md`\n- `.github/aw/create-agentic-workflow.md`\n- `.github/aw/create-shared-agentic-workflow.md`\n- `.github/aw/debug-agentic-workflow.md`\n- `.github/aw/dependabot.md`\n- `.github/aw/deployment-status.md`\n- `.github/aw/designer-mappings.md`\n- `.github/aw/designer.md`\n- `.github/aw/evals.md`\n- `.github/aw/experiments.md`\n- `.github/aw/github-agentic-workflows.md`\n- `.github/aw/github-mcp-server-pagination.md`\n- `.github/aw/github-mcp-server.md`\n- `.github/aw/instructions.md`\n- `.github/aw/linter-workflows.md`\n- `.github/aw/llms.md`\n- `.github/aw/loop.md`\n- `.github/aw/lsp.md`\n- `.github/aw/maintainer.md`\n- `.github/aw/mcp-clis.md`\n- `.github/aw/memory-stateful-patterns.md`\n- `.github/aw/memory.md`\n- `.github/aw/messages.md`\n- `.github/aw/multi-agent-research.md`\n- `.github/aw/network.md`\n- `.github/aw/optimize-agentic-workflow.md`\n- `.github/aw/patterns.md`\n- `.github/aw/pr-reviewer.md`\n- `.github/aw/release-workflow.md`\n- `.github/aw/report.md`\n- `.github/aw/reuse.md`\n- `.github/aw/safe-outputs-automation.md`\n- `.github/aw/safe-outputs-content.md`\n- `.github/aw/safe-outputs-management.md`\n- `.github/aw/safe-outputs-runtime.md`\n- `.github/aw/safe-outputs.md`\n- `.github/aw/serena-tool.md`\n- `.github/aw/shared-safe-jobs.md`\n- `.github/aw/skills.md`\n- `.github/aw/subagents.md`\n- `.github/aw/syntax-agentic.md`\n- `.github/aw/syntax-core.md`\n- `.github/aw/syntax-engine.md`\n- `.github/aw/syntax-tools-imports.md`\n- `.github/aw/syntax.md`\n- `.github/aw/test-coverage.md`\n- `.github/aw/test-expression.md`\n- `.github/aw/token-optimization-caching-budgets.md`\n- `.github/aw/token-optimization-observability.md`\n- `.github/aw/token-optimization.md`\n- `.github/aw/triggers.md`\n- `.github/aw/update-agentic-workflow.md`\n- `.github/aw/upgrade-agentic-workflows.md`\n- `.github/aw/visual-regression.md`\n- `.github/aw/workflow-constraints.md`\n- `.github/aw/workflow-editing.md`\n- `.github/aw/workflow-patterns.md`\n\nAfter loading the matching workflow prompt or skill, follow it directly:\n\n- Design workflows from scratch via interview: `.github/aw/designer.md`\n- Create new workflows: `.github/aw/create-agentic-workflow.md`\n- Configure or add declarative engines: `.github/aw/configure-agentic-engine.md`\n- Update existing workflows: `.github/aw/update-agentic-workflow.md`\n- Debug, audit, or investigate workflows: `.github/aw/debug-agentic-workflow.md`\n- Upgrade workflows and fix deprecations: `.github/aw/upgrade-agentic-workflows.md`\n- Create shared components or MCP wrappers: `.github/aw/create-shared-agentic-workflow.md`\n- Create report-generating workflows: `.github/aw/report.md`\n- Fix Dependabot manifest PRs: `.github/aw/dependabot.md`\n- Analyze coverage workflows: `.github/aw/test-coverage.md`\n- Render compact markdown charts: `.github/aw/asciicharts.md`\n- Map CLI commands to MCP usage: `.github/aw/cli-commands.md`\n- Choose workflow architecture and patterns: `.github/aw/patterns.md`\n- Optimize token usage and cost: `.github/aw/token-optimization.md`\n- Design long-running multi-agent research workflows: `.github/aw/multi-agent-research.md`\n\nWhen the task involves OTEL, OTLP, traces, observability backends, or telemetry-driven analysis, also read and follow `skills/otel-queries/SKILL.md` after loading the matching workflow prompt or skill.\n","AGENTS.md":"# React Router Development Guide\n\n## Commands\n\n- **Build**: `pnpm build` (all packages) or `pnpm run --filter <package> build` (single package)\n- **Test (Jest)**: `pnpm test` (all packages), `pnpm test packages/<package>/` (single package), `pnpm test packages/react-router/__tests__/router/fetchers-test.ts` (single file), or `pnpm test -- -t \"action fetch\"` (tests matching name)\n- **Integration tests (Playwright)**: `pnpm test:integration --project chromium` (build + test all), `pnpm test:integration:run --project chromium` (test only, all), `pnpm test:integration:run integration/middleware-test.ts --project chromium` (single file), or `pnpm test:integration:run --project chromium -g \"middleware\"` (tests matching name)\n- **Typecheck**: `pnpm run typecheck`\n- **Lint**: `pnpm run lint`\n- **Docs generation**: `pnpm run docs` (regenerates API docs from JSDoc)\n- **Type generation**: `pnpm run typegen` (Framework Mode only)\n- **Clean**: `pnpm run clean` (git clean -fdX)\n\n## Modes\n\n**Five distinct modes**: Declarative, Data, Framework, RSC Data (unstable), RSC Framework (unstable). **Always identify which mode(s) a feature applies to.**\n\n1. **Declarative**: `<BrowserRouter>`, `<Routes>`, `<Route>`\n2. **Data**: `createBrowserRouter()` with `loader`/`action`, `<RouterProvider>`\n3. **Framework**: Vite plugin + `routes.ts` + Route Module API (route exports like `loader`, `action`, `default`) + type generation + SSR/SPA\n4. **RSC Data** (unstable): RSC runtime APIs, manual bundler setup, runtime route config\n5. **RSC Framework** (unstable): Framework Mode with `unstable_reactRouterRSC` Vite plugin\n\n**RSC mode differences:**\n\n- **RSC Framework**: `unstable_reactRouterRSC` plugin, `@vitejs/plugin-rsc`, different entry points/format\n- **RSC Data**: Manual bundler, runtime route config typically in `src/routes.ts`, `unstable_RSCRouteConfig`, different runtime APIs, `setupRscTest` in `integration/rsc/`\n\n## Architecture\n\n- **Monorepo**: pnpm workspace, packages in `packages/`\n- **Key packages**:\n - `react-router`: Core (all modes) - `lib/components.tsx`, `lib/hooks.tsx`, `lib/router/`, `lib/dom/`, `lib/rsc/`\n - `@react-router/dev`: Framework tooling - `vite/plugin.ts` (Framework), `vite/rsc/plugin.ts` (RSC Framework), `typegen/`\n - `@react-router/node`, `@react-router/cloudflare`, `@react-router/express`: Server adapters\n - `@react-router/serve`: Minimal server for Framework Mode\n - `@react-router/fs-routes`: File-system routing (`flatRoutes()`)\n\n## Testing\n\n### Unit Tests (`packages/react-router/__tests__/`)\n\nUse Jest for pure routing logic, pure server runtime behavior, router state, React component behavior. No build required.\n\n```bash\npnpm test # All packages\npnpm test packages/react-router/ # Single package\npnpm test packages/react-router/__tests__/router/fetchers-test.ts # Single file\npnpm test -- -t \"action fetch\" # Tests matching name\n```\n\n### Integration Tests (`integration/`)\n\nUse Playwright for Vite plugin, build pipeline, SSR/hydration, RSC, type generation.\n\n```bash\npnpm test:integration --project chromium # Build + test all\npnpm test:integration:run --project chromium # Test only, all\npnpm test:integration:run integration/middleware-test.ts --project chromium # Single file\npnpm test:integration:run --project chromium -g \"middleware\" # Tests matching name\n```\n\n**Project**: Always use `chromium` for integration tests, unless explicitly stated otherwise.\n\n**Rebuild when**: First run, after changing `packages/` (not needed for test-only changes)\n\n**Organization**: Use `createFixture()` → `createAppFixture()` → `PlaywrightFixture`. Templates available: `vite-6-template/`, `rsc-vite-framework/`, etc. Test all applicable modes (iterate over template array when behavior should work across modes). Test both states when introducing future flags (one test with flag on, one with flag off).\n\n**RSC testing**:\n\n- **RSC Framework**: Use `createFixture` with `rsc-vite-framework/` template\n- **RSC Data**: Use `setupRscTest` in `integration/rsc/`\n\nTest shared behavior across multiple templates (e.g., `[\"vite-5-template\", \"rsc-vite-framework\"]`). Test RSC-specific features against RSC template.\n\n## routes.ts\n\nFramework Mode uses `routes.ts` in `app/`. Most tests use `flatRoutes()` for file-system routing:\n\n```ts\n// app/routes.ts\nimport { type RouteConfig } from \"@react-router/dev/routes\";\nimport { flatRoutes } from \"@react-router/fs-routes\";\n\nexport default flatRoutes() satisfies RouteConfig;\n```\n\n**File-system conventions** (`app/routes/`):\n\n- `_index.tsx` → `/` (index route)\n- `about.tsx` → `/about`\n- `blog.$slug.tsx` → `/blog/:slug` (URL param)\n- `settings.profile.tsx` → `/settings/profile` (`.` creates nesting)\n- `_layout.tsx` → pathless layout route\n\n**Manual config alternative**:\n\n```ts\nimport { index, route, layout } from \"@react-router/dev/routes\";\nexport default [\n index(\"./home.tsx\"),\n route(\"about\", \"./about.tsx\"),\n layout(\"./auth-layout.tsx\", [route(\"login\", \"./login.tsx\")]),\n];\n```\n\n## Documentation\n\n**Don't edit generated files**: `docs/api/` (from JSDoc), `.react-router/types/` (from typegen)\n\n**Mode indicators**: Every doc needs `[MODES: framework, data, declarative]`\n\n**API docs**: Edit JSDoc in `packages/react-router/lib/`, run `pnpm docs`\n\n**Unstable features**: Prefix `unstable_`, add `unstable: true` to frontmatter, include warning block\n\n## Future Flags\n\n- **Future flags** (`vX_*`): Stable breaking changes for next major\n- **Unstable flags** (`unstable_*`): Experimental, may change\n\nTest both states (on/off) for future flags. Don't break existing behavior without a flag.\n\n## License\n\nBy contributing to React Router, you agree that your contributions will be licensed under the [MIT License](./LICENSE.md).\n\n## Change Files\n\nWhen making changes that affect users, create a change file at `packages/<package>/.changes/<type>.<unique-meaningful-name>.md`. `<type>` should be either `patch`, `minor`, `major` or `unstable` to indicate the type of API change being made. If iterating on a change that hasn't shipped yet, update the existing change file instead of creating a new one.\n\nFormat:\n\n```markdown\nBrief description of the change\n\n- Additional details if needed\n```\n\n## Branching\n\n- **`main`**: Active Development\n- **`v7`**: v7.x maintenance\n- **`v6`**: v6.x maintenance\n- Branch from `main` for code and docs changes\n\n## Key Files\n\n| Purpose | Location |\n| ----------------- | ----------------------------------------------------------- |\n| Router | `packages/react-router/lib/router/router.ts` |\n| React API | `packages/react-router/lib/components.tsx`, `lib/hooks.tsx` |\n| Vite plugin | `packages/react-router-dev/vite/plugin.ts` |\n| RSC Vite plugin | `packages/react-router-dev/vite/rsc/plugin.ts` |\n| Type generation | `packages/react-router-dev/typegen/` |\n| Unit tests | `packages/react-router/__tests__/` |\n| Integration tests | `integration/` |\n| Decision docs | `decisions/` |\n","CLAUDE.md":"# React Router Project Instructions\n\n## Session Start\n\n**REQUIRED**: Read [./AGENTS.md](./AGENTS.md) at the start of every session. It contains:\n\n- Project architecture and key files\n- React Router modes (Declarative, Data, Framework, RSC)\n- Build/test commands (Jest unit tests, Playwright integration tests with `--project chromium`)\n- Testing patterns and conventions\n- Documentation guidelines\n\n### Skills\n\nIf there is an [`.agents/skills`](.agents/skills) directory in the repository, symlink those skills to `.claude/skills` to make sure they are made available to Claude. Refresh you list of available skills if needed. This is a git ignored directory because we want to keep the canonical skills in `.agents/skills`.\n\n## During Work\n\n**Always consult AGENTS.md** when you need to:\n\n- Run tests or builds\n- Understand which mode(s) a feature applies to\n- Find key file locations\n- Understand testing patterns\n\nDo not guess at commands - reference AGENTS.md for the correct syntax.\n","packages/create-react-router/README.md":"Create a new React Router app.\n\n```sh\nnpm create react-router\n```\n","packages/react-router-architect/README.md":"[Architect](https://arc.codes) server request handler for React Router.\n\n```bash\nnpm install @react-router/architect\n```\n","packages/react-router-cloudflare/README.md":"Cloudflare platform abstractions for React Router\n\n```bash\nnpm install @react-router/cloudflare @cloudflare/workers-types\n```\n","packages/react-router-dev/README.md":"Dev tools and CLI for React Router that enables framework features through bundler integration like server rendering, code splitting, HMR, etc.\n\n```sh\nnpm install @react-router/dev --save-dev\n```\n","packages/react-router-express/README.md":"[Express](https://expressjs.com) server request handler for React Router.\n\n```sh\nnpm install @react-router/express\n```\n","packages/react-router-fs-routes/README.md":"File system routing conventions for React Router\n\n```sh\nnpm install @react-router/fs-routes\n```\n","packages/react-router-node/README.md":"Node.js platform abstractions for React Router\n\n```sh\nnpm install @react-router/node\n```\n","packages/react-router-remix-routes-option-adapter/README.md":"# @react-router/remix-routes-option-adapter\n\nAdapter for [Remix's](https://remix.run) `routes` config option, for use within `routes.ts`.\n\n```sh\nnpm install @react-router/remix-routes-option-adapter\n```\n","packages/react-router-serve/README.md":"Node.js application server for React Router\n\n```sh\nnpm install @react-router/serve\n```\n","packages/react-router/README.md":"`react-router` is the primary package in the React Router project.\n\n## Installation\n\n```sh\nnpm i react-router\n```\n",".cursorrules (react-router-v7.mdc)":"# React Router v7 Rules\n\n## Route Modules\n\n- Use route modules as the boundary for route UI, loader data, actions, metadata, and error boundaries.\n- Keep route modules small; move shared UI to components and reusable data access to services.\n- Prefer file-based routing in framework mode when the project is configured for it.\n- Use nested routes for shared layouts and progressive disclosure.\n- Export route-specific `ErrorBoundary` components for recoverable route failures.\n\n## Data Loading\n\n- Use loaders for route data that should be available before render.\n- Keep loaders deterministic and side-effect free.\n- Validate params and search params at the loader boundary.\n- Return typed data and consume it through route hooks rather than duplicating fetch logic in components.\n- Use deferred or streaming patterns only when they improve perceived performance.\n\n## Mutations\n\n- Use actions for route mutations and form submissions.\n- Prefer `Form`, `useFetcher`, and `useSubmit` for progressive enhancement.\n- Revalidate affected loader data after mutations.\n- Handle validation errors as typed action data instead of generic exceptions.\n- Keep server-only secrets and privileged operations out of client actions.\n\n## Navigation and State\n\n- Store shareable state in URL params or search params.\n- Keep ephemeral UI state local to components.\n- Use pending navigation state to show optimistic or loading UI.\n- Avoid global state for data that belongs to route loaders.\n\n## TypeScript and Testing\n\n- Type loader and action return values.\n- Add tests for route loaders, actions, validation failures, and error boundaries.\n- Use integration tests for critical form and navigation flows.\n- Mock network and persistence at the route-service boundary.\n\n## Common Mistakes\n\n- Do not duplicate loader fetches in `useEffect`.\n- Do not mutate data in loaders.\n- Do not hide route errors behind a single generic app-level catch-all.\n- Do not put auth checks only in components when loader data is protected."},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# React Router Development Guide\n\n## Commands\n\n- **Build**: `pnpm build` (all packages) or `pnpm run --filter <package> build` (single package)\n- **Test (Jest)**: `pnpm test` (all packages), `pnpm test packages/<package>/` (single package), `pnpm test packages/react-router/__tests__/router/fetchers-test.ts` (single file), or `pnpm test -- -t \"action fetch\"` (tests matching name)\n- **Integration tests (Playwright)**: `pnpm test:integration --project chromium` (build + test all), `pnpm test:integration:run --project chromium` (test only, all), `pnpm test:integration:run integration/middleware-test.ts --project chromium` (single file), or `pnpm test:integration:run --project chromium -g \"middleware\"` (tests matching name)\n- **Typecheck**: `pnpm run typecheck`\n- **Lint**: `pnpm run lint`\n- **Docs generation**: `pnpm run docs` (regenerates API docs from JSDoc)\n- **Type generation**: `pnpm run typegen` (Framework Mode only)\n- **Clean**: `pnpm run clean` (git clean -fdX)\n\n## Modes\n\n**Five distinct modes**: Declarative, Data, Framework, RSC Data (unstable), RSC Framework (unstable). **Always identify which mode(s) a feature applies to.**\n\n1. **Declarative**: `<BrowserRouter>`, `<Routes>`, `<Route>`\n2. **Data**: `createBrowserRouter()` with `loader`/`action`, `<RouterProvider>`\n3. **Framework**: Vite plugin + `routes.ts` + Route Module API (route exports like `loader`, `action`, `default`) + type generation + SSR/SPA\n4. **RSC Data** (unstable): RSC runtime APIs, manual bundler setup, runtime route config\n5. **RSC Framework** (unstable): Framework Mode with `unstable_reactRouterRSC` Vite plugin\n\n**RSC mode differences:**\n\n- **RSC Framework**: `unstable_reactRouterRSC` plugin, `@vitejs/plugin-rsc`, different entry points/format\n- **RSC Data**: Manual bundler, runtime route config typically in `src/routes.ts`, `unstable_RSCRouteConfig`, different runtime APIs, `setupRscTest` in `integration/rsc/`\n\n## Architecture\n\n- **Monorepo**: pnpm workspace, packages in `packages/`\n- **Key packages**:\n - `react-router`: Core (all modes) - `lib/components.tsx`, `lib/hooks.tsx`, `lib/router/`, `lib/dom/`, `lib/rsc/`\n - `@react-router/dev`: Framework tooling - `vite/plugin.ts` (Framework), `vite/rsc/plugin.ts` (RSC Framework), `typegen/`\n - `@react-router/node`, `@react-router/cloudflare`, `@react-router/express`: Server adapters\n - `@react-router/serve`: Minimal server for Framework Mode\n - `@react-router/fs-routes`: File-system routing (`flatRoutes()`)\n\n## Testing\n\n### Unit Tests (`packages/react-router/__tests__/`)\n\nUse Jest for pure routing logic, pure server runtime behavior, router state, React component behavior. No build required.\n\n```bash\npnpm test # All packages\npnpm test packages/react-router/ # Single package\npnpm test packages/react-router/__tests__/router/fetchers-test.ts # Single file\npnpm test -- -t \"action fetch\" # Tests matching name\n```\n\n### Integration Tests (`integration/`)\n\nUse Playwright for Vite plugin, build pipeline, SSR/hydration, RSC, type generation.\n\n```bash\npnpm test:integration --project chromium # Build + test all\npnpm test:integration:run --project chromium # Test only, all\npnpm test:integration:run integration/middleware-test.ts --project chromium # Single file\npnpm test:integration:run --project chromium -g \"middleware\" # Tests matching name\n```\n\n**Project**: Always use `chromium` for integration tests, unless explicitly stated otherwise.\n\n**Rebuild when**: First run, after changing `packages/` (not needed for test-only changes)\n\n**Organization**: Use `createFixture()` → `createAppFixture()` → `PlaywrightFixture`. Templates available: `vite-6-template/`, `rsc-vite-framework/`, etc. Test all applicable modes (iterate over template array when behavior should work across modes). Test both states when introducing future flags (one test with flag on, one with flag off).\n\n**RSC testing**:\n\n- **RSC Framework**: Use `createFixture` with `rsc-vite-framework/` template\n- **RSC Data**: Use `setupRscTest` in `integration/rsc/`\n\nTest shared behavior across multiple templates (e.g., `[\"vite-5-template\", \"rsc-vite-framework\"]`). Test RSC-specific features against RSC template.\n\n## routes.ts\n\nFramework Mode uses `routes.ts` in `app/`. Most tests use `flatRoutes()` for file-system routing:\n\n```ts\n// app/routes.ts\nimport { type RouteConfig } from \"@react-router/dev/routes\";\nimport { flatRoutes } from \"@react-router/fs-routes\";\n\nexport default flatRoutes() satisfies RouteConfig;\n```\n\n**File-system conventions** (`app/routes/`):\n\n- `_index.tsx` → `/` (index route)\n- `about.tsx` → `/about`\n- `blog.$slug.tsx` → `/blog/:slug` (URL param)\n- `settings.profile.tsx` → `/settings/profile` (`.` creates nesting)\n- `_layout.tsx` → pathless layout route\n\n**Manual config alternative**:\n\n```ts\nimport { index, route, layout } from \"@react-router/dev/routes\";\nexport default [\n index(\"./home.tsx\"),\n route(\"about\", \"./about.tsx\"),\n layout(\"./auth-layout.tsx\", [route(\"login\", \"./login.tsx\")]),\n];\n```\n\n## Documentation\n\n**Don't edit generated files**: `docs/api/` (from JSDoc), `.react-router/types/` (from typegen)\n\n**Mode indicators**: Every doc needs `[MODES: framework, data, declarative]`\n\n**API docs**: Edit JSDoc in `packages/react-router/lib/`, run `pnpm docs`\n\n**Unstable features**: Prefix `unstable_`, add `unstable: true` to frontmatter, include warning block\n\n## Future Flags\n\n- **Future flags** (`vX_*`): Stable breaking changes for next major\n- **Unstable flags** (`unstable_*`): Experimental, may change\n\nTest both states (on/off) for future flags. Don't break existing behavior without a flag.\n\n## License\n\nBy contributing to React Router, you agree that your contributions will be licensed under the [MIT License](./LICENSE.md).\n\n## Change Files\n\nWhen making changes that affect users, create a change file at `packages/<package>/.changes/<type>.<unique-meaningful-name>.md`. `<type>` should be either `patch`, `minor`, `major` or `unstable` to indicate the type of API change being made. If iterating on a change that hasn't shipped yet, update the existing change file instead of creating a new one.\n\nFormat:\n\n```markdown\nBrief description of the change\n\n- Additional details if needed\n```\n\n## Branching\n\n- **`main`**: Active Development\n- **`v7`**: v7.x maintenance\n- **`v6`**: v6.x maintenance\n- Branch from `main` for code and docs changes\n\n## Key Files\n\n| Purpose | Location |\n| ----------------- | ----------------------------------------------------------- |\n| Router | `packages/react-router/lib/router/router.ts` |\n| React API | `packages/react-router/lib/components.tsx`, `lib/hooks.tsx` |\n| Vite plugin | `packages/react-router-dev/vite/plugin.ts` |\n| RSC Vite plugin | `packages/react-router-dev/vite/rsc/plugin.ts` |\n| Type generation | `packages/react-router-dev/typegen/` |\n| Unit tests | `packages/react-router/__tests__/` |\n| Integration tests | `integration/` |\n| Decision docs | `decisions/` |\n","isInternal":false,"tokens":1802,"sizeBytes":7415},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# React Router Project Instructions\n\n## Session Start\n\n**REQUIRED**: Read [./AGENTS.md](./AGENTS.md) at the start of every session. It contains:\n\n- Project architecture and key files\n- React Router modes (Declarative, Data, Framework, RSC)\n- Build/test commands (Jest unit tests, Playwright integration tests with `--project chromium`)\n- Testing patterns and conventions\n- Documentation guidelines\n\n### Skills\n\nIf there is an [`.agents/skills`](.agents/skills) directory in the repository, symlink those skills to `.claude/skills` to make sure they are made available to Claude. Refresh you list of available skills if needed. This is a git ignored directory because we want to keep the canonical skills in `.agents/skills`.\n\n## During Work\n\n**Always consult AGENTS.md** when you need to:\n\n- Run tests or builds\n- Understand which mode(s) a feature applies to\n- Find key file locations\n- Understand testing patterns\n\nDo not guess at commands - reference AGENTS.md for the correct syntax.\n","isInternal":false,"tokens":219,"sizeBytes":988},{"name":"SKILL.md","path":".agents/skills/create-pr/SKILL.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/create-pr/SKILL.md","title":"create-pr","category":"anthropic-skill","format":"markdown","content":"---\nname: create-pr\ndescription: Create and package React Router pull requests. Use when the user asks to create, open, prepare, or finish a PR for this repository, including branch/commit/push handoff, draft PR creation, PR body writing, and applying GitHub labels such as pkg:*, feat:*, docs, github-actions, or dependencies.\n---\n\n# Create React Router PR\n\nCreate the pull request handoff for completed React Router work. Default to a draft PR targeting `main` unless the user explicitly asks for a ready PR or a different base branch.\n\n## Preconditions\n\n- Inspect `git status --short --branch` and `git branch --show-current`.\n- Do not include unrelated dirty files. If unrelated changes are present, leave them unstaged and mention them.\n- If the worktree is detached, create a branch from the current `HEAD` before committing. Use the branch name requested by the user, an existing repository convention, or `<author>/<semantic-name>` when no stronger convention is available.\n- If already on a suitable named branch, use it.\n- Confirm appropriate automated coverage exists or was added. Do not list routine CI-covered checks in the PR body.\n- If user-facing functionality is being updated, check that the appropriate package has a change file under `packages/<package>/.changes/`. This is not necessary for docs-only, GitHub Actions/workflow-only, or dependency-maintenance PRs unless the dependency change itself has user-facing impact.\n\n## Context\n\n- Capture what changed, why it changed, and who it affects.\n- Find related issues, discussions, or PRs and include links when relevant.\n- Prefer `git diff --stat` plus focused `git diff` over broad repo archaeology when the change is small.\n- If the user supplies a report, issue, discussion, or related PR, treat that as the primary context source.\n- For new feature work, include a concise usage snippet. If the feature replaces or improves an older approach, include before/after examples when they help reviewers.\n\n## Commit and Push\n\n1. Review the diff with `git diff --stat` and focused `git diff` as needed.\n2. Stage only the intended files.\n3. Commit with a concise imperative subject.\n4. Push the branch before creating the PR.\n\n## PR Creation\n\nSave the PR body to a temporary file, then use `gh pr create` with:\n\n```sh\ngh pr create --draft --base main --head <branch> --title \"<title>\" --body-file <file>\n```\n\n- Omit `--draft` only when the user explicitly asks for a ready PR.\n- Change `--base` only when the user explicitly requests a different base branch.\n- Keep shell quoting simple. Prefer a body file if the body contains backticks, quotes, or multiple paragraphs.\n- Include issue/discussion links when known. Use `Closes #NNNN` for bug fixes the PR should close; use `Implements #NNNN` or a plain link for RFCs/discussions when closing semantics are not appropriate.\n- Include testing notes only for manual checks, unusual verification, skipped non-CI checks, or failures that reviewers should know about.\n- If `gh pr create` fails, leave the branch pushed when possible and give the user a ready-to-open compare URL plus the prepared title and body.\n\nRecommended PR body shape:\n\n````markdown\nThis change ...\n\n- Optional extra detail when useful.\n\n```tsx\n// Optional feature usage example\n```\n````\n\n```tsx\n// Optional before/after example\n```\n\n**Testing**\n\n- Optional manual or non-CI verification notes only.\n\n````\n\n- Do not use a `## Summary` heading. Start with one or two short sentences explaining what the change accomplishes.\n- Add bullets after the opening only when more detail is useful.\n- Include usage examples for new features, and before/after examples for replacements or improvements, when they help reviewers understand the change.\n- Add `**Testing**` with bullets below the description only when there are manual checks, unusual verification steps, skipped non-CI checks, or failures reviewers should know about. Omit it for routine automated coverage.\n\n## Testing Notes\n\n- Do not list linting, typechecking, unit test, or integration test commands in the PR body, even if they were run locally. CI runs these automatically.\n- Do not say that CI will run routine linting, typechecking, unit tests, or integration tests. That is assumed for every PR.\n- Do not add manual testing instructions by default.\n- Add manual testing instructions only when necessary, such as visual/UI behavior that needs human review, environment-specific behavior not covered by CI, release/publish dry-run steps, external service integration, or a reproduction that cannot be expressed reliably in automated tests.\n- When manual testing is necessary, keep the instructions minimal and directly tied to the uncovered risk.\n\n## Labels\n\nApply labels after the PR exists. Rely on the stable labels listed in this skill for normal PRs.\n\nApply labels with:\n\n```sh\ngh pr edit <number-or-url> --add-label \"<label>\"\n````\n\nIf `gh pr edit --add-label` fails because the specified label is invalid or missing, run:\n\n```sh\ngh label list --limit 200\n```\n\nThen choose the correct label from the live list and update this skill in place so the stable label guidance stays current. Use real labels only. If the right label does not exist, do not invent one; mention the missing label.\n\n### Package Labels\n\nAdd every applicable `pkg:*` label based on touched package paths:\n\n| Touched path | Label |\n| ---------------------------------------------------- | ----------------------------------------------- |\n| `packages/react-router/` | `pkg:react-router` |\n| `packages/react-router-dev/` | `pkg:@react-router/dev` |\n| `packages/create-react-router/` | `pkg:create-react-router` |\n| `packages/react-router-architect/` | `pkg:@react-router/architect` |\n| `packages/react-router-cloudflare/` | `pkg:@react-router/cloudflare` |\n| `packages/react-router-node/` | `pkg:@react-router/node` |\n| `packages/react-router-serve/` | `pkg:@react-router/serve` |\n| `packages/react-router-express/` | `pkg:@react-router/express` |\n| `packages/react-router-fs-routes/` | `pkg:@react-router/fs-routes` |\n| `packages/react-router-remix-routes-option-adapter/` | `pkg:@react-router/remix-routes-option-adapter` |\n\nIf a package path is unclear, inspect its `package.json` `name` and use `pkg:<name>` when that label exists. If a change touches generated artifacts or integration tests only, infer the package label from the runtime/tooling area being tested. For example, Vite plugin or prerender integration coverage usually maps to `pkg:@react-router/dev`.\n\n### Feature Labels\n\nAdd applicable `feat:*` labels for the behavior area being changed. Common labels include:\n\n| Behavior area | Label |\n| --------------------------------------------------------------------------------- | --------------------------- |\n| Core navigation, loaders/actions, fetchers, redirects, matching, and router state | `feat:router` |\n| Route config APIs and `routes.ts` | `feat:routes.ts` |\n| Vite plugin and build pipeline behavior | `feat:vite` |\n| SPA mode | `feat:spa-mode` |\n| Prerendering | `feat:prerender` |\n| Lazy route discovery | `feat:lazy-route-discovery` |\n| Hydration and hydration fallback behavior | `feat:hydration` |\n| View transition APIs | `feat:view-transitions` |\n| Middleware behavior | `feat:middleware` |\n| Split route module behavior | `feat:split-route-modules` |\n| Streaming behavior | `feat:streaming` |\n| CSS handling | `feat:css` |\n| Windows-specific fixes | `feat:windows` |\n| RSC Data or RSC Framework behavior | `feat:rsc` |\n| Path matching semantics | `feat:path-matching` |\n| Single fetch behavior | `feat:single-fetch` |\n| Types, typegen, and TypeScript behavior | `feat:typescript` |\n\nMultiple feature labels are fine when the diff truly spans multiple areas. Prefer the most specific label that exists.\n\n### Non-Package Labels\n\nSome PRs do not need package or feature labels:\n\n- Add `docs` for documentation-only changes.\n- Add `github-actions` for `.github/workflows/` or Actions infrastructure changes.\n- Add `dependencies` for dependency or lockfile-only maintenance.\n- Add version labels such as `v6`, `v7`, or `v8` only when the PR is intentionally scoped to that release line or the user asks for it.\n\n## Final Report\n\nReport:\n\n- Branch name.\n- Commit hash.\n- PR URL and whether it is draft or ready.\n- Base branch.\n- Labels applied.\n- Verification performed or skipped.\n","frontmatter":{"name":"create-pr","description":"Create and package React Router pull requests. Use when the user asks to create, open, prepare, or finish a PR for this repository, including branch/commit/push handoff, draft PR creation, PR body writing, and applying GitHub labels such as pkg:*, feat:*, docs, github-actions, or dependencies."},"isInternal":false,"tokens":1904,"sizeBytes":9967},{"name":"SKILL.md","path":".agents/skills/finish-line/SKILL.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/finish-line/SKILL.md","title":"finish-line","category":"anthropic-skill","format":"markdown","content":"---\nname: finish-line\ndescription: Bring a blocked React Router community pull request across the finish line. Use when the user invokes `/finish-line` or `$finish-line`, provides a PR number or URL, and asks Codex to resolve merge blockers such as a missing change file, missing documentation, missing tests, or stale contributor follow-up. Handles evaluating the blocker and pushing small maintainer fixes onto a contributor PR branch when authorized.\n---\n\n# Finish Line\n\n## Overview\n\nFinish blocked community PRs in `remix-run/react-router` while respecting contributor ownership and the repo's PR packaging conventions.\n\nTreat the PR number or URL in `$ARGUMENTS` as the target PR. If no target is provided, ask for it before doing anything.\n\n## Triage\n\n1. Inspect local state with `git status --short --branch`. If unrelated dirty files exist, do not overwrite or stage them.\n2. Fetch current main before making branch decisions:\n\n```sh\ngit fetch origin main\n```\n\n3. Gather PR context:\n\n```sh\ngh pr view <pr> --repo remix-run/react-router --json number,title,body,state,isDraft,author,baseRefName,headRefName,headRepository,headRepositoryOwner,maintainerCanModify,mergeStateStatus,reviewDecision,labels,files,commits,statusCheckRollup,url\ngh pr checks <pr> --repo remix-run/react-router\ngh pr diff <pr> --repo remix-run/react-router --stat\ngh pr view <pr> --repo remix-run/react-router --comments\n```\n\n4. Identify merge blockers. In particular:\n\n- If the PR only needs repo-maintainer additions such as tests, a change file, or docs, use the contributor-branch workflow.\n- If the contributor branch cannot be modified, summarize the evidence and ask the user whether to wait for the contributor or recreate the work on a maintainer branch.\n- If the blocker is unclear, summarize the evidence and ask the user which path to take.\n\n5. Evaluate test coverage before deciding the finish-line changes:\n - Inspect the PR diff, changed files, existing nearby tests, review comments, and failed checks for test expectations.\n - If the PR changes runtime behavior, build/plugin behavior, routing semantics, generated types, RSC behavior, docs rendering, or any bug/feature surface that can regress, add or preserve a focused test unless equivalent coverage already exists.\n - If tests are already included, verify they exercise the changed behavior and cover the affected React Router mode(s): Declarative, Data, Framework, RSC Data, and/or RSC Framework.\n - If tests are not needed because the change is documentation-only, packaging-only, a change file, or otherwise not executable behavior, note that rationale in the final report.\n - If a useful test is required but too large or risky for the finish-line scope, stop and ask the user before broadening the PR.\n\n## Contributor-Branch Workflow\n\nUse this path when the missing work is a small maintainer follow-up, such as tests, a change file, or docs, and the contributor branch can be modified.\n\n1. Check out the PR branch:\n\n```sh\ngh pr checkout <pr-number> --repo remix-run/react-router\n```\n\n2. Confirm the branch and local state:\n\n```sh\ngit status --short --branch\ngit branch --show-current\n```\n\n3. Make only the missing finish-line changes, including focused tests when the coverage evaluation requires them. Do not refactor the contributor's work unless it is necessary to unblock mergeability and the user agrees.\n4. Validate the exact content with the user before pushing:\n - For a change file, show the package path, file name, change type, and full markdown contents.\n - For docs, show the affected files and the relevant prose/API snippets.\n - For tests, show the test file path, the behavior covered, and the mode(s) covered.\n - Ask explicitly for approval to commit and push back to the PR branch.\n5. After approval, run focused validation when appropriate, commit the maintainer follow-up, and push to the PR branch. If `git push` fails because the contributor branch cannot be modified, stop and report the failure instead of opening a replacement PR unless the user approves that pivot.\n\n## Change Files\n\nCreate change files under the affected package:\n\n```text\npackages/<package>/.changes/<type>.<unique-meaningful-name>.md\n```\n\nUse `patch`, `minor`, `major`, or `unstable` for `<type>`. For bug fixes and narrow behavior fixes, default to `patch`. Keep the content concise:\n\n```markdown\nBrief description of the user-facing change\n```\n\nIf the PR spans multiple packages, prefer the package with the direct user-facing API or runtime behavior. Ask the user when the package or change type is not obvious.\n\n## Documentation\n\nDo not add documentation by default for ordinary bug fixes. Add docs when the PR changes a documented API, introduces new behavior users need to discover, changes examples, or the user/reviewer explicitly requested docs.\n\nFollow repo docs rules:\n\n- Edit source docs or JSDoc, not generated `docs/api/` output.\n- Include mode context when adding docs for React Router behavior: Declarative, Data, Framework, RSC Data, or RSC Framework.\n- For API docs generated from JSDoc, edit `packages/react-router/lib/` comments and note that `pnpm run docs` may be required.\n\n## Final Report\n\nReport the path taken and the current PR state:\n\n- Original PR number and blocker.\n- Whether changes were pushed to the contributor branch or a replacement PR was opened.\n- Branch, commit hash, and PR URL when applicable.\n- Any old-PR comment/close action taken.\n- Validation performed or skipped.\n- Test coverage decision: added, already present, or intentionally omitted with rationale.\n","frontmatter":{"name":"finish-line","description":"Bring a blocked React Router community pull request across the finish line. Use when the user invokes `/finish-line` or `$finish-line`, provides a PR number or URL, and asks Codex to resolve merge blockers such as a missing change file, missing documentation, missing tests, or stale contributor follow-up. Handles evaluating the blocker and pushing small maintainer fixes onto a contributor PR branch when authorized."},"isInternal":false,"tokens":1208,"sizeBytes":5577},{"name":"SKILL.md","path":".agents/skills/fix-bug/SKILL.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/fix-bug/SKILL.md","title":"fix-bug","category":"anthropic-skill","format":"markdown","content":"---\nname: fix-bug\ndescription: \"Fix a reported bug in React Router from a GitHub issue. Use when the user provides a GitHub issue URL and asks to fix a bug, investigate an issue, or reproduce a problem. Handles the full workflow: fetching the issue, finding the reproduction, writing a failing test, and implementing the fix.\"\ndisable-model-invocation: true\n---\n\n# Fix React Router Bug\n\nFix the bug reported in the following GitHub issue: $ARGUMENTS\n\n## Branching\n\nBug fixes should start from a clean working tree. If there are changes, prompt me to resolve them before continuing.\n\nBugs should be fixed from the `main` branch in a new branch using the format `{author}/{semantic-branch-name}` (i.e., `brophdawg11/fix-navigation`):\n\n```sh\ngit branch {author}/{semantic-branch-name} main\ngit checkout {author}/{semantic-branch-name}\n```\n\n## Workflow\n\n### 1. Fetch and Understand the Issue\n\nUse `gh issue view <number> --repo remix-run/react-router` or `WebFetch` to read the full issue.\n\nExtract:\n\n- Bug description and expected vs actual behavior\n- React Router version and mode (Declarative / Data / Framework / RSC)\n- Any code snippets in the issue\n- Links to reproductions (StackBlitz, CodeSandbox, GitHub repo, etc.)\n\n### 2. Validate the Reproduction\n\n**If there's a StackBlitz/CodeSandbox/online sandbox link:**\n\n- Use `WebFetch` to read the sandbox URL and extract the relevant code\n- Identify the exact sequence of events that triggers the bug\n\n**If there's a GitHub repository link:**\n\n- Use `WebFetch` to read key files (`package.json`, relevant source files) from the raw GitHub URL\n- Identify the route configuration, loaders, actions, or components involved\n\n**If no reproduction link exists:**\n\n- Search the issue comments with `gh issue view <number> --repo remix-run/react-router --comments`\n- Look for code snippets in comments\n- Ask the user: \"No reproduction was provided. Can you share a minimal reproduction or paste the relevant code?\"\n\n### 3. Identify the Affected Code\n\nBased on the bug, locate the relevant source files. Consult the key file map:\n\n| Area | Files |\n| ---------------------- | ----------------------------------------------------------- |\n| Core router logic | `packages/react-router/lib/router/router.ts` |\n| React components/hooks | `packages/react-router/lib/components.tsx`, `lib/hooks.tsx` |\n| DOM utilities | `packages/react-router/lib/dom/` |\n| Vite/Framework plugin | `packages/react-router-dev/vite/plugin.ts` |\n| RSC | `packages/react-router/lib/rsc/` |\n\nUse `Grep` and `Glob` to trace the relevant code paths.\n\n### 4. Write a Failing Test\n\n**Unit test** (for router logic, hooks, pure component behavior — no build needed):\n\n- Location: `packages/react-router/__tests__/`\n- Use Jest; run with: `pnpm test packages/react-router/__tests__/<file>`\n- Match the style of nearby test files (describe/it blocks, `createStaticHandler`, `createMemoryRouter`, `render`, `screen`, etc.)\n\n**Integration test** (for Vite plugin, SSR, hydration, Framework Mode):\n\n- Location: `integration/`\n- Use Playwright with `createFixture()` → `createAppFixture()` → `PlaywrightFixture`\n- Run with: `pnpm test:integration:run --project chromium integration/<file>`\n- Build first if needed: `pnpm test:integration --project chromium`\n\nWrite the test to **reproduce the bug exactly** — it must fail before the fix.\n\nRun it and confirm it fails:\n\n```bash\npnpm test packages/react-router/__tests__/<file> # unit\n# or\npnpm test:integration:run --project chromium integration/<file> # integration\n```\n\n### 5. Implement the Fix\n\n- Make the minimal change needed to fix the bug\n- Do not refactor unrelated code\n- Confirm the fix addresses the root cause, not just the symptom\n- Consider all five modes: does this fix break anything in Declarative / Data / Framework / RSC?\n\nRun the failing test again — it must now pass:\n\n```bash\npnpm test packages/react-router/__tests__/<file>\n```\n\nRun the broader test suite to check for regressions:\n\n```bash\npnpm test packages/react-router/\n```\n\nIf the fix touches Framework/Vite code, run integration tests too:\n\n```bash\npnpm test:integration:run --project chromium\n```\n\nConfirm linting and typechecking pass:\n\n```bash\npnpm lint\npnpm typecheck\n```\n\n### 6. Create a Change file\n\nCreate a change file at `packages/<package>/.changes/<type>.<unique-meaningful-name>.md`. `<type>` should be either `patch`, `minor`, `major` or `unstable` to indicate the type of API change being made.\n\nFormat:\n\n```markdown\nfix: <brief description of what was fixed>\n```\n\n### 7. Report Results\n\nSummarize:\n\n- What the bug was and why it happened\n- What code was changed and why\n- That the test now passes\n- Any edge cases or related issues noticed\n\nAsk me to review the changes and iterate based on any feedback.\n\n### 8. Open PR\n\nOnce I approve the fix, commit the changes and open a PR to `main`. Include a `Closes #NNNN` in the description to link the PR to the original issue. Also link the issue in the `Development` sidebar\n","frontmatter":{"name":"fix-bug","description":"Fix a reported bug in React Router from a GitHub issue. Use when the user provides a GitHub issue URL and asks to fix a bug, investigate an issue, or reproduce a problem. Handles the full workflow: fetching the issue, finding the reproduction, writing a failing test, and implementing the fix.","disable-model-invocation":true,"disableModelInvocation":true},"isInternal":false,"tokens":1201,"sizeBytes":5168},{"name":"SKILL.md","path":".agents/skills/implement-rfc/SKILL.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/implement-rfc/SKILL.md","title":"implement-rfc","category":"anthropic-skill","format":"markdown","content":"---\nname: implement-rfc\ndescription: Implement a React Router RFC from a GitHub discussion URL. Fetches the proposal, evaluates community feedback, resolves outstanding questions interactively, then implements the feature with tests, future flags (if breaking), and a changeset.\ndisable-model-invocation: true\n---\n\n# Implement React Router RFC\n\nImplement the RFC from the following GitHub discussion: $ARGUMENTS\n\n## Branching\n\nRFC implementations should start from a clean working tree. If there are uncommitted changes, stop and ask me to resolve them before continuing.\n\n- If you are already on a named branch that is at the same HEAD as `main`, use that branch.\n- Otherwise, create a branch from `main` using the format `{author}/rfc-{semantic-name}`:\n ```sh\n git branch {author}/rfc-{semantic-name} main\n git checkout {author}/rfc-{semantic-name}\n ```\n\n## Workflow\n\n### 1. Fetch and Understand the RFC\n\nUse `WebFetch` to read the discussion URL. If a GitHub discussion number is given instead of a URL, construct:\n`https://github.com/remix-run/react-router/discussions/<number>`\n\nExtract:\n\n- **Problem being solved**: what pain point does this RFC address?\n- **Proposed API**: exact function signatures, hook names, types, option shapes\n- **Affected modes**: Declarative / Data / Framework / RSC Data / RSC Framework\n- **Breaking changes**: does this change or remove existing public API?\n- **Open questions**: anything explicitly marked as unresolved, \"TBD\", or asked as a question in the proposal\n- **Status**: are there linked tracking issues? Look for links to other github issues and read them to see if there is additional context.\n\n ```sh\n gh issue view <number> --repo remix-run/react-router\n ```\n\n### 2. Evaluate Community Feedback\n\nFetch all comments from the discussion:\n\nUse `WebFetch` on `https://github.com/remix-run/react-router/discussions/<number>` and scroll through the full thread. Look for:\n\n- **Concerns or objections** raised by community members or maintainers\n- **Alternative proposals** or API shape suggestions\n- **Edge cases** raised that the proposal does not address\n- **Positive signals** — repeated praise for a specific approach signals it's the right direction\n- **Maintainer responses** — Ryan Florence, Michael Jackson, or other core team members clarifying intent\n\nSummarize the community sentiment into:\n\n- Points of consensus (safe to proceed)\n- Points of contention (need resolution before implementing)\n- Unanswered questions from the original proposal\n\n### 3. Resolve Outstanding Questions\n\nBefore writing any code, present me with a numbered list of every unresolved question — from both the RFC itself and from community feedback. For each question:\n\n- State the question clearly\n- Summarize relevant community input\n- Offer a recommended answer with reasoning\n\nAsk me to confirm, override, or skip each question. Do not proceed to implementation until all questions are either answered or explicitly deferred.\n\nExample format:\n\n```\n## Unresolved Questions\n\n1. **Should `useRouterState()` accept a path argument for scoped matching?**\n Community feedback: 3 comments in favor, 1 against (concerns about complexity).\n Recommendation: Yes — scoped matching improves type safety for nested routes.\n → Your decision: [confirm / override / defer]\n\n2. **What should happen when the path doesn't match the current location?**\n Recommendation: Return `null` for active state (consistent with `useMatch()`).\n → Your decision: [confirm / override / defer]\n```\n\nSave the resolved decisions to a scratch file at `tasks/rfc-decisions.md` for reference during implementation.\n\n### 4. Plan the Implementation\n\nBefore writing code, produce a concise implementation plan covering:\n\n- New types/interfaces to add\n- New functions/hooks to implement and their file locations\n- Existing APIs to deprecate (mark with `@deprecated` JSDoc + console warning in dev)\n- Whether a future flag is needed (see §5 below)\n- Test files to create or extend (unit and/or integration)\n- Changeset bump level (`minor` for new features, `major` for breaking changes behind a future flag that is now defaulted on)\n\nPresent the plan to me and wait for approval before implementing.\n\n### 5. Future Flags for Breaking Changes\n\nIf the RFC changes or removes existing public API behavior, it **must** ship behind a future flag which will start with an `unstable_` prefix.\n\n**Future flag pattern:**\n\n1. Add the flag to `FutureConfig` in `packages/react-router/lib/router/utils.ts`:\n\n ```ts\n export interface FutureConfig {\n // existing flags...\n unstable_myNewBehavior: boolean;\n }\n ```\n\n2. Gate the new behavior on the flag:\n\n ```ts\n if (router.future.unstable_myNewBehavior) {\n // new behavior\n } else {\n // legacy behavior\n }\n ```\n\n3. Document the flag in `docs/upgrading/future-flags.md` if it exists.\n\nNew additive APIs (no behavior change to existing code) do **not** need a future flag.\n\n### 6. Key File Locations\n\n| Area | Files |\n| --------------------- | -------------------------------------------- |\n| Core router logic | `packages/react-router/lib/router/router.ts` |\n| Router types/utils | `packages/react-router/lib/router/utils.ts` |\n| React components | `packages/react-router/lib/components.tsx` |\n| React hooks | `packages/react-router/lib/hooks.tsx` |\n| Public exports | `packages/react-router/index.ts` |\n| DOM utilities | `packages/react-router/lib/dom/` |\n| Framework/Vite plugin | `packages/react-router-dev/vite/plugin.ts` |\n| RSC runtime | `packages/react-router/lib/rsc/` |\n| Unit tests | `packages/react-router/__tests__/` |\n| Integration tests | `integration/` |\n| Future flags doc | `docs/upgrading/future-flags.md` |\n\nConfirm existing patterns before writing new code - prefer using the LSP but `Grep`/`Glob` also work. Match naming conventions and code style exactly.\n\n### 7. Implement the Feature\n\nFollow the approved plan. For each logical unit of work:\n\n1. Write the implementation\n2. Export from the appropriate public entry point (`packages/react-router/index.ts`)\n3. Add `@deprecated` JSDoc to any APIs being superseded\n4. Run typecheck to catch type errors early:\n ```sh\n pnpm typecheck\n ```\n\nKeep changes minimal and focused. Do not refactor unrelated code. Commit as often as needed.\n\n### 8. Write Tests\n\n**Unit tests** (for hooks, pure router logic, component behavior — no build):\n\n- Location: `packages/react-router/__tests__/`\n- Runner: Jest → `pnpm test packages/react-router/__tests__/<file>`\n- Cover: happy path, edge cases identified in RFC/community feedback, future flag gating (if applicable), deprecation warnings\n\n**Integration tests** (for Vite/Framework Mode, SSR, hydration):\n\n- Location: `integration/`\n- Runner: Playwright → `pnpm test:integration:run --project chromium integration/<file>`\n- Required if the RFC touches Framework Mode, file-system routing, or SSR behavior\n\nRun all tests and confirm they pass:\n\n```sh\npnpm test packages/react-router/\npnpm test:integration:run --project chromium # only if integration tests were added/changed\n```\n\n### 9. Lint and Typecheck\n\n```sh\npnpm lint\npnpm typecheck\n```\n\nFix all errors before proceeding.\n\n### 10. Create a Change File\n\nCreate `packages/<package>/.changes/<bump-level>.<descriptive-name>.md`. Use the RFC title or tracking issue as the description:\n\n```markdown\nfeat: <brief description matching the RFC title>\n\nImplements the `useRouterState()` RFC (#12358). Deprecates `useLocation`,\n`useParams`, `useSearchParams`, `useNavigation`, `useMatches`, `useMatch`,\n`useNavigationType`, and `useViewTransitionState` in favor of a unified API.\n\nEnable the `unstable_consolidatedRouterState` future flag to opt in.\n```\n\nBump levels:\n\n- `patch` — bug-adjacent fix only\n- `minor` — new additive API (no breaking changes)\n- `major` — breaking change (should be rare; most breaking changes go behind a future flag as `minor` first)\n- `unstable` — new API that is not yet stable (e.g. added in a future flag, or an experimental API that may be removed without a major bump)\n\n### 11. Report and Review\n\nSummarize:\n\n- What RFC was implemented and which decisions were made\n- New public APIs added (with brief usage example)\n- APIs deprecated and the migration path\n- Future flag name (if applicable) and how to opt in\n- Test coverage added\n- Anything deferred or explicitly out of scope\n\nAsk me to review and iterate before opening a PR.\n\n### 12. Commit\n\nOnce I approve, commit and open a PR to `main`:\n\n```sh\ngh pr create --base main --title \"feat: <RFC title>\" --body \"...\"\n```\n\nPR body should include:\n\n- Link to the RFC discussion (Closes or Implements #NNNN)\n- Summary of what was implemented\n- Future flag instructions if applicable\n- Testing notes\n- Any decisions that deviated from the original proposal and why\n","frontmatter":{"name":"implement-rfc","description":"Implement a React Router RFC from a GitHub discussion URL. Fetches the proposal, evaluates community feedback, resolves outstanding questions interactively, then implements the feature with tests, future flags (if breaking), and a changeset.","disable-model-invocation":true,"disableModelInvocation":true},"isInternal":false,"tokens":2026,"sizeBytes":9033},{"name":"openai.yaml","path":".agents/skills/prepare-release-notes/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/prepare-release-notes/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"interface:\n display_name: \"Prepare Release Notes\"\n short_description: \"Polish React Router release notes\"\n default_prompt: \"Use $prepare-release-notes to review pending React Router change files and draft any needed What's Changed notes.\"\n","isInternal":false,"tokens":49,"sizeBytes":242},{"name":"whats-changed.md","path":".agents/skills/prepare-release-notes/references/whats-changed.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/prepare-release-notes/references/whats-changed.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# What's Changed Reference\n\nLoad this when deciding whether a React Router release needs `scripts/changes/whats-changed.md`.\n\n## Include A Manual Section For\n\n- Major releases with baseline changes, removed packages, removed deprecated APIs, new runtime requirements, or migration guidance\n- Stabilizations and flag renames where adopters of unstable APIs need explicit before/after guidance\n- New APIs or flags that deserve a narrative introduction or usage example\n- Cross-cutting performance or behavior work where several bullets form one user-facing story\n- Breaking bug fixes, deployment-sensitive fixes, or adapter/runtime behavior changes where users may need to test or update config\n\n## Usually Do Not Include One For\n\n- Straightforward bug fixes\n- Dependency removals or upgrades where the bullet is sufficient\n- Internal refactors with no public API change\n- A minor feature that is fully understandable from one concise bullet and nested detail bullets\n- Releases where the only content is a normal patch list\n\n## Existing Changelog Patterns\n\n- `v8.1.0`: Uses headings for agent skill installation and observability metadata, including an instrumentation code example. The generated minor bullets still carry the per-package details.\n- `v8.0.0`: Uses long-form migration notes for a major release: baseline support, adopted future flags, removed packages/APIs, and behavior changes.\n- `v7.18.0`: Explains a CSRF check fix that may be a breaking bug fix for reverse-proxy deployments and tells users what to test.\n- `v7.15.0`: Groups several unstable-to-stable API renames and route matching optimizations into narrative sections before listing individual minor bullets.\n- `v7.15.1`: Uses a \"What's New\" style section for an unstable hook with a code example. For new release notes, prefer the current `What's Changed` file path; the generated heading will be `### What's Changed`.\n\n## Drafting Tips\n\n- Use `####` headings inside `scripts/changes/whats-changed.md`; the release script wraps the file in `### What's Changed` if needed\n- Mention applicable React Router modes when the distinction matters: Declarative, Data, Framework, RSC Data, or RSC Framework\n- Keep examples short and directly tied to adoption\n- Avoid repeating the package prefix and PR-link details already provided by generated change sections\n- If unsure, run `pnpm changes:preview` with and without the manual section and keep it only if the generated notes are meaningfully clearer with the narrative\n","isInternal":false,"tokens":521,"sizeBytes":2488},{"name":"SKILL.md","path":".agents/skills/prepare-release-notes/SKILL.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/prepare-release-notes/SKILL.md","title":"prepare-release-notes","category":"anthropic-skill","format":"markdown","content":"---\nname: prepare-release-notes\ndescription: Prepare React Router release notes before running the changes/versioning scripts. Use when asked to review, polish, normalize, or prepare pending change files under packages/*/.changes, remove semantic commit prefixes from release bullets, enforce imperative tense, decide whether a manual scripts/changes/whats-changed.md section is warranted, or draft long-form release notes for new features, stable future flags, or unstable flags.\n---\n\n# Prepare Release Notes\n\nPolish pending React Router change files and add manual release notes only when the release needs narrative context beyond the generated change lists.\n\n## Workflow\n\n1. Inspect local state:\n\n```sh\ngit status --short\nfind packages -path '*/.changes/*.md' -not -name README.md -not -name .gitkeep -print | sort\n```\n\n2. Read every pending change file. Do not edit generated changelogs or released notes directly.\n\n3. Normalize each change file:\n - Remove `feat:`, `feat(...)`, `fix:`, and `fix(...)` semantic-commit prefixes from prose\n - Use present or imperative tense for the first line and top-level release bullets: prefer `Add`, `Fix`, `Remove`, `Support`, `Stabilize`, `Preserve`, `Update`, `Avoid`, `Prevent`, `Throw`, `Warn`, `Expose`\n - Nested detail bullets can stay explanatory when they expand on the parent bullet; do not rewrite them solely to force present or imperative tense\n - Remove terminal sentence periods from bullet items because release generation appends PR/commit links after the first bullet line\n - Remove terminal sentence periods from nested bullet items too, unless the punctuation is part of code, a URL, an abbreviation, a version number, or another token where removing it would be wrong\n - If one bullet contains multiple sentences, split it into a shorter parent bullet plus nested bullet items\n - Keep the first line concise and user-facing; use nested bullets for details or migration notes\n\n4. Review whether `scripts/changes/whats-changed.md` is needed:\n - Read `CHANGELOG.md` examples or `references/whats-changed.md` when uncertain\n - Add `scripts/changes/whats-changed.md` only for features, future flag stabilizations, unstable flags, migration guidance, breaking bug fixes, or complex behavior that needs long-form text or examples\n - Do not add it for ordinary bug fixes, dependency cleanup, internal refactors, or release bullets that are already clear\n - If adding it, write the body only; the release script adds `### What's Changed` when missing\n\n5. Validate:\n\n```sh\npnpm changes:validate\npnpm changes:preview\n```\n\nUse `changes:preview` to inspect the generated root release notes and confirm the PR/commit link placement, section ordering, and any manual What's Changed placement. If dependencies are missing or the command is too expensive for the context, state what was skipped.\n\n## Change File Style\n\nSingle-line entries should read well with an auto-appended PR link:\n\n```markdown\nFix `href()` to stringify and URL-encode param values like `generatePath()`\n```\n\nUse nested bullets for additional sentences:\n\n```markdown\nFix route ranking for dynamic parameters with static extension suffixes\n\n- Identify `/:name.xml` as a dynamic segment instead of a static segment\n- Preserve static route priority for paths like `/sitemap.xml`\n```\n\nAvoid semantic commit prefixes:\n\n```markdown\nAdd support for nub as a package manager\n```\n\nnot:\n\n```markdown\nfeat: add support for nub as a package manager.\n```\n\n## What's Changed Guidance\n\nUse `scripts/changes/whats-changed.md` for release-level narrative, not package-specific bullets. Good candidates include:\n\n- A new user-facing API or feature that benefits from example code\n- Stabilization or renaming of unstable APIs/flags, especially when adopters must migrate\n- A stable future flag that changes behavior and needs adoption guidance\n- A breaking bug fix or adapter/runtime behavior change that may require deployment checks\n- A cluster of related changes whose combined effect matters more than the individual bullet list\n\nKeep the tone direct and practical. Prefer headings under the generated `### What's Changed` section:\n\n````markdown\n#### Feature Name\n\nExplain what changed, who it affects, and how to adopt it.\n\n```ts\n// Optional short example\n```\n````\n\nDo not duplicate every bullet from Minor/Patch/Unstable Changes. Let generated change files carry ordinary PR-level details.\n\nSee `references/whats-changed.md` for examples distilled from the existing changelog.\n","frontmatter":{"name":"prepare-release-notes","description":"Prepare React Router release notes before running the changes/versioning scripts. Use when asked to review, polish, normalize, or prepare pending change files under packages/*/.changes, remove semantic commit prefixes from release bullets, enforce imperative tense, decide whether a manual scripts/changes/whats-changed.md section is warranted, or draft long-form release notes for new features, stable future flags, or unstable flags."},"isInternal":false,"tokens":965,"sizeBytes":4504},{"name":"data-mode.md","path":".agents/skills/react-router/references/data-mode.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/react-router/references/data-mode.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Data Mode\n\nData Mode uses data routers such as `createBrowserRouter` and renders with `<RouterProvider>`. It gives an app route objects, loaders, actions, pending UI, fetchers, and SSR primitives without adopting the Framework Vite plugin or route-module file conventions.\n\nUse this reference after the main skill identifies a Data Mode app.\n\n## Read the Local Docs by Mode\n\nStart with:\n\n```txt\nreact-router/docs/start/modes.md\nreact-router/docs/start/data/index.md\n```\n\nThen use the Data docs under:\n\n```txt\nreact-router/docs/start/data/\n```\n\nThose files cover installation, route objects, routing, data loading, actions, navigation, pending UI, and testing. For task-specific details, read relevant files in:\n\n```txt\nreact-router/docs/how-to/\nreact-router/docs/explanation/\n```\n\nAlways check the `[MODES: data, ...]` marker in a doc before applying it.\n\n## Data Router Shape\n\nTypical setup:\n\n```tsx\nimport { createBrowserRouter, RouterProvider } from \"react-router\";\n\nconst router = createBrowserRouter([\n {\n path: \"/\",\n Component: Root,\n loader: rootLoader,\n children: [\n { index: true, Component: Home },\n {\n path: \"projects/:projectId\",\n Component: Project,\n loader: projectLoader,\n },\n ],\n },\n]);\n\nroot.render(<RouterProvider router={router} />);\n```\n\nLook for route object arrays and APIs such as:\n\n- `createBrowserRouter`\n- `createHashRouter`\n- `createMemoryRouter`\n- `RouterProvider`\n- `loader`\n- `action`\n- `Component`\n- `ErrorBoundary`\n- `lazy`\n- `children`\n\n## Route Objects and Routing\n\nBefore editing route configuration, read:\n\n```txt\nreact-router/docs/start/data/routing.md\nreact-router/docs/start/data/route-object.md\n```\n\nRules:\n\n- Keep route objects outside render when possible.\n- Use nested routes for shared layouts and data boundaries.\n- Use index routes for default child content.\n- Use dynamic segments and splats according to route-object docs.\n- Prefer `Component`/`ErrorBoundary` route object properties in Data Mode examples unless the existing app uses `element` consistently.\n\n## Data and Mutations\n\nBefore working on data loading or mutations, read:\n\n```txt\nreact-router/docs/start/data/data-loading.md\nreact-router/docs/start/data/actions.md\n```\n\nRules:\n\n- Load route data with route `loader` functions.\n- Mutate route data with route `action` functions.\n- Prefer loaders/actions over route-level `useEffect` fetching.\n- Use `request`, `params`, and returned/throwable Responses as described in the docs.\n- Let React Router revalidate after actions unless there is a documented reason to customize revalidation.\n\nCommon patterns:\n\n- Validation failure from an action: return `data({ errors, values }, { status: 400 })`, then render errors with `useActionData()` or `fetcher.data`.\n- Missing record in a loader: throw `data(\"Not Found\", { status: 404 })` and render the route `ErrorBoundary`.\n- Search/filter data: parse `new URL(request.url).searchParams` in the loader so the URL is shareable and bookmarkable.\n\n## Forms, Fetchers, and Pending UI\n\nFor forms and pending UI, read:\n\n```txt\nreact-router/docs/start/data/actions.md\nreact-router/docs/start/data/pending-ui.md\nreact-router/docs/how-to/fetchers.md\nreact-router/docs/explanation/form-vs-fetcher.md\n```\n\nRules of thumb:\n\n- Search/filter form that updates the URL: `<Form method=\"get\">`.\n- Mutation that should change URL/history or redirect after completion: `<Form method=\"post\">`.\n- Mutation that should keep the user on the same page: `useFetcher` / `<fetcher.Form>`.\n- Optimistic UI: derive from `fetcher.formData` or `navigation.formData`.\n\n## Navigation and URL State\n\nBefore changing navigation or search params, read:\n\n```txt\nreact-router/docs/start/data/navigating.md\nreact-router/docs/how-to/search-params.md\nreact-router/docs/explanation/location.md\n```\n\nRules:\n\n- Use `<Link>`/`<NavLink>` for user-initiated internal navigation.\n- Use `redirect` in loaders/actions when navigation follows data loading or mutations.\n- Use `useNavigate` for imperative client-side event navigation.\n- Treat URL params as strings and validate/parse them.\n- Preserve unrelated search params unless intentionally resetting them.\n\n## SSR in Data Mode\n\nData Mode SSR is manual and lower-level than Framework Mode. Before implementing or changing SSR, read the Data Mode custom/SSR docs and match existing server abstractions.\n\nStart with:\n\n```txt\nreact-router/docs/start/data/custom.md\n```\n\nLook for APIs like `createStaticHandler`, `createStaticRouter`, `StaticRouterProvider`, and hydration data handling in the current app before changing anything.\n\n## RSC Data\n\nIf this Data Mode app uses `unstable_RSCRouteConfig`, RSC route config, or low-level RSC server APIs, also read:\n\n```txt\nreferences/rsc.md\nreact-router/docs/how-to/react-server-components.md\n```\n","isInternal":false,"tokens":1070,"sizeBytes":4797},{"name":"declarative-mode.md","path":".agents/skills/react-router/references/declarative-mode.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/react-router/references/declarative-mode.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Declarative Mode\n\nDeclarative Mode is React Router's simplest mode. It uses router components like `<BrowserRouter>` and JSX routes with `<Routes>`/`<Route>`. It does not provide loaders, actions, fetchers, or data-router pending UI.\n\nUse this reference after the main skill identifies a Declarative Mode app.\n\n## Read the Local Docs by Mode\n\nStart with:\n\n```txt\nreact-router/docs/start/modes.md\nreact-router/docs/start/declarative/index.md\n```\n\nThen use the Declarative docs under:\n\n```txt\nreact-router/docs/start/declarative/\n```\n\nThose files cover installation, routing, navigation, and URL values. For conceptual details, read relevant files in:\n\n```txt\nreact-router/docs/explanation/\n```\n\nAlways check the `[MODES: declarative, ...]` marker in a doc before applying it.\n\n## Declarative Router Shape\n\nTypical setup:\n\n```tsx\nimport { BrowserRouter, Routes, Route } from \"react-router\";\n\nfunction App() {\n return (\n <BrowserRouter>\n <Routes>\n <Route path=\"/\" element={<Home />} />\n <Route path=\"about\" element={<About />} />\n <Route path=\"dashboard\" element={<DashboardLayout />}>\n <Route index element={<DashboardHome />} />\n <Route path=\"settings\" element={<Settings />} />\n </Route>\n </Routes>\n </BrowserRouter>\n );\n}\n```\n\nLook for APIs such as:\n\n- `<BrowserRouter>`\n- `<HashRouter>`\n- `<MemoryRouter>`\n- `<Routes>`\n- `<Route>`\n- `element={<Component />}`\n- `useRoutes`\n\n## Routing\n\nBefore editing routes, read:\n\n```txt\nreact-router/docs/start/declarative/routing.md\n```\n\nRules:\n\n- Use `<Routes>` and `<Route>` for route configuration.\n- Use nested routes with `<Outlet>` for shared layout.\n- Use index routes for default child UI.\n- Use route params and splats according to the declarative routing docs.\n- Do not add route object loaders/actions to a Declarative router.\n\n## Navigation\n\nBefore changing navigation, read:\n\n```txt\nreact-router/docs/start/declarative/navigating.md\n```\n\nRules:\n\n- Use `<Link>` or `<NavLink>` for user-initiated internal navigation.\n- Use `NavLink` when active styling matters.\n- Use `useNavigate` for imperative navigation from event handlers or effects.\n- Do not use plain `<a href>` for internal navigation unless intentionally forcing a full document navigation.\n\n## URL Values\n\nBefore changing params, search params, or location state, read:\n\n```txt\nreact-router/docs/start/declarative/url-values.md\nreact-router/docs/explanation/location.md\n```\n\nRules:\n\n- Use `useParams` for dynamic route params.\n- Use `useSearchParams` for query string state.\n- Use `useLocation` for the current location object and navigation state.\n- Validate and parse URL params; they are strings and can be absent.\n- Preserve unrelated search params unless intentionally resetting them.\n\n## Mode Boundary\n\nDeclarative Mode does not have Data/Framework APIs such as:\n\n- `loader`\n- `action`\n- `<Form>`\n- `useFetcher`\n- `useNavigation`\n- route module exports\n- generated `./+types` route types\n\nIf the user asks for route data loading, DB/API-backed data, CRUD, form mutations, validation returned from submissions, revalidation, pending UI, optimistic UI, or fetchers, recommend Data Mode or Framework Mode depending on how much structure they want. Ask before migrating unless they already requested it.\n","isInternal":false,"tokens":735,"sizeBytes":3284},{"name":"framework-mode.md","path":".agents/skills/react-router/references/framework-mode.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/react-router/references/framework-mode.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Framework Mode\n\nFramework Mode is React Router's full-stack mode. It uses the React Router Vite plugin, route config in `app/routes.ts`, route modules, generated route types, and rendering strategies such as SSR, SPA mode, and pre-rendering.\n\nUse this reference after the main skill identifies a Framework Mode app.\n\n## Read the Local Docs by Mode\n\nStart with:\n\n```txt\nreact-router/docs/start/modes.md\nreact-router/docs/start/framework/index.md\n```\n\nThen use the Framework docs under:\n\n```txt\nreact-router/docs/start/framework/\n```\n\nThose files cover installation, routing, route modules, data loading, actions, navigation, pending UI, rendering, deploying, and testing. For task-specific details, read relevant files in:\n\n```txt\nreact-router/docs/how-to/\nreact-router/docs/explanation/\n```\n\nAlways check the `[MODES: framework, ...]` marker in a doc before applying it.\n\n## Framework Shape\n\nExamples usually assume the default `appDirectory` of `app`. Check `react-router.config.ts` before assuming exact paths.\n\nLook for these files and conventions:\n\n```txt\nreact-router.config.ts\napp/root.tsx\napp/routes.ts\napp/routes/**/*.tsx\nroute modules importing from ./+types/...\n```\n\nTypical route module:\n\n```tsx\nimport type { Route } from \"./+types/product\";\n\nexport async function loader({ params }: Route.LoaderArgs) {\n return { product: await getProduct(params.productId) };\n}\n\nexport default function Product({ loaderData }: Route.ComponentProps) {\n return <h1>{loaderData.product.name}</h1>;\n}\n```\n\n## Route Configuration\n\nFramework apps use `app/routes.ts`. Many apps use file-system routing via `flatRoutes()`, but manual route config is also supported.\n\nBefore editing routes, read:\n\n```txt\nreact-router/docs/start/framework/routing.md\n```\n\nIf the app uses file-route conventions, read:\n\n```txt\nreact-router/docs/how-to/file-route-conventions.md\n```\n\n## Route Modules\n\nRoute modules are the main unit of Framework Mode. Before adding or changing route exports, read:\n\n```txt\nreact-router/docs/start/framework/route-module.md\n```\n\nCommon exports include:\n\n| Export | Use |\n| --------------------------------- | ------------------------------------------------------------------- |\n| `default` | Route component rendered for the match |\n| `loader` | Server data loading for SSR/pre-rendering/server data requests |\n| `clientLoader` | Browser-only data loading or supplementing server loader data |\n| `action` | Server mutation called by `<Form>`, `useSubmit`, or fetchers |\n| `clientAction` | Browser-only mutation or client-side wrapper around a server action |\n| `ErrorBoundary` | UI for errors thrown by this route's loaders/actions/component |\n| `HydrateFallback` | Initial fallback while client loader hydration runs |\n| `links` / `meta` | Route document links and metadata |\n| `handle` | Arbitrary route metadata consumed via `useMatches` |\n| `shouldRevalidate` | Overrides default loader revalidation behavior |\n| `middleware` / `clientMiddleware` | Server/client request pipeline hooks when enabled |\n\nUse generated `Route.*` types from `./+types/<route>` for route module args and props.\n\n## Layout and Root Route Rules\n\n- `app/root.tsx` is the root route and should contain global document/app shell concerns.\n- Put global providers, app-wide nav, app-wide footer, scripts/meta/links, and document structure in `root.tsx` when appropriate.\n- Use nested routes/layout routes for section-specific layouts.\n- Do not flatten routes that should share UI or data boundaries.\n\nUseful docs:\n\n```txt\nreact-router/docs/explanation/special-files.md\nreact-router/docs/start/framework/routing.md\n```\n\n## Data and Mutations\n\nBefore working on route data:\n\n```txt\nreact-router/docs/start/framework/data-loading.md\nreact-router/docs/start/framework/actions.md\n```\n\nFramework rules:\n\n- Load route data with `loader` or `clientLoader`.\n- Mutate route data with `action` or `clientAction`.\n- Prefer route loaders/actions over ad hoc `useEffect` fetching for route data.\n- Use `data()`/Responses and redirects according to the docs.\n- Let React Router revalidate after actions unless the docs point you to `shouldRevalidate`.\n- In SSR/server data routes, keep Node-only/database code in server-only modules and call it from `loader`/`action`, not from browser-rendered component code.\n\nCommon patterns:\n\n- Validation failure from an action: return `data({ errors, values }, { status: 400 })`, then render errors from `Route.ComponentProps[\"actionData\"]` or `fetcher.data`.\n- Missing record in a loader: throw `data(\"Not Found\", { status: 404 })` and render the route `ErrorBoundary`.\n- Search/filter data: parse the route request URL/search params in the loader so the URL is shareable and bookmarkable.\n\n## Forms, Fetchers, and Pending UI\n\nFor forms and pending UI, read:\n\n```txt\nreact-router/docs/start/framework/actions.md\nreact-router/docs/start/framework/pending-ui.md\nreact-router/docs/how-to/fetchers.md\nreact-router/docs/explanation/form-vs-fetcher.md\n```\n\nRules of thumb:\n\n- Search/filter form that updates the URL: `<Form method=\"get\">`.\n- Mutation that should change URL/history or redirect after completion: `<Form method=\"post\">`.\n- Mutation that should keep the user on the same page: `useFetcher` / `<fetcher.Form>`.\n- Optimistic UI: derive from `fetcher.formData` or `navigation.formData`.\n\n## Type Safety\n\nBefore changing generated route types or typed URL behavior, read:\n\n```txt\nreact-router/docs/how-to/route-module-type-safety.md\nreact-router/docs/explanation/type-safety.md\n```\n\nRules:\n\n- Import types from `./+types/<route>`.\n- Use `Route.LoaderArgs`, `Route.ActionArgs`, `Route.ComponentProps`, etc.\n- Use type-only imports where appropriate.\n- Do not edit generated `.react-router/types` files.\n\n## Metadata\n\nBefore changing `meta`, read:\n\n```txt\nreact-router/docs/how-to/meta.md\nreact-router/docs/start/framework/route-module.md\n```\n\nImportant: `meta` receives `loaderData`; do not use deprecated `data` args.\n\n## Rendering Strategy\n\nFramework Mode can be SSR, SPA, pre-rendered, or mixed depending on config and route behavior. Before changing rendering behavior, read:\n\n```txt\nreact-router/docs/start/framework/rendering.md\nreact-router/docs/how-to/spa.md\nreact-router/docs/how-to/pre-rendering.md\nreact-router/docs/explanation/hydration.md\n```\n\n## Middleware, Sessions, and Auth\n\nBefore implementing middleware or auth/session flows, read:\n\n```txt\nreact-router/docs/how-to/middleware.md\nreact-router/docs/explanation/sessions-and-cookies.md\n```\n\nMiddleware and context APIs are version/config sensitive. Check the installed React Router version and the app's `react-router.config.ts` before implementing.\n\n## RSC Framework\n\nIf this Framework app uses `unstable_reactRouterRSC` or `@vitejs/plugin-rsc`, also read:\n\n```txt\nreferences/rsc.md\nreact-router/docs/how-to/react-server-components.md\n```\n","isInternal":false,"tokens":1534,"sizeBytes":7271},{"name":"rsc.md","path":".agents/skills/react-router/references/rsc.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/react-router/references/rsc.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# React Server Components (RSC)\n\nReact Router's RSC support is unstable and exists in two variants:\n\n- **RSC Framework Mode**: Framework Mode with the unstable RSC Vite plugin.\n- **RSC Data Mode**: lower-level RSC runtime APIs and manual bundler/server integration.\n\nUse this reference in addition to `framework-mode.md` or `data-mode.md` after the main skill identifies an RSC app.\n\n## Read the Local RSC Docs\n\nStart with:\n\n```txt\nreact-router/docs/how-to/react-server-components.md\n```\n\nThen read the relevant base mode docs:\n\n```txt\nreact-router/docs/start/framework/\nreact-router/docs/start/data/\n```\n\nRSC docs may describe differences from non-RSC mode rather than repeating every Framework/Data concept, so keep both layers in mind.\n\n## Detect RSC Framework Mode\n\nLook for:\n\n- `unstable_reactRouterRSC` imported from `@react-router/dev/vite`\n- `@vitejs/plugin-rsc`\n- `vite.config.ts` with `plugins: [reactRouterRSC(), rsc()]`\n- Framework route modules plus RSC route exports\n- RSC entry files such as `entry.rsc`\n\nRSC Framework Mode uses a different Vite plugin from non-RSC Framework Mode. Do not swap it for the regular `reactRouter()` plugin.\n\n## Detect RSC Data Mode\n\nLook for:\n\n- `unstable_RSCRouteConfig`\n- route config passed to lower-level RSC APIs\n- APIs such as `unstable_matchRSCServerRequest`, `unstable_routeRSCServerRequest`, `unstable_RSCHydratedRouter`, or `unstable_RSCStaticRouter`\n- custom bundler/server setup around RSC\n\nRSC Data Mode is more manual than RSC Framework Mode. Match the app's bundler and server abstractions before changing routes or entries.\n\n## RSC Route Module Differences\n\nIn RSC Framework Mode, many normal Framework Mode concepts still apply, but routes can use server component exports.\n\nImportant route-module concepts from the RSC docs include:\n\n- `ServerComponent` instead of the usual client `default` component\n- `ServerErrorBoundary` paired with `ErrorBoundary`\n- `ServerLayout` paired with `Layout`\n- `ServerHydrateFallback` paired with `HydrateFallback`\n- server-rendered React elements returned from loaders/actions\n\nA route module cannot export both the normal client component and its server component counterpart for the same role. Read the RSC docs before adding these exports.\n\n## Client/Server Boundaries\n\nRSC code must respect React's client/server split:\n\n- Use `\"use client\"` for components that need hooks, browser APIs, or event handlers.\n- Use server-only modules for server data access and secrets.\n- In RSC Framework Mode, prefer the `server-only` and `client-only` boundary imports described in the docs.\n- Do not assume `.server`/`.client` file naming works the same way in RSC Framework Mode; read the RSC docs before relying on those conventions.\n\n## Data Loading in RSC\n\nRSC changes where data can be loaded:\n\n- Server Components can fetch data directly on the server.\n- Loaders/actions may still exist and can have RSC-specific behavior.\n- Client components still need client-safe data and cannot directly access server-only modules.\n\nWhen choosing between a server component fetch, a loader, and a client loader/action, follow the RSC docs and match existing app patterns.\n\n## Stability\n\nRSC APIs are explicitly unstable. Before implementing or refactoring RSC code:\n\n- Check the installed React Router version.\n- Check the installed `@vitejs/plugin-rsc` version.\n- Read the app's existing RSC entry/config files.\n- Prefer minimal changes that match current patterns.\n","isInternal":false,"tokens":777,"sizeBytes":3447},{"name":"SKILL.md","path":".agents/skills/react-router/SKILL.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/react-router/SKILL.md","title":"react-router","category":"anthropic-skill","format":"markdown","content":"---\nname: react-router\ndescription: Build applications with React Router in Framework, Data, Declarative, and unstable RSC modes. Use when configuring routes, route modules, loaders, actions, forms, fetchers, navigation, pending UI, SSR/SPA/pre-rendering, middleware, URL params/search params, or React Router upgrades.\nlicense: MIT\n---\n\n# React Router\n\nReact Router is mode-specific. Before changing an app, identify the mode, load the matching reference, then read the installed docs for the installed package version.\n\n## Identify the Mode\n\nDo not apply Framework/Data patterns to a Declarative app unless you are intentionally migrating modes.\n\n### Framework Mode\n\nUse Framework Mode guidance when you see:\n\n- `@react-router/dev` in dependencies\n- `react-router.config.ts`\n- `app/routes.ts`\n- `app/entry.server.tsx` and/or `app/entry.client.tsx` files\n- route modules under `app/routes/`\n- route exports like `loader`, `action`, `clientLoader`, `clientAction`, `ErrorBoundary`, `meta`, `links`, or `headers`\n- imports from `./+types/...`\n- the React Router Vite plugin from `@react-router/dev/vite`\n\nFramework examples usually use the default `app/` directory, but check `react-router.config.ts` for a custom `appDirectory` before assuming exact paths.\n\nThen read `references/framework-mode.md`.\n\n### Data Mode\n\nUse Data Mode guidance when you see:\n\n- `createBrowserRouter`, `createHashRouter`, `createMemoryRouter`, or `createStaticRouter`\n- `<RouterProvider router={router}>`\n- route objects with properties like `path`, `children`, `loader`, `action`, `Component`, `ErrorBoundary`, or `lazy`\n- data APIs without the Framework Vite plugin\n\nThen read `references/data-mode.md`.\n\n### Declarative Mode\n\nUse Declarative Mode guidance when you see:\n\n- `<BrowserRouter>`, `<HashRouter>`, or `<MemoryRouter>`\n- `<Routes>` and `<Route>` JSX route configuration\n- route components passed with `element={<Component />}`\n- no data router, no route module convention, and no loaders/actions\n\nThen read `references/declarative-mode.md`.\n\n### RSC Framework and RSC Data Modes\n\nReact Server Components support is unstable and exists in both Framework and Data variants. Use RSC guidance when you see:\n\n- `unstable_reactRouterRSC`\n- `@vitejs/plugin-rsc`\n- `unstable_RSCRouteConfig`\n- RSC entry files such as `entry.rsc`\n- `ServerComponent`, `ServerErrorBoundary`, `ServerLayout`, or `ServerHydrateFallback`\n- React directives or boundary packages such as `\"use client\"`, `\"server-only\"`, or `\"client-only\"`\n\nFor RSC Framework, read both `references/framework-mode.md` and `references/rsc.md`.\nFor RSC Data, read both `references/data-mode.md` and `references/rsc.md`.\n\n## Use Installed Docs as Source of Truth\n\nReact Router ships markdown docs in the package so guidance can match the installed version:\n\n```txt\nnode_modules/react-router/docs/\n```\n\nKey docs paths:\n\n```txt\nnode_modules/react-router/docs/index.md\nnode_modules/react-router/docs/start/\nnode_modules/react-router/docs/how-to/\nnode_modules/react-router/docs/explanation/\nnode_modules/react-router/docs/upgrading/\n```\n\nWhen this skill references `react-router/docs/...`, read the matching file under `node_modules/react-router/docs/`. If the installed version does not include local docs, use the repo `docs/` directory when working inside the React Router repository; in a consuming app, fall back to version-matched website docs.\n\nMost docs include a mode marker near the top:\n\n```txt\n[MODES: framework, data, declarative]\n```\n\nOnly apply a doc when its mode marker matches the app mode. If a task spans modes, prefer the section or file that matches the current app.\n\nRSC is documented primarily in:\n\n```txt\nnode_modules/react-router/docs/how-to/react-server-components.md\n```\n\n## Skill References\n\nLoad the relevant reference after identifying the mode:\n\n| Reference | Use When |\n| -------------------------------- | --------------------------------------------- |\n| `references/framework-mode.md` | Framework Mode or RSC Framework base behavior |\n| `references/data-mode.md` | Data Mode or RSC Data base behavior |\n| `references/declarative-mode.md` | Declarative Mode |\n| `references/rsc.md` | Any unstable RSC app |\n\n## Mode Migration Doc Index\n\nIf the user explicitly asks to switch modes, read the target mode reference plus the migration-relevant docs:\n\n| Migration | Docs to read |\n| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Declarative → Data | `react-router/docs/start/modes.md`, `react-router/docs/start/data/routing.md`, `react-router/docs/start/data/data-loading.md`, `react-router/docs/start/data/actions.md` |\n| Declarative/Data → Framework | `react-router/docs/start/modes.md`, `react-router/docs/start/framework/routing.md`, `react-router/docs/start/framework/route-module.md`, `react-router/docs/how-to/route-module-type-safety.md` |\n| Framework SPA/SSR/pre-render changes | `react-router/docs/start/framework/rendering.md`, `react-router/docs/how-to/spa.md`, `react-router/docs/how-to/pre-rendering.md`, `react-router/docs/start/framework/data-loading.md`, `react-router/docs/start/framework/actions.md` |\n| Future flags/upgrades | `react-router/docs/upgrading/future.md` and relevant files under `react-router/docs/upgrading/` |\n","frontmatter":{"name":"react-router","description":"Build applications with React Router in Framework, Data, Declarative, and unstable RSC modes. Use when configuring routes, route modules, loaders, actions, forms, fetchers, navigation, pending UI, SSR/SPA/pre-rendering, middleware, URL params/search params, or React Router upgrades.","license":"MIT"},"isInternal":false,"tokens":1189,"sizeBytes":6104},{"name":"openai.yaml","path":".agents/skills/sc-summary/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/sc-summary/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"interface:\n display_name: \"SC Summary\"\n short_description: \"Summarize React Router Steering Committee meetings\"\n default_prompt: \"Use $sc-summary with the meeting notes location I provide to update GOVERNANCE.md.\"\n","isInternal":false,"tokens":47,"sizeBytes":217},{"name":"SKILL.md","path":".agents/skills/sc-summary/SKILL.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.agents/skills/sc-summary/SKILL.md","title":"sc-summary","category":"anthropic-skill","format":"markdown","content":"---\nname: sc-summary\ndescription: Summarize React Router Steering Committee meeting notes from a user-provided location in GOVERNANCE.md. Use when asked to add or revise Steering Committee meeting summaries.\n---\n\n# Steering Committee Meeting Summaries\n\nUse the notes folder or files the user supplies in the request or current conversation. If no source location is available, ask for it. Write to the repository's `GOVERNANCE.md`, under **Meeting Notes**.\n\n1. Read the existing Meeting Notes entries and list the files at the supplied location. Summarize the requested dates or files. If the user gives no date or quantity, choose the earliest meeting without an entry and do one meeting for review. Do not duplicate an existing entry unless asked to revise it.\n2. Read each entire source note, especially the details. Resolve repeated or inconsistent points before writing. Treat proposed ideas, decisions, and suggested next steps distinctly; do not present an unconfirmed proposal as an agreed decision.\n3. Write a public-facing, high-level summary of React Router discussion only. Omit unrelated conversation and banter. Refer to participants by first name. Follow the existing `<details>` format and prose in `GOVERNANCE.md`; use short topical headings when useful. Match the depth of existing entries, adjusted to how much substantive discussion occurred.\n4. Insert each entry near the other meeting dates, preserve unrelated content, then review the diff against the source and run `git diff --check`. Show the new or revised entries to the user. Do not post them to GitHub, commit, or publish unless requested.\n","frontmatter":{"name":"sc-summary","description":"Summarize React Router Steering Committee meeting notes from a user-provided location in GOVERNANCE.md. Use when asked to add or revise Steering Committee meeting summaries."},"isInternal":false,"tokens":321,"sizeBytes":1620},{"name":"SKILL.md","path":".github/skills/agentic-workflows/SKILL.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/.github/skills/agentic-workflows/SKILL.md","title":"agentic-workflows","category":"anthropic-skill","format":"markdown","content":"---\nname: agentic-workflows\ndescription: Route gh-aw workflow design/create/debug/upgrade requests to the right prompts.\n---\n\n# Agentic Workflows Router\n\nUse this skill when a user asks to design, create, update, debug, or upgrade GitHub Agentic Workflows in this repository.\n\nThis skill is a dispatcher: identify the task type, load the matching workflow prompt/skill file, and follow it directly. Keep responses concise and ask a clarifying question if the correct prompt is unclear.\n\nRepository overlay (optional):\n\n- If `.github/aw/instructions.md` exists, load it with `@.github/aw/instructions.md` after loading the matched prompt/skill.\n- Precedence: repository overlay instructions override upstream defaults when they conflict.\n\nRead only the files you need:\nLoad these files from `github/gh-aw` (they are not available locally).\n\n- `.github/aw/action-container-substitutions.md`\n- `.github/aw/agent-runtime-instructions.md`\n- `.github/aw/agentic-chat.md`\n- `.github/aw/agentic-workflows-mcp.md`\n- `.github/aw/asciicharts.md`\n- `.github/aw/campaign.md`\n- `.github/aw/charts-trending.md`\n- `.github/aw/charts.md`\n- `.github/aw/cli-commands.md`\n- `.github/aw/configure-agentic-engine.md`\n- `.github/aw/context.md`\n- `.github/aw/create-agentic-workflow-trigger-details.md`\n- `.github/aw/create-agentic-workflow.md`\n- `.github/aw/create-shared-agentic-workflow.md`\n- `.github/aw/debug-agentic-workflow.md`\n- `.github/aw/dependabot.md`\n- `.github/aw/deployment-status.md`\n- `.github/aw/designer-mappings.md`\n- `.github/aw/designer.md`\n- `.github/aw/evals.md`\n- `.github/aw/experiments.md`\n- `.github/aw/github-agentic-workflows.md`\n- `.github/aw/github-mcp-server-pagination.md`\n- `.github/aw/github-mcp-server.md`\n- `.github/aw/instructions.md`\n- `.github/aw/linter-workflows.md`\n- `.github/aw/llms.md`\n- `.github/aw/loop.md`\n- `.github/aw/lsp.md`\n- `.github/aw/maintainer.md`\n- `.github/aw/mcp-clis.md`\n- `.github/aw/memory-stateful-patterns.md`\n- `.github/aw/memory.md`\n- `.github/aw/messages.md`\n- `.github/aw/multi-agent-research.md`\n- `.github/aw/network.md`\n- `.github/aw/optimize-agentic-workflow.md`\n- `.github/aw/patterns.md`\n- `.github/aw/pr-reviewer.md`\n- `.github/aw/release-workflow.md`\n- `.github/aw/report.md`\n- `.github/aw/reuse.md`\n- `.github/aw/safe-outputs-automation.md`\n- `.github/aw/safe-outputs-content.md`\n- `.github/aw/safe-outputs-management.md`\n- `.github/aw/safe-outputs-runtime.md`\n- `.github/aw/safe-outputs.md`\n- `.github/aw/serena-tool.md`\n- `.github/aw/shared-safe-jobs.md`\n- `.github/aw/skills.md`\n- `.github/aw/subagents.md`\n- `.github/aw/syntax-agentic.md`\n- `.github/aw/syntax-core.md`\n- `.github/aw/syntax-engine.md`\n- `.github/aw/syntax-tools-imports.md`\n- `.github/aw/syntax.md`\n- `.github/aw/test-coverage.md`\n- `.github/aw/test-expression.md`\n- `.github/aw/token-optimization-caching-budgets.md`\n- `.github/aw/token-optimization-observability.md`\n- `.github/aw/token-optimization.md`\n- `.github/aw/triggers.md`\n- `.github/aw/update-agentic-workflow.md`\n- `.github/aw/upgrade-agentic-workflows.md`\n- `.github/aw/visual-regression.md`\n- `.github/aw/workflow-constraints.md`\n- `.github/aw/workflow-editing.md`\n- `.github/aw/workflow-patterns.md`\n\nAfter loading the matching workflow prompt or skill, follow it directly:\n\n- Design workflows from scratch via interview: `.github/aw/designer.md`\n- Create new workflows: `.github/aw/create-agentic-workflow.md`\n- Configure or add declarative engines: `.github/aw/configure-agentic-engine.md`\n- Update existing workflows: `.github/aw/update-agentic-workflow.md`\n- Debug, audit, or investigate workflows: `.github/aw/debug-agentic-workflow.md`\n- Upgrade workflows and fix deprecations: `.github/aw/upgrade-agentic-workflows.md`\n- Create shared components or MCP wrappers: `.github/aw/create-shared-agentic-workflow.md`\n- Create report-generating workflows: `.github/aw/report.md`\n- Fix Dependabot manifest PRs: `.github/aw/dependabot.md`\n- Analyze coverage workflows: `.github/aw/test-coverage.md`\n- Render compact markdown charts: `.github/aw/asciicharts.md`\n- Map CLI commands to MCP usage: `.github/aw/cli-commands.md`\n- Choose workflow architecture and patterns: `.github/aw/patterns.md`\n- Optimize token usage and cost: `.github/aw/token-optimization.md`\n- Design long-running multi-agent research workflows: `.github/aw/multi-agent-research.md`\n\nWhen the task involves OTEL, OTLP, traces, observability backends, or telemetry-driven analysis, also read and follow `skills/otel-queries/SKILL.md` after loading the matching workflow prompt or skill.\n","frontmatter":{"name":"agentic-workflows","description":"Route gh-aw workflow design/create/debug/upgrade requests to the right prompts."},"isInternal":false,"tokens":1232,"sizeBytes":4542},{"name":"README.md","path":"packages/create-react-router/README.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/packages/create-react-router/README.md","title":"create-react-router Documentation","category":"plugin-manifest","format":"markdown","content":"Create a new React Router app.\n\n```sh\nnpm create react-router\n```\n","isInternal":false,"tokens":17,"sizeBytes":66},{"name":"README.md","path":"packages/react-router-architect/README.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/packages/react-router-architect/README.md","title":"react-router-architect Documentation","category":"plugin-manifest","format":"markdown","content":"[Architect](https://arc.codes) server request handler for React Router.\n\n```bash\nnpm install @react-router/architect\n```\n","isInternal":false,"tokens":29,"sizeBytes":121},{"name":"README.md","path":"packages/react-router-cloudflare/README.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/packages/react-router-cloudflare/README.md","title":"react-router-cloudflare Documentation","category":"plugin-manifest","format":"markdown","content":"Cloudflare platform abstractions for React Router\n\n```bash\nnpm install @react-router/cloudflare @cloudflare/workers-types\n```\n","isInternal":false,"tokens":28,"sizeBytes":126},{"name":"README.md","path":"packages/react-router-dev/README.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/packages/react-router-dev/README.md","title":"react-router-dev Documentation","category":"plugin-manifest","format":"markdown","content":"Dev tools and CLI for React Router that enables framework features through bundler integration like server rendering, code splitting, HMR, etc.\n\n```sh\nnpm install @react-router/dev --save-dev\n```\n","isInternal":false,"tokens":42,"sizeBytes":196},{"name":"README.md","path":"packages/react-router-express/README.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/packages/react-router-express/README.md","title":"react-router-express Documentation","category":"plugin-manifest","format":"markdown","content":"[Express](https://expressjs.com) server request handler for React Router.\n\n```sh\nnpm install @react-router/express\n```\n","isInternal":false,"tokens":29,"sizeBytes":119},{"name":"README.md","path":"packages/react-router-fs-routes/README.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/packages/react-router-fs-routes/README.md","title":"react-router-fs-routes Documentation","category":"plugin-manifest","format":"markdown","content":"File system routing conventions for React Router\n\n```sh\nnpm install @react-router/fs-routes\n```\n","isInternal":false,"tokens":22,"sizeBytes":96},{"name":"README.md","path":"packages/react-router-node/README.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/packages/react-router-node/README.md","title":"react-router-node Documentation","category":"plugin-manifest","format":"markdown","content":"Node.js platform abstractions for React Router\n\n```sh\nnpm install @react-router/node\n```\n","isInternal":false,"tokens":21,"sizeBytes":89},{"name":"README.md","path":"packages/react-router-remix-routes-option-adapter/README.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/packages/react-router-remix-routes-option-adapter/README.md","title":"react-router-remix-routes-option-adapter Documentation","category":"plugin-manifest","format":"markdown","content":"# @react-router/remix-routes-option-adapter\n\nAdapter for [Remix's](https://remix.run) `routes` config option, for use within `routes.ts`.\n\n```sh\nnpm install @react-router/remix-routes-option-adapter\n```\n","isInternal":false,"tokens":56,"sizeBytes":203},{"name":"README.md","path":"packages/react-router-serve/README.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/packages/react-router-serve/README.md","title":"react-router-serve Documentation","category":"plugin-manifest","format":"markdown","content":"Node.js application server for React Router\n\n```sh\nnpm install @react-router/serve\n```\n","isInternal":false,"tokens":21,"sizeBytes":87},{"name":"README.md","path":"packages/react-router/README.md","rawUrl":"https://raw.githubusercontent.com/remix-run/react-router/HEAD/packages/react-router/README.md","title":"react-router Documentation","category":"plugin-manifest","format":"markdown","content":"`react-router` is the primary package in the React Router project.\n\n## Installation\n\n```sh\nnpm i react-router\n```\n","isInternal":false,"tokens":27,"sizeBytes":114},{"name":".cursorrules","path":".cursorrules (react-router-v7.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/react-router-v7.mdc","title":"React Router v7 rules for framework mode, data routers, loaders, actions, route modules, and progressive enhancement","category":"cursor-rule","format":"markdown","content":"# React Router v7 Rules\n\n## Route Modules\n\n- Use route modules as the boundary for route UI, loader data, actions, metadata, and error boundaries.\n- Keep route modules small; move shared UI to components and reusable data access to services.\n- Prefer file-based routing in framework mode when the project is configured for it.\n- Use nested routes for shared layouts and progressive disclosure.\n- Export route-specific `ErrorBoundary` components for recoverable route failures.\n\n## Data Loading\n\n- Use loaders for route data that should be available before render.\n- Keep loaders deterministic and side-effect free.\n- Validate params and search params at the loader boundary.\n- Return typed data and consume it through route hooks rather than duplicating fetch logic in components.\n- Use deferred or streaming patterns only when they improve perceived performance.\n\n## Mutations\n\n- Use actions for route mutations and form submissions.\n- Prefer `Form`, `useFetcher`, and `useSubmit` for progressive enhancement.\n- Revalidate affected loader data after mutations.\n- Handle validation errors as typed action data instead of generic exceptions.\n- Keep server-only secrets and privileged operations out of client actions.\n\n## Navigation and State\n\n- Store shareable state in URL params or search params.\n- Keep ephemeral UI state local to components.\n- Use pending navigation state to show optimistic or loading UI.\n- Avoid global state for data that belongs to route loaders.\n\n## TypeScript and Testing\n\n- Type loader and action return values.\n- Add tests for route loaders, actions, validation failures, and error boundaries.\n- Use integration tests for critical form and navigation flows.\n- Mock network and persistence at the route-service boundary.\n\n## Common Mistakes\n\n- Do not duplicate loader fetches in `useEffect`.\n- Do not mutate data in loaders.\n- Do not hide route errors behind a single generic app-level catch-all.\n- Do not put auth checks only in components when loader data is protected.","frontmatter":{"description":"React Router v7 rules for framework mode, data routers, loaders, actions, route modules, and progressive enhancement","globs":["app/routes/**/*","src/routes/**/*","routes/**/*","react-router.config.*","vite.config.*","**/*.tsx","**/*.ts"],"alwaysApply":false},"tokens":458,"sizeBytes":1999}],"systemPromptSnippet":"<yakaai_skills repo=\"remix-run/react-router\">\n<!-- File: AGENTS.md (Tokens: ~1802 | Category: root-instruction) -->\n# React Router Development Guide\n\n## Commands\n\n- **Build**: `pnpm build` (all packages) or `pnpm run --filter <package> build` (single package)\n- **Test (Jest)**: `pnpm test` (all packages), `pnpm test packages/<package>/` (single package), `pnpm test packages/react-router/__tests__/router/fetchers-test.ts` (single file), or `pnpm test -- -t \"action fetch\"` (tests matching name)\n- **Integration tests (Playwright)**: `pnpm test:integration --project chromium` (build + test all), `pnpm test:integration:run --project chromium` (test only, all), `pnpm test:integration:run integration/middleware-test.ts --project chromium` (single file), or `pnpm test:integration:run --project chromium -g \"middleware\"` (tests matching name)\n- **Typecheck**: `pnpm run typecheck`\n- **Lint**: `pnpm run lint`\n- **Docs generation**: `pnpm run docs` (regenerates API docs from JSDoc)\n- **Type generation**: `pnpm run typegen` (Framework Mode only)\n- **Clean**: `pnpm run clean` (git clean -fdX)\n\n## Modes\n\n**Five distinct modes**: Declarative, Data, Framework, RSC Data (unstable), RSC Framework (unstable). **Always identify which mode(s) a feature applies to.**\n\n1. **Declarative**: `<BrowserRouter>`, `<Routes>`, `<Route>`\n2. **Data**: `createBrowserRouter()` with `loader`/`action`, `<RouterProvider>`\n3. **Framework**: Vite plugin + `routes.ts` + Route Module API (route exports like `loader`, `action`, `default`) + type generation + SSR/SPA\n4. **RSC Data** (unstable): RSC runtime APIs, manual bundler setup, runtime route config\n5. **RSC Framework** (unstable): Framework Mode with `unstable_reactRouterRSC` Vite plugin\n\n**RSC mode differences:**\n\n- **RSC Framework**: `unstable_reactRouterRSC` plugin, `@vitejs/plugin-rsc`, different entry points/format\n- **RSC Data**: Manual bundler, runtime route config typically in `src/routes.ts`, `unstable_RSCRouteConfig`, different runtime APIs, `setupRscTest` in `integration/rsc/`\n\n## Architecture\n\n- **Monorepo**: pnpm workspace, packages in `packages/`\n- **Key packages**:\n - `react-router`: Core (all modes) - `lib/components.tsx`, `lib/hooks.tsx`, `lib/router/`, `lib/dom/`, `lib/rsc/`\n - `@react-router/dev`: Framework tooling - `vite/plugin.ts` (Framework), `vite/rsc/plugin.ts` (RSC Framework), `typegen/`\n - `@react-router/node`, `@react-router/cloudflare`, `@react-router/express`: Server adapters\n - `@react-router/serve`: Minimal server for Framework Mode\n - `@react-router/fs-routes`: File-system routing (`flatRoutes()`)\n\n## Testing\n\n### Unit Tests (`packages/react-router/__tests__/`)\n\nUse Jest for pure routing logic, pure server runtime behavior, router state, React component behavior. No build required.\n\n```bash\npnpm test # All packages\npnpm test packages/react-router/ # Single package\npnpm test packages/react-router/__tests__/router/fetchers-test.ts # Single file\npnpm test -- -t \"action fetch\" # Tests matching name\n```\n\n### Integration Tests (`integration/`)\n\nUse Playwright for Vite plugin, build pipeline, SSR/hydration, RSC, type generation.\n\n```bash\npnpm test:integration --project chromium # Build + test all\npnpm test:integration:run --project chromium # Test only, all\npnpm test:integration:run integration/middleware-test.ts --project chromium # Single file\npnpm test:integration:run --project chromium -g \"middleware\" # Tests matching name\n```\n\n**Project**: Always use `chromium` for integration tests, unless explicitly stated otherwise.\n\n**Rebuild when**: First run, after changing `packages/` (not needed for test-only changes)\n\n**Organization**: Use `createFixture()` → `createAppFixture()` → `PlaywrightFixture`. Templates available: `vite-6-template/`, `rsc-vite-framework/`, etc. Test all applicable modes (iterate over template array when behavior should work across modes). Test both states when introducing future flags (one test with flag on, one with flag off).\n\n**RSC testing**:\n\n- **RSC Framework**: Use `createFixture` with `rsc-vite-framework/` template\n- **RSC Data**: Use `setupRscTest` in `integration/rsc/`\n\nTest shared behavior across multiple templates (e.g., `[\"vite-5-template\", \"rsc-vite-framework\"]`). Test RSC-specific features against RSC template.\n\n## routes.ts\n\nFramework Mode uses `routes.ts` in `app/`. Most tests use `flatRoutes()` for file-system routing:\n\n```ts\n// app/routes.ts\nimport { type RouteConfig } from \"@react-router/dev/routes\";\nimport { flatRoutes } from \"@react-router/fs-routes\";\n\nexport default flatRoutes() satisfies RouteConfig;\n```\n\n**File-system conventions** (`app/routes/`):\n\n- `_index.tsx` → `/` (index route)\n- `about.tsx` → `/about`\n- `blog.$slug.tsx` → `/blog/:slug` (URL param)\n- `settings.profile.tsx` → `/settings/profile` (`.` creates nesting)\n- `_layout.tsx` → pathless layout route\n\n**Manual config alternative**:\n\n```ts\nimport { index, route, layout } from \"@react-router/dev/routes\";\nexport default [\n index(\"./home.tsx\"),\n route(\"about\", \"./about.tsx\"),\n layout(\"./auth-layout.tsx\", [route(\"login\", \"./login.tsx\")]),\n];\n```\n\n## Documentation\n\n**Don't edit generated files**: `docs/api/` (from JSDoc), `.react-router/types/` (from typegen)\n\n**Mode indicators**: Every doc needs `[MODES: framework, data, declarative]`\n\n**API docs**: Edit JSDoc in `packages/react-router/lib/`, run `pnpm docs`\n\n**Unstable features**: Prefix `unstable_`, add `unstable: true` to frontmatter, include warning block\n\n## Future Flags\n\n- **Future flags** (`vX_*`): Stable breaking changes for next major\n- **Unstable flags** (`unstable_*`): Experimental, may change\n\nTest both states (on/off) for future flags. Don't break existing behavior without a flag.\n\n## License\n\nBy contributing to React Router, you agree that your contributions will be licensed under the [MIT License](./LICENSE.md).\n\n## Change Files\n\nWhen making changes that affect users, create a change file at `packages/<package>/.changes/<type>.<unique-meaningful-name>.md`. `<type>` should be either `patch`, `minor`, `major` or `unstable` to indicate the type of API change being made. If iterating on a change that hasn't shipped yet, update the existing change file instead of creating a new one.\n\nFormat:\n\n```markdown\nBrief description of the change\n\n- Additional details if needed\n```\n\n## Branching\n\n- **`main`**: Active Development\n- **`v7`**: v7.x maintenance\n- **`v6`**: v6.x maintenance\n- Branch from `main` for code and docs changes\n\n## Key Files\n\n| Purpose | Location |\n| ----------------- | ----------------------------------------------------------- |\n| Router | `packages/react-router/lib/router/router.ts` |\n| React API | `packages/react-router/lib/components.tsx`, `lib/hooks.tsx` |\n| Vite plugin | `packages/react-router-dev/vite/plugin.ts` |\n| RSC Vite plugin | `packages/react-router-dev/vite/rsc/plugin.ts` |\n| Type generation | `packages/react-router-dev/typegen/` |\n| Unit tests | `packages/react-router/__tests__/` |\n| Integration tests | `integration/` |\n| Decision docs | `decisions/` |\n\n<!-- File: CLAUDE.md (Tokens: ~219 | Category: claude-rule) -->\n# React Router Project Instructions\n\n## Session Start\n\n**REQUIRED**: Read [./AGENTS.md](./AGENTS.md) at the start of every session. It contains:\n\n- Project architecture and key files\n- React Router modes (Declarative, Data, Framework, RSC)\n- Build/test commands (Jest unit tests, Playwright integration tests with `--project chromium`)\n- Testing patterns and conventions\n- Documentation guidelines\n\n### Skills\n\nIf there is an [`.agents/skills`](.agents/skills) directory in the repository, symlink those skills to `.claude/skills` to make sure they are made available to Claude. Refresh you list of available skills if needed. This is a git ignored directory because we want to keep the canonical skills in `.agents/skills`.\n\n## During Work\n\n**Always consult AGENTS.md** when you need to:\n\n- Run tests or builds\n- Understand which mode(s) a feature applies to\n- Find key file locations\n- Understand testing patterns\n\nDo not guess at commands - reference AGENTS.md for the correct syntax.\n\n<!-- File: .agents/skills/create-pr/SKILL.md (Tokens: ~1904 | Category: anthropic-skill) -->\n---\nname: create-pr\ndescription: Create and package React Router pull requests. Use when the user asks to create, open, prepare, or finish a PR for this repository, including branch/commit/push handoff, draft PR creation, PR body writing, and applying GitHub labels such as pkg:*, feat:*, docs, github-actions, or dependencies.\n---\n\n# Create React Router PR\n\nCreate the pull request handoff for completed React Router work. Default to a draft PR targeting `main` unless the user explicitly asks for a ready PR or a different base branch.\n\n## Preconditions\n\n- Inspect `git status --short --branch` and `git branch --show-current`.\n- Do not include unrelated dirty files. If unrelated changes are present, leave them unstaged and mention them.\n- If the worktree is detached, create a branch from the current `HEAD` before committing. Use the branch name requested by the user, an existing repository convention, or `<author>/<semantic-name>` when no stronger convention is available.\n- If already on a suitable named branch, use it.\n- Confirm appropriate automated coverage exists or was added. Do not list routine CI-covered checks in the PR body.\n- If user-facing functionality is being updated, check that the appropriate package has a change file under `packages/<package>/.changes/`. This is not necessary for docs-only, GitHub Actions/workflow-only, or dependency-maintenance PRs unless the dependency change itself has user-facing impact.\n\n## Context\n\n- Capture what changed, why it changed, and who it affects.\n- Find related issues, discussions, or PRs and include links when relevant.\n- Prefer `git diff --stat` plus focused `git diff` over broad repo archaeology when the change is small.\n- If the user supplies a report, issue, discussion, or related PR, treat that as the primary context source.\n- For new feature work, include a concise usage snippet. If the feature replaces or improves an older approach, include before/after examples when they help reviewers.\n\n## Commit and Push\n\n1. Review the diff with `git diff --stat` and focused `git diff` as needed.\n2. Stage only the intended files.\n3. Commit with a concise imperative subject.\n4. Push the branch before creating the PR.\n\n## PR Creation\n\nSave the PR body to a temporary file, then use `gh pr create` with:\n\n```sh\ngh pr create --draft --base main --head <branch> --title \"<title>\" --body-file <file>\n```\n\n- Omit `--draft` only when the user explicitly asks for a ready PR.\n- Change `--base` only when the user explicitly requests a different base branch.\n- Keep shell quoting simple. Prefer a body file if the body contains backticks, quotes, or multiple paragraphs.\n- Include issue/discussion links when known. Use `Closes #NNNN` for bug fixes the PR should close; use `Implements #NNNN` or a plain link for RFCs/discussions when closing semantics are not appropriate.\n- Include testing notes only for manual checks, unusual verification, skipped non-CI checks, or failures that reviewers should know about.\n- If `gh pr create` fails, leave the branch pushed when possible and give the user a ready-to-open compare URL plus the prepared title and body.\n\nRecommended PR body shape:\n\n````markdown\nThis change ...\n\n- Optional extra detail when useful.\n\n```tsx\n// Optional feature usage example\n```\n````\n\n```tsx\n// Optional before/after example\n```\n\n**Testing**\n\n- Optional manual or non-CI verification notes only.\n\n````\n\n- Do not use a `## Summary` heading. Start with one or two short sentences explaining what the change accomplishes.\n- Add bullets after the opening only when more detail is useful.\n- Include usage examples for new features, and before/after examples for replacements or improvements, when they help reviewers understand the change.\n- Add `**Testing**` with bullets below the description only when there are manual checks, unusual verification steps, skipped non-CI checks, or failures reviewers should know about. Omit it for routine automated coverage.\n\n## Testing Notes\n\n- Do not list linting, typechecking, unit test, or integration test commands in the PR body, even if they were run locally. CI runs these automatically.\n- Do not say that CI will run routine linting, typechecking, unit tests, or integration tests. That is assumed for every PR.\n- Do not add manual testing instructions by default.\n- Add manual testing instructions only when necessary, such as visual/UI behavior that needs human review, environment-specific behavior not covered by CI, release/publish dry-run steps, external service integration, or a reproduction that cannot be expressed reliably in automated tests.\n- When manual testing is necessary, keep the instructions minimal and directly tied to the uncovered risk.\n\n## Labels\n\nApply labels after the PR exists. Rely on the stable labels listed in this skill for normal PRs.\n\nApply labels with:\n\n```sh\ngh pr edit <number-or-url> --add-label \"<label>\"\n````\n\nIf `gh pr edit --add-label` fails because the specified label is invalid or missing, run:\n\n```sh\ngh label list --limit 200\n```\n\nThen choose the correct label from the live list and update this skill in place so the stable label guidance stays current. Use real labels only. If the right label does not exist, do not invent one; mention the missing label.\n\n### Package Labels\n\nAdd every applicable `pkg:*` label based on touched package paths:\n\n| Touched path | Label |\n| ---------------------------------------------------- | ----------------------------------------------- |\n| `packages/react-router/` | `pkg:react-router` |\n| `packages/react-router-dev/` | `pkg:@react-router/dev` |\n| `packages/create-react-router/` | `pkg:create-react-router` |\n| `packages/react-router-architect/` | `pkg:@react-router/architect` |\n| `packages/react-router-cloudflare/` | `pkg:@react-router/cloudflare` |\n| `packages/react-router-node/` | `pkg:@react-router/node` |\n| `packages/react-router-serve/` | `pkg:@react-router/serve` |\n| `packages/react-router-express/` | `pkg:@react-router/express` |\n| `packages/react-router-fs-routes/` | `pkg:@react-router/fs-routes` |\n| `packages/react-router-remix-routes-option-adapter/` | `pkg:@react-router/remix-routes-option-adapter` |\n\nIf a package path is unclear, inspect its `package.json` `name` and use `pkg:<name>` when that label exists. If a change touches generated artifacts or integration tests only, infer the package label from the runtime/tooling area being tested. For example, Vite plugin or prerender integration coverage usually maps to `pkg:@react-router/dev`.\n\n### Feature Labels\n\nAdd applicable `feat:*` labels for the behavior area being changed. Common labels include:\n\n| Behavior area | Label |\n| --------------------------------------------------------------------------------- | --------------------------- |\n| Core navigation, loaders/actions, fetchers, redirects, matching, and router state | `feat:router` |\n| Route config APIs and `routes.ts` | `feat:routes.ts` |\n| Vite plugin and build pipeline behavior | `feat:vite` |\n| SPA mode | `feat:spa-mode` |\n| Prerendering | `feat:prerender` |\n| Lazy route discovery | `feat:lazy-route-discovery` |\n| Hydration and hydration fallback behavior | `feat:hydration` |\n| View transition APIs | `feat:view-transitions` |\n| Middleware behavior | `feat:middleware` |\n| Split route module behavior | `feat:split-route-modules` |\n| Streaming behavior | `feat:streaming` |\n| CSS handling | `feat:css` |\n| Windows-specific fixes | `feat:windows` |\n| RSC Data or RSC Framework behavior | `feat:rsc` |\n| Path matching semantics | `feat:path-matching` |\n| Single fetch behavior | `feat:single-fetch` |\n| Types, typegen, and TypeScript behavior | `feat:typescript` |\n\nMultiple feature labels are fine when the diff truly spans multiple areas. Prefer the most specific label that exists.\n\n### Non-Package Labels\n\nSome PRs do not need package or feature labels:\n\n- Add `docs` for documentation-only changes.\n- Add `github-actions` for `.github/workflows/` or Actions infrastructure changes.\n- Add `dependencies` for dependency or lockfile-only maintenance.\n- Add version labels such as `v6`, `v7`, or `v8` only when the PR is intentionally scoped to that release line or the user asks for it.\n\n## Final Report\n\nReport:\n\n- Branch name.\n- Commit hash.\n- PR URL and whether it is draft or ready.\n- Base branch.\n- Labels applied.\n- Verification performed or skipped.\n\n<!-- File: .agents/skills/finish-line/SKILL.md (Tokens: ~1208 | Category: anthropic-skill) -->\n---\nname: finish-line\ndescription: Bring a blocked React Router community pull request across the finish line. Use when the user invokes `/finish-line` or `$finish-line`, provides a PR number or URL, and asks Codex to resolve merge blockers such as a missing change file, missing documentation, missing tests, or stale contributor follow-up. Handles evaluating the blocker and pushing small maintainer fixes onto a contributor PR branch when authorized.\n---\n\n# Finish Line\n\n## Overview\n\nFinish blocked community PRs in `remix-run/react-router` while respecting contributor ownership and the repo's PR packaging conventions.\n\nTreat the PR number or URL in `$ARGUMENTS` as the target PR. If no target is provided, ask for it before doing anything.\n\n## Triage\n\n1. Inspect local state with `git status --short --branch`. If unrelated dirty files exist, do not overwrite or stage them.\n2. Fetch current main before making branch decisions:\n\n```sh\ngit fetch origin main\n```\n\n3. Gather PR context:\n\n```sh\ngh pr view <pr> --repo remix-run/react-router --json number,title,body,state,isDraft,author,baseRefName,headRefName,headRepository,headRepositoryOwner,maintainerCanModify,mergeStateStatus,reviewDecision,labels,files,commits,statusCheckRollup,url\ngh pr checks <pr> --repo remix-run/react-router\ngh pr diff <pr> --repo remix-run/react-router --stat\ngh pr view <pr> --repo remix-run/react-router --comments\n```\n\n4. Identify merge blockers. In particular:\n\n- If the PR only needs repo-maintainer additions such as tests, a change file, or docs, use the contributor-branch workflow.\n- If the contributor branch cannot be modified, summarize the evidence and ask the user whether to wait for the contributor or recreate the work on a maintainer branch.\n- If the blocker is unclear, summarize the evidence and ask the user which path to take.\n\n5. Evaluate test coverage before deciding the finish-line changes:\n - Inspect the PR diff, changed files, existing nearby tests, review comments, and failed checks for test expectations.\n - If the PR changes runtime behavior, build/plugin behavior, routing semantics, generated types, RSC behavior, docs rendering, or any bug/feature surface that can regress, add or preserve a focused test unless equivalent coverage already exists.\n - If tests are already included, verify they exercise the changed behavior and cover the affected React Router mode(s): Declarative, Data, Framework, RSC Data, and/or RSC Framework.\n - If tests are not needed because the change is documentation-only, packaging-only, a change file, or otherwise not executable behavior, note that rationale in the final report.\n - If a useful test is required but too large or risky for the finish-line scope, stop and ask the user before broadening the PR.\n\n## Contributor-Branch Workflow\n\nUse this path when the missing work is a small maintainer follow-up, such as tests, a change file, or docs, and the contributor branch can be modified.\n\n1. Check out the PR branch:\n\n```sh\ngh pr checkout <pr-number> --repo remix-run/react-router\n```\n\n2. Confirm the branch and local state:\n\n```sh\ngit status --short --branch\ngit branch --show-current\n```\n\n3. Make only the missing finish-line changes, including focused tests when the coverage evaluation requires them. Do not refactor the contributor's work unless it is necessary to unblock mergeability and the user agrees.\n4. Validate the exact content with the user before pushing:\n - For a change file, show the package path, file name, change type, and full markdown contents.\n - For docs, show the affected files and the relevant prose/API snippets.\n - For tests, show the test file path, the behavior covered, and the mode(s) covered.\n - Ask explicitly for approval to commit and push back to the PR branch.\n5. After approval, run focused validation when appropriate, commit the maintainer follow-up, and push to the PR branch. If `git push` fails because the contributor branch cannot be modified, stop and report the failure instead of opening a replacement PR unless the user approves that pivot.\n\n## Change Files\n\nCreate change files under the affected package:\n\n```text\npackages/<package>/.changes/<type>.<unique-meaningful-name>.md\n```\n\nUse `patch`, `minor`, `major`, or `unstable` for `<type>`. For bug fixes and narrow behavior fixes, default to `patch`. Keep the content concise:\n\n```markdown\nBrief description of the user-facing change\n```\n\nIf the PR spans multiple packages, prefer the package with the direct user-facing API or runtime behavior. Ask the user when the package or change type is not obvious.\n\n## Documentation\n\nDo not add documentation by default for ordinary bug fixes. Add docs when the PR changes a documented API, introduces new behavior users need to discover, changes examples, or the user/reviewer explicitly requested docs.\n\nFollow repo docs rules:\n\n- Edit source docs or JSDoc, not generated `docs/api/` output.\n- Include mode context when adding docs for React Router behavior: Declarative, Data, Framework, RSC Data, or RSC Framework.\n- For API docs generated from JSDoc, edit `packages/react-router/lib/` comments and note that `pnpm run docs` may be required.\n\n## Final Report\n\nReport the path taken and the current PR state:\n\n- Original PR number and blocker.\n- Whether changes were pushed to the contributor branch or a replacement PR was opened.\n- Branch, commit hash, and PR URL when applicable.\n- Any old-PR comment/close action taken.\n- Validation performed or skipped.\n- Test coverage decision: added, already present, or intentionally omitted with rationale.\n\n<!-- File: .agents/skills/fix-bug/SKILL.md (Tokens: ~1201 | Category: anthropic-skill) -->\n---\nname: fix-bug\ndescription: \"Fix a reported bug in React Router from a GitHub issue. Use when the user provides a GitHub issue URL and asks to fix a bug, investigate an issue, or reproduce a problem. Handles the full workflow: fetching the issue, finding the reproduction, writing a failing test, and implementing the fix.\"\ndisable-model-invocation: true\n---\n\n# Fix React Router Bug\n\nFix the bug reported in the following GitHub issue: $ARGUMENTS\n\n## Branching\n\nBug fixes should start from a clean working tree. If there are changes, prompt me to resolve them before continuing.\n\nBugs should be fixed from the `main` branch in a new branch using the format `{author}/{semantic-branch-name}` (i.e., `brophdawg11/fix-navigation`):\n\n```sh\ngit branch {author}/{semantic-branch-name} main\ngit checkout {author}/{semantic-branch-name}\n```\n\n## Workflow\n\n### 1. Fetch and Understand the Issue\n\nUse `gh issue view <number> --repo remix-run/react-router` or `WebFetch` to read the full issue.\n\nExtract:\n\n- Bug description and expected vs actual behavior\n- React Router version and mode (Declarative / Data / Framework / RSC)\n- Any code snippets in the issue\n- Links to reproductions (StackBlitz, CodeSandbox, GitHub repo, etc.)\n\n### 2. Validate the Reproduction\n\n**If there's a StackBlitz/CodeSandbox/online sandbox link:**\n\n- Use `WebFetch` to read the sandbox URL and extract the relevant code\n- Identify the exact sequence of events that triggers the bug\n\n**If there's a GitHub repository link:**\n\n- Use `WebFetch` to read key files (`package.json`, relevant source files) from the raw GitHub URL\n- Identify the route configuration, loaders, actions, or components involved\n\n**If no reproduction link exists:**\n\n- Search the issue comments with `gh issue view <number> --repo remix-run/react-router --comments`\n- Look for code snippets in comments\n- Ask the user: \"No reproduction was provided. Can you share a minimal reproduction or paste the relevant code?\"\n\n### 3. Identify the Affected Code\n\nBased on the bug, locate the relevant source files. Consult the key file map:\n\n| Area | Files |\n| ---------------------- | ----------------------------------------------------------- |\n| Core router logic | `packages/react-router/lib/router/router.ts` |\n| React components/hooks | `packages/react-router/lib/components.tsx`, `lib/hooks.tsx` |\n| DOM utilities | `packages/react-router/lib/dom/` |\n| Vite/Framework plugin | `packages/react-router-dev/vite/plugin.ts` |\n| RSC | `packages/react-router/lib/rsc/` |\n\nUse `Grep` and `Glob` to trace the relevant code paths.\n\n### 4. Write a Failing Test\n\n**Unit test** (for router logic, hooks, pure component behavior — no build needed):\n\n- Location: `packages/react-router/__tests__/`\n- Use Jest; run with: `pnpm test packages/react-router/__tests__/<file>`\n- Match the style of nearby test files (describe/it blocks, `createStaticHandler`, `createMemoryRouter`, `render`, `screen`, etc.)\n\n**Integration test** (for Vite plugin, SSR, hydration, Framework Mode):\n\n- Location: `integration/`\n- Use Playwright with `createFixture()` → `createAppFixture()` → `PlaywrightFixture`\n- Run with: `pnpm test:integration:run --project chromium integration/<file>`\n- Build first if needed: `pnpm test:integration --project chromium`\n\nWrite the test to **reproduce the bug exactly** — it must fail before the fix.\n\nRun it and confirm it fails:\n\n```bash\npnpm test packages/react-router/__tests__/<file> # unit\n# or\npnpm test:integration:run --project chromium integration/<file> # integration\n```\n\n### 5. Implement the Fix\n\n- Make the minimal change needed to fix the bug\n- Do not refactor unrelated code\n- Confirm the fix addresses the root cause, not just the symptom\n- Consider all five modes: does this fix break anything in Declarative / Data / Framework / RSC?\n\nRun the failing test again — it must now pass:\n\n```bash\npnpm test packages/react-router/__tests__/<file>\n```\n\nRun the broader test suite to check for regressions:\n\n```bash\npnpm test packages/react-router/\n```\n\nIf the fix touches Framework/Vite code, run integration tests too:\n\n```bash\npnpm test:integration:run --project chromium\n```\n\nConfirm linting and typechecking pass:\n\n```bash\npnpm lint\npnpm typecheck\n```\n\n### 6. Create a Change file\n\nCreate a change file at `packages/<package>/.changes/<type>.<unique-meaningful-name>.md`. `<type>` should be either `patch`, `minor`, `major` or `unstable` to indicate the type of API change being made.\n\nFormat:\n\n```markdown\nfix: <brief description of what was fixed>\n```\n\n### 7. Report Results\n\nSummarize:\n\n- What the bug was and why it happened\n- What code was changed and why\n- That the test now passes\n- Any edge cases or related issues noticed\n\nAsk me to review the changes and iterate based on any feedback.\n\n### 8. Open PR\n\nOnce I approve the fix, commit the changes and open a PR to `main`. Include a `Closes #NNNN` in the description to link the PR to the original issue. Also link the issue in the `Development` sidebar\n\n<!-- File: .agents/skills/implement-rfc/SKILL.md (Tokens: ~2026 | Category: anthropic-skill) -->\n---\nname: implement-rfc\ndescription: Implement a React Router RFC from a GitHub discussion URL. Fetches the proposal, evaluates community feedback, resolves outstanding questions interactively, then implements the feature with tests, future flags (if breaking), and a changeset.\ndisable-model-invocation: true\n---\n\n# Implement React Router RFC\n\nImplement the RFC from the following GitHub discussion: $ARGUMENTS\n\n## Branching\n\nRFC implementations should start from a clean working tree. If there are uncommitted changes, stop and ask me to resolve them before continuing.\n\n- If you are already on a named branch that is at the same HEAD as `main`, use that branch.\n- Otherwise, create a branch from `main` using the format `{author}/rfc-{semantic-name}`:\n ```sh\n git branch {author}/rfc-{semantic-name} main\n git checkout {author}/rfc-{semantic-name}\n ```\n\n## Workflow\n\n### 1. Fetch and Understand the RFC\n\nUse `WebFetch` to read the discussion URL. If a GitHub discussion number is given instead of a URL, construct:\n`https://github.com/remix-run/react-router/discussions/<number>`\n\nExtract:\n\n- **Problem being solved**: what pain point does this RFC address?\n- **Proposed API**: exact function signatures, hook names, types, option shapes\n- **Affected modes**: Declarative / Data / Framework / RSC Data / RSC Framework\n- **Breaking changes**: does this change or remove existing public API?\n- **Open questions**: anything explicitly marked as unresolved, \"TBD\", or asked as a question in the proposal\n- **Status**: are there linked tracking issues? Look for links to other github issues and read them to see if there is additional context.\n\n ```sh\n gh issue view <number> --repo remix-run/react-router\n ```\n\n### 2. Evaluate Community Feedback\n\nFetch all comments from the discussion:\n\nUse `WebFetch` on `https://github.com/remix-run/react-router/discussions/<number>` and scroll through the full thread. Look for:\n\n- **Concerns or objections** raised by community members or maintainers\n- **Alternative proposals** or API shape suggestions\n- **Edge cases** raised that the proposal does not address\n- **Positive signals** — repeated praise for a specific approach signals it's the right direction\n- **Maintainer responses** — Ryan Florence, Michael Jackson, or other core team members clarifying intent\n\nSummarize the community sentiment into:\n\n- Points of consensus (safe to proceed)\n- Points of contention (need resolution before implementing)\n- Unanswered questions from the original proposal\n\n### 3. Resolve Outstanding Questions\n\nBefore writing any code, present me with a numbered list of every unresolved question — from both the RFC itself and from community feedback. For each question:\n\n- State the question clearly\n- Summarize relevant community input\n- Offer a recommended answer with reasoning\n\nAsk me to confirm, override, or skip each question. Do not proceed to implementation until all questions are either answered or explicitly deferred.\n\nExample format:\n\n```\n## Unresolved Questions\n\n1. **Should `useRouterState()` accept a path argument for scoped matching?**\n Community feedback: 3 comments in favor, 1 against (concerns about complexity).\n Recommendation: Yes — scoped matching improves type safety for nested routes.\n → Your decision: [confirm / override / defer]\n\n2. **What should happen when the path doesn't match the current location?**\n Recommendation: Return `null` for active state (consistent with `useMatch()`).\n → Your decision: [confirm / override / defer]\n```\n\nSave the resolved decisions to a scratch file at `tasks/rfc-decisions.md` for reference during implementation.\n\n### 4. Plan the Implementation\n\nBefore writing code, produce a concise implementation plan covering:\n\n- New types/interfaces to add\n- New functions/hooks to implement and their file locations\n- Existing APIs to deprecate (mark with `@deprecated` JSDoc + console warning in dev)\n- Whether a future flag is needed (see §5 below)\n- Test files to create or extend (unit and/or integration)\n- Changeset bump level (`minor` for new features, `major` for breaking changes behind a future flag that is now defaulted on)\n\nPresent the plan to me and wait for approval before implementing.\n\n### 5. Future Flags for Breaking Changes\n\nIf the RFC changes or removes existing public API behavior, it **must** ship behind a future flag which will start with an `unstable_` prefix.\n\n**Future flag pattern:**\n\n1. Add the flag to `FutureConfig` in `packages/react-router/lib/router/utils.ts`:\n\n ```ts\n export interface FutureConfig {\n // existing flags...\n unstable_myNewBehavior: boolean;\n }\n ```\n\n2. Gate the new behavior on the flag:\n\n ```ts\n if (router.future.unstable_myNewBehavior) {\n // new behavior\n } else {\n // legacy behavior\n }\n ```\n\n3. Document the flag in `docs/upgrading/future-flags.md` if it exists.\n\nNew additive APIs (no behavior change to existing code) do **not** need a future flag.\n\n### 6. Key File Locations\n\n| Area | Files |\n| --------------------- | -------------------------------------------- |\n| Core router logic | `packages/react-router/lib/router/router.ts` |\n| Router types/utils | `packages/react-router/lib/router/utils.ts` |\n| React components | `packages/react-router/lib/components.tsx` |\n| React hooks | `packages/react-router/lib/hooks.tsx` |\n| Public exports | `packages/react-router/index.ts` |\n| DOM utilities | `packages/react-router/lib/dom/` |\n| Framework/Vite plugin | `packages/react-router-dev/vite/plugin.ts` |\n| RSC runtime | `packages/react-router/lib/rsc/` |\n| Unit tests | `packages/react-router/__tests__/` |\n| Integration tests | `integration/` |\n| Future flags doc | `docs/upgrading/future-flags.md` |\n\nConfirm existing patterns before writing new code - prefer using the LSP but `Grep`/`Glob` also work. Match naming conventions and code style exactly.\n\n### 7. Implement the Feature\n\nFollow the approved plan. For each logical unit of work:\n\n1. Write the implementation\n2. Export from the appropriate public entry point (`packages/react-router/index.ts`)\n3. Add `@deprecated` JSDoc to any APIs being superseded\n4. Run typecheck to catch type errors early:\n ```sh\n pnpm typecheck\n ```\n\nKeep changes minimal and focused. Do not refactor unrelated code. Commit as often as needed.\n\n### 8. Write Tests\n\n**Unit tests** (for hooks, pure router logic, component behavior — no build):\n\n- Location: `packages/react-router/__tests__/`\n- Runner: Jest → `pnpm test packages/react-router/__tests__/<file>`\n- Cover: happy path, edge cases identified in RFC/community feedback, future flag gating (if applicable), deprecation warnings\n\n**Integration tests** (for Vite/Framework Mode, SSR, hydration):\n\n- Location: `integration/`\n- Runner: Playwright → `pnpm test:integration:run --project chromium integration/<file>`\n- Required if the RFC touches Framework Mode, file-system routing, or SSR behavior\n\nRun all tests and confirm they pass:\n\n```sh\npnpm test packages/react-router/\npnpm test:integration:run --project chromium # only if integration tests were added/changed\n```\n\n### 9. Lint and Typecheck\n\n```sh\npnpm lint\npnpm typecheck\n```\n\nFix all errors before proceeding.\n\n### 10. Create a Change File\n\nCreate `packages/<package>/.changes/<bump-level>.<descriptive-name>.md`. Use the RFC title or tracking issue as the description:\n\n```markdown\nfeat: <brief description matching the RFC title>\n\nImplements the `useRouterState()` RFC (#12358). Deprecates `useLocation`,\n`useParams`, `useSearchParams`, `useNavigation`, `useMatches`, `useMatch`,\n`useNavigationType`, and `useViewTransitionState` in favor of a unified API.\n\nEnable the `unstable_consolidatedRouterState` future flag to opt in.\n```\n\nBump levels:\n\n- `patch` — bug-adjacent fix only\n- `minor` — new additive API (no breaking changes)\n- `major` — breaking change (should be rare; most breaking changes go behind a future flag as `minor` first)\n- `unstable` — new API that is not yet stable (e.g. added in a future flag, or an experimental API that may be removed without a major bump)\n\n### 11. Report and Review\n\nSummarize:\n\n- What RFC was implemented and which decisions were made\n- New public APIs added (with brief usage example)\n- APIs deprecated and the migration path\n- Future flag name (if applicable) and how to opt in\n- Test coverage added\n- Anything deferred or explicitly out of scope\n\nAsk me to review and iterate before opening a PR.\n\n### 12. Commit\n\nOnce I approve, commit and open a PR to `main`:\n\n```sh\ngh pr create --base main --title \"feat: <RFC title>\" --body \"...\"\n```\n\nPR body should include:\n\n- Link to the RFC discussion (Closes or Implements #NNNN)\n- Summary of what was implemented\n- Future flag instructions if applicable\n- Testing notes\n- Any decisions that deviated from the original proposal and why\n\n<!-- File: .agents/skills/prepare-release-notes/agents/openai.yaml (Tokens: ~49 | Category: anthropic-skill) -->\ninterface:\n display_name: \"Prepare Release Notes\"\n short_description: \"Polish React Router release notes\"\n default_prompt: \"Use $prepare-release-notes to review pending React Router change files and draft any needed What's Changed notes.\"\n\n<!-- File: .agents/skills/prepare-release-notes/references/whats-changed.md (Tokens: ~521 | Category: anthropic-skill) -->\n# What's Changed Reference\n\nLoad this when deciding whether a React Router release needs `scripts/changes/whats-changed.md`.\n\n## Include A Manual Section For\n\n- Major releases with baseline changes, removed packages, removed deprecated APIs, new runtime requirements, or migration guidance\n- Stabilizations and flag renames where adopters of unstable APIs need explicit before/after guidance\n- New APIs or flags that deserve a narrative introduction or usage example\n- Cross-cutting performance or behavior work where several bullets form one user-facing story\n- Breaking bug fixes, deployment-sensitive fixes, or adapter/runtime behavior changes where users may need to test or update config\n\n## Usually Do Not Include One For\n\n- Straightforward bug fixes\n- Dependency removals or upgrades where the bullet is sufficient\n- Internal refactors with no public API change\n- A minor feature that is fully understandable from one concise bullet and nested detail bullets\n- Releases where the only content is a normal patch list\n\n## Existing Changelog Patterns\n\n- `v8.1.0`: Uses headings for agent skill installation and observability metadata, including an instrumentation code example. The generated minor bullets still carry the per-package details.\n- `v8.0.0`: Uses long-form migration notes for a major release: baseline support, adopted future flags, removed packages/APIs, and behavior changes.\n- `v7.18.0`: Explains a CSRF check fix that may be a breaking bug fix for reverse-proxy deployments and tells users what to test.\n- `v7.15.0`: Groups several unstable-to-stable API renames and route matching optimizations into narrative sections before listing individual minor bullets.\n- `v7.15.1`: Uses a \"What's New\" style section for an unstable hook with a code example. For new release notes, prefer the current `What's Changed` file path; the generated heading will be `### What's Changed`.\n\n## Drafting Tips\n\n- Use `####` headings inside `scripts/changes/whats-changed.md`; the release script wraps the file in `### What's Changed` if needed\n- Mention applicable React Router modes when the distinction matters: Declarative, Data, Framework, RSC Data, or RSC Framework\n- Keep examples short and directly tied to adoption\n- Avoid repeating the package prefix and PR-link details already provided by generated change sections\n- If unsure, run `pnpm changes:preview` with and without the manual section and keep it only if the generated notes are meaningfully clearer with the narrative\n\n<!-- File: .agents/skills/prepare-release-notes/SKILL.md (Tokens: ~965 | Category: anthropic-skill) -->\n---\nname: prepare-release-notes\ndescription: Prepare React Router release notes before running the changes/versioning scripts. Use when asked to review, polish, normalize, or prepare pending change files under packages/*/.changes, remove semantic commit prefixes from release bullets, enforce imperative tense, decide whether a manual scripts/changes/whats-changed.md section is warranted, or draft long-form release notes for new features, stable future flags, or unstable flags.\n---\n\n# Prepare Release Notes\n\nPolish pending React Router change files and add manual release notes only when the release needs narrative context beyond the generated change lists.\n\n## Workflow\n\n1. Inspect local state:\n\n```sh\ngit status --short\nfind packages -path '*/.changes/*.md' -not -name README.md -not -name .gitkeep -print | sort\n```\n\n2. Read every pending change file. Do not edit generated changelogs or released notes directly.\n\n3. Normalize each change file:\n - Remove `feat:`, `feat(...)`, `fix:`, and `fix(...)` semantic-commit prefixes from prose\n - Use present or imperative tense for the first line and top-level release bullets: prefer `Add`, `Fix`, `Remove`, `Support`, `Stabilize`, `Preserve`, `Update`, `Avoid`, `Prevent`, `Throw`, `Warn`, `Expose`\n - Nested detail bullets can stay explanatory when they expand on the parent bullet; do not rewrite them solely to force present or imperative tense\n - Remove terminal sentence periods from bullet items because release generation appends PR/commit links after the first bullet line\n - Remove terminal sentence periods from nested bullet items too, unless the punctuation is part of code, a URL, an abbreviation, a version number, or another token where removing it would be wrong\n - If one bullet contains multiple sentences, split it into a shorter parent bullet plus nested bullet items\n - Keep the first line concise and user-facing; use nested bullets for details or migration notes\n\n4. Review whether `scripts/changes/whats-changed.md` is needed:\n - Read `CHANGELOG.md` examples or `references/whats-changed.md` when uncertain\n - Add `scripts/changes/whats-changed.md` only for features, future flag stabilizations, unstable flags, migration guidance, breaking bug fixes, or complex behavior that needs long-form text or examples\n - Do not add it for ordinary bug fixes, dependency cleanup, internal refactors, or release bullets that are already clear\n - If adding it, write the body only; the release script adds `### What's Changed` when missing\n\n5. Validate:\n\n```sh\npnpm changes:validate\npnpm changes:preview\n```\n\nUse `changes:preview` to inspect the generated root release notes and confirm the PR/commit link placement, section ordering, and any manual What's Changed placement. If dependencies are missing or the command is too expensive for the context, state what was skipped.\n\n## Change File Style\n\nSingle-line entries should read well with an auto-appended PR link:\n\n```markdown\nFix `href()` to stringify and URL-encode param values like `generatePath()`\n```\n\nUse nested bullets for additional sentences:\n\n```markdown\nFix route ranking for dynamic parameters with static extension suffixes\n\n- Identify `/:name.xml` as a dynamic segment instead of a static segment\n- Preserve static route priority for paths like `/sitemap.xml`\n```\n\nAvoid semantic commit prefixes:\n\n```markdown\nAdd support for nub as a package manager\n```\n\nnot:\n\n```markdown\nfeat: add support for nub as a package manager.\n```\n\n## What's Changed Guidance\n\nUse `scripts/changes/whats-changed.md` for release-level narrative, not package-specific bullets. Good candidates include:\n\n- A new user-facing API or feature that benefits from example code\n- Stabilization or renaming of unstable APIs/flags, especially when adopters must migrate\n- A stable future flag that changes behavior and needs adoption guidance\n- A breaking bug fix or adapter/runtime behavior change that may require deployment checks\n- A cluster of related changes whose combined effect matters more than the individual bullet list\n\nKeep the tone direct and practical. Prefer headings under the generated `### What's Changed` section:\n\n````markdown\n#### Feature Name\n\nExplain what changed, who it affects, and how to adopt it.\n\n```ts\n// Optional short example\n```\n````\n\nDo not duplicate every bullet from Minor/Patch/Unstable Changes. Let generated change files carry ordinary PR-level details.\n\nSee `references/whats-changed.md` for examples distilled from the existing changelog.\n\n<!-- File: .agents/skills/react-router/references/data-mode.md (Tokens: ~1070 | Category: anthropic-skill) -->\n# Data Mode\n\nData Mode uses data routers such as `createBrowserRouter` and renders with `<RouterProvider>`. It gives an app route objects, loaders, actions, pending UI, fetchers, and SSR primitives without adopting the Framework Vite plugin or route-module file conventions.\n\nUse this reference after the main skill identifies a Data Mode app.\n\n## Read the Local Docs by Mode\n\nStart with:\n\n```txt\nreact-router/docs/start/modes.md\nreact-router/docs/start/data/index.md\n```\n\nThen use the Data docs under:\n\n```txt\nreact-router/docs/start/data/\n```\n\nThose files cover installation, route objects, routing, data loading, actions, navigation, pending UI, and testing. For task-specific details, read relevant files in:\n\n```txt\nreact-router/docs/how-to/\nreact-router/docs/explanation/\n```\n\nAlways check the `[MODES: data, ...]` marker in a doc before applying it.\n\n## Data Router Shape\n\nTypical setup:\n\n```tsx\nimport { createBrowserRouter, RouterProvider } from \"react-router\";\n\nconst router = createBrowserRouter([\n {\n path: \"/\",\n Component: Root,\n loader: rootLoader,\n children: [\n { index: true, Component: Home },\n {\n path: \"projects/:projectId\",\n Component: Project,\n loader: projectLoader,\n },\n ],\n },\n]);\n\nroot.render(<RouterProvider router={router} />);\n```\n\nLook for route object arrays and APIs such as:\n\n- `createBrowserRouter`\n- `createHashRouter`\n- `createMemoryRouter`\n- `RouterProvider`\n- `loader`\n- `action`\n- `Component`\n- `ErrorBoundary`\n- `lazy`\n- `children`\n\n## Route Objects and Routing\n\nBefore editing route configuration, read:\n\n```txt\nreact-router/docs/start/data/routing.md\nreact-router/docs/start/data/route-object.md\n```\n\nRules:\n\n- Keep route objects outside render when possible.\n- Use nested routes for shared layouts and data boundaries.\n- Use index routes for default child content.\n- Use dynamic segments and splats according to route-object docs.\n- Prefer `Component`/`ErrorBoundary` route object properties in Data Mode examples unless the existing app uses `element` consistently.\n\n## Data and Mutations\n\nBefore working on data loading or mutations, read:\n\n```txt\nreact-router/docs/start/data/data-loading.md\nreact-router/docs/start/data/actions.md\n```\n\nRules:\n\n- Load route data with route `loader` functions.\n- Mutate route data with route `action` functions.\n- Prefer loaders/actions over route-level `useEffect` fetching.\n- Use `request`, `params`, and returned/throwable Responses as described in the docs.\n- Let React Router revalidate after actions unless there is a documented reason to customize revalidation.\n\nCommon patterns:\n\n- Validation failure from an action: return `data({ errors, values }, { status: 400 })`, then render errors with `useActionData()` or `fetcher.data`.\n- Missing record in a loader: throw `data(\"Not Found\", { status: 404 })` and render the route `ErrorBoundary`.\n- Search/filter data: parse `new URL(request.url).searchParams` in the loader so the URL is shareable and bookmarkable.\n\n## Forms, Fetchers, and Pending UI\n\nFor forms and pending UI, read:\n\n```txt\nreact-router/docs/start/data/actions.md\nreact-router/docs/start/data/pending-ui.md\nreact-router/docs/how-to/fetchers.md\nreact-router/docs/explanation/form-vs-fetcher.md\n```\n\nRules of thumb:\n\n- Search/filter form that updates the URL: `<Form method=\"get\">`.\n- Mutation that should change URL/history or redirect after completion: `<Form method=\"post\">`.\n- Mutation that should keep the user on the same page: `useFetcher` / `<fetcher.Form>`.\n- Optimistic UI: derive from `fetcher.formData` or `navigation.formData`.\n\n## Navigation and URL State\n\nBefore changing navigation or search params, read:\n\n```txt\nreact-router/docs/start/data/navigating.md\nreact-router/docs/how-to/search-params.md\nreact-router/docs/explanation/location.md\n```\n\nRules:\n\n- Use `<Link>`/`<NavLink>` for user-initiated internal navigation.\n- Use `redirect` in loaders/actions when navigation follows data loading or mutations.\n- Use `useNavigate` for imperative client-side event navigation.\n- Treat URL params as strings and validate/parse them.\n- Preserve unrelated search params unless intentionally resetting them.\n\n## SSR in Data Mode\n\nData Mode SSR is manual and lower-level than Framework Mode. Before implementing or changing SSR, read the Data Mode custom/SSR docs and match existing server abstractions.\n\nStart with:\n\n```txt\nreact-router/docs/start/data/custom.md\n```\n\nLook for APIs like `createStaticHandler`, `createStaticRouter`, `StaticRouterProvider`, and hydration data handling in the current app before changing anything.\n\n## RSC Data\n\nIf this Data Mode app uses `unstable_RSCRouteConfig`, RSC route config, or low-level RSC server APIs, also read:\n\n```txt\nreferences/rsc.md\nreact-router/docs/how-to/react-server-components.md\n```\n\n<!-- File: .agents/skills/react-router/references/declarative-mode.md (Tokens: ~735 | Category: anthropic-skill) -->\n# Declarative Mode\n\nDeclarative Mode is React Router's simplest mode. It uses router components like `<BrowserRouter>` and JSX routes with `<Routes>`/`<Route>`. It does not provide loaders, actions, fetchers, or data-router pending UI.\n\nUse this reference after the main skill identifies a Declarative Mode app.\n\n## Read the Local Docs by Mode\n\nStart with:\n\n```txt\nreact-router/docs/start/modes.md\nreact-router/docs/start/declarative/index.md\n```\n\nThen use the Declarative docs under:\n\n```txt\nreact-router/docs/start/declarative/\n```\n\nThose files cover installation, routing, navigation, and URL values. For conceptual details, read relevant files in:\n\n```txt\nreact-router/docs/explanation/\n```\n\nAlways check the `[MODES: declarative, ...]` marker in a doc before applying it.\n\n## Declarative Router Shape\n\nTypical setup:\n\n```tsx\nimport { BrowserRouter, Routes, Route } from \"react-router\";\n\nfunction App() {\n return (\n <BrowserRouter>\n <Routes>\n <Route path=\"/\" element={<Home />} />\n <Route path=\"about\" element={<About />} />\n <Route path=\"dashboard\" element={<DashboardLayout />}>\n <Route index element={<DashboardHome />} />\n <Route path=\"settings\" element={<Settings />} />\n </Route>\n </Routes>\n </BrowserRouter>\n );\n}\n```\n\nLook for APIs such as:\n\n- `<BrowserRouter>`\n- `<HashRouter>`\n- `<MemoryRouter>`\n- `<Routes>`\n- `<Route>`\n- `element={<Component />}`\n- `useRoutes`\n\n## Routing\n\nBefore editing routes, read:\n\n```txt\nreact-router/docs/start/declarative/routing.md\n```\n\nRules:\n\n- Use `<Routes>` and `<Route>` for route configuration.\n- Use nested routes with `<Outlet>` for shared layout.\n- Use index routes for default child UI.\n- Use route params and splats according to the declarative routing docs.\n- Do not add route object loaders/actions to a Declarative router.\n\n## Navigation\n\nBefore changing navigation, read:\n\n```txt\nreact-router/docs/start/declarative/navigating.md\n```\n\nRules:\n\n- Use `<Link>` or `<NavLink>` for user-initiated internal navigation.\n- Use `NavLink` when active styling matters.\n- Use `useNavigate` for imperative navigation from event handlers or effects.\n- Do not use plain `<a href>` for internal navigation unless intentionally forcing a full document navigation.\n\n## URL Values\n\nBefore changing params, search params, or location state, read:\n\n```txt\nreact-router/docs/start/declarative/url-values.md\nreact-router/docs/explanation/location.md\n```\n\nRules:\n\n- Use `useParams` for dynamic route params.\n- Use `useSearchParams` for query string state.\n- Use `useLocation` for the current location object and navigation state.\n- Validate and parse URL params; they are strings and can be absent.\n- Preserve unrelated search params unless intentionally resetting them.\n\n## Mode Boundary\n\nDeclarative Mode does not have Data/Framework APIs such as:\n\n- `loader`\n- `action`\n- `<Form>`\n- `useFetcher`\n- `useNavigation`\n- route module exports\n- generated `./+types` route types\n\nIf the user asks for route data loading, DB/API-backed data, CRUD, form mutations, validation returned from submissions, revalidation, pending UI, optimistic UI, or fetchers, recommend Data Mode or Framework Mode depending on how much structure they want. Ask before migrating unless they already requested it.\n\n<!-- File: .agents/skills/react-router/references/framework-mode.md (Tokens: ~1534 | Category: anthropic-skill) -->\n# Framework Mode\n\nFramework Mode is React Router's full-stack mode. It uses the React Router Vite plugin, route config in `app/routes.ts`, route modules, generated route types, and rendering strategies such as SSR, SPA mode, and pre-rendering.\n\nUse this reference after the main skill identifies a Framework Mode app.\n\n## Read the Local Docs by Mode\n\nStart with:\n\n```txt\nreact-router/docs/start/modes.md\nreact-router/docs/start/framework/index.md\n```\n\nThen use the Framework docs under:\n\n```txt\nreact-router/docs/start/framework/\n```\n\nThose files cover installation, routing, route modules, data loading, actions, navigation, pending UI, rendering, deploying, and testing. For task-specific details, read relevant files in:\n\n```txt\nreact-router/docs/how-to/\nreact-router/docs/explanation/\n```\n\nAlways check the `[MODES: framework, ...]` marker in a doc before applying it.\n\n## Framework Shape\n\nExamples usually assume the default `appDirectory` of `app`. Check `react-router.config.ts` before assuming exact paths.\n\nLook for these files and conventions:\n\n```txt\nreact-router.config.ts\napp/root.tsx\napp/routes.ts\napp/routes/**/*.tsx\nroute modules importing from ./+types/...\n```\n\nTypical route module:\n\n```tsx\nimport type { Route } from \"./+types/product\";\n\nexport async function loader({ params }: Route.LoaderArgs) {\n return { product: await getProduct(params.productId) };\n}\n\nexport default function Product({ loaderData }: Route.ComponentProps) {\n return <h1>{loaderData.product.name}</h1>;\n}\n```\n\n## Route Configuration\n\nFramework apps use `app/routes.ts`. Many apps use file-system routing via `flatRoutes()`, but manual route config is also supported.\n\nBefore editing routes, read:\n\n```txt\nreact-router/docs/start/framework/routing.md\n```\n\nIf the app uses file-route conventions, read:\n\n```txt\nreact-router/docs/how-to/file-route-conventions.md\n```\n\n## Route Modules\n\nRoute modules are the main unit of Framework Mode. Before adding or changing route exports, read:\n\n```txt\nreact-router/docs/start/framework/route-module.md\n```\n\nCommon exports include:\n\n| Export | Use |\n| --------------------------------- | ------------------------------------------------------------------- |\n| `default` | Route component rendered for the match |\n| `loader` | Server data loading for SSR/pre-rendering/server data requests |\n| `clientLoader` | Browser-only data loading or supplementing server loader data |\n| `action` | Server mutation called by `<Form>`, `useSubmit`, or fetchers |\n| `clientAction` | Browser-only mutation or client-side wrapper around a server action |\n| `ErrorBoundary` | UI for errors thrown by this route's loaders/actions/component |\n| `HydrateFallback` | Initial fallback while client loader hydration runs |\n| `links` / `meta` | Route document links and metadata |\n| `handle` | Arbitrary route metadata consumed via `useMatches` |\n| `shouldRevalidate` | Overrides default loader revalidation behavior |\n| `middleware` / `clientMiddleware` | Server/client request pipeline hooks when enabled |\n\nUse generated `Route.*` types from `./+types/<route>` for route module args and props.\n\n## Layout and Root Route Rules\n\n- `app/root.tsx` is the root route and should contain global document/app shell concerns.\n- Put global providers, app-wide nav, app-wide footer, scripts/meta/links, and document structure in `root.tsx` when appropriate.\n- Use nested routes/layout routes for section-specific layouts.\n- Do not flatten routes that should share UI or data boundaries.\n\nUseful docs:\n\n```txt\nreact-router/docs/explanation/special-files.md\nreact-router/docs/start/framework/routing.md\n```\n\n## Data and Mutations\n\nBefore working on route data:\n\n```txt\nreact-router/docs/start/framework/data-loading.md\nreact-router/docs/start/framework/actions.md\n```\n\nFramework rules:\n\n- Load route data with `loader` or `clientLoader`.\n- Mutate route data with `action` or `clientAction`.\n- Prefer route loaders/actions over ad hoc `useEffect` fetching for route data.\n- Use `data()`/Responses and redirects according to the docs.\n- Let React Router revalidate after actions unless the docs point you to `shouldRevalidate`.\n- In SSR/server data routes, keep Node-only/database code in server-only modules and call it from `loader`/`action`, not from browser-rendered component code.\n\nCommon patterns:\n\n- Validation failure from an action: return `data({ errors, values }, { status: 400 })`, then render errors from `Route.ComponentProps[\"actionData\"]` or `fetcher.data`.\n- Missing record in a loader: throw `data(\"Not Found\", { status: 404 })` and render the route `ErrorBoundary`.\n- Search/filter data: parse the route request URL/search params in the loader so the URL is shareable and bookmarkable.\n\n## Forms, Fetchers, and Pending UI\n\nFor forms and pending UI, read:\n\n```txt\nreact-router/docs/start/framework/actions.md\nreact-router/docs/start/framework/pending-ui.md\nreact-router/docs/how-to/fetchers.md\nreact-router/docs/explanation/form-vs-fetcher.md\n```\n\nRules of thumb:\n\n- Search/filter form that updates the URL: `<Form method=\"get\">`.\n- Mutation that should change URL/history or redirect after completion: `<Form method=\"post\">`.\n- Mutation that should keep the user on the same page: `useFetcher` / `<fetcher.Form>`.\n- Optimistic UI: derive from `fetcher.formData` or `navigation.formData`.\n\n## Type Safety\n\nBefore changing generated route types or typed URL behavior, read:\n\n```txt\nreact-router/docs/how-to/route-module-type-safety.md\nreact-router/docs/explanation/type-safety.md\n```\n\nRules:\n\n- Import types from `./+types/<route>`.\n- Use `Route.LoaderArgs`, `Route.ActionArgs`, `Route.ComponentProps`, etc.\n- Use type-only imports where appropriate.\n- Do not edit generated `.react-router/types` files.\n\n## Metadata\n\nBefore changing `meta`, read:\n\n```txt\nreact-router/docs/how-to/meta.md\nreact-router/docs/start/framework/route-module.md\n```\n\nImportant: `meta` receives `loaderData`; do not use deprecated `data` args.\n\n## Rendering Strategy\n\nFramework Mode can be SSR, SPA, pre-rendered, or mixed depending on config and route behavior. Before changing rendering behavior, read:\n\n```txt\nreact-router/docs/start/framework/rendering.md\nreact-router/docs/how-to/spa.md\nreact-router/docs/how-to/pre-rendering.md\nreact-router/docs/explanation/hydration.md\n```\n\n## Middleware, Sessions, and Auth\n\nBefore implementing middleware or auth/session flows, read:\n\n```txt\nreact-router/docs/how-to/middleware.md\nreact-router/docs/explanation/sessions-and-cookies.md\n```\n\nMiddleware and context APIs are version/config sensitive. Check the installed React Router version and the app's `react-router.config.ts` before implementing.\n\n## RSC Framework\n\nIf this Framework app uses `unstable_reactRouterRSC` or `@vitejs/plugin-rsc`, also read:\n\n```txt\nreferences/rsc.md\nreact-router/docs/how-to/react-server-components.md\n```\n\n<!-- File: .agents/skills/react-router/references/rsc.md (Tokens: ~777 | Category: anthropic-skill) -->\n# React Server Components (RSC)\n\nReact Router's RSC support is unstable and exists in two variants:\n\n- **RSC Framework Mode**: Framework Mode with the unstable RSC Vite plugin.\n- **RSC Data Mode**: lower-level RSC runtime APIs and manual bundler/server integration.\n\nUse this reference in addition to `framework-mode.md` or `data-mode.md` after the main skill identifies an RSC app.\n\n## Read the Local RSC Docs\n\nStart with:\n\n```txt\nreact-router/docs/how-to/react-server-components.md\n```\n\nThen read the relevant base mode docs:\n\n```txt\nreact-router/docs/start/framework/\nreact-router/docs/start/data/\n```\n\nRSC docs may describe differences from non-RSC mode rather than repeating every Framework/Data concept, so keep both layers in mind.\n\n## Detect RSC Framework Mode\n\nLook for:\n\n- `unstable_reactRouterRSC` imported from `@react-router/dev/vite`\n- `@vitejs/plugin-rsc`\n- `vite.config.ts` with `plugins: [reactRouterRSC(), rsc()]`\n- Framework route modules plus RSC route exports\n- RSC entry files such as `entry.rsc`\n\nRSC Framework Mode uses a different Vite plugin from non-RSC Framework Mode. Do not swap it for the regular `reactRouter()` plugin.\n\n## Detect RSC Data Mode\n\nLook for:\n\n- `unstable_RSCRouteConfig`\n- route config passed to lower-level RSC APIs\n- APIs such as `unstable_matchRSCServerRequest`, `unstable_routeRSCServerRequest`, `unstable_RSCHydratedRouter`, or `unstable_RSCStaticRouter`\n- custom bundler/server setup around RSC\n\nRSC Data Mode is more manual than RSC Framework Mode. Match the app's bundler and server abstractions before changing routes or entries.\n\n## RSC Route Module Differences\n\nIn RSC Framework Mode, many normal Framework Mode concepts still apply, but routes can use server component exports.\n\nImportant route-module concepts from the RSC docs include:\n\n- `ServerComponent` instead of the usual client `default` component\n- `ServerErrorBoundary` paired with `ErrorBoundary`\n- `ServerLayout` paired with `Layout`\n- `ServerHydrateFallback` paired with `HydrateFallback`\n- server-rendered React elements returned from loaders/actions\n\nA route module cannot export both the normal client component and its server component counterpart for the same role. Read the RSC docs before adding these exports.\n\n## Client/Server Boundaries\n\nRSC code must respect React's client/server split:\n\n- Use `\"use client\"` for components that need hooks, browser APIs, or event handlers.\n- Use server-only modules for server data access and secrets.\n- In RSC Framework Mode, prefer the `server-only` and `client-only` boundary imports described in the docs.\n- Do not assume `.server`/`.client` file naming works the same way in RSC Framework Mode; read the RSC docs before relying on those conventions.\n\n## Data Loading in RSC\n\nRSC changes where data can be loaded:\n\n- Server Components can fetch data directly on the server.\n- Loaders/actions may still exist and can have RSC-specific behavior.\n- Client components still need client-safe data and cannot directly access server-only modules.\n\nWhen choosing between a server component fetch, a loader, and a client loader/action, follow the RSC docs and match existing app patterns.\n\n## Stability\n\nRSC APIs are explicitly unstable. Before implementing or refactoring RSC code:\n\n- Check the installed React Router version.\n- Check the installed `@vitejs/plugin-rsc` version.\n- Read the app's existing RSC entry/config files.\n- Prefer minimal changes that match current patterns.\n\n<!-- File: .agents/skills/react-router/SKILL.md (Tokens: ~1189 | Category: anthropic-skill) -->\n---\nname: react-router\ndescription: Build applications with React Router in Framework, Data, Declarative, and unstable RSC modes. Use when configuring routes, route modules, loaders, actions, forms, fetchers, navigation, pending UI, SSR/SPA/pre-rendering, middleware, URL params/search params, or React Router upgrades.\nlicense: MIT\n---\n\n# React Router\n\nReact Router is mode-specific. Before changing an app, identify the mode, load the matching reference, then read the installed docs for the installed package version.\n\n## Identify the Mode\n\nDo not apply Framework/Data patterns to a Declarative app unless you are intentionally migrating modes.\n\n### Framework Mode\n\nUse Framework Mode guidance when you see:\n\n- `@react-router/dev` in dependencies\n- `react-router.config.ts`\n- `app/routes.ts`\n- `app/entry.server.tsx` and/or `app/entry.client.tsx` files\n- route modules under `app/routes/`\n- route exports like `loader`, `action`, `clientLoader`, `clientAction`, `ErrorBoundary`, `meta`, `links`, or `headers`\n- imports from `./+types/...`\n- the React Router Vite plugin from `@react-router/dev/vite`\n\nFramework examples usually use the default `app/` directory, but check `react-router.config.ts` for a custom `appDirectory` before assuming exact paths.\n\nThen read `references/framework-mode.md`.\n\n### Data Mode\n\nUse Data Mode guidance when you see:\n\n- `createBrowserRouter`, `createHashRouter`, `createMemoryRouter`, or `createStaticRouter`\n- `<RouterProvider router={router}>`\n- route objects with properties like `path`, `children`, `loader`, `action`, `Component`, `ErrorBoundary`, or `lazy`\n- data APIs without the Framework Vite plugin\n\nThen read `references/data-mode.md`.\n\n### Declarative Mode\n\nUse Declarative Mode guidance when you see:\n\n- `<BrowserRouter>`, `<HashRouter>`, or `<MemoryRouter>`\n- `<Routes>` and `<Route>` JSX route configuration\n- route components passed with `element={<Component />}`\n- no data router, no route module convention, and no loaders/actions\n\nThen read `references/declarative-mode.md`.\n\n### RSC Framework and RSC Data Modes\n\nReact Server Components support is unstable and exists in both Framework and Data variants. Use RSC guidance when you see:\n\n- `unstable_reactRouterRSC`\n- `@vitejs/plugin-rsc`\n- `unstable_RSCRouteConfig`\n- RSC entry files such as `entry.rsc`\n- `ServerComponent`, `ServerErrorBoundary`, `ServerLayout`, or `ServerHydrateFallback`\n- React directives or boundary packages such as `\"use client\"`, `\"server-only\"`, or `\"client-only\"`\n\nFor RSC Framework, read both `references/framework-mode.md` and `references/rsc.md`.\nFor RSC Data, read both `references/data-mode.md` and `references/rsc.md`.\n\n## Use Installed Docs as Source of Truth\n\nReact Router ships markdown docs in the package so guidance can match the installed version:\n\n```txt\nnode_modules/react-router/docs/\n```\n\nKey docs paths:\n\n```txt\nnode_modules/react-router/docs/index.md\nnode_modules/react-router/docs/start/\nnode_modules/react-router/docs/how-to/\nnode_modules/react-router/docs/explanation/\nnode_modules/react-router/docs/upgrading/\n```\n\nWhen this skill references `react-router/docs/...`, read the matching file under `node_modules/react-router/docs/`. If the installed version does not include local docs, use the repo `docs/` directory when working inside the React Router repository; in a consuming app, fall back to version-matched website docs.\n\nMost docs include a mode marker near the top:\n\n```txt\n[MODES: framework, data, declarative]\n```\n\nOnly apply a doc when its mode marker matches the app mode. If a task spans modes, prefer the section or file that matches the current app.\n\nRSC is documented primarily in:\n\n```txt\nnode_modules/react-router/docs/how-to/react-server-components.md\n```\n\n## Skill References\n\nLoad the relevant reference after identifying the mode:\n\n| Reference | Use When |\n| -------------------------------- | --------------------------------------------- |\n| `references/framework-mode.md` | Framework Mode or RSC Framework base behavior |\n| `references/data-mode.md` | Data Mode or RSC Data base behavior |\n| `references/declarative-mode.md` | Declarative Mode |\n| `references/rsc.md` | Any unstable RSC app |\n\n## Mode Migration Doc Index\n\nIf the user explicitly asks to switch modes, read the target mode reference plus the migration-relevant docs:\n\n| Migration | Docs to read |\n| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Declarative → Data | `react-router/docs/start/modes.md`, `react-router/docs/start/data/routing.md`, `react-router/docs/start/data/data-loading.md`, `react-router/docs/start/data/actions.md` |\n| Declarative/Data → Framework | `react-router/docs/start/modes.md`, `react-router/docs/start/framework/routing.md`, `react-router/docs/start/framework/route-module.md`, `react-router/docs/how-to/route-module-type-safety.md` |\n| Framework SPA/SSR/pre-render changes | `react-router/docs/start/framework/rendering.md`, `react-router/docs/how-to/spa.md`, `react-router/docs/how-to/pre-rendering.md`, `react-router/docs/start/framework/data-loading.md`, `react-router/docs/start/framework/actions.md` |\n| Future flags/upgrades | `react-router/docs/upgrading/future.md` and relevant files under `react-router/docs/upgrading/` |\n\n<!-- File: .agents/skills/sc-summary/agents/openai.yaml (Tokens: ~47 | Category: anthropic-skill) -->\ninterface:\n display_name: \"SC Summary\"\n short_description: \"Summarize React Router Steering Committee meetings\"\n default_prompt: \"Use $sc-summary with the meeting notes location I provide to update GOVERNANCE.md.\"\n\n<!-- File: .agents/skills/sc-summary/SKILL.md (Tokens: ~321 | Category: anthropic-skill) -->\n---\nname: sc-summary\ndescription: Summarize React Router Steering Committee meeting notes from a user-provided location in GOVERNANCE.md. Use when asked to add or revise Steering Committee meeting summaries.\n---\n\n# Steering Committee Meeting Summaries\n\nUse the notes folder or files the user supplies in the request or current conversation. If no source location is available, ask for it. Write to the repository's `GOVERNANCE.md`, under **Meeting Notes**.\n\n1. Read the existing Meeting Notes entries and list the files at the supplied location. Summarize the requested dates or files. If the user gives no date or quantity, choose the earliest meeting without an entry and do one meeting for review. Do not duplicate an existing entry unless asked to revise it.\n2. Read each entire source note, especially the details. Resolve repeated or inconsistent points before writing. Treat proposed ideas, decisions, and suggested next steps distinctly; do not present an unconfirmed proposal as an agreed decision.\n3. Write a public-facing, high-level summary of React Router discussion only. Omit unrelated conversation and banter. Refer to participants by first name. Follow the existing `<details>` format and prose in `GOVERNANCE.md`; use short topical headings when useful. Match the depth of existing entries, adjusted to how much substantive discussion occurred.\n4. Insert each entry near the other meeting dates, preserve unrelated content, then review the diff against the source and run `git diff --check`. Show the new or revised entries to the user. Do not post them to GitHub, commit, or publish unless requested.\n\n<!-- File: .github/skills/agentic-workflows/SKILL.md (Tokens: ~1232 | Category: anthropic-skill) -->\n---\nname: agentic-workflows\ndescription: Route gh-aw workflow design/create/debug/upgrade requests to the right prompts.\n---\n\n# Agentic Workflows Router\n\nUse this skill when a user asks to design, create, update, debug, or upgrade GitHub Agentic Workflows in this repository.\n\nThis skill is a dispatcher: identify the task type, load the matching workflow prompt/skill file, and follow it directly. Keep responses concise and ask a clarifying question if the correct prompt is unclear.\n\nRepository overlay (optional):\n\n- If `.github/aw/instructions.md` exists, load it with `@.github/aw/instructions.md` after loading the matched prompt/skill.\n- Precedence: repository overlay instructions override upstream defaults when they conflict.\n\nRead only the files you need:\nLoad these files from `github/gh-aw` (they are not available locally).\n\n- `.github/aw/action-container-substitutions.md`\n- `.github/aw/agent-runtime-instructions.md`\n- `.github/aw/agentic-chat.md`\n- `.github/aw/agentic-workflows-mcp.md`\n- `.github/aw/asciicharts.md`\n- `.github/aw/campaign.md`\n- `.github/aw/charts-trending.md`\n- `.github/aw/charts.md`\n- `.github/aw/cli-commands.md`\n- `.github/aw/configure-agentic-engine.md`\n- `.github/aw/context.md`\n- `.github/aw/create-agentic-workflow-trigger-details.md`\n- `.github/aw/create-agentic-workflow.md`\n- `.github/aw/create-shared-agentic-workflow.md`\n- `.github/aw/debug-agentic-workflow.md`\n- `.github/aw/dependabot.md`\n- `.github/aw/deployment-status.md`\n- `.github/aw/designer-mappings.md`\n- `.github/aw/designer.md`\n- `.github/aw/evals.md`\n- `.github/aw/experiments.md`\n- `.github/aw/github-agentic-workflows.md`\n- `.github/aw/github-mcp-server-pagination.md`\n- `.github/aw/github-mcp-server.md`\n- `.github/aw/instructions.md`\n- `.github/aw/linter-workflows.md`\n- `.github/aw/llms.md`\n- `.github/aw/loop.md`\n- `.github/aw/lsp.md`\n- `.github/aw/maintainer.md`\n- `.github/aw/mcp-clis.md`\n- `.github/aw/memory-stateful-patterns.md`\n- `.github/aw/memory.md`\n- `.github/aw/messages.md`\n- `.github/aw/multi-agent-research.md`\n- `.github/aw/network.md`\n- `.github/aw/optimize-agentic-workflow.md`\n- `.github/aw/patterns.md`\n- `.github/aw/pr-reviewer.md`\n- `.github/aw/release-workflow.md`\n- `.github/aw/report.md`\n- `.github/aw/reuse.md`\n- `.github/aw/safe-outputs-automation.md`\n- `.github/aw/safe-outputs-content.md`\n- `.github/aw/safe-outputs-management.md`\n- `.github/aw/safe-outputs-runtime.md`\n- `.github/aw/safe-outputs.md`\n- `.github/aw/serena-tool.md`\n- `.github/aw/shared-safe-jobs.md`\n- `.github/aw/skills.md`\n- `.github/aw/subagents.md`\n- `.github/aw/syntax-agentic.md`\n- `.github/aw/syntax-core.md`\n- `.github/aw/syntax-engine.md`\n- `.github/aw/syntax-tools-imports.md`\n- `.github/aw/syntax.md`\n- `.github/aw/test-coverage.md`\n- `.github/aw/test-expression.md`\n- `.github/aw/token-optimization-caching-budgets.md`\n- `.github/aw/token-optimization-observability.md`\n- `.github/aw/token-optimization.md`\n- `.github/aw/triggers.md`\n- `.github/aw/update-agentic-workflow.md`\n- `.github/aw/upgrade-agentic-workflows.md`\n- `.github/aw/visual-regression.md`\n- `.github/aw/workflow-constraints.md`\n- `.github/aw/workflow-editing.md`\n- `.github/aw/workflow-patterns.md`\n\nAfter loading the matching workflow prompt or skill, follow it directly:\n\n- Design workflows from scratch via interview: `.github/aw/designer.md`\n- Create new workflows: `.github/aw/create-agentic-workflow.md`\n- Configure or add declarative engines: `.github/aw/configure-agentic-engine.md`\n- Update existing workflows: `.github/aw/update-agentic-workflow.md`\n- Debug, audit, or investigate workflows: `.github/aw/debug-agentic-workflow.md`\n- Upgrade workflows and fix deprecations: `.github/aw/upgrade-agentic-workflows.md`\n- Create shared components or MCP wrappers: `.github/aw/create-shared-agentic-workflow.md`\n- Create report-generating workflows: `.github/aw/report.md`\n- Fix Dependabot manifest PRs: `.github/aw/dependabot.md`\n- Analyze coverage workflows: `.github/aw/test-coverage.md`\n- Render compact markdown charts: `.github/aw/asciicharts.md`\n- Map CLI commands to MCP usage: `.github/aw/cli-commands.md`\n- Choose workflow architecture and patterns: `.github/aw/patterns.md`\n- Optimize token usage and cost: `.github/aw/token-optimization.md`\n- Design long-running multi-agent research workflows: `.github/aw/multi-agent-research.md`\n\nWhen the task involves OTEL, OTLP, traces, observability backends, or telemetry-driven analysis, also read and follow `skills/otel-queries/SKILL.md` after loading the matching workflow prompt or skill.\n\n<!-- File: packages/create-react-router/README.md (Tokens: ~17 | Category: plugin-manifest) -->\nCreate a new React Router app.\n\n```sh\nnpm create react-router\n```\n\n<!-- File: packages/react-router-architect/README.md (Tokens: ~29 | Category: plugin-manifest) -->\n[Architect](https://arc.codes) server request handler for React Router.\n\n```bash\nnpm install @react-router/architect\n```\n\n<!-- File: packages/react-router-cloudflare/README.md (Tokens: ~28 | Category: plugin-manifest) -->\nCloudflare platform abstractions for React Router\n\n```bash\nnpm install @react-router/cloudflare @cloudflare/workers-types\n```\n\n<!-- File: packages/react-router-dev/README.md (Tokens: ~42 | Category: plugin-manifest) -->\nDev tools and CLI for React Router that enables framework features through bundler integration like server rendering, code splitting, HMR, etc.\n\n```sh\nnpm install @react-router/dev --save-dev\n```\n\n<!-- File: packages/react-router-express/README.md (Tokens: ~29 | Category: plugin-manifest) -->\n[Express](https://expressjs.com) server request handler for React Router.\n\n```sh\nnpm install @react-router/express\n```\n\n<!-- File: packages/react-router-fs-routes/README.md (Tokens: ~22 | Category: plugin-manifest) -->\nFile system routing conventions for React Router\n\n```sh\nnpm install @react-router/fs-routes\n```\n\n<!-- File: packages/react-router-node/README.md (Tokens: ~21 | Category: plugin-manifest) -->\nNode.js platform abstractions for React Router\n\n```sh\nnpm install @react-router/node\n```\n\n<!-- File: packages/react-router-remix-routes-option-adapter/README.md (Tokens: ~56 | Category: plugin-manifest) -->\n# @react-router/remix-routes-option-adapter\n\nAdapter for [Remix's](https://remix.run) `routes` config option, for use within `routes.ts`.\n\n```sh\nnpm install @react-router/remix-routes-option-adapter\n```\n\n<!-- File: packages/react-router-serve/README.md (Tokens: ~21 | Category: plugin-manifest) -->\nNode.js application server for React Router\n\n```sh\nnpm install @react-router/serve\n```\n\n<!-- File: packages/react-router/README.md (Tokens: ~27 | Category: plugin-manifest) -->\n`react-router` is the primary package in the React Router project.\n\n## Installation\n\n```sh\nnpm i react-router\n```\n\n<!-- File: .cursorrules (react-router-v7.mdc) (Tokens: ~458 | Category: cursor-rule) -->\n# React Router v7 Rules\n\n## Route Modules\n\n- Use route modules as the boundary for route UI, loader data, actions, metadata, and error boundaries.\n- Keep route modules small; move shared UI to components and reusable data access to services.\n- Prefer file-based routing in framework mode when the project is configured for it.\n- Use nested routes for shared layouts and progressive disclosure.\n- Export route-specific `ErrorBoundary` components for recoverable route failures.\n\n## Data Loading\n\n- Use loaders for route data that should be available before render.\n- Keep loaders deterministic and side-effect free.\n- Validate params and search params at the loader boundary.\n- Return typed data and consume it through route hooks rather than duplicating fetch logic in components.\n- Use deferred or streaming patterns only when they improve perceived performance.\n\n## Mutations\n\n- Use actions for route mutations and form submissions.\n- Prefer `Form`, `useFetcher`, and `useSubmit` for progressive enhancement.\n- Revalidate affected loader data after mutations.\n- Handle validation errors as typed action data instead of generic exceptions.\n- Keep server-only secrets and privileged operations out of client actions.\n\n## Navigation and State\n\n- Store shareable state in URL params or search params.\n- Keep ephemeral UI state local to components.\n- Use pending navigation state to show optimistic or loading UI.\n- Avoid global state for data that belongs to route loaders.\n\n## TypeScript and Testing\n\n- Type loader and action return values.\n- Add tests for route loaders, actions, validation failures, and error boundaries.\n- Use integration tests for critical form and navigation flows.\n- Mock network and persistence at the route-service boundary.\n\n## Common Mistakes\n\n- Do not duplicate loader fetches in `useEffect`.\n- Do not mutate data in loaders.\n- Do not hide route errors behind a single generic app-level catch-all.\n- Do not put auth checks only in components when loader data is protected.\n</yakaai_skills>"}