{"owner":"apolloconfig","repo":"apollo","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":1161,"categories":["root-instruction","cursor-rule"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".cursorrules (react-graphql-apollo-client-cursorrules-prompt-file.mdc)"],"skills":{"AGENTS.md":"# Repository Guidelines\n\n## Project Structure & Module Organization\n- Multi-module Maven repo with root `pom.xml` and service modules like `apollo-configservice`, `apollo-adminservice`, and `apollo-portal`, shared libs in `apollo-common`, and packaging in `apollo-assembly`.\n- `apollo-biz` is a shared business-logic module used by services like config/admin (not a standalone service).\n- Build and release tooling lives in `scripts/` (e.g., `scripts/build.sh`) and `apollo-buildtools/` (code style configs).\n- Database and schema assets are under `scripts/sql` and module `src/main/resources` folders.\n- Tests follow standard Maven layout: `*/src/test/java` and `*/src/test/resources` inside each module.\n- Documentation is in `docs/`.\n\n## Build, Test, and Development Commands\n- `./mvnw -DskipTests package` builds all modules.\n- `./mvnw test` runs the full test suite via Surefire (may log warnings if local meta/admin services are not running).\n- `./mvnw -pl apollo-configservice -am test` runs tests for a specific module and its dependencies.\n- `./mvnw spotless:apply` formats code and must be run before opening a PR.\n- `./scripts/build.sh` generates distributable packages (used for deployment workflows).\n\n## Coding Style & Naming Conventions\n- Follow Google Java Style Guide; 2-space indentation and standard Java conventions apply.\n- Use the IDE configs in `apollo-buildtools/style/` (IntelliJ/Eclipse).\n- New Java classes should include a short Javadoc describing the class purpose.\n- Use standard Java naming: packages `lower.case`, classes `UpperCamelCase`, tests `*Test`.\n\n## OpenAPI Contract Workflow (apollo-portal)\n- Treat OpenAPI as contract-first: update spec in `apolloconfig/apollo-openapi` before (or together with) portal implementation changes.\n- `apollo-portal/pom.xml` uses `apollo.openapi.spec.url` + `openapi-generator-maven-plugin`; generated sources under `target/generated-sources/openapi/src/main/java` are added to compile path via `build-helper-maven-plugin`.\n- For new/changed OpenAPI endpoints, prefer implementing generated `*ManagementApi` interfaces and generated models; avoid introducing hand-written DTO/controller contracts that bypass the spec pipeline.\n- In PR review, verify contract alignment explicitly: endpoint path, request/response model, and permissions in `apollo` should match the spec in `apollo-openapi`.\n\n## Testing Guidelines\n- JUnit 5 is the default, with Vintage enabled for legacy JUnit 4 tests.\n- Put new tests under the module’s `src/test/java` with `*Test` suffix.\n- Add unit tests for new features or important bug fixes.\n\n## Commit & Pull Request Guidelines\n- Use Conventional Commits format (e.g., `feat:`, `fix:`).\n- If a commit fixes an issue, append `Fixes #123` in the commit message.\n- Commit only on feature branches; never commit directly to `master` or `main`.\n- `CHANGES.md` entries must use a PR URL in Markdown link format; if the PR URL is not available yet, open the PR first, then add/update `CHANGES.md` in a follow-up commit.\n- Rebase onto `master` and squash feature work into a single commit before merge.\n- When merging a PR on GitHub: if it has a single commit, use rebase and merge; if it has multiple commits, use squash and merge.\n- Non-trivial contributions require signing the CLA.\n- Open a feature branch for your change and submit a PR using `.github/PULL_REQUEST_TEMPLATE.md`.\n- PRs should include a clear description, tests run, and any relevant screenshots/logs; use GitHub issues for tracking.\n- The PR checklist expects `mvn clean test`, `mvn spotless:apply`, and an update to `CHANGES.md`.\n- For upstream contributions, open PRs against `apolloconfig/apollo` and fill the template with real content (not the raw template text).\n\n## Security & Configuration Notes\n- Apollo supports H2 in-memory for local development and MySQL for production; prefer H2 locally unless you need a real database.\n- Review `scripts/sql` and environment config when using MySQL.\n- Do not commit secrets or environment-specific credentials; use local overrides instead.\n- Follow `SECURITY.md` for vulnerability reporting.\n",".cursorrules (react-graphql-apollo-client-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for GraphQL development with Apollo Client integration.\"\nglobs: **/*\nalwaysApply: false\n---\n// React + GraphQL (Apollo Client) .cursorrules\n\n// Prefer functional components with hooks\n\nconst preferFunctionalComponents = true;\n\n// GraphQL and Apollo Client best practices\n\nconst graphqlBestPractices = [\n  \"Use Apollo Client for state management and data fetching\",\n  \"Implement query components for data fetching\",\n  \"Utilize mutations for data modifications\",\n  \"Use fragments for reusable query parts\",\n  \"Implement proper error handling and loading states\",\n];\n\n// Folder structure\n\nconst folderStructure = `\nsrc/\n  components/\n  graphql/\n    queries/\n    mutations/\n    fragments/\n  hooks/\n  pages/\n  utils/\n`;\n\n// Additional instructions\n\nconst additionalInstructions = `\n1. Use Apollo Provider at the root of your app\n2. Implement custom hooks for Apollo operations\n3. Use TypeScript for type safety with GraphQL operations\n4. Utilize Apollo Client's caching capabilities\n5. Implement proper error boundaries for GraphQL errors\n6. Use Apollo Client DevTools for debugging\n7. Follow naming conventions for queries, mutations, and fragments\n`;\n"},"files":{"AGENTS.md":"# Repository Guidelines\n\n## Project Structure & Module Organization\n- Multi-module Maven repo with root `pom.xml` and service modules like `apollo-configservice`, `apollo-adminservice`, and `apollo-portal`, shared libs in `apollo-common`, and packaging in `apollo-assembly`.\n- `apollo-biz` is a shared business-logic module used by services like config/admin (not a standalone service).\n- Build and release tooling lives in `scripts/` (e.g., `scripts/build.sh`) and `apollo-buildtools/` (code style configs).\n- Database and schema assets are under `scripts/sql` and module `src/main/resources` folders.\n- Tests follow standard Maven layout: `*/src/test/java` and `*/src/test/resources` inside each module.\n- Documentation is in `docs/`.\n\n## Build, Test, and Development Commands\n- `./mvnw -DskipTests package` builds all modules.\n- `./mvnw test` runs the full test suite via Surefire (may log warnings if local meta/admin services are not running).\n- `./mvnw -pl apollo-configservice -am test` runs tests for a specific module and its dependencies.\n- `./mvnw spotless:apply` formats code and must be run before opening a PR.\n- `./scripts/build.sh` generates distributable packages (used for deployment workflows).\n\n## Coding Style & Naming Conventions\n- Follow Google Java Style Guide; 2-space indentation and standard Java conventions apply.\n- Use the IDE configs in `apollo-buildtools/style/` (IntelliJ/Eclipse).\n- New Java classes should include a short Javadoc describing the class purpose.\n- Use standard Java naming: packages `lower.case`, classes `UpperCamelCase`, tests `*Test`.\n\n## OpenAPI Contract Workflow (apollo-portal)\n- Treat OpenAPI as contract-first: update spec in `apolloconfig/apollo-openapi` before (or together with) portal implementation changes.\n- `apollo-portal/pom.xml` uses `apollo.openapi.spec.url` + `openapi-generator-maven-plugin`; generated sources under `target/generated-sources/openapi/src/main/java` are added to compile path via `build-helper-maven-plugin`.\n- For new/changed OpenAPI endpoints, prefer implementing generated `*ManagementApi` interfaces and generated models; avoid introducing hand-written DTO/controller contracts that bypass the spec pipeline.\n- In PR review, verify contract alignment explicitly: endpoint path, request/response model, and permissions in `apollo` should match the spec in `apollo-openapi`.\n\n## Testing Guidelines\n- JUnit 5 is the default, with Vintage enabled for legacy JUnit 4 tests.\n- Put new tests under the module’s `src/test/java` with `*Test` suffix.\n- Add unit tests for new features or important bug fixes.\n\n## Commit & Pull Request Guidelines\n- Use Conventional Commits format (e.g., `feat:`, `fix:`).\n- If a commit fixes an issue, append `Fixes #123` in the commit message.\n- Commit only on feature branches; never commit directly to `master` or `main`.\n- `CHANGES.md` entries must use a PR URL in Markdown link format; if the PR URL is not available yet, open the PR first, then add/update `CHANGES.md` in a follow-up commit.\n- Rebase onto `master` and squash feature work into a single commit before merge.\n- When merging a PR on GitHub: if it has a single commit, use rebase and merge; if it has multiple commits, use squash and merge.\n- Non-trivial contributions require signing the CLA.\n- Open a feature branch for your change and submit a PR using `.github/PULL_REQUEST_TEMPLATE.md`.\n- PRs should include a clear description, tests run, and any relevant screenshots/logs; use GitHub issues for tracking.\n- The PR checklist expects `mvn clean test`, `mvn spotless:apply`, and an update to `CHANGES.md`.\n- For upstream contributions, open PRs against `apolloconfig/apollo` and fill the template with real content (not the raw template text).\n\n## Security & Configuration Notes\n- Apollo supports H2 in-memory for local development and MySQL for production; prefer H2 locally unless you need a real database.\n- Review `scripts/sql` and environment config when using MySQL.\n- Do not commit secrets or environment-specific credentials; use local overrides instead.\n- Follow `SECURITY.md` for vulnerability reporting.\n",".cursorrules (react-graphql-apollo-client-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for GraphQL development with Apollo Client integration.\"\nglobs: **/*\nalwaysApply: false\n---\n// React + GraphQL (Apollo Client) .cursorrules\n\n// Prefer functional components with hooks\n\nconst preferFunctionalComponents = true;\n\n// GraphQL and Apollo Client best practices\n\nconst graphqlBestPractices = [\n  \"Use Apollo Client for state management and data fetching\",\n  \"Implement query components for data fetching\",\n  \"Utilize mutations for data modifications\",\n  \"Use fragments for reusable query parts\",\n  \"Implement proper error handling and loading states\",\n];\n\n// Folder structure\n\nconst folderStructure = `\nsrc/\n  components/\n  graphql/\n    queries/\n    mutations/\n    fragments/\n  hooks/\n  pages/\n  utils/\n`;\n\n// Additional instructions\n\nconst additionalInstructions = `\n1. Use Apollo Provider at the root of your app\n2. Implement custom hooks for Apollo operations\n3. Use TypeScript for type safety with GraphQL operations\n4. Utilize Apollo Client's caching capabilities\n5. Implement proper error boundaries for GraphQL errors\n6. Use Apollo Client DevTools for debugging\n7. Follow naming conventions for queries, mutations, and fragments\n`;\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/apolloconfig/apollo/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Repository Guidelines\n\n## Project Structure & Module Organization\n- Multi-module Maven repo with root `pom.xml` and service modules like `apollo-configservice`, `apollo-adminservice`, and `apollo-portal`, shared libs in `apollo-common`, and packaging in `apollo-assembly`.\n- `apollo-biz` is a shared business-logic module used by services like config/admin (not a standalone service).\n- Build and release tooling lives in `scripts/` (e.g., `scripts/build.sh`) and `apollo-buildtools/` (code style configs).\n- Database and schema assets are under `scripts/sql` and module `src/main/resources` folders.\n- Tests follow standard Maven layout: `*/src/test/java` and `*/src/test/resources` inside each module.\n- Documentation is in `docs/`.\n\n## Build, Test, and Development Commands\n- `./mvnw -DskipTests package` builds all modules.\n- `./mvnw test` runs the full test suite via Surefire (may log warnings if local meta/admin services are not running).\n- `./mvnw -pl apollo-configservice -am test` runs tests for a specific module and its dependencies.\n- `./mvnw spotless:apply` formats code and must be run before opening a PR.\n- `./scripts/build.sh` generates distributable packages (used for deployment workflows).\n\n## Coding Style & Naming Conventions\n- Follow Google Java Style Guide; 2-space indentation and standard Java conventions apply.\n- Use the IDE configs in `apollo-buildtools/style/` (IntelliJ/Eclipse).\n- New Java classes should include a short Javadoc describing the class purpose.\n- Use standard Java naming: packages `lower.case`, classes `UpperCamelCase`, tests `*Test`.\n\n## OpenAPI Contract Workflow (apollo-portal)\n- Treat OpenAPI as contract-first: update spec in `apolloconfig/apollo-openapi` before (or together with) portal implementation changes.\n- `apollo-portal/pom.xml` uses `apollo.openapi.spec.url` + `openapi-generator-maven-plugin`; generated sources under `target/generated-sources/openapi/src/main/java` are added to compile path via `build-helper-maven-plugin`.\n- For new/changed OpenAPI endpoints, prefer implementing generated `*ManagementApi` interfaces and generated models; avoid introducing hand-written DTO/controller contracts that bypass the spec pipeline.\n- In PR review, verify contract alignment explicitly: endpoint path, request/response model, and permissions in `apollo` should match the spec in `apollo-openapi`.\n\n## Testing Guidelines\n- JUnit 5 is the default, with Vintage enabled for legacy JUnit 4 tests.\n- Put new tests under the module’s `src/test/java` with `*Test` suffix.\n- Add unit tests for new features or important bug fixes.\n\n## Commit & Pull Request Guidelines\n- Use Conventional Commits format (e.g., `feat:`, `fix:`).\n- If a commit fixes an issue, append `Fixes #123` in the commit message.\n- Commit only on feature branches; never commit directly to `master` or `main`.\n- `CHANGES.md` entries must use a PR URL in Markdown link format; if the PR URL is not available yet, open the PR first, then add/update `CHANGES.md` in a follow-up commit.\n- Rebase onto `master` and squash feature work into a single commit before merge.\n- When merging a PR on GitHub: if it has a single commit, use rebase and merge; if it has multiple commits, use squash and merge.\n- Non-trivial contributions require signing the CLA.\n- Open a feature branch for your change and submit a PR using `.github/PULL_REQUEST_TEMPLATE.md`.\n- PRs should include a clear description, tests run, and any relevant screenshots/logs; use GitHub issues for tracking.\n- The PR checklist expects `mvn clean test`, `mvn spotless:apply`, and an update to `CHANGES.md`.\n- For upstream contributions, open PRs against `apolloconfig/apollo` and fill the template with real content (not the raw template text).\n\n## Security & Configuration Notes\n- Apollo supports H2 in-memory for local development and MySQL for production; prefer H2 locally unless you need a real database.\n- Review `scripts/sql` and environment config when using MySQL.\n- Do not commit secrets or environment-specific credentials; use local overrides instead.\n- Follow `SECURITY.md` for vulnerability reporting.\n","isInternal":false,"tokens":924,"sizeBytes":4103},{"name":".cursorrules","path":".cursorrules (react-graphql-apollo-client-cursorrules-prompt-file.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/react-graphql-apollo-client-cursorrules-prompt-file.mdc","title":"Awesome Cursorrules: react graphql apollo client","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for GraphQL development with Apollo Client integration.\"\nglobs: **/*\nalwaysApply: false\n---\n// React + GraphQL (Apollo Client) .cursorrules\n\n// Prefer functional components with hooks\n\nconst preferFunctionalComponents = true;\n\n// GraphQL and Apollo Client best practices\n\nconst graphqlBestPractices = [\n  \"Use Apollo Client for state management and data fetching\",\n  \"Implement query components for data fetching\",\n  \"Utilize mutations for data modifications\",\n  \"Use fragments for reusable query parts\",\n  \"Implement proper error handling and loading states\",\n];\n\n// Folder structure\n\nconst folderStructure = `\nsrc/\n  components/\n  graphql/\n    queries/\n    mutations/\n    fragments/\n  hooks/\n  pages/\n  utils/\n`;\n\n// Additional instructions\n\nconst additionalInstructions = `\n1. Use Apollo Provider at the root of your app\n2. Implement custom hooks for Apollo operations\n3. Use TypeScript for type safety with GraphQL operations\n4. Utilize Apollo Client's caching capabilities\n5. Implement proper error boundaries for GraphQL errors\n6. Use Apollo Client DevTools for debugging\n7. Follow naming conventions for queries, mutations, and fragments\n`;\n","tokens":237,"sizeBytes":1179}],"systemPromptSnippet":"<yakaai_skills repo=\"apolloconfig/apollo\">\n<!-- File: AGENTS.md (Tokens: ~924 | Category: root-instruction) -->\n# Repository Guidelines\n\n## Project Structure & Module Organization\n- Multi-module Maven repo with root `pom.xml` and service modules like `apollo-configservice`, `apollo-adminservice`, and `apollo-portal`, shared libs in `apollo-common`, and packaging in `apollo-assembly`.\n- `apollo-biz` is a shared business-logic module used by services like config/admin (not a standalone service).\n- Build and release tooling lives in `scripts/` (e.g., `scripts/build.sh`) and `apollo-buildtools/` (code style configs).\n- Database and schema assets are under `scripts/sql` and module `src/main/resources` folders.\n- Tests follow standard Maven layout: `*/src/test/java` and `*/src/test/resources` inside each module.\n- Documentation is in `docs/`.\n\n## Build, Test, and Development Commands\n- `./mvnw -DskipTests package` builds all modules.\n- `./mvnw test` runs the full test suite via Surefire (may log warnings if local meta/admin services are not running).\n- `./mvnw -pl apollo-configservice -am test` runs tests for a specific module and its dependencies.\n- `./mvnw spotless:apply` formats code and must be run before opening a PR.\n- `./scripts/build.sh` generates distributable packages (used for deployment workflows).\n\n## Coding Style & Naming Conventions\n- Follow Google Java Style Guide; 2-space indentation and standard Java conventions apply.\n- Use the IDE configs in `apollo-buildtools/style/` (IntelliJ/Eclipse).\n- New Java classes should include a short Javadoc describing the class purpose.\n- Use standard Java naming: packages `lower.case`, classes `UpperCamelCase`, tests `*Test`.\n\n## OpenAPI Contract Workflow (apollo-portal)\n- Treat OpenAPI as contract-first: update spec in `apolloconfig/apollo-openapi` before (or together with) portal implementation changes.\n- `apollo-portal/pom.xml` uses `apollo.openapi.spec.url` + `openapi-generator-maven-plugin`; generated sources under `target/generated-sources/openapi/src/main/java` are added to compile path via `build-helper-maven-plugin`.\n- For new/changed OpenAPI endpoints, prefer implementing generated `*ManagementApi` interfaces and generated models; avoid introducing hand-written DTO/controller contracts that bypass the spec pipeline.\n- In PR review, verify contract alignment explicitly: endpoint path, request/response model, and permissions in `apollo` should match the spec in `apollo-openapi`.\n\n## Testing Guidelines\n- JUnit 5 is the default, with Vintage enabled for legacy JUnit 4 tests.\n- Put new tests under the module’s `src/test/java` with `*Test` suffix.\n- Add unit tests for new features or important bug fixes.\n\n## Commit & Pull Request Guidelines\n- Use Conventional Commits format (e.g., `feat:`, `fix:`).\n- If a commit fixes an issue, append `Fixes #123` in the commit message.\n- Commit only on feature branches; never commit directly to `master` or `main`.\n- `CHANGES.md` entries must use a PR URL in Markdown link format; if the PR URL is not available yet, open the PR first, then add/update `CHANGES.md` in a follow-up commit.\n- Rebase onto `master` and squash feature work into a single commit before merge.\n- When merging a PR on GitHub: if it has a single commit, use rebase and merge; if it has multiple commits, use squash and merge.\n- Non-trivial contributions require signing the CLA.\n- Open a feature branch for your change and submit a PR using `.github/PULL_REQUEST_TEMPLATE.md`.\n- PRs should include a clear description, tests run, and any relevant screenshots/logs; use GitHub issues for tracking.\n- The PR checklist expects `mvn clean test`, `mvn spotless:apply`, and an update to `CHANGES.md`.\n- For upstream contributions, open PRs against `apolloconfig/apollo` and fill the template with real content (not the raw template text).\n\n## Security & Configuration Notes\n- Apollo supports H2 in-memory for local development and MySQL for production; prefer H2 locally unless you need a real database.\n- Review `scripts/sql` and environment config when using MySQL.\n- Do not commit secrets or environment-specific credentials; use local overrides instead.\n- Follow `SECURITY.md` for vulnerability reporting.\n\n<!-- File: .cursorrules (react-graphql-apollo-client-cursorrules-prompt-file.mdc) (Tokens: ~237 | Category: cursor-rule) -->\n---\ndescription: \"Cursor rules for GraphQL development with Apollo Client integration.\"\nglobs: **/*\nalwaysApply: false\n---\n// React + GraphQL (Apollo Client) .cursorrules\n\n// Prefer functional components with hooks\n\nconst preferFunctionalComponents = true;\n\n// GraphQL and Apollo Client best practices\n\nconst graphqlBestPractices = [\n  \"Use Apollo Client for state management and data fetching\",\n  \"Implement query components for data fetching\",\n  \"Utilize mutations for data modifications\",\n  \"Use fragments for reusable query parts\",\n  \"Implement proper error handling and loading states\",\n];\n\n// Folder structure\n\nconst folderStructure = `\nsrc/\n  components/\n  graphql/\n    queries/\n    mutations/\n    fragments/\n  hooks/\n  pages/\n  utils/\n`;\n\n// Additional instructions\n\nconst additionalInstructions = `\n1. Use Apollo Provider at the root of your app\n2. Implement custom hooks for Apollo operations\n3. Use TypeScript for type safety with GraphQL operations\n4. Utilize Apollo Client's caching capabilities\n5. Implement proper error boundaries for GraphQL errors\n6. Use Apollo Client DevTools for debugging\n7. Follow naming conventions for queries, mutations, and fragments\n`;\n</yakaai_skills>"}