{"owner":"ChilliCream","repo":"graphql-platform","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md","AGENTS.md"],"skills":{"CLAUDE.md":"# CLAUDE.md - Claude Code Configuration\n\nThis file provides guidance to Claude Code when working with this repository.\n\n## Build\n\n### Website\n\nUse `yarn` instead of `npm`.\n\n```bash\ncd website\nyarn\n```\n\n### C# Source Code\n\n```bash\ndotnet build src/All.slnx\n```\n\nEach area has its own solution file, so you can build or test a subset directly:\n\n```bash\ndotnet test src/HotChocolate/Fusion\n```\n\n## Code Quality\n\n### C# / .NET\n\n- Always use curly braces for loops and conditionals, no exceptions\n- File-scoped namespaces, 4-space indent\n- Test naming: `Method_Should_Outcome_When_Condition`\n- No vacuous assertions (`Assert.NotNull` alone is not a test)\n- If you need 8 stubs + reflection, you're at the wrong test tier\n- Do not use em dash style sentences in docs, comments, or XML documentation. Use commas, periods, parentheses, or colons instead.\n- XML docs should describe the contract and concepts, not internals like pooling, iteration mechanics or leak other implementation detail.\n- XML docs and comments are 1-2 sentences stating the contract: what it is, what null or edge values mean. No rationale, no use-case examples, no design justification. If a sentence explains why the design is right instead of what the member promises, delete it. The same applies to docs pages: every sentence must inform the reader, none may justify the design.\n- Do not make new parameters optional just to avoid updating call sites. A parameter should only be optional when it has a sensible semantic default and the API is frequently used (where call-site brevity outweighs explicitness). If a parameter is logically required, make it required and update all call sites.\n\n### Testing\n\n- Prefer snapshot tests over manual `Assert` calls, use **CookieCrumble** for snapshots\n- CookieCrumble has native snapshot support for `IExecutionResult`, `GraphQLHttpResponse`, and other core types\n- For smaller snapshots, prefer **inline snapshots** (`MatchInlineSnapshot`) over snapshot files\n- For a collection of results (for example a stream of subscription events), snapshot the list with `MatchInlineSnapshots` (a parallel list of per-element inline snapshots). Do NOT concatenate with `string.Join(\"---\", values).MatchInlineSnapshot(...)`: a manual separator hides element boundaries and reinvents what the collection overload does natively.\n- For tests with multiple assertions, use **Markdown snapshots** (`MatchMarkdownSnapshot`)\n- Hard limit: a single test method must contain at most 5 `Assert.*` calls. Anything beyond that is too hard to reason about in review, switch to a snapshot (Markdown for multi-shape state, inline or file for a single output)\n- Use the AAA section marker style. Each section starts with a single-line comment, the test name documents intent, no paragraph-style block comments above sections:\n\n  ```csharp\n  // arrange\n  // optional one-line description, only when the next code is non-obvious\n  ... arrange code ...\n\n  // act\n  ... act code ...\n\n  // assert\n  ... assert code ...\n  ```\n\n- Avoid `Assert.DoesNotContain` as it is a weak assertion that easily goes out of date, it only proves something is absent without verifying what *is* present. Prefer `Assert.Equal` to check the entire string value, or `Assert.Collection` to verify the complete contents of a collection.\n- Snapshot tests: update from `__mismatch__/` directory, understand ordering issues before updating\n- Filter tests during iteration, never run the full suite unnecessarily\n- Real databases in integration tests, not mocks (unless explicitly instructed otherwise)\n\n## Performance\n\n### C# / .NET\n\nThis is framework code — performance matters. Aim for zero allocations on hot paths.\n\n- Use `ChunkedArrayWriter` or `PooledArrayWriter` when you need an `IBufferWriter<byte>` for in-memory byte writing.\n\n## Tools\n\n### C# / .NET\n\nIf you need to search for packages on nuget.org use the `dotnet` cli, eg `dotnet package search HotChocolate`.\n\n### Nitro persisted operations (Fusion Aspire)\n\nAfter adding or editing any `.graphql` document under `src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations`, regenerate the `.sha256` sidecars and verify them:\n\n```bash\n.github/scripts/nitro-aspire-operations.sh update \\\n    --source src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations\n.github/scripts/nitro-aspire-operations.sh verify \\\n    --source src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations \\\n    --output /tmp/nitro-aspire-operations.json\n```\n\nNever hand-write or hand-edit a `.sha256` sidecar. The `update` command is the only source of sidecar content, and `verify` must pass before handoff.\n","AGENTS.md":"# AGENTS.md - OpenAI Codex Configuration\n\nThis file provides guidance to OpenAI Codex and other coding agents when working with this repository.\n\n## Build\n\n### Website\n\nUse `yarn` instead of `npm`.\n\n```bash\ncd website\nyarn\n```\n\n### C# Source Code\n\nBuild full solution:\n\n```bash\ndotnet build src/All.slnx\n```\n\nBuild or test a subset directly (each area has its own solution file):\n\n```bash\ndotnet test src/HotChocolate/Fusion\n```\n\n## Code Quality\n\n### C# / .NET\n\n- Always use curly braces for loops and conditionals.\n- Use file-scoped namespaces and 4-space indentation.\n- Use test naming format: `Method_Should_Outcome_When_Condition`.\n- Do not write vacuous assertions (`Assert.NotNull` alone is not a complete test).\n- If a test requires excessive stubs and reflection, use a more appropriate test tier.\n- Do not use em dash style sentences in docs, comments, or XML documentation. Use commas, periods, parentheses, or colons instead.\n- Do not make new parameters optional just to avoid updating call sites. A parameter should only be optional when it has a sensible semantic default and the API is frequently used (where call-site brevity outweighs explicitness). If a parameter is logically required, make it required and update all call sites.\n\n### Testing\n\n- Prefer snapshot tests over manual `Assert` calls using CookieCrumble.\n- Use CookieCrumble native snapshot support for `IExecutionResult`, `GraphQLHttpResponse`, and related core types.\n- For small snapshots, prefer inline snapshots (`MatchInlineSnapshot`).\n- For tests with multiple assertions, use markdown snapshots (`MatchMarkdownSnapshot`).\n- Avoid `Assert.DoesNotContain` as it is a weak assertion that easily goes out of date, it only proves something is absent without verifying what *is* present. Prefer `Assert.Equal` to check the entire string value, or `Assert.Collection` to verify the complete contents of a collection.\n- For snapshot updates, use `__mismatch__/` and understand ordering issues before updating snapshots.\n- Filter tests during iteration and avoid full-suite runs unless necessary.\n- Use real databases in integration tests instead of mocks unless explicitly instructed otherwise.\n\n## Performance\n\n### C# / .NET\n\nThis is framework code. Performance matters; optimize for low allocations on hot paths.\n\n- Use `ChunkedArrayWriter` or `PooledArrayWriter` when an in-memory `IBufferWriter<byte>` is required.\n\n## Tools\n\n### C# / .NET\n\nUse `dotnet` CLI to search NuGet packages, for example:\n\n```bash\ndotnet package search HotChocolate\n```\n\n### Nitro persisted operations (Fusion Aspire)\n\nAfter adding or editing any `.graphql` document under `src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations`, regenerate the `.sha256` sidecars and verify them:\n\n```bash\n.github/scripts/nitro-aspire-operations.sh update \\\n    --source src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations\n.github/scripts/nitro-aspire-operations.sh verify \\\n    --source src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations \\\n    --output /tmp/nitro-aspire-operations.json\n```\n\nNever hand-write or hand-edit a `.sha256` sidecar. The `update` command is the only source of sidecar content, and `verify` must pass before handoff.\n"},"files":{"CLAUDE.md":"# CLAUDE.md - Claude Code Configuration\n\nThis file provides guidance to Claude Code when working with this repository.\n\n## Build\n\n### Website\n\nUse `yarn` instead of `npm`.\n\n```bash\ncd website\nyarn\n```\n\n### C# Source Code\n\n```bash\ndotnet build src/All.slnx\n```\n\nEach area has its own solution file, so you can build or test a subset directly:\n\n```bash\ndotnet test src/HotChocolate/Fusion\n```\n\n## Code Quality\n\n### C# / .NET\n\n- Always use curly braces for loops and conditionals, no exceptions\n- File-scoped namespaces, 4-space indent\n- Test naming: `Method_Should_Outcome_When_Condition`\n- No vacuous assertions (`Assert.NotNull` alone is not a test)\n- If you need 8 stubs + reflection, you're at the wrong test tier\n- Do not use em dash style sentences in docs, comments, or XML documentation. Use commas, periods, parentheses, or colons instead.\n- XML docs should describe the contract and concepts, not internals like pooling, iteration mechanics or leak other implementation detail.\n- XML docs and comments are 1-2 sentences stating the contract: what it is, what null or edge values mean. No rationale, no use-case examples, no design justification. If a sentence explains why the design is right instead of what the member promises, delete it. The same applies to docs pages: every sentence must inform the reader, none may justify the design.\n- Do not make new parameters optional just to avoid updating call sites. A parameter should only be optional when it has a sensible semantic default and the API is frequently used (where call-site brevity outweighs explicitness). If a parameter is logically required, make it required and update all call sites.\n\n### Testing\n\n- Prefer snapshot tests over manual `Assert` calls, use **CookieCrumble** for snapshots\n- CookieCrumble has native snapshot support for `IExecutionResult`, `GraphQLHttpResponse`, and other core types\n- For smaller snapshots, prefer **inline snapshots** (`MatchInlineSnapshot`) over snapshot files\n- For a collection of results (for example a stream of subscription events), snapshot the list with `MatchInlineSnapshots` (a parallel list of per-element inline snapshots). Do NOT concatenate with `string.Join(\"---\", values).MatchInlineSnapshot(...)`: a manual separator hides element boundaries and reinvents what the collection overload does natively.\n- For tests with multiple assertions, use **Markdown snapshots** (`MatchMarkdownSnapshot`)\n- Hard limit: a single test method must contain at most 5 `Assert.*` calls. Anything beyond that is too hard to reason about in review, switch to a snapshot (Markdown for multi-shape state, inline or file for a single output)\n- Use the AAA section marker style. Each section starts with a single-line comment, the test name documents intent, no paragraph-style block comments above sections:\n\n  ```csharp\n  // arrange\n  // optional one-line description, only when the next code is non-obvious\n  ... arrange code ...\n\n  // act\n  ... act code ...\n\n  // assert\n  ... assert code ...\n  ```\n\n- Avoid `Assert.DoesNotContain` as it is a weak assertion that easily goes out of date, it only proves something is absent without verifying what *is* present. Prefer `Assert.Equal` to check the entire string value, or `Assert.Collection` to verify the complete contents of a collection.\n- Snapshot tests: update from `__mismatch__/` directory, understand ordering issues before updating\n- Filter tests during iteration, never run the full suite unnecessarily\n- Real databases in integration tests, not mocks (unless explicitly instructed otherwise)\n\n## Performance\n\n### C# / .NET\n\nThis is framework code — performance matters. Aim for zero allocations on hot paths.\n\n- Use `ChunkedArrayWriter` or `PooledArrayWriter` when you need an `IBufferWriter<byte>` for in-memory byte writing.\n\n## Tools\n\n### C# / .NET\n\nIf you need to search for packages on nuget.org use the `dotnet` cli, eg `dotnet package search HotChocolate`.\n\n### Nitro persisted operations (Fusion Aspire)\n\nAfter adding or editing any `.graphql` document under `src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations`, regenerate the `.sha256` sidecars and verify them:\n\n```bash\n.github/scripts/nitro-aspire-operations.sh update \\\n    --source src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations\n.github/scripts/nitro-aspire-operations.sh verify \\\n    --source src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations \\\n    --output /tmp/nitro-aspire-operations.json\n```\n\nNever hand-write or hand-edit a `.sha256` sidecar. The `update` command is the only source of sidecar content, and `verify` must pass before handoff.\n","AGENTS.md":"# AGENTS.md - OpenAI Codex Configuration\n\nThis file provides guidance to OpenAI Codex and other coding agents when working with this repository.\n\n## Build\n\n### Website\n\nUse `yarn` instead of `npm`.\n\n```bash\ncd website\nyarn\n```\n\n### C# Source Code\n\nBuild full solution:\n\n```bash\ndotnet build src/All.slnx\n```\n\nBuild or test a subset directly (each area has its own solution file):\n\n```bash\ndotnet test src/HotChocolate/Fusion\n```\n\n## Code Quality\n\n### C# / .NET\n\n- Always use curly braces for loops and conditionals.\n- Use file-scoped namespaces and 4-space indentation.\n- Use test naming format: `Method_Should_Outcome_When_Condition`.\n- Do not write vacuous assertions (`Assert.NotNull` alone is not a complete test).\n- If a test requires excessive stubs and reflection, use a more appropriate test tier.\n- Do not use em dash style sentences in docs, comments, or XML documentation. Use commas, periods, parentheses, or colons instead.\n- Do not make new parameters optional just to avoid updating call sites. A parameter should only be optional when it has a sensible semantic default and the API is frequently used (where call-site brevity outweighs explicitness). If a parameter is logically required, make it required and update all call sites.\n\n### Testing\n\n- Prefer snapshot tests over manual `Assert` calls using CookieCrumble.\n- Use CookieCrumble native snapshot support for `IExecutionResult`, `GraphQLHttpResponse`, and related core types.\n- For small snapshots, prefer inline snapshots (`MatchInlineSnapshot`).\n- For tests with multiple assertions, use markdown snapshots (`MatchMarkdownSnapshot`).\n- Avoid `Assert.DoesNotContain` as it is a weak assertion that easily goes out of date, it only proves something is absent without verifying what *is* present. Prefer `Assert.Equal` to check the entire string value, or `Assert.Collection` to verify the complete contents of a collection.\n- For snapshot updates, use `__mismatch__/` and understand ordering issues before updating snapshots.\n- Filter tests during iteration and avoid full-suite runs unless necessary.\n- Use real databases in integration tests instead of mocks unless explicitly instructed otherwise.\n\n## Performance\n\n### C# / .NET\n\nThis is framework code. Performance matters; optimize for low allocations on hot paths.\n\n- Use `ChunkedArrayWriter` or `PooledArrayWriter` when an in-memory `IBufferWriter<byte>` is required.\n\n## Tools\n\n### C# / .NET\n\nUse `dotnet` CLI to search NuGet packages, for example:\n\n```bash\ndotnet package search HotChocolate\n```\n\n### Nitro persisted operations (Fusion Aspire)\n\nAfter adding or editing any `.graphql` document under `src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations`, regenerate the `.sha256` sidecars and verify them:\n\n```bash\n.github/scripts/nitro-aspire-operations.sh update \\\n    --source src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations\n.github/scripts/nitro-aspire-operations.sh verify \\\n    --source src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations \\\n    --output /tmp/nitro-aspire-operations.json\n```\n\nNever hand-write or hand-edit a `.sha256` sidecar. The `update` command is the only source of sidecar content, and `verify` must pass before handoff.\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# CLAUDE.md - Claude Code Configuration\n\nThis file provides guidance to Claude Code when working with this repository.\n\n## Build\n\n### Website\n\nUse `yarn` instead of `npm`.\n\n```bash\ncd website\nyarn\n```\n\n### C# Source Code\n\n```bash\ndotnet build src/All.slnx\n```\n\nEach area has its own solution file, so you can build or test a subset directly:\n\n```bash\ndotnet test src/HotChocolate/Fusion\n```\n\n## Code Quality\n\n### C# / .NET\n\n- Always use curly braces for loops and conditionals, no exceptions\n- File-scoped namespaces, 4-space indent\n- Test naming: `Method_Should_Outcome_When_Condition`\n- No vacuous assertions (`Assert.NotNull` alone is not a test)\n- If you need 8 stubs + reflection, you're at the wrong test tier\n- Do not use em dash style sentences in docs, comments, or XML documentation. Use commas, periods, parentheses, or colons instead.\n- XML docs should describe the contract and concepts, not internals like pooling, iteration mechanics or leak other implementation detail.\n- XML docs and comments are 1-2 sentences stating the contract: what it is, what null or edge values mean. No rationale, no use-case examples, no design justification. If a sentence explains why the design is right instead of what the member promises, delete it. The same applies to docs pages: every sentence must inform the reader, none may justify the design.\n- Do not make new parameters optional just to avoid updating call sites. A parameter should only be optional when it has a sensible semantic default and the API is frequently used (where call-site brevity outweighs explicitness). If a parameter is logically required, make it required and update all call sites.\n\n### Testing\n\n- Prefer snapshot tests over manual `Assert` calls, use **CookieCrumble** for snapshots\n- CookieCrumble has native snapshot support for `IExecutionResult`, `GraphQLHttpResponse`, and other core types\n- For smaller snapshots, prefer **inline snapshots** (`MatchInlineSnapshot`) over snapshot files\n- For a collection of results (for example a stream of subscription events), snapshot the list with `MatchInlineSnapshots` (a parallel list of per-element inline snapshots). Do NOT concatenate with `string.Join(\"---\", values).MatchInlineSnapshot(...)`: a manual separator hides element boundaries and reinvents what the collection overload does natively.\n- For tests with multiple assertions, use **Markdown snapshots** (`MatchMarkdownSnapshot`)\n- Hard limit: a single test method must contain at most 5 `Assert.*` calls. Anything beyond that is too hard to reason about in review, switch to a snapshot (Markdown for multi-shape state, inline or file for a single output)\n- Use the AAA section marker style. Each section starts with a single-line comment, the test name documents intent, no paragraph-style block comments above sections:\n\n  ```csharp\n  // arrange\n  // optional one-line description, only when the next code is non-obvious\n  ... arrange code ...\n\n  // act\n  ... act code ...\n\n  // assert\n  ... assert code ...\n  ```\n\n- Avoid `Assert.DoesNotContain` as it is a weak assertion that easily goes out of date, it only proves something is absent without verifying what *is* present. Prefer `Assert.Equal` to check the entire string value, or `Assert.Collection` to verify the complete contents of a collection.\n- Snapshot tests: update from `__mismatch__/` directory, understand ordering issues before updating\n- Filter tests during iteration, never run the full suite unnecessarily\n- Real databases in integration tests, not mocks (unless explicitly instructed otherwise)\n\n## Performance\n\n### C# / .NET\n\nThis is framework code — performance matters. Aim for zero allocations on hot paths.\n\n- Use `ChunkedArrayWriter` or `PooledArrayWriter` when you need an `IBufferWriter<byte>` for in-memory byte writing.\n\n## Tools\n\n### C# / .NET\n\nIf you need to search for packages on nuget.org use the `dotnet` cli, eg `dotnet package search HotChocolate`.\n\n### Nitro persisted operations (Fusion Aspire)\n\nAfter adding or editing any `.graphql` document under `src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations`, regenerate the `.sha256` sidecars and verify them:\n\n```bash\n.github/scripts/nitro-aspire-operations.sh update \\\n    --source src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations\n.github/scripts/nitro-aspire-operations.sh verify \\\n    --source src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations \\\n    --output /tmp/nitro-aspire-operations.json\n```\n\nNever hand-write or hand-edit a `.sha256` sidecar. The `update` command is the only source of sidecar content, and `verify` must pass before handoff.\n","category":"root","tokens":1151},{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md - OpenAI Codex Configuration\n\nThis file provides guidance to OpenAI Codex and other coding agents when working with this repository.\n\n## Build\n\n### Website\n\nUse `yarn` instead of `npm`.\n\n```bash\ncd website\nyarn\n```\n\n### C# Source Code\n\nBuild full solution:\n\n```bash\ndotnet build src/All.slnx\n```\n\nBuild or test a subset directly (each area has its own solution file):\n\n```bash\ndotnet test src/HotChocolate/Fusion\n```\n\n## Code Quality\n\n### C# / .NET\n\n- Always use curly braces for loops and conditionals.\n- Use file-scoped namespaces and 4-space indentation.\n- Use test naming format: `Method_Should_Outcome_When_Condition`.\n- Do not write vacuous assertions (`Assert.NotNull` alone is not a complete test).\n- If a test requires excessive stubs and reflection, use a more appropriate test tier.\n- Do not use em dash style sentences in docs, comments, or XML documentation. Use commas, periods, parentheses, or colons instead.\n- Do not make new parameters optional just to avoid updating call sites. A parameter should only be optional when it has a sensible semantic default and the API is frequently used (where call-site brevity outweighs explicitness). If a parameter is logically required, make it required and update all call sites.\n\n### Testing\n\n- Prefer snapshot tests over manual `Assert` calls using CookieCrumble.\n- Use CookieCrumble native snapshot support for `IExecutionResult`, `GraphQLHttpResponse`, and related core types.\n- For small snapshots, prefer inline snapshots (`MatchInlineSnapshot`).\n- For tests with multiple assertions, use markdown snapshots (`MatchMarkdownSnapshot`).\n- Avoid `Assert.DoesNotContain` as it is a weak assertion that easily goes out of date, it only proves something is absent without verifying what *is* present. Prefer `Assert.Equal` to check the entire string value, or `Assert.Collection` to verify the complete contents of a collection.\n- For snapshot updates, use `__mismatch__/` and understand ordering issues before updating snapshots.\n- Filter tests during iteration and avoid full-suite runs unless necessary.\n- Use real databases in integration tests instead of mocks unless explicitly instructed otherwise.\n\n## Performance\n\n### C# / .NET\n\nThis is framework code. Performance matters; optimize for low allocations on hot paths.\n\n- Use `ChunkedArrayWriter` or `PooledArrayWriter` when an in-memory `IBufferWriter<byte>` is required.\n\n## Tools\n\n### C# / .NET\n\nUse `dotnet` CLI to search NuGet packages, for example:\n\n```bash\ndotnet package search HotChocolate\n```\n\n### Nitro persisted operations (Fusion Aspire)\n\nAfter adding or editing any `.graphql` document under `src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations`, regenerate the `.sha256` sidecars and verify them:\n\n```bash\n.github/scripts/nitro-aspire-operations.sh update \\\n    --source src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations\n.github/scripts/nitro-aspire-operations.sh verify \\\n    --source src/HotChocolate/Fusion/src/Fusion.Aspire/Nitro/Operations \\\n    --output /tmp/nitro-aspire-operations.json\n```\n\nNever hand-write or hand-edit a `.sha256` sidecar. The `update` command is the only source of sidecar content, and `verify` must pass before handoff.\n","category":"root","tokens":802}]}