{"owner":"carbon-design-system","repo":"carbon","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"<!--\nHUMAN MAINTAINERS:\nThis file should be as short as possible. More length = more tokens used.\n-->\n\nThis is a monorepo for IBM's Carbon Design System that contains React\ncomponents, web components, Sass styles, foundational elements (colors, grid,\nicons, pictograms, layout, motion, themes, type), and tooling.\n\n# Repository Guidelines\n\n- The correct Node version to use is present in `.nvmrc`\n- Yarn workspaces manage dependencies and package relationships\n- `package.json` scripts make use of Lerna for build and task sequencing\n\n## Workflow details\n\n- Avoid scanning the entire repo as a first step. Start from the most necessary\n  surface for the task and expand or drill down only when necessary\n- Follow the coding style guide, see `docs/style.md`\n- Follow the developer guide, see `docs/developer-handbook.md`\n- Project decisions are recorded through Architecture Decision Records (ADRs) in\n  `docs/decisions/`\n- For procedural instructions on various tasks for maintainers, see\n  `docs/guides/`\n- The approach for delivering experimental, feature-flagged, \"preview\" code:\n  `docs/experimental-code.md`, `docs/feature-flags.md`, `docs/preview-code.md`\n- Every code change that affects v12 behavior, including code exercised through\n  `enable-v12-release`, an individual `enable-v12-*` flag, or a related package\n  change, must meaningfully update `docs/migration/v12.md` in the same change.\n  Keep it accurate for a consumer or agent migrating from v11 to v12: update an\n  existing section when possible, document only consumer-visible behavior and\n  migration burden, and omit internal details or maintainer notes. Do not\n  duplicate flag or codemod metadata. See\n  `docs/working-with-v12.md#required-v12-migration-documentation`.\n- Linting, formatting, build and tests should all pass before committing\n- Before opening or reviewing a pull request (PR), follow the instructions:\n  `docs/guides/reviewing-pull-requests.md`\n- When opening a PR, always use and fill out the pull request template:\n  `.github/PULL_REQUEST_TEMPLATE.md`\n- When opening an issue, always use a template: `.github/ISSUE_TEMPLATE/*.yaml`\n\n## Package relationships\n\n- The packages contained within this monorepo and published to NPM are\n  intentionally layered on top of each other. Higher-level packages re-export or\n  wrap lower-level packages.\n- A directory-to-package mapping is generated from the build:\n  `docs/generated/package-structure.json`\n- A detailed graph of packages and their relationships is generated from the\n  build: `docs/generated/package-structure-graph.json`\n\n## Package-specific details\n\n- A dual-flagship model is followed for `@carbon/react` and\n  `@carbon/web-components`. These two are intended to provide an equal\n  experience for consumers choosing to build with either library. Visual and\n  functional parity are paramount, though the implementations themselves are\n  allowed to diverge as necessary. Opportunities to unify logic between the two\n  can be considered and surfaced as an option when appropriate. Framework\n  conventions should be prioritized over logic unification when beneficial to\n  either/both packages in areas included, but not limited to, performance\n  optimization and ease of maintenance.\n- `carbon-components` is a deprecated package that re-exports `@carbon/styles`\n- `carbon-components-react` is a deprecated package that re-exports\n  `@carbon/react`\n\n## End user/practitioner guidance\n\nIf the task is complicated and specialized enough to require it, there is\nexternal documentation focused towards end users of the system (designers,\ndevelopers, product managers)\n\n- Detailed design and usage information for the system as a whole:\n  https://github.com/carbon-design-system/carbon-website/tree/main/src/pages\n- Developer-focused, component-specific usage docs are surfaced through\n  storybook and housed in colocated `.mdx` files.\n"},"files":{"AGENTS.md":"<!--\nHUMAN MAINTAINERS:\nThis file should be as short as possible. More length = more tokens used.\n-->\n\nThis is a monorepo for IBM's Carbon Design System that contains React\ncomponents, web components, Sass styles, foundational elements (colors, grid,\nicons, pictograms, layout, motion, themes, type), and tooling.\n\n# Repository Guidelines\n\n- The correct Node version to use is present in `.nvmrc`\n- Yarn workspaces manage dependencies and package relationships\n- `package.json` scripts make use of Lerna for build and task sequencing\n\n## Workflow details\n\n- Avoid scanning the entire repo as a first step. Start from the most necessary\n  surface for the task and expand or drill down only when necessary\n- Follow the coding style guide, see `docs/style.md`\n- Follow the developer guide, see `docs/developer-handbook.md`\n- Project decisions are recorded through Architecture Decision Records (ADRs) in\n  `docs/decisions/`\n- For procedural instructions on various tasks for maintainers, see\n  `docs/guides/`\n- The approach for delivering experimental, feature-flagged, \"preview\" code:\n  `docs/experimental-code.md`, `docs/feature-flags.md`, `docs/preview-code.md`\n- Every code change that affects v12 behavior, including code exercised through\n  `enable-v12-release`, an individual `enable-v12-*` flag, or a related package\n  change, must meaningfully update `docs/migration/v12.md` in the same change.\n  Keep it accurate for a consumer or agent migrating from v11 to v12: update an\n  existing section when possible, document only consumer-visible behavior and\n  migration burden, and omit internal details or maintainer notes. Do not\n  duplicate flag or codemod metadata. See\n  `docs/working-with-v12.md#required-v12-migration-documentation`.\n- Linting, formatting, build and tests should all pass before committing\n- Before opening or reviewing a pull request (PR), follow the instructions:\n  `docs/guides/reviewing-pull-requests.md`\n- When opening a PR, always use and fill out the pull request template:\n  `.github/PULL_REQUEST_TEMPLATE.md`\n- When opening an issue, always use a template: `.github/ISSUE_TEMPLATE/*.yaml`\n\n## Package relationships\n\n- The packages contained within this monorepo and published to NPM are\n  intentionally layered on top of each other. Higher-level packages re-export or\n  wrap lower-level packages.\n- A directory-to-package mapping is generated from the build:\n  `docs/generated/package-structure.json`\n- A detailed graph of packages and their relationships is generated from the\n  build: `docs/generated/package-structure-graph.json`\n\n## Package-specific details\n\n- A dual-flagship model is followed for `@carbon/react` and\n  `@carbon/web-components`. These two are intended to provide an equal\n  experience for consumers choosing to build with either library. Visual and\n  functional parity are paramount, though the implementations themselves are\n  allowed to diverge as necessary. Opportunities to unify logic between the two\n  can be considered and surfaced as an option when appropriate. Framework\n  conventions should be prioritized over logic unification when beneficial to\n  either/both packages in areas included, but not limited to, performance\n  optimization and ease of maintenance.\n- `carbon-components` is a deprecated package that re-exports `@carbon/styles`\n- `carbon-components-react` is a deprecated package that re-exports\n  `@carbon/react`\n\n## End user/practitioner guidance\n\nIf the task is complicated and specialized enough to require it, there is\nexternal documentation focused towards end users of the system (designers,\ndevelopers, product managers)\n\n- Detailed design and usage information for the system as a whole:\n  https://github.com/carbon-design-system/carbon-website/tree/main/src/pages\n- Developer-focused, component-specific usage docs are surfaced through\n  storybook and housed in colocated `.mdx` files.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"<!--\nHUMAN MAINTAINERS:\nThis file should be as short as possible. More length = more tokens used.\n-->\n\nThis is a monorepo for IBM's Carbon Design System that contains React\ncomponents, web components, Sass styles, foundational elements (colors, grid,\nicons, pictograms, layout, motion, themes, type), and tooling.\n\n# Repository Guidelines\n\n- The correct Node version to use is present in `.nvmrc`\n- Yarn workspaces manage dependencies and package relationships\n- `package.json` scripts make use of Lerna for build and task sequencing\n\n## Workflow details\n\n- Avoid scanning the entire repo as a first step. Start from the most necessary\n  surface for the task and expand or drill down only when necessary\n- Follow the coding style guide, see `docs/style.md`\n- Follow the developer guide, see `docs/developer-handbook.md`\n- Project decisions are recorded through Architecture Decision Records (ADRs) in\n  `docs/decisions/`\n- For procedural instructions on various tasks for maintainers, see\n  `docs/guides/`\n- The approach for delivering experimental, feature-flagged, \"preview\" code:\n  `docs/experimental-code.md`, `docs/feature-flags.md`, `docs/preview-code.md`\n- Every code change that affects v12 behavior, including code exercised through\n  `enable-v12-release`, an individual `enable-v12-*` flag, or a related package\n  change, must meaningfully update `docs/migration/v12.md` in the same change.\n  Keep it accurate for a consumer or agent migrating from v11 to v12: update an\n  existing section when possible, document only consumer-visible behavior and\n  migration burden, and omit internal details or maintainer notes. Do not\n  duplicate flag or codemod metadata. See\n  `docs/working-with-v12.md#required-v12-migration-documentation`.\n- Linting, formatting, build and tests should all pass before committing\n- Before opening or reviewing a pull request (PR), follow the instructions:\n  `docs/guides/reviewing-pull-requests.md`\n- When opening a PR, always use and fill out the pull request template:\n  `.github/PULL_REQUEST_TEMPLATE.md`\n- When opening an issue, always use a template: `.github/ISSUE_TEMPLATE/*.yaml`\n\n## Package relationships\n\n- The packages contained within this monorepo and published to NPM are\n  intentionally layered on top of each other. Higher-level packages re-export or\n  wrap lower-level packages.\n- A directory-to-package mapping is generated from the build:\n  `docs/generated/package-structure.json`\n- A detailed graph of packages and their relationships is generated from the\n  build: `docs/generated/package-structure-graph.json`\n\n## Package-specific details\n\n- A dual-flagship model is followed for `@carbon/react` and\n  `@carbon/web-components`. These two are intended to provide an equal\n  experience for consumers choosing to build with either library. Visual and\n  functional parity are paramount, though the implementations themselves are\n  allowed to diverge as necessary. Opportunities to unify logic between the two\n  can be considered and surfaced as an option when appropriate. Framework\n  conventions should be prioritized over logic unification when beneficial to\n  either/both packages in areas included, but not limited to, performance\n  optimization and ease of maintenance.\n- `carbon-components` is a deprecated package that re-exports `@carbon/styles`\n- `carbon-components-react` is a deprecated package that re-exports\n  `@carbon/react`\n\n## End user/practitioner guidance\n\nIf the task is complicated and specialized enough to require it, there is\nexternal documentation focused towards end users of the system (designers,\ndevelopers, product managers)\n\n- Detailed design and usage information for the system as a whole:\n  https://github.com/carbon-design-system/carbon-website/tree/main/src/pages\n- Developer-focused, component-specific usage docs are surfaced through\n  storybook and housed in colocated `.mdx` files.\n","category":"root","tokens":969}]}