{"owner":"cytoscape","repo":"cytoscape.js","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Cytoscape.js AGENTS.md\n\nGuidelines for agents contributing to the Cytoscape.js graph theory and visualisation library.\n\n## Environment & tooling\n- Use Node via `.nvmrc` when possible: `nvm use` or `mise en`.\n- Use `npm`; the repo is configured around `package-lock.json` and the existing npm scripts.\n- Library source of truth is in `src/`. Documentation source lives in `documentation/md/`, `documentation/demos/`, and `documentation/docmaker.json`. Built artifacts in `build/`, `dist/`, and generated files under `documentation/` should only be updated via the project scripts.\n- Bundles are produced with Rollup from `src/index.mjs` into UMD, minified UMD, CJS, ESM, and minified ESM outputs.\n- The repo uses ESM source files (`.mjs`), ESLint, Mocha, and Playwright.\n- Before starting significant work, read any repo docs directly related to the area you are changing. For architecture context, start with `documentation/md/architecture.md`.\n- If you want to read the documentation, you can grep `documentation/docmaker.json`, which contains all the documentation data (and API in JSON format).  You can search for things like \"cy.on\" for the `cy.on()` method.  `docmaker.json` references markdown files in `documentation/md/` for prose that elaborates on particular API methods and also for general prose sections, like the intro or getting started sections.  You can also grep `documentation/md/**/*.md` generally for doc searches.  The paths broadly match the `src/**/*.mjs` paths.\n\n## Development flow\n- Make sure dependencies are installed when you first start: `npm install`.\n- Install Playwright browsers before running browser coverage or the full test suite on a fresh environment: `npx playwright install --with-deps`.\n- Make your changes.\n- Lint source files: `npm run lint`.\n- Run the narrowest useful test loop while iterating, but run the relevant verification before handing work back:\n  - Source or algorithm changes: `npm run test:js` and `npm run test:modules`.\n  - Renderer or interaction changes: `npm run test:js`, `npm run test:modules`, and sanity check in `debug/` via `npm run watch`; run Playwright when browser behaviour is affected.\n  - Bundle, packaging, or docs pipeline changes: `npm run build`, `npm run docs`, and any targeted release script checks that apply.\n  - If the change is broad or you are unsure, run `npm test`.\n- Build all bundles but only if you're modifying the build system: `npm run build`.\n\n## Repository structure\n- `src/`: Main library source.\n  - `src/core/`: Core instance lifecycle, viewport, rendering, style, layout, animation, and notifications.\n  - `src/collection/`: Collection APIs, traversals, dimensions, styling, and graph algorithms.\n  - `src/style/`: Style parsing, application, bypasses, and stylesheet helpers.\n  - `src/selector/`: Selector parsing and matching.\n  - `src/extensions/`: Built-in layouts and renderers.\n    - `src/extensions/renderer/base/`: Shared renderer state and geometry logic.\n    - `src/extensions/renderer/canvas/`: Canvas renderer, drawing pipeline, caches, and WebGL helpers.\n    - `src/extensions/layout/`: Built-in layouts like grid, cose, concentric, and breadthfirst.\n  - `src/util/`: Shared low-level helpers.\n- `test/`: Mocha tests. Add regression coverage here for API and logic changes.\n- `debug/`: Manual visual and interaction test pages. Use this for renderer, interaction, and gesture changes that are hard to verify in unit tests alone.\n- `playwright-tests/` and `playwright.config.js`: Browser-level regression coverage.\n- `documentation/`: Generated site plus source markdown, demos, and the doc generator.\n  - `documentation/md/`: Documentation source.\n  - `documentation/demos/`: Demo apps and assets used by the docs site.\n  - `documentation/docmaker.mjs`: Docs build entrypoint.\n- `.github/workflows/`: CI and release workflows.\n- `benchmark/`: Performance comparisons and targeted benchmark runners.\n- `typescript/`: TypeScript-related tests and fixtures.\n\n## Code standards\n1. Preserve the existing style: two-space indentation, single quotes, ESM imports/exports, and concise readable functions.\n2. Do not hand-edit generated outputs when a source file exists instead. In particular, prefer editing `src/` and `documentation/md/` over generated files in `build/`, `dist/`, and compiled docs assets.\n3. Keep module boundaries aligned with the existing architecture. New source files should live near the corresponding subsystem in `src/`.\n4. When fixing a bug, add or update a regression test whenever practical. Put public-behaviour tests in `test/`; keep internal-only coverage in `test/modules/` when applicable.\n5. For renderer, gesture, or grab-state changes, verify behaviour in `debug/` because visual regressions are not always caught by Mocha alone.  You need to control a browser instance to use this and you need to run `npm run watch` to run a dev server with auto-rebuild.\n6. Keep docs in sync with API or behaviour changes. Update `documentation/md/`, demos, and `docmaker.json` inputs rather than patching generated HTML by hand.\n7. Avoid introducing new build tools, frameworks, or repo-wide conventions unless the task explicitly requires it.\n8. When adding new top-level workflows, major directories, or important source areas not already documented here, update `AGENTS.md`.\n\n## Testing notes\n- `npm test` matches CI closely: GitHub Actions installs dependencies, installs Playwright browsers, and runs `npm test`.\n- `npm run test:build` exercises the built bundle rather than source files; use it when a bug could be introduced by bundling or build-time transforms.\n- Playwright setup depends on a built UMD bundle and a local HTTP server. Use the existing scripts rather than inventing a parallel harness.\n\n## Documentation notes\n- Documentation HTML is generated. Do not edit generated docs directly when the corresponding markdown or template source (i.e. `docmaker.json` and `template.html`) should be changed instead.\n\n## Contribution notes\n- Keep changes narrowly scoped. Cytoscape.js has a large public API and small internal regressions can surface broadly.\n- Prefer extending existing tests, demos, and docs over adding parallel mechanisms.\n- If a change affects public API semantics, selectors, style behaviour, layouts, rendering, or documentation structure, call that out explicitly in your summary to the user.\n"},"files":{"AGENTS.md":"# Cytoscape.js AGENTS.md\n\nGuidelines for agents contributing to the Cytoscape.js graph theory and visualisation library.\n\n## Environment & tooling\n- Use Node via `.nvmrc` when possible: `nvm use` or `mise en`.\n- Use `npm`; the repo is configured around `package-lock.json` and the existing npm scripts.\n- Library source of truth is in `src/`. Documentation source lives in `documentation/md/`, `documentation/demos/`, and `documentation/docmaker.json`. Built artifacts in `build/`, `dist/`, and generated files under `documentation/` should only be updated via the project scripts.\n- Bundles are produced with Rollup from `src/index.mjs` into UMD, minified UMD, CJS, ESM, and minified ESM outputs.\n- The repo uses ESM source files (`.mjs`), ESLint, Mocha, and Playwright.\n- Before starting significant work, read any repo docs directly related to the area you are changing. For architecture context, start with `documentation/md/architecture.md`.\n- If you want to read the documentation, you can grep `documentation/docmaker.json`, which contains all the documentation data (and API in JSON format).  You can search for things like \"cy.on\" for the `cy.on()` method.  `docmaker.json` references markdown files in `documentation/md/` for prose that elaborates on particular API methods and also for general prose sections, like the intro or getting started sections.  You can also grep `documentation/md/**/*.md` generally for doc searches.  The paths broadly match the `src/**/*.mjs` paths.\n\n## Development flow\n- Make sure dependencies are installed when you first start: `npm install`.\n- Install Playwright browsers before running browser coverage or the full test suite on a fresh environment: `npx playwright install --with-deps`.\n- Make your changes.\n- Lint source files: `npm run lint`.\n- Run the narrowest useful test loop while iterating, but run the relevant verification before handing work back:\n  - Source or algorithm changes: `npm run test:js` and `npm run test:modules`.\n  - Renderer or interaction changes: `npm run test:js`, `npm run test:modules`, and sanity check in `debug/` via `npm run watch`; run Playwright when browser behaviour is affected.\n  - Bundle, packaging, or docs pipeline changes: `npm run build`, `npm run docs`, and any targeted release script checks that apply.\n  - If the change is broad or you are unsure, run `npm test`.\n- Build all bundles but only if you're modifying the build system: `npm run build`.\n\n## Repository structure\n- `src/`: Main library source.\n  - `src/core/`: Core instance lifecycle, viewport, rendering, style, layout, animation, and notifications.\n  - `src/collection/`: Collection APIs, traversals, dimensions, styling, and graph algorithms.\n  - `src/style/`: Style parsing, application, bypasses, and stylesheet helpers.\n  - `src/selector/`: Selector parsing and matching.\n  - `src/extensions/`: Built-in layouts and renderers.\n    - `src/extensions/renderer/base/`: Shared renderer state and geometry logic.\n    - `src/extensions/renderer/canvas/`: Canvas renderer, drawing pipeline, caches, and WebGL helpers.\n    - `src/extensions/layout/`: Built-in layouts like grid, cose, concentric, and breadthfirst.\n  - `src/util/`: Shared low-level helpers.\n- `test/`: Mocha tests. Add regression coverage here for API and logic changes.\n- `debug/`: Manual visual and interaction test pages. Use this for renderer, interaction, and gesture changes that are hard to verify in unit tests alone.\n- `playwright-tests/` and `playwright.config.js`: Browser-level regression coverage.\n- `documentation/`: Generated site plus source markdown, demos, and the doc generator.\n  - `documentation/md/`: Documentation source.\n  - `documentation/demos/`: Demo apps and assets used by the docs site.\n  - `documentation/docmaker.mjs`: Docs build entrypoint.\n- `.github/workflows/`: CI and release workflows.\n- `benchmark/`: Performance comparisons and targeted benchmark runners.\n- `typescript/`: TypeScript-related tests and fixtures.\n\n## Code standards\n1. Preserve the existing style: two-space indentation, single quotes, ESM imports/exports, and concise readable functions.\n2. Do not hand-edit generated outputs when a source file exists instead. In particular, prefer editing `src/` and `documentation/md/` over generated files in `build/`, `dist/`, and compiled docs assets.\n3. Keep module boundaries aligned with the existing architecture. New source files should live near the corresponding subsystem in `src/`.\n4. When fixing a bug, add or update a regression test whenever practical. Put public-behaviour tests in `test/`; keep internal-only coverage in `test/modules/` when applicable.\n5. For renderer, gesture, or grab-state changes, verify behaviour in `debug/` because visual regressions are not always caught by Mocha alone.  You need to control a browser instance to use this and you need to run `npm run watch` to run a dev server with auto-rebuild.\n6. Keep docs in sync with API or behaviour changes. Update `documentation/md/`, demos, and `docmaker.json` inputs rather than patching generated HTML by hand.\n7. Avoid introducing new build tools, frameworks, or repo-wide conventions unless the task explicitly requires it.\n8. When adding new top-level workflows, major directories, or important source areas not already documented here, update `AGENTS.md`.\n\n## Testing notes\n- `npm test` matches CI closely: GitHub Actions installs dependencies, installs Playwright browsers, and runs `npm test`.\n- `npm run test:build` exercises the built bundle rather than source files; use it when a bug could be introduced by bundling or build-time transforms.\n- Playwright setup depends on a built UMD bundle and a local HTTP server. Use the existing scripts rather than inventing a parallel harness.\n\n## Documentation notes\n- Documentation HTML is generated. Do not edit generated docs directly when the corresponding markdown or template source (i.e. `docmaker.json` and `template.html`) should be changed instead.\n\n## Contribution notes\n- Keep changes narrowly scoped. Cytoscape.js has a large public API and small internal regressions can surface broadly.\n- Prefer extending existing tests, demos, and docs over adding parallel mechanisms.\n- If a change affects public API semantics, selectors, style behaviour, layouts, rendering, or documentation structure, call that out explicitly in your summary to the user.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Cytoscape.js AGENTS.md\n\nGuidelines for agents contributing to the Cytoscape.js graph theory and visualisation library.\n\n## Environment & tooling\n- Use Node via `.nvmrc` when possible: `nvm use` or `mise en`.\n- Use `npm`; the repo is configured around `package-lock.json` and the existing npm scripts.\n- Library source of truth is in `src/`. Documentation source lives in `documentation/md/`, `documentation/demos/`, and `documentation/docmaker.json`. Built artifacts in `build/`, `dist/`, and generated files under `documentation/` should only be updated via the project scripts.\n- Bundles are produced with Rollup from `src/index.mjs` into UMD, minified UMD, CJS, ESM, and minified ESM outputs.\n- The repo uses ESM source files (`.mjs`), ESLint, Mocha, and Playwright.\n- Before starting significant work, read any repo docs directly related to the area you are changing. For architecture context, start with `documentation/md/architecture.md`.\n- If you want to read the documentation, you can grep `documentation/docmaker.json`, which contains all the documentation data (and API in JSON format).  You can search for things like \"cy.on\" for the `cy.on()` method.  `docmaker.json` references markdown files in `documentation/md/` for prose that elaborates on particular API methods and also for general prose sections, like the intro or getting started sections.  You can also grep `documentation/md/**/*.md` generally for doc searches.  The paths broadly match the `src/**/*.mjs` paths.\n\n## Development flow\n- Make sure dependencies are installed when you first start: `npm install`.\n- Install Playwright browsers before running browser coverage or the full test suite on a fresh environment: `npx playwright install --with-deps`.\n- Make your changes.\n- Lint source files: `npm run lint`.\n- Run the narrowest useful test loop while iterating, but run the relevant verification before handing work back:\n  - Source or algorithm changes: `npm run test:js` and `npm run test:modules`.\n  - Renderer or interaction changes: `npm run test:js`, `npm run test:modules`, and sanity check in `debug/` via `npm run watch`; run Playwright when browser behaviour is affected.\n  - Bundle, packaging, or docs pipeline changes: `npm run build`, `npm run docs`, and any targeted release script checks that apply.\n  - If the change is broad or you are unsure, run `npm test`.\n- Build all bundles but only if you're modifying the build system: `npm run build`.\n\n## Repository structure\n- `src/`: Main library source.\n  - `src/core/`: Core instance lifecycle, viewport, rendering, style, layout, animation, and notifications.\n  - `src/collection/`: Collection APIs, traversals, dimensions, styling, and graph algorithms.\n  - `src/style/`: Style parsing, application, bypasses, and stylesheet helpers.\n  - `src/selector/`: Selector parsing and matching.\n  - `src/extensions/`: Built-in layouts and renderers.\n    - `src/extensions/renderer/base/`: Shared renderer state and geometry logic.\n    - `src/extensions/renderer/canvas/`: Canvas renderer, drawing pipeline, caches, and WebGL helpers.\n    - `src/extensions/layout/`: Built-in layouts like grid, cose, concentric, and breadthfirst.\n  - `src/util/`: Shared low-level helpers.\n- `test/`: Mocha tests. Add regression coverage here for API and logic changes.\n- `debug/`: Manual visual and interaction test pages. Use this for renderer, interaction, and gesture changes that are hard to verify in unit tests alone.\n- `playwright-tests/` and `playwright.config.js`: Browser-level regression coverage.\n- `documentation/`: Generated site plus source markdown, demos, and the doc generator.\n  - `documentation/md/`: Documentation source.\n  - `documentation/demos/`: Demo apps and assets used by the docs site.\n  - `documentation/docmaker.mjs`: Docs build entrypoint.\n- `.github/workflows/`: CI and release workflows.\n- `benchmark/`: Performance comparisons and targeted benchmark runners.\n- `typescript/`: TypeScript-related tests and fixtures.\n\n## Code standards\n1. Preserve the existing style: two-space indentation, single quotes, ESM imports/exports, and concise readable functions.\n2. Do not hand-edit generated outputs when a source file exists instead. In particular, prefer editing `src/` and `documentation/md/` over generated files in `build/`, `dist/`, and compiled docs assets.\n3. Keep module boundaries aligned with the existing architecture. New source files should live near the corresponding subsystem in `src/`.\n4. When fixing a bug, add or update a regression test whenever practical. Put public-behaviour tests in `test/`; keep internal-only coverage in `test/modules/` when applicable.\n5. For renderer, gesture, or grab-state changes, verify behaviour in `debug/` because visual regressions are not always caught by Mocha alone.  You need to control a browser instance to use this and you need to run `npm run watch` to run a dev server with auto-rebuild.\n6. Keep docs in sync with API or behaviour changes. Update `documentation/md/`, demos, and `docmaker.json` inputs rather than patching generated HTML by hand.\n7. Avoid introducing new build tools, frameworks, or repo-wide conventions unless the task explicitly requires it.\n8. When adding new top-level workflows, major directories, or important source areas not already documented here, update `AGENTS.md`.\n\n## Testing notes\n- `npm test` matches CI closely: GitHub Actions installs dependencies, installs Playwright browsers, and runs `npm test`.\n- `npm run test:build` exercises the built bundle rather than source files; use it when a bug could be introduced by bundling or build-time transforms.\n- Playwright setup depends on a built UMD bundle and a local HTTP server. Use the existing scripts rather than inventing a parallel harness.\n\n## Documentation notes\n- Documentation HTML is generated. Do not edit generated docs directly when the corresponding markdown or template source (i.e. `docmaker.json` and `template.html`) should be changed instead.\n\n## Contribution notes\n- Keep changes narrowly scoped. Cytoscape.js has a large public API and small internal regressions can surface broadly.\n- Prefer extending existing tests, demos, and docs over adding parallel mechanisms.\n- If a change affects public API semantics, selectors, style behaviour, layouts, rendering, or documentation structure, call that out explicitly in your summary to the user.\n","category":"root","tokens":1591}]}