{"owner":"visgl","repo":"deck.gl","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Repository Guidance\n\nThis file applies to the entire `deck.gl` repository. More specific `AGENTS.md` files in\nsubdirectories may add local guidance.\n\n## Setup Commands\n\n- Install dependencies from the repo root: `yarn`\n- Build packages: `yarn build`\n- Run lint: `yarn lint`\n- Run all tests: `yarn test`\n- Run headless tests: `yarn test-headless`\n- Run render tests: `yarn test-render`\n- Run browser tests: `yarn test-browser`\n- Run website checks: `yarn test-website`\n- Use the exact script names from `package.json`; do not substitute spaced forms such as\n  `yarn test headless`.\n\n## Before Committing\n\n- Run the most relevant tests for the changed packages, integrations, examples, or docs.\n- Run `yarn lint` for JavaScript and TypeScript changes. If lint failures are unrelated existing\n  issues, call that out explicitly instead of hiding it.\n- If dependencies or package metadata changed, run `yarn` in the repo root and include any\n  `yarn.lock` updates.\n- Do not reformat files you are not otherwise changing. Keep formatting-only churn separate from\n  logic changes when practical.\n\n## Ready For Merge\n\nWhen asked to \"get ready for merge\", do a full merge-readiness pass:\n\n- Audit the public API surface touched by the change. Add or update TSDoc for every new or changed\n  public class, function, method, property, and type.\n- Do a documentation pass when behavior, public API, examples, or migration guidance changed.\n  Include relevant module docs, examples, sidebars, `docs/whats-new.md`, and upgrade or migration\n  guide content.\n- Keep upgrade guides focused on breaking changes, removals, and deprecations. Put new-feature\n  notes in the appropriate module docs or release notes instead.\n- Run `yarn` in the repo root so workspace metadata and `yarn.lock` are up to date, especially\n  after any `package.json` change.\n- Run `yarn build` as the repo-wide type, declaration, and package build gate.\n- Run `yarn lint` for the final lint and formatting gate, then review the resulting diff.\n- Run the relevant tests for the changed packages, examples, integrations, and docs/website wiring.\n  Typical commands are `yarn test`, `yarn test-headless`, `yarn test-render`, `yarn test-browser`,\n  and `yarn test-website`.\n- For website or docs changes, run the website check from the repo root with `yarn test-website`.\n- Prepare a copyable Markdown PR description based on the branch diff compared to `master`. Start\n  with the PR goals, then list the actual changes and validation.\n- In the final handoff, call out which merge-readiness gates passed, which were not run, and any\n  remaining risk or unrelated pre-existing failures.\n\n## Code Style\n\n- Prefer TypeScript and ES module syntax.\n- Match the surrounding file style. In source files, use single quotes and semicolons.\n- Never abbreviate variable names. Use camelCase for variables, functions, and fields; PascalCase\n  for types and classes; and CAPITAL_CASE for constants.\n- Prefer verb-noun names for functions and methods.\n- File names should be kebab-case unless an existing local convention differs.\n\n## Dependencies\n\n- Be conservative with new external dependencies. Add one only when it provides meaningful\n  capability, not just a small utility.\n- Prefer vis.gl ecosystem packages when they fit the layering. Lower-level math or utility modules\n  should not depend on deck.gl.\n- Prefer math.gl modules for math helpers.\n- Avoid lodash-style dependencies for simple operations.\n\n## Investigation\n\n- Do not fix problems by adding caches. Investigate why the problem occurs and address the root\n  cause.\n"},"files":{"AGENTS.md":"# Repository Guidance\n\nThis file applies to the entire `deck.gl` repository. More specific `AGENTS.md` files in\nsubdirectories may add local guidance.\n\n## Setup Commands\n\n- Install dependencies from the repo root: `yarn`\n- Build packages: `yarn build`\n- Run lint: `yarn lint`\n- Run all tests: `yarn test`\n- Run headless tests: `yarn test-headless`\n- Run render tests: `yarn test-render`\n- Run browser tests: `yarn test-browser`\n- Run website checks: `yarn test-website`\n- Use the exact script names from `package.json`; do not substitute spaced forms such as\n  `yarn test headless`.\n\n## Before Committing\n\n- Run the most relevant tests for the changed packages, integrations, examples, or docs.\n- Run `yarn lint` for JavaScript and TypeScript changes. If lint failures are unrelated existing\n  issues, call that out explicitly instead of hiding it.\n- If dependencies or package metadata changed, run `yarn` in the repo root and include any\n  `yarn.lock` updates.\n- Do not reformat files you are not otherwise changing. Keep formatting-only churn separate from\n  logic changes when practical.\n\n## Ready For Merge\n\nWhen asked to \"get ready for merge\", do a full merge-readiness pass:\n\n- Audit the public API surface touched by the change. Add or update TSDoc for every new or changed\n  public class, function, method, property, and type.\n- Do a documentation pass when behavior, public API, examples, or migration guidance changed.\n  Include relevant module docs, examples, sidebars, `docs/whats-new.md`, and upgrade or migration\n  guide content.\n- Keep upgrade guides focused on breaking changes, removals, and deprecations. Put new-feature\n  notes in the appropriate module docs or release notes instead.\n- Run `yarn` in the repo root so workspace metadata and `yarn.lock` are up to date, especially\n  after any `package.json` change.\n- Run `yarn build` as the repo-wide type, declaration, and package build gate.\n- Run `yarn lint` for the final lint and formatting gate, then review the resulting diff.\n- Run the relevant tests for the changed packages, examples, integrations, and docs/website wiring.\n  Typical commands are `yarn test`, `yarn test-headless`, `yarn test-render`, `yarn test-browser`,\n  and `yarn test-website`.\n- For website or docs changes, run the website check from the repo root with `yarn test-website`.\n- Prepare a copyable Markdown PR description based on the branch diff compared to `master`. Start\n  with the PR goals, then list the actual changes and validation.\n- In the final handoff, call out which merge-readiness gates passed, which were not run, and any\n  remaining risk or unrelated pre-existing failures.\n\n## Code Style\n\n- Prefer TypeScript and ES module syntax.\n- Match the surrounding file style. In source files, use single quotes and semicolons.\n- Never abbreviate variable names. Use camelCase for variables, functions, and fields; PascalCase\n  for types and classes; and CAPITAL_CASE for constants.\n- Prefer verb-noun names for functions and methods.\n- File names should be kebab-case unless an existing local convention differs.\n\n## Dependencies\n\n- Be conservative with new external dependencies. Add one only when it provides meaningful\n  capability, not just a small utility.\n- Prefer vis.gl ecosystem packages when they fit the layering. Lower-level math or utility modules\n  should not depend on deck.gl.\n- Prefer math.gl modules for math helpers.\n- Avoid lodash-style dependencies for simple operations.\n\n## Investigation\n\n- Do not fix problems by adding caches. Investigate why the problem occurs and address the root\n  cause.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Repository Guidance\n\nThis file applies to the entire `deck.gl` repository. More specific `AGENTS.md` files in\nsubdirectories may add local guidance.\n\n## Setup Commands\n\n- Install dependencies from the repo root: `yarn`\n- Build packages: `yarn build`\n- Run lint: `yarn lint`\n- Run all tests: `yarn test`\n- Run headless tests: `yarn test-headless`\n- Run render tests: `yarn test-render`\n- Run browser tests: `yarn test-browser`\n- Run website checks: `yarn test-website`\n- Use the exact script names from `package.json`; do not substitute spaced forms such as\n  `yarn test headless`.\n\n## Before Committing\n\n- Run the most relevant tests for the changed packages, integrations, examples, or docs.\n- Run `yarn lint` for JavaScript and TypeScript changes. If lint failures are unrelated existing\n  issues, call that out explicitly instead of hiding it.\n- If dependencies or package metadata changed, run `yarn` in the repo root and include any\n  `yarn.lock` updates.\n- Do not reformat files you are not otherwise changing. Keep formatting-only churn separate from\n  logic changes when practical.\n\n## Ready For Merge\n\nWhen asked to \"get ready for merge\", do a full merge-readiness pass:\n\n- Audit the public API surface touched by the change. Add or update TSDoc for every new or changed\n  public class, function, method, property, and type.\n- Do a documentation pass when behavior, public API, examples, or migration guidance changed.\n  Include relevant module docs, examples, sidebars, `docs/whats-new.md`, and upgrade or migration\n  guide content.\n- Keep upgrade guides focused on breaking changes, removals, and deprecations. Put new-feature\n  notes in the appropriate module docs or release notes instead.\n- Run `yarn` in the repo root so workspace metadata and `yarn.lock` are up to date, especially\n  after any `package.json` change.\n- Run `yarn build` as the repo-wide type, declaration, and package build gate.\n- Run `yarn lint` for the final lint and formatting gate, then review the resulting diff.\n- Run the relevant tests for the changed packages, examples, integrations, and docs/website wiring.\n  Typical commands are `yarn test`, `yarn test-headless`, `yarn test-render`, `yarn test-browser`,\n  and `yarn test-website`.\n- For website or docs changes, run the website check from the repo root with `yarn test-website`.\n- Prepare a copyable Markdown PR description based on the branch diff compared to `master`. Start\n  with the PR goals, then list the actual changes and validation.\n- In the final handoff, call out which merge-readiness gates passed, which were not run, and any\n  remaining risk or unrelated pre-existing failures.\n\n## Code Style\n\n- Prefer TypeScript and ES module syntax.\n- Match the surrounding file style. In source files, use single quotes and semicolons.\n- Never abbreviate variable names. Use camelCase for variables, functions, and fields; PascalCase\n  for types and classes; and CAPITAL_CASE for constants.\n- Prefer verb-noun names for functions and methods.\n- File names should be kebab-case unless an existing local convention differs.\n\n## Dependencies\n\n- Be conservative with new external dependencies. Add one only when it provides meaningful\n  capability, not just a small utility.\n- Prefer vis.gl ecosystem packages when they fit the layering. Lower-level math or utility modules\n  should not depend on deck.gl.\n- Prefer math.gl modules for math helpers.\n- Avoid lodash-style dependencies for simple operations.\n\n## Investigation\n\n- Do not fix problems by adding caches. Investigate why the problem occurs and address the root\n  cause.\n","category":"root","tokens":895}]}