{"owner":"webiny","repo":"webiny-js","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md",".github/copilot-instructions.md"],"skills":{"AGENTS.md":"## Exploration\n\n- DO NOT read code in `dist` folders.\n\n## Persist Learnings\n\nWhen new backend features are discovered, update `ai-context/core-features-reference.md` with the new feature reference. DO NOT update this file with React features.\n\n## Code\n\nCode-style rules live in `ai-context/code-style/`, one rule per file (ESLint-style `do this / don't do this`). Read every rule in that folder before writing or editing code; see `ai-context/code-style/README.md` for the index. When adding a new rule, create a new `*.md` file there and add it to the index.\n\n- When generating code, once done, run `git add .` to stage all changes.\n\n## Building\n\n- When type checking, use `yarn check -p <package-name>`, e.g., `yarn check -p @webiny/api-core`\n- When building a single package, use `yarn build -p <package-name> --safe-replace`, e.g., `yarn build -p @webiny/api-core --safe-replace`. We use \"--safe-replace\" in order to not have our active bundling watch process break.\n- To build all packages, simply run `yarn build`.\n- To build all packages without caching, use `yarn build --no-cache `.\n\n## Testing\n\n- To test a package, use `yarn test packages/<package-name>`, e.g., `yarn test packages/api-core`\n\n## Commits\n\n- Always run the full pre-commit checklist and commit after every code change — do not wait to be asked:\n  ```bash\n  git add .\n  yarn > /dev/null 2>&1\n  node scripts/generateTsConfigsInPackages.js\n  yarn adio\n  yarn format > /dev/null 2>&1\n  yarn lint\n  yarn webiny sync-dependencies\n  git add .\n  ```\n  If any step fixes something, rerun from the top before committing.\n- Avoid overly verbose descriptions or unnecessary details.\n- Use conventional commit message formats like:\n  - feat: for new features\n  - fix: for bug fixes\n  - docs: for documentation changes\n\n## Entry Data Factory Pattern (`api-headless-cms`)\n\nEntry data factories are injectable features, not imported functions. When writing use cases in `packages/api-headless-cms` that need to produce domain entry objects:\n\n- **Do not** import from `~/crud/contentEntry/entryDataFactories/`\n- **Do** inject the factory token via `createImplementation` dependencies and call `this.xyzFactory.create(...)`\n- Factories live in `packages/api-headless-cms/src/features/contentEntry/entryDataFactories/`\n- Token scope: `\"Cms/Entry/<FactoryName>\"` (e.g. `\"Cms/Entry/CreateEntryDataFactory\"`)\n- All factories are singletons\n\nAvailable factories:\n\n- `CreateEntryDataFactory` — new entry from raw input\n- `UpdateEntryDataFactory` — update existing entry\n- `CreateEntryRevisionFromDataFactory` — new revision from existing entry\n- `CreatePublishEntryDataFactory` — transition to published state\n- `CreateUnpublishEntryDataFactory` — transition to unpublished state\n- `CreateRepublishEntryDataFactory` — re-publish with refreshed references\n\n## Webiny\n\nThis project uses the Webiny framework.\nA `webiny` MCP server is available.\nWhen helping with Webiny-related tasks:\n\n1. Call `list_webiny_skills` to see available skills.\n2. Call `get_webiny_skill` with the relevant topic before writing code.\n\n## CI/CD - GitHub Actions\n\nWhen working on GitHub Actions workflows, when possible, we always want to make modifications on `.github/workflows/wac` TS files first, and then emit YAML files via `yarn ci-workflows:build`. Only work on YAML files if a corresponding .wac.ts file does not exist.\n","CLAUDE.md":"# Context\n\nRead `AGENTS.md`.\n\n# Claude Project Guidelines\n\nThis file is read by Claude Code on every run. Keep it up to date with your project's conventions.\n\n# Reading code\n\nNEVER call Read or Grep to understand code structure or locate symbols.\nYou MUST use codegraph_context, codegraph_search, or codegraph_callers first.\nOnly call Read if codegraph explicitly returns no results AND you explain why in your response.\n\n## Development Commands\n\nAlways suppress verbose output to keep token usage low.\nRedirect stdout to `/dev/null` for noisy commands and capture only stderr,\nor use `tail` to capture just the last few lines when you need a summary.\n\n```bash\n# Install dependencies  (suppress all output – it's noise)\nyarn > /dev/null 2>&1\n\n# Run tests  (keep output – failures matter, but cap at last 50 lines)\nyarn test packages/{package-name} 2>&1 | tail -50\n\n# Build all changed packages  (capture last 30 lines to see result without full log)\nyarn build 2>&1 | tail -30\n\n# Build a single package  (capture last 30 lines to see result without full log)\nyarn build -p @webiny/api-core 2>&1 | tail -30\n```\n\n## Before Commit\n\nBefore each commit, run the following commands:\n\n```\n# Stage all changed files\ngit add .\n\n# Ensure yarn.lock is up to date\nyarn > /dev/null 2>&1\n\n# Update all tsconfig files\nnode scripts/generateTsConfigsInPackages.js\n\n# Make sure all package.json deps are configured correctly\nyarn adio\n\n# Format changed files\nyarn format > /dev/null 2>&1\n\n# Run oxlint\nyarn lint\n\n# Make sure dependencies are in sync\nyarn webiny sync-dependencies\n\n# Stage all changed files (again!)\ngit add .\n```\n\nIf any of the steps fail, and you fix anything, you must rerun all scripts from the beginning.\n\n## Code Conventions\n\n- **Formatting:** oxfmt with project defaults (`.oxfmtrc.json`)\n- **Linting:** Oxlint with project config (`.oxlintrc.json`)\n- **Commit style:** Conventional Commits (`feat:`, `fix:`, `chore:`, etc.)\n- **Branch naming:** `claude/issue-<number>` for Claude-generated branches\n- **PR titles:** Mirror the commit style\n\n## Webiny\n\nThis project uses the Webiny framework.\nA `webiny` MCP server is available.\nWhen helping with Webiny-related tasks, call `get_started()` first.\n",".github/copilot-instructions.md":"# Instructions For GitHub Copilot\n\n- once done with code changes, run \"npx pretty-quick --staged\" to format all staged files before committing\n- make PR body concise and to the point, summarizing the key changes and their purpose without unnecessary elaboration\n"},"files":{"AGENTS.md":"## Exploration\n\n- DO NOT read code in `dist` folders.\n\n## Persist Learnings\n\nWhen new backend features are discovered, update `ai-context/core-features-reference.md` with the new feature reference. DO NOT update this file with React features.\n\n## Code\n\nCode-style rules live in `ai-context/code-style/`, one rule per file (ESLint-style `do this / don't do this`). Read every rule in that folder before writing or editing code; see `ai-context/code-style/README.md` for the index. When adding a new rule, create a new `*.md` file there and add it to the index.\n\n- When generating code, once done, run `git add .` to stage all changes.\n\n## Building\n\n- When type checking, use `yarn check -p <package-name>`, e.g., `yarn check -p @webiny/api-core`\n- When building a single package, use `yarn build -p <package-name> --safe-replace`, e.g., `yarn build -p @webiny/api-core --safe-replace`. We use \"--safe-replace\" in order to not have our active bundling watch process break.\n- To build all packages, simply run `yarn build`.\n- To build all packages without caching, use `yarn build --no-cache `.\n\n## Testing\n\n- To test a package, use `yarn test packages/<package-name>`, e.g., `yarn test packages/api-core`\n\n## Commits\n\n- Always run the full pre-commit checklist and commit after every code change — do not wait to be asked:\n  ```bash\n  git add .\n  yarn > /dev/null 2>&1\n  node scripts/generateTsConfigsInPackages.js\n  yarn adio\n  yarn format > /dev/null 2>&1\n  yarn lint\n  yarn webiny sync-dependencies\n  git add .\n  ```\n  If any step fixes something, rerun from the top before committing.\n- Avoid overly verbose descriptions or unnecessary details.\n- Use conventional commit message formats like:\n  - feat: for new features\n  - fix: for bug fixes\n  - docs: for documentation changes\n\n## Entry Data Factory Pattern (`api-headless-cms`)\n\nEntry data factories are injectable features, not imported functions. When writing use cases in `packages/api-headless-cms` that need to produce domain entry objects:\n\n- **Do not** import from `~/crud/contentEntry/entryDataFactories/`\n- **Do** inject the factory token via `createImplementation` dependencies and call `this.xyzFactory.create(...)`\n- Factories live in `packages/api-headless-cms/src/features/contentEntry/entryDataFactories/`\n- Token scope: `\"Cms/Entry/<FactoryName>\"` (e.g. `\"Cms/Entry/CreateEntryDataFactory\"`)\n- All factories are singletons\n\nAvailable factories:\n\n- `CreateEntryDataFactory` — new entry from raw input\n- `UpdateEntryDataFactory` — update existing entry\n- `CreateEntryRevisionFromDataFactory` — new revision from existing entry\n- `CreatePublishEntryDataFactory` — transition to published state\n- `CreateUnpublishEntryDataFactory` — transition to unpublished state\n- `CreateRepublishEntryDataFactory` — re-publish with refreshed references\n\n## Webiny\n\nThis project uses the Webiny framework.\nA `webiny` MCP server is available.\nWhen helping with Webiny-related tasks:\n\n1. Call `list_webiny_skills` to see available skills.\n2. Call `get_webiny_skill` with the relevant topic before writing code.\n\n## CI/CD - GitHub Actions\n\nWhen working on GitHub Actions workflows, when possible, we always want to make modifications on `.github/workflows/wac` TS files first, and then emit YAML files via `yarn ci-workflows:build`. Only work on YAML files if a corresponding .wac.ts file does not exist.\n","CLAUDE.md":"# Context\n\nRead `AGENTS.md`.\n\n# Claude Project Guidelines\n\nThis file is read by Claude Code on every run. Keep it up to date with your project's conventions.\n\n# Reading code\n\nNEVER call Read or Grep to understand code structure or locate symbols.\nYou MUST use codegraph_context, codegraph_search, or codegraph_callers first.\nOnly call Read if codegraph explicitly returns no results AND you explain why in your response.\n\n## Development Commands\n\nAlways suppress verbose output to keep token usage low.\nRedirect stdout to `/dev/null` for noisy commands and capture only stderr,\nor use `tail` to capture just the last few lines when you need a summary.\n\n```bash\n# Install dependencies  (suppress all output – it's noise)\nyarn > /dev/null 2>&1\n\n# Run tests  (keep output – failures matter, but cap at last 50 lines)\nyarn test packages/{package-name} 2>&1 | tail -50\n\n# Build all changed packages  (capture last 30 lines to see result without full log)\nyarn build 2>&1 | tail -30\n\n# Build a single package  (capture last 30 lines to see result without full log)\nyarn build -p @webiny/api-core 2>&1 | tail -30\n```\n\n## Before Commit\n\nBefore each commit, run the following commands:\n\n```\n# Stage all changed files\ngit add .\n\n# Ensure yarn.lock is up to date\nyarn > /dev/null 2>&1\n\n# Update all tsconfig files\nnode scripts/generateTsConfigsInPackages.js\n\n# Make sure all package.json deps are configured correctly\nyarn adio\n\n# Format changed files\nyarn format > /dev/null 2>&1\n\n# Run oxlint\nyarn lint\n\n# Make sure dependencies are in sync\nyarn webiny sync-dependencies\n\n# Stage all changed files (again!)\ngit add .\n```\n\nIf any of the steps fail, and you fix anything, you must rerun all scripts from the beginning.\n\n## Code Conventions\n\n- **Formatting:** oxfmt with project defaults (`.oxfmtrc.json`)\n- **Linting:** Oxlint with project config (`.oxlintrc.json`)\n- **Commit style:** Conventional Commits (`feat:`, `fix:`, `chore:`, etc.)\n- **Branch naming:** `claude/issue-<number>` for Claude-generated branches\n- **PR titles:** Mirror the commit style\n\n## Webiny\n\nThis project uses the Webiny framework.\nA `webiny` MCP server is available.\nWhen helping with Webiny-related tasks, call `get_started()` first.\n",".github/copilot-instructions.md":"# Instructions For GitHub Copilot\n\n- once done with code changes, run \"npx pretty-quick --staged\" to format all staged files before committing\n- make PR body concise and to the point, summarizing the key changes and their purpose without unnecessary elaboration\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"## Exploration\n\n- DO NOT read code in `dist` folders.\n\n## Persist Learnings\n\nWhen new backend features are discovered, update `ai-context/core-features-reference.md` with the new feature reference. DO NOT update this file with React features.\n\n## Code\n\nCode-style rules live in `ai-context/code-style/`, one rule per file (ESLint-style `do this / don't do this`). Read every rule in that folder before writing or editing code; see `ai-context/code-style/README.md` for the index. When adding a new rule, create a new `*.md` file there and add it to the index.\n\n- When generating code, once done, run `git add .` to stage all changes.\n\n## Building\n\n- When type checking, use `yarn check -p <package-name>`, e.g., `yarn check -p @webiny/api-core`\n- When building a single package, use `yarn build -p <package-name> --safe-replace`, e.g., `yarn build -p @webiny/api-core --safe-replace`. We use \"--safe-replace\" in order to not have our active bundling watch process break.\n- To build all packages, simply run `yarn build`.\n- To build all packages without caching, use `yarn build --no-cache `.\n\n## Testing\n\n- To test a package, use `yarn test packages/<package-name>`, e.g., `yarn test packages/api-core`\n\n## Commits\n\n- Always run the full pre-commit checklist and commit after every code change — do not wait to be asked:\n  ```bash\n  git add .\n  yarn > /dev/null 2>&1\n  node scripts/generateTsConfigsInPackages.js\n  yarn adio\n  yarn format > /dev/null 2>&1\n  yarn lint\n  yarn webiny sync-dependencies\n  git add .\n  ```\n  If any step fixes something, rerun from the top before committing.\n- Avoid overly verbose descriptions or unnecessary details.\n- Use conventional commit message formats like:\n  - feat: for new features\n  - fix: for bug fixes\n  - docs: for documentation changes\n\n## Entry Data Factory Pattern (`api-headless-cms`)\n\nEntry data factories are injectable features, not imported functions. When writing use cases in `packages/api-headless-cms` that need to produce domain entry objects:\n\n- **Do not** import from `~/crud/contentEntry/entryDataFactories/`\n- **Do** inject the factory token via `createImplementation` dependencies and call `this.xyzFactory.create(...)`\n- Factories live in `packages/api-headless-cms/src/features/contentEntry/entryDataFactories/`\n- Token scope: `\"Cms/Entry/<FactoryName>\"` (e.g. `\"Cms/Entry/CreateEntryDataFactory\"`)\n- All factories are singletons\n\nAvailable factories:\n\n- `CreateEntryDataFactory` — new entry from raw input\n- `UpdateEntryDataFactory` — update existing entry\n- `CreateEntryRevisionFromDataFactory` — new revision from existing entry\n- `CreatePublishEntryDataFactory` — transition to published state\n- `CreateUnpublishEntryDataFactory` — transition to unpublished state\n- `CreateRepublishEntryDataFactory` — re-publish with refreshed references\n\n## Webiny\n\nThis project uses the Webiny framework.\nA `webiny` MCP server is available.\nWhen helping with Webiny-related tasks:\n\n1. Call `list_webiny_skills` to see available skills.\n2. Call `get_webiny_skill` with the relevant topic before writing code.\n\n## CI/CD - GitHub Actions\n\nWhen working on GitHub Actions workflows, when possible, we always want to make modifications on `.github/workflows/wac` TS files first, and then emit YAML files via `yarn ci-workflows:build`. Only work on YAML files if a corresponding .wac.ts file does not exist.\n","category":"root","tokens":839},{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# Context\n\nRead `AGENTS.md`.\n\n# Claude Project Guidelines\n\nThis file is read by Claude Code on every run. Keep it up to date with your project's conventions.\n\n# Reading code\n\nNEVER call Read or Grep to understand code structure or locate symbols.\nYou MUST use codegraph_context, codegraph_search, or codegraph_callers first.\nOnly call Read if codegraph explicitly returns no results AND you explain why in your response.\n\n## Development Commands\n\nAlways suppress verbose output to keep token usage low.\nRedirect stdout to `/dev/null` for noisy commands and capture only stderr,\nor use `tail` to capture just the last few lines when you need a summary.\n\n```bash\n# Install dependencies  (suppress all output – it's noise)\nyarn > /dev/null 2>&1\n\n# Run tests  (keep output – failures matter, but cap at last 50 lines)\nyarn test packages/{package-name} 2>&1 | tail -50\n\n# Build all changed packages  (capture last 30 lines to see result without full log)\nyarn build 2>&1 | tail -30\n\n# Build a single package  (capture last 30 lines to see result without full log)\nyarn build -p @webiny/api-core 2>&1 | tail -30\n```\n\n## Before Commit\n\nBefore each commit, run the following commands:\n\n```\n# Stage all changed files\ngit add .\n\n# Ensure yarn.lock is up to date\nyarn > /dev/null 2>&1\n\n# Update all tsconfig files\nnode scripts/generateTsConfigsInPackages.js\n\n# Make sure all package.json deps are configured correctly\nyarn adio\n\n# Format changed files\nyarn format > /dev/null 2>&1\n\n# Run oxlint\nyarn lint\n\n# Make sure dependencies are in sync\nyarn webiny sync-dependencies\n\n# Stage all changed files (again!)\ngit add .\n```\n\nIf any of the steps fail, and you fix anything, you must rerun all scripts from the beginning.\n\n## Code Conventions\n\n- **Formatting:** oxfmt with project defaults (`.oxfmtrc.json`)\n- **Linting:** Oxlint with project config (`.oxlintrc.json`)\n- **Commit style:** Conventional Commits (`feat:`, `fix:`, `chore:`, etc.)\n- **Branch naming:** `claude/issue-<number>` for Claude-generated branches\n- **PR titles:** Mirror the commit style\n\n## Webiny\n\nThis project uses the Webiny framework.\nA `webiny` MCP server is available.\nWhen helping with Webiny-related tasks, call `get_started()` first.\n","category":"root","tokens":551},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","title":"copilot-instructions.md","content":"# Instructions For GitHub Copilot\n\n- once done with code changes, run \"npx pretty-quick --staged\" to format all staged files before committing\n- make PR body concise and to the point, summarizing the key changes and their purpose without unnecessary elaboration\n","category":".github","tokens":66}]}