{"owner":"backstage","repo":"backstage","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".github/copilot-instructions.md"],"files":{"AGENTS.md":"---\nalwaysApply: true\n---\n\nBackstage is an open platform for building developer portals. This is a TypeScript monorepo using Yarn workspaces.\n\n## Key Directories\n\n- `/packages`: Core framework packages (prefixed `@backstage/`)\n- `/plugins`: Plugin packages (prefixed `@backstage/plugin-*`)\n- `/packages/app`: Main example app using the new frontend system\n- `/packages/app-legacy`: Example app using the old frontend system\n- `/packages/backend`: Example backend for local development\n- `/docs`: Documentation files\n\nPackages prefixed with `core-` (e.g., `@backstage/core-plugin-api`) are part of the old frontend system. Packages prefixed with `frontend-` (e.g., `@backstage/frontend-plugin-api`) are part of the new frontend system. Packages prefixed with `backend-` (e.g., `@backstage/backend-plugin-api`) are part of the backend system.\n\n## Writing Standards\n\nChanges to the docs should follow the documentation style guide at `/docs/contribute/doc-style-guide.md`.\n\n## Code Standards\n\nThe following files contain guidelines for the project:\n\n- `/CONTRIBUTING.md`: comprehensive contribution guidelines.\n- `/STYLE.md`: guidelines for code style.\n- `/REVIEWING.md`: guidelines for pull requests and writing changesets.\n- `/SECURITY.md`: guidelines for security.\n- `/docs/architecture-decisions/`: contains the architecture decisions for the project.\n\nAll new source files (`.ts`, `.tsx`, `.js`, `.jsx`) must include an Apache 2.0 copyright header with the current year. This does not apply to generated files, configuration files (JSON, YAML), or documentation files. Do NOT update the copyright year on existing files — leave the original year as-is.\n\nWhen writing or generating code, always match the existing coding style of each individual package and file. Different packages in the monorepo may have different conventions — consistency within a package is more important than consistency across the repo.\n\nWhen writing or generating tests, prefer fewer thorough tests with multiple assertions over many small tests. When using React Testing Library, prefer using `screen` and `.findBy*` queries over `waitFor`, and avoid adding test IDs to the implementation.\n\n## Development Flow\n\nBefore any of these commands can be run, you need to run `yarn install` in the project root.\n\n- Build: There is no need to build the project during development, and it is verified automatically in the CI pipeline.\n- Test: Use `CI=1 yarn test <path>` in the project root to run tests. The path can be either a single file or a directory. Always provide a path, avoid running all tests.\n- Type checking: Use `yarn tsc` in the project root to run the type checker. Do not try to run it somewhere else than the project root and do not supply any options.\n- Code formatting: Use `yarn prettier --write <...paths>` to format code. Run it explicitly for file paths that you know are changed, not for entire folders - otherwise it may change formatting of unrelated files.\n- Lint: Use `yarn lint --fix` in the project root to run the linter.\n- API reports: Before submitting a pull request with changes to any package in the workspace, run `yarn build:api-reports` in the project root to generate API reports for all packages.\n- Dev server: Use `yarn start` to run the example app locally (frontend on :3000, backend on :7007).\n- Create: Use `yarn new` to scaffold new plugins, packages, or modules.\n\nYou MUST NOT run builds or create a release by running `yarn build`, `yarn changesets version`, or `yarn release` as part of any changes. Builds and releases are made by separate workflows.\n\nAll changes that affect the published version of packages in the `/packages` and `/plugins` directories must be accompanied by a changeset. Changes outside of these directories (e.g. `.patches/`, `.github/`, `docs/`, root config files) do not need changesets. Only non-private packages require changesets. See the guidelines in `/CONTRIBUTING.md#creating-changesets` for information on how to write good changesets. Changesets are stored in the `/.changeset` directory and should be created by writing changeset files directly — never use the changeset CLI. Breaking changes must be accompanied by a `minor` version bump for packages below version `1.0.0`, or a `major` version bump for packages at version `1.0.0` or higher. For non-breaking changes that introduce new APIs or features, use `minor` for packages at version `1.0.0` or higher, and `patch` for packages below `1.0.0`. Each changeset message should be relevant to the specific package it targets and written for Backstage adopters as the audience — describe user-facing behavior changes in plain language. Never reference internal implementation details such as function names, class names, variable names, or other code symbols that are not part of the public API. If a change spans multiple packages you often need to create separate changesets to make sure they are tailored to each package.\n\nChanges that introduce new features or modify existing behavior must include documentation updates. Documentation should be placed in [TSDoc](https://tsdoc.org) comments, the package README, or within the `/docs` folder, whichever is most appropriate. Documentation should follow the style guide at `/docs/contribute/doc-style-guide.md`.\n\nBefore creating a pull request, check whether there is already an open PR for the same change to avoid duplicating effort.\n\nWhen creating pull requests, use the template at `/.github/PULL_REQUEST_TEMPLATE.md`. Do NOT erase or replace the template — fill it in and only check items on the checklist that have actually been completed. PR descriptions should be short and concise. If there are extensive details to share (design rationale, migration context, investigation notes), suggest opening a GitHub issue and linking to it from the PR instead. If the PR is related to an existing issue, link to it in the PR description.\n\nNever update ESLint, Prettier, or TypeScript configuration files unless specifically requested.\n\nNever make changes to the release notes in `/docs/releases` unless explicitly asked. These document past releases and should not be updated based on newer changes.\n\n## Repository Structure\n\nSee `/docs/contribute/project-structure.md` for a detailed description of the repository structure.\n",".github/copilot-instructions.md":"See `/AGENTS.md` for full repository structure, code standards, development flow, and contribution guidelines.\n\n## Pull Request Reviews\n\nWhen reviewing a pull request you MUST calculate a priority score between 0 and 100, where a higher score indicates higher priority. You MUST include the score as an HTML comment immediately after the `## PR Overview` heading, before any other content, using the following format:\n\n```markdown\n## PR Overview\n\n<!-- priority: <score> -->\n```\n\nThe score MUST be calculated as a sum of the following:\n\n- **60% Guideline Adherence**: How well does the pull request follow the project guidelines in `/STYLE.md`, `/REVIEWING.md`, `/CONTRIBUTING.md`, and `/SECURITY.md`? A pull request that fully adheres to all guidelines scores 60 points, while one that violates multiple guidelines scores closer to 0.\n\n- **40% Complexity**: How straightforward is the pull request? A simple bug fix or documentation update scores the full 40 points. A complex API change, new feature, or architectural modification scores closer to 0.\n\nHigher priority pull requests (higher scores) are those that are both well-crafted according to project standards AND easy to review and merge quickly.\n\n### Do NOT Review Automated PRs\n\nSkip reviews entirely for pull requests authored by any of these accounts:\n\n- `renovate[bot]` (dependency update bot)\n- `dependabot[bot]` (dependency update bot)\n- `backstage-service` (automated Backstage service account)\n- `backstage-goalie[bot]` (automated Backstage service account)\n\nThese PRs are managed through their own automated workflows and do not require code review from Copilot.\n\n### Review Guidelines\n\nWhen reviewing human-authored pull requests:\n\n- Check that a changeset is included for any changes to published (non-private) packages.\n- Confirm that new source files include the Apache 2.0 copyright header with the current year.\n- Confirm that existing source files have NOT had their copyright year updated.\n- Check that the PR description follows the template from `/.github/PULL_REQUEST_TEMPLATE.md`.\n- Verify that commits include `Signed-off-by` lines (DCO).\n- Check for consistent code style within the package being modified.\n- Verify tests are included for new functionality and bug fixes.\n- PRs that introduce new features or change existing behavior should include documentation updates. Documentation should be placed in [TSDoc](https://tsdoc.org) comments, the package README, or within the `/docs` folder, whichever is most appropriate.\n- Check that ESLint, Prettier, and TypeScript configs are not modified unless the PR explicitly states that as its purpose.\n- Check that release notes in `/docs/releases` are not modified unless the PR explicitly states that as its purpose.\n- Changes to the docs should follow the documentation style guide at `/docs/contribute/doc-style-guide.md`.\n"}}