@cratis/pi 7.101.0 → 7.103.0

package/package/corpus/skills/check-bin-obj-clash/NOTICE

@@ -0,0 +1,27 @@
+Detecting OutputPath and IntermediateOutputPath Clashes
+Copyright (c) .NET Foundation and Contributors
+Licensed under the MIT License. See LICENSE.
+
+Upstream source: https://github.com/dotnet/skills/blob/a6bf43ab61967c30919334986515163ab24d7635/plugins/dotnet-msbuild/skills/check-bin-obj-clash/SKILL.md
+
+Changes made by Cratis:
+
+LICENSE:
+- Copy upstream MIT license and copyright verbatim.
+
+SKILL.md:
+- Normalize frontmatter serialization, add MIT license where absent; preserve name and description.
+- Add marked modification/source comment and applicability/Cratis precedence line.
+- Render unimported msbuild-antipatterns routing reference as plain topic text.
+- Replace the blanket BuildProjectReferences=false exclusion with an evidence-based metadata-only query qualification.
+- Qualify the structured workflow exclusion by actual targets and writes.
+- Qualify the text-replay exclusion by actual targets and writes.
+- Move the complete ## Common Causes and Fixes section verbatim into references/common-causes-and-fixes.md to fit the body limit; leave a direct pointer.
+- Rewrite the description to the Cratis shape (what it does, Use when, Not for) and drop references to skills that are not part of this corpus.
+- Point the antipatterns cross-references at the bundled msbuild skill reference.
+
+references/common-causes-and-fixes.md:
+- Contain the section moved verbatim from SKILL.md, with a reference H1 title.
+- Add or normalize the top Contents list from existing headings; preserve section content.
+
+NOTICE: Add this attribution, change list, and any download/execution disclosure.

package/package/corpus/skills/check-bin-obj-clash/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: check-bin-obj-clash
+description: 'Detects MSBuild projects with conflicting OutputPath or IntermediateOutputPath and fixes the clash. Use when builds fail with ''Cannot create a file when that file already exists'' or ''The process cannot access the file because it is being used by another process'', fail intermittently but pass on retry, or overwrite outputs in multi-project or multi-targeting builds where bin/obj or project.assets.json collide. Not for OS-level file locking, single-project single-TFM builds, or non-MSBuild build systems.'
+license: MIT
+---
+
+<!-- Modified by Cratis from dotnet's original (MIT): frontmatter, applicability, navigation and the changes listed in NOTICE. Upstream: https://github.com/dotnet/skills (plugins/dotnet-msbuild/skills/check-bin-obj-clash/SKILL.md; see NOTICE) -->
+
+# Detecting OutputPath and IntermediateOutputPath Clashes
+
+Cratis rules in `.cratis/ai/rules/` (including `csharp.md`, `specs.csharp.md`, and `orleans.md`) and the `cratis-*` skills win where they differ.
+
+## Overview
+
+This skill helps identify when multiple MSBuild project evaluations share the same `OutputPath` or `IntermediateOutputPath`. This is a common source of build failures including:
+
+- File access conflicts during parallel builds
+- Missing or overwritten output files
+- Intermittent build failures
+- "File in use" errors
+- **NuGet restore errors like `Cannot create a file when that file already exists`** - this strongly indicates multiple projects share the same `IntermediateOutputPath` where `project.assets.json` is written
+
+Clashes can occur between:
+- **Different projects** sharing the same output directory
+- **Multi-targeting builds** (e.g., `TargetFrameworks=net8.0;net9.0`) where the path doesn't include the target framework
+- **Multiple solution builds** where the same project is built from different solutions in a single build
+
+**Cratis qualification:** `BuildProjectReferences=false` only suppresses building referenced projects; it does not prove that this project instance is read-only. Exclude an instance only when its actual targets and writes show a metadata-only query (for example, `GetTargetPath`).
+
+## When to Use This Skill
+
+**Invoke this skill immediately when you see:**
+- `Cannot create a file when that file already exists` during NuGet restore
+- `The process cannot access the file because it is being used by another process`
+- Intermittent build failures that succeed on retry
+- Missing output files or unexpected overwriting
+
+## Step 1: Generate a Binary Log
+
+Use the `binlog-generation` skill to generate a binary log with the correct naming convention.
+
+## Primary workflow — binlog MCP
+
+The MCP server exposes structured tools for inspecting a `.binlog` without
+parsing text logs. Call them directly instead of replaying the binlog to a text
+file. Call `tools/list` for the MCP first if you are unsure which tools are available.
+
+**Important constraints:**
+- The `.binlog` file is a **binary format** — do NOT try to `cat`, `head`, `strings`, or read it directly. Use only the MCP tools to query it.
+- **Synthesize findings as you go.** Do not spend all available time investigating — once you have enough evidence, present your conclusions.
+
+### Step 2: Get an overview and list projects
+
+Use the MCP overview and projects tools to understand the build and list all projects that participated.
+
+### Step 3: Check evaluations and global properties
+
+Use the MCP `evaluations` and `evaluation_global_properties` tools to find all evaluations per project. Look for:
+- Multiple evaluations for the same project (indicates multi-targeting or multiple build configurations)
+- Differing global properties between evaluations (`TargetFramework`, `Configuration`, `RuntimeIdentifier`, `SolutionFileName`, `PublishReadyToRun`, etc.)
+
+### Step 4: Get output paths for each evaluation
+
+Use the MCP properties tool to query `OutputPath`, `IntermediateOutputPath`, `BaseOutputPath`, and `BaseIntermediateOutputPath` for each project evaluation.
+
+### Step 5: Check for double writes
+
+Use the MCP double_writes tool if available — it directly detects files written by multiple project instances.
+
+### Step 6: Identify clashes
+
+Compare the `OutputPath` and `IntermediateOutputPath` values across all evaluations:
+1. **Normalize paths** - Convert to absolute paths and normalize separators
+2. **Group by path** - Find evaluations that share the same OutputPath or IntermediateOutputPath
+3. **Filter out non-build evaluations** - Exclude only instances proven by their targets and writes to be metadata-only queries; `BuildProjectReferences=false` alone is insufficient.
+4. **Report clashes** - Any group with more than one evaluation indicates a clash
+
+## Fallback workflow — text-log replay (when MCP is unavailable)
+
+Use this only when the MCP server cannot be started.
+
+Replay the binlog to a diagnostic text log, then grep for the same signals the MCP tools surface:
+
+```bash
+dotnet msbuild build.binlog -noconlog -fl "-flp:v=diag;logfile=full.log"
+```
+
+Then extract the clash signals:
+
+- **Projects & evaluations** — list evaluation starts and count them per project: `grep 'Evaluation started' full.log | grep -oiE '"[^"]+\.[a-z]+proj"' | sort | uniq -c`. Matching the full **quoted path** keeps same-named projects in different directories distinct (and tolerates spaces in paths); a path with a count ≥ 2 was evaluated more than once (multi-targeting or extra global properties). (`grep -c` alone only totals evaluations across the whole log, so it can't reveal per-project duplication.)
+- **Output paths** — `grep -iE 'OutputPath[[:space:]]*=|IntermediateOutputPath[[:space:]]*=|BaseOutputPath[[:space:]]*=|BaseIntermediateOutputPath[[:space:]]*=' full.log | sort -u`, or query a project directly: `dotnet msbuild MyProject.csproj -getProperty:OutputPath` (and `IntermediateOutputPath`, `BaseIntermediateOutputPath`).
+- **Distinguishing global properties** — `grep -iE 'TargetFramework|Configuration|Platform|RuntimeIdentifier|SolutionFileName|PublishReadyToRun' full.log`. See the [Global Properties to Check](references/common-causes-and-fixes.md#global-properties-to-check-when-comparing-evaluations) table for which affect the path and which just fork a redundant instance.
+- **Corroborating evidence (optional)** — `grep 'Target "CopyFilesToOutputDirectory"' full.log` plus `grep 'SkipUnchangedFiles' full.log` show a second instance writing (or skipping a masked write) to the same path; a long vs ~0 ms `CoreCompile` distinguishes the real build from a redundant instance.
+
+**Then identify clashes:** normalize paths to absolute, group evaluations by `OutputPath` and by `IntermediateOutputPath`, and exclude only instances proven by their targets and writes to be metadata-only queries, not merely marked `BuildProjectReferences=false` — plus, for `OutputPath` only, `MSBuildRestoreSessionId` restore evaluations. Any group with more than one remaining evaluation is a clash.
+
+Read references/common-causes-and-fixes.md when selecting the relevant diagnostic workflow.
+
+## Tips
+
+- The SDK default paths include `$(TargetFramework)` — clashes often occur when projects override these defaults; normalize relative paths to absolute before comparing.
+- **Cross-project `IntermediateOutputPath` clashes cannot be fixed with `AppendTargetFrameworkToOutputPath`** — files like `project.assets.json` are written directly to the intermediate path. For multi-targeting clashes *within the same project*, `AppendTargetFrameworkToOutputPath=true` is the correct fix.
+- Error messages that indicate a path clash: `Cannot create a file when that file already exists` (NuGet restore), `The process cannot access the file because it is being used by another process`, or intermittent failures that succeed on retry.
+
+### Global Properties to Check When Comparing Evaluations
+
+When multiple evaluations share an output path, compare these global properties to understand why:
+
+| Property | Affects OutputPath? | Notes |
+|----------|---------------------|-------|
+| `TargetFramework` | Yes | Different TFMs should have different paths. **Exception:** re-injecting a *single-targeting* project's own TFM (e.g. via `SetTargetFramework` with the same value) is path-neutral — it forks a redundant instance sharing the output path (see "`SetTargetFramework` re-injecting...") |
+| `RuntimeIdentifier` | Yes | Different RIDs should have different paths |
+| `Configuration` | Yes | Debug vs Release |
+| `Platform` | Yes | AnyCPU vs x64 etc. |
+| `SolutionFileName` | No | Identifies which solution built the project — different values indicate multi-solution clash |
+| `SolutionName` | No | Solution name without extension |
+| `SolutionPath` | No | Full path to the solution file |
+| `SolutionDir` | No | Directory containing the solution file |
+| `CurrentSolutionConfigurationContents` | No | XML with project entries — count of entries reveals which solution |
+| `BuildProjectReferences` | No | `false` = P2P query, not a real build - ignore these |
+| `MSBuildRestoreSessionId` | No | Present = restore phase evaluation |
+| `PublishReadyToRun` | No | Publish setting, doesn't change build output path but creates distinct project instances |
+| `_IsPublishing` | No | Publish flag; an `<MSBuild>` Build/Publish call with this set (in this project or another that consumes it) forks a publish instance sharing the build output path (see "Explicit `<MSBuild>` Build/Publish with extra global properties") |
+
+## Testing Fixes
+
+After making changes to fix path clashes, clean and rebuild to verify. See the `binlog-generation` skill's "Cleaning the Repository" section on how to clean the repository while preserving binlog files.

package/package/corpus/skills/check-bin-obj-clash/references/common-causes-and-fixes.md

@@ -0,0 +1,206 @@
+# Output-path clash causes and fixes
+
+## Contents
+
+- Common Causes and Fixes
+  - Multi-targeting without TargetFramework in path
+  - Shared output directory across projects (CANNOT be fixed with AppendTargetFramework)
+  - RuntimeIdentifier builds clashing
+  - Multiple solutions building the same project
+  - Extra global properties creating redundant project instances
+  - Explicit `<MSBuild>` Build/Publish with extra global properties (self or cross-project)
+  - `SetTargetFramework` re-injecting a single-targeting project's own TFM on a `ProjectReference`
+
+## Common Causes and Fixes
+
+### Multi-targeting without TargetFramework in path
+
+**Problem:** Project uses `TargetFrameworks` but OutputPath doesn't vary by framework.
+
+```xml
+<!-- BAD: Same path for all frameworks -->
+<OutputPath>bin\$(Configuration)\</OutputPath>
+```
+
+**Fix:** Include TargetFramework in the path:
+
+```xml
+<!-- GOOD: Path varies by framework -->
+<OutputPath>bin\$(Configuration)\$(TargetFramework)\</OutputPath>
+```
+
+Or rely on SDK defaults which handle this automatically:
+
+```xml
+<AppendTargetFrameworkToOutputPath>true</AppendTargetFrameworkToOutputPath>
+<AppendTargetFrameworkToIntermediateOutputPath>true</AppendTargetFrameworkToIntermediateOutputPath>
+```
+
+### Shared output directory across projects (CANNOT be fixed with AppendTargetFramework)
+
+**Problem:** Multiple projects explicitly set the same `BaseOutputPath` or `BaseIntermediateOutputPath`.
+
+```xml
+<!-- Project A - Directory.Build.props -->
+<BaseOutputPath>..\SharedOutput\</BaseOutputPath>
+<BaseIntermediateOutputPath>..\SharedObj\</BaseIntermediateOutputPath>
+
+<!-- Project B - Directory.Build.props -->
+<BaseOutputPath>..\SharedOutput\</BaseOutputPath>
+<BaseIntermediateOutputPath>..\SharedObj\</BaseIntermediateOutputPath>
+```
+
+**IMPORTANT:** Even with `AppendTargetFrameworkToOutputPath=true`, this will still clash! .NET writes certain files directly to the `IntermediateOutputPath` without the TargetFramework suffix, including:
+
+- `project.assets.json` (NuGet restore output)
+- Other NuGet-related files
+
+This causes errors like `Cannot create a file when that file already exists` during parallel restore.
+
+**Fix:** Each project MUST have a unique `BaseIntermediateOutputPath`. Do not share intermediate output directories across projects:
+
+```xml
+<!-- Project A -->
+<BaseIntermediateOutputPath>..\obj\ProjectA\</BaseIntermediateOutputPath>
+
+<!-- Project B -->
+<BaseIntermediateOutputPath>..\obj\ProjectB\</BaseIntermediateOutputPath>
+```
+
+Or simply use the SDK defaults which place `obj` inside each project's directory.
+
+### RuntimeIdentifier builds clashing
+
+**Problem:** Building for multiple RIDs without RID in path.
+
+**Fix:** Ensure RuntimeIdentifier is in the path:
+
+```xml
+<AppendRuntimeIdentifierToOutputPath>true</AppendRuntimeIdentifierToOutputPath>
+```
+
+### Multiple solutions building the same project
+
+**Problem:** A single build invokes multiple solutions (e.g., via MSBuild task or command line) that include the same project. Each solution build evaluates and builds the project independently, with different `Solution*` global properties that don't affect the output path.
+
+**How to detect:** Compare `SolutionFileName` and `CurrentSolutionConfigurationContents` across evaluations for the same project. Different values indicate multi-solution builds. For example:
+
+| Property | Eval from Solution A | Eval from Solution B |
+|---|---|---|
+| `SolutionFileName` | `BuildAnalyzers.sln` | `Main.slnx` |
+| `CurrentSolutionConfigurationContents` | 1 project entry | ~49 project entries |
+| `OutputPath` | `bin\Release\netstandard2.0\` | `bin\Release\netstandard2.0\` ← **clash** |
+
+**Example:** A repo build script builds `BuildAnalyzers.sln` then `Main.slnx`, and both solutions include `SharedAnalyzers.csproj`. Both builds write to `bin\Release\netstandard2.0\`. The first build compiles; the second skips compilation but still runs `CopyFilesToOutputDirectory`.
+
+**Fix:** Options include:
+1. **Consolidate solutions** - Ensure each project is only built from one solution in a single build
+2. **Use different configurations** - Build solutions with different `Configuration` values that result in different output paths
+3. **Exclude duplicate projects** - Use solution filters or conditional project inclusion to avoid building the same project twice
+
+### Extra global properties creating redundant project instances
+
+**Problem:** A project is built multiple times within the same solution due to extra global properties (e.g., `PublishReadyToRun=false`) that create distinct MSBuild project instances. These properties don't affect output paths but prevent MSBuild from caching results across instances, causing redundant target execution.
+
+**How to detect:** Compare global properties across evaluations for the same project within the same solution (same `SolutionFileName`). Look for properties that differ but don't contribute to path differentiation:
+
+| Property | Eval A (from Razor.slnx) | Eval B (from Razor.slnx) |
+|---|---|---|
+| `PublishReadyToRun` | *(not set)* | `false` |
+| `OutputPath` | `bin\Release\netstandard2.0\` | `bin\Release\netstandard2.0\` ← **clash** |
+
+This is particularly wasteful for projects where the extra property has no effect (e.g., `PublishReadyToRun` on a `netstandard2.0` class library that doesn't use ReadyToRun compilation).
+
+**Fix:** Options include:
+1. **Remove the extra global property** - Investigate which parent target/task is injecting the property and prevent it from being passed to projects that don't need it
+2. **Use `RemoveGlobalProperties` metadata** - On `ProjectReference` items, use `RemoveGlobalProperties="PublishReadyToRun"` to strip the property before building the referenced project
+3. **Condition the property** - Only set the property on projects that actually use it (e.g., only for executable projects, not class libraries)
+
+### Explicit `<MSBuild>` Build/Publish with extra global properties (self or cross-project)
+
+**Problem:** A target uses the `<MSBuild>` task to build or publish a project with an extra global property, most commonly a "publish-on-build" target. The offending call can be in the target project itself **or in another project** that consumes it (e.g. a test or layout project publishing a tool):
+
+```xml
+<!-- (a) same project (publish-on-build) -->
+<Target Name="PublishOnBuild" AfterTargets="Build">
+  <MSBuild Projects="$(MSBuildProjectFullPath)" Targets="Publish" Properties="_IsPublishing=true" />
+</Target>
+
+<!-- (b) project A publishes project B that it consumes -->
+<MSBuild Projects="..\tool\tool.csproj" Targets="Publish" Properties="_IsPublishing=true" />
+```
+
+Either way this forks a distinct instance of the target project (`path` + `{_IsPublishing=true}`) that shares the same `OutputPath`/`IntermediateOutputPath` as the instance the solution/graph already builds. Both write the same files — for NativeAOT this includes the `*.sourcelink` intermediate, which produces `SourceLinkWriter` / "file in use" failures under parallel builds.
+
+**How to detect:** Follow the Primary workflow above — the `evaluations` and `evaluation_global_properties` tools surface two evaluations of the target project that share the same `OutputPath`/`IntermediateOutputPath` but differ only by a path-neutral publish flag such as `_IsPublishing`, and the `double_writes` tool flags the resulting shared-file writes directly. To tell case (a) from (b), see which project the extra `{_IsPublishing=true}` evaluation runs *under* in the build tree (from the overview/projects tools): the target project itself for (a), or a consumer project that invoked the `<MSBuild>` task for (b).
+
+**Fix:** Depends on where the call lives:
+
+- **Same project (a):** you can't strip the property with `RemoveGlobalProperties` (the project injects it on itself). Set the flag as a **static** (non-global) property and run the target in the **same** instance via `DependsOnTargets`/`CallTarget`, with a guard against a target cycle when publish is the entry point:
+
+```xml
+<PropertyGroup>
+  <_PublishWasInvokedDirectly Condition="'$(_IsPublishing)' == 'true'">true</_PublishWasInvokedDirectly>
+  <_IsPublishing>true</_IsPublishing>
+</PropertyGroup>
+<Target Name="PublishOnBuild"
+        AfterTargets="Build"
+        DependsOnTargets="Publish"
+        Condition="'$(_PublishWasInvokedDirectly)' != 'true'" />
+```
+
+- **Cross-project (b):** the consumer must not fork the producer with path-neutral global properties. Make the producer publish as part of its own build (the (a) fix in *its* project), then have the consumer **sequence** it and read its output instead of re-publishing it:
+
+```xml
+<ItemGroup>
+  <ProjectReference Include="..\tool\tool.csproj" ReferenceOutputAssembly="false" />
+</ItemGroup>
+<!-- consumer reads tool's publish dir; it does NOT invoke Publish on tool -->
+```
+
+See `msbuild` skill `references/msbuild-antipatterns.md` (AP-22) for the authoring-time smell and rationale.
+
+### `SetTargetFramework` re-injecting a single-targeting project's own TFM on a `ProjectReference`
+
+**Problem:** A `ProjectReference` sets `SetTargetFramework="TargetFramework=<tfm>"` metadata pointing at a **single-targeting** project (one that uses singular `<TargetFramework>`, not `<TargetFrameworks>`), where the injected `<tfm>` **equals the TFM the project already targets**. `SetTargetFramework` injects `TargetFramework` as a **global property** on the referenced project's build.
+
+```xml
+<!-- BAD: Tool.csproj single-targets net8.0 and we inject that SAME net8.0 -->
+<ProjectReference Include="..\Tool\Tool.csproj" SetTargetFramework="TargetFramework=net8.0" />
+```
+
+Injecting the TFM the project already targets is **path-neutral** — the project already resolves to `bin\<config>\net8.0\` and `obj\<config>\net8.0\` on its own. So it doesn't change the output path; it only forks a distinct instance `(project, {TargetFramework=net8.0})`. The solution/graph builds the very same project as `(project, {})`. Both share the same `OutputPath`/`IntermediateOutputPath`, so the project is **built twice** to the same location — a bin/obj clash under parallel builds.
+
+**How to detect:** Follow the Primary workflow above. The `evaluations` and `evaluation_global_properties` tools surface two evaluations of the referenced project that share the same `OutputPath`/`IntermediateOutputPath` and differ only by a `TargetFramework` global property, while the project itself is single-targeting (its own `TargetFramework` already equals the injected value). The `double_writes` tool flags the resulting shared-file writes directly.
+
+**Note:** The P2P protocol itself does **not** inject `TargetFramework` for a non-multi-targeting reference — the clash comes specifically from the explicit `SetTargetFramework` metadata overriding that safe default.
+
+**Fix:** Remove the redundant `SetTargetFramework` when it just restates the project's own single TFM:
+
+```xml
+<!-- GOOD -->
+<ProjectReference Include="..\Tool\Tool.csproj" />
+```
+
+**When `SetTargetFramework` is legitimate (not a clash):**
+
+- **Multi-targeting reference** — the referenced project uses `<TargetFrameworks>` and you need one specific TFM. Each TFM has a distinct output path, so no clash.
+- **Overriding to a *different* TFM** — you may use `SetTargetFramework` on a single-targeting project to build it under a TFM *other than* the one it declares. Because the injected TFM then changes the output path (`obj\<config>\<different-tfm>\`), the instance no longer collides with `(project, {})`. Only the *same-TFM* case is path-neutral and clashing.
+- **Framework-incompatible reference** — whenever the referencing and referenced projects target **incompatible frameworks** (e.g. a `.NETFramework` project referencing a `.NETCoreApp` project, or vice-versa) — **regardless of single- or multi-targeting on either side** — set `SkipGetTargetFrameworkProperties="true"` (the P2P `GetTargetFrameworkProperties` negotiation would otherwise fail) and `ReferenceOutputAssembly="false"` (an assembly built for an incompatible framework can't be consumed as a reference — you only want to trigger/sequence the build):
+
+  ```xml
+  <ProjectReference Include="..\Tool\Tool.csproj"
+                    SkipGetTargetFrameworkProperties="true"
+                    ReferenceOutputAssembly="false" />
+  ```
+
+  With `SkipGetTargetFrameworkProperties="true"`, the negotiation no longer stops the **referencing** project's own `TargetFramework` global property (present when it builds for a specific TFM, e.g. it is multi-targeting) from flowing into the referenced project. For a **single-targeting** referenced project that would force it to build under the wrong TFM / output path. Prevent it by either setting `SetTargetFramework="TargetFramework=<tfm>"` (pin the TFM) **or** `UndefineProperties="TargetFramework"` (strip the inherited global property so the project builds as it declares) — use one, not both:
+
+  ```xml
+  <ProjectReference Include="..\Tool\Tool.csproj"
+                    SkipGetTargetFrameworkProperties="true"
+                    UndefineProperties="TargetFramework"
+                    ReferenceOutputAssembly="false" />
+  ```
+
+See `msbuild` skill `references/msbuild-antipatterns.md` (AP-23) for the authoring-time smell and rationale.

package/package/corpus/skills/coverage-analysis/LICENSE

@@ -0,0 +1,23 @@
+The MIT License (MIT)
+
+Copyright (c) .NET Foundation and Contributors
+
+All rights reserved.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/package/corpus/skills/coverage-analysis/NOTICE

@@ -0,0 +1,32 @@
+Coverage Analysis
+Copyright (c) .NET Foundation and Contributors
+Licensed under the MIT License. See LICENSE.
+
+Upstream source: https://github.com/dotnet/skills/blob/a6bf43ab61967c30919334986515163ab24d7635/plugins/dotnet-test/skills/coverage-analysis/SKILL.md
+
+Changes made by Cratis:
+
+LICENSE:
+- Copy upstream MIT license and copyright verbatim.
+
+SKILL.md:
+- Normalize frontmatter serialization, add MIT license where absent; preserve name and description.
+- Add marked modification/source comment and applicability/Cratis precedence line with the skill-specific safety, ownership or compatibility caveat.
+- Render unimported find-untested-sources routing reference as plain topic text.
+- Render unimported test-gap-analysis routing reference as plain topic text.
+- Render unimported test-tagging routing reference as plain topic text.
+- Render unimported crap-score routing reference as plain topic text.
+- Add direct conditional pointers for all otherwise-indirect reference/script/asset files: scripts/Compute-CrapScores.ps1, scripts/CoverageData.ps1, scripts/Extract-MethodCoverage.ps1.
+- Rewrite the description to the Cratis shape (what it does, Use when, Not for) and drop references to skills that are not part of this corpus.
+- Remove references to sibling skills that are not part of this corpus.
+
+references/report-generation.md:
+- Prefix official tool downloads/installs with marked approval/pinned-version guidance and privileged/perfcollect examples with explicit root/container-security approval, where present.
+
+references/setup-discovery.md:
+- Add or normalize the top Contents list from existing headings; preserve section content.
+
+NOTICE: Add this attribution, change list, and any download/execution disclosure.
+
+Executes or downloads (instructions retained, not executed by this import):
+- references/report-generation.md: dotnet tool install dotnet-reportgenerator-globaltool --tool-path $rgToolPath

package/package/corpus/skills/coverage-analysis/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: coverage-analysis
+description: 'Interprets supplied .NET coverage reports (Cobertura, line, branch, condition metrics) or collects coverage on request: partial conditions, plateaus, target arithmetic, project-wide coverage-backed CRAP, and refactoring safety. Use when coverage reports, percentages, or an explicit coverage-collection request are present. Analyzes supplied reports directly without rerunning tests or installing tools. Not for requests with no coverage evidence, hypothetical change-survival questions, CRAP for one named target, writing tests (use cratis-specifications-csharp), or running tests (use run-tests).'
+license: MIT
+---
+
+<!-- Modified by Cratis from dotnet's original (MIT): frontmatter, applicability, navigation and the changes listed in NOTICE. Upstream: https://github.com/dotnet/skills (plugins/dotnet-test/skills/coverage-analysis/SKILL.md; see NOTICE) -->
+
+# Coverage Analysis
+
+Cratis rules in `.cratis/ai/rules/` (including `csharp.md`, `specs.csharp.md`, and `orleans.md`) and the `cratis-*` skills win where they differ. The C# and Python pairing scripts differ on `.Spec`/`.Specs` project suffixes; Cratis specification projects end in `.Specs`. Coverage is not behavior evidence.
+
+## Purpose
+
+Explain what .NET coverage evidence proves, reconcile target arithmetic, and
+identify the code blocking progress. Add complexity/CRAP ranking only when the
+user explicitly asks for risk hotspots, CRAP, priorities by risk, or refactoring
+safety.
+
+## When to Use
+
+Use this skill for interpreting supplied .NET line/branch/condition evidence,
+coverage gaps and plateaus, target arithmetic, or explicit project-wide
+coverage-backed risk analysis.
+
+## When Not to Use
+
+- **Named method, class, or file CRAP/refactoring-safety analysis** — out of scope; analyze that target directly
+- **Static source-to-test pairing or listing files with no tests** — out of scope
+- **Behavioral or pseudo-mutation gaps in existing tests** — out of scope
+- **Test trait/category distributions or coverage shape by test type** — out of scope
+- **Writing or generating tests** — this skill identifies where tests are needed, not write them
+- **General test execution** unrelated to coverage or CRAP analysis
+- **Only collecting .NET coverage or printing a raw percentage with no diagnosis** — use `run-tests`; use native tooling for non-.NET coverage collection or analysis. Interpreting .NET line/branch gaps remains in scope here
+
+## Inputs
+
+| Input | Required | Default | Description |
+|-------|----------|---------|-------------|
+| Project/solution path | No | Current directory | Path to the .NET solution or project |
+| Line coverage threshold | No | 80% | Minimum acceptable line coverage |
+| Branch coverage threshold | No | 70% | Minimum acceptable branch coverage |
+| Existing Cobertura path | No | Discover only if not supplied | Preferred input; never rerun tests when usable |
+| CRAP threshold | No | 30 | Used only for explicit risk/CRAP requests |
+| Hotspot count | No | 3 | Explicit risk requests only; cap at 10 unless the user asks for more |
+
+Discover optional inputs from the workspace. Do not ask for a project path when
+the current directory or a supplied report is sufficient.
+
+## Choose the smallest matching path
+
+| User intent | Required work | Do not do |
+|-------------|---------------|-----------|
+| Explain a supplied excerpt, condition, or summary | Answer directly from the supplied evidence | Tools, CRAP, discovery, report files |
+| Interpret a supplied Cobertura path or diagnose a plateau | Read that report, reconcile totals, name all material gaps, answer directly | Rerun tests, install tools, compute CRAP, or generate files unless explicitly requested |
+| Rank risk hotspots, compute project-wide CRAP, or assess refactoring safety | Use the supplied/existing report, read `references/guidelines.md`, and compute CRAP before ranking | Coverage-only ranking or a full report template unless requested |
+| Analyze coverage when no report exists | Invoke `run-tests` to collect coverage with the repository-compatible runner, then analyze the generated report | Choose or execute a test command independently; CRAP unless risk was requested |
+| Produce a full markdown/HTML/CSV report | First deliver the direct answer; then read `references/output-format.md` or `references/report-generation.md` | Report generation before the answer |
+
+Words such as **analyze coverage**, **what is blocking coverage**, or **why is
+coverage stuck** do not by themselves request CRAP. Explicit signals include
+**risk hotspot**, **CRAP**, **complexity-weighted priority**, **safe to refactor**,
+or an equivalent request to combine complexity with coverage.
+
+## Existing-data fast path
+
+When the user supplies a coverage excerpt, summary, or valid Cobertura path:
+
+- Treat it as authoritative input and start there.
+- Do not discover the solution or test projects unless source mapping is necessary.
+- Do not run `dotnet test`, install ReportGenerator, add a coverage package, or
+  read `references/setup-discovery.md` or `references/report-generation.md`.
+- Do not write `coverage-analysis.md` or create a report directory unless the user
+  requested a saved/full report.
+- For interpretation and plateau questions, parse only the evidence needed to
+  answer. For explicit project-wide risk requests, use the bundled scripts as
+  described in `references/guidelines.md`.
+
+A failed read/view operation is not proof that a named path does not exist.
+Classify the failure, then make one targeted existence probe and use a normalized
+path or alternate reader only for confirmed tool availability, transport, or
+path-normalization failures and only after verifying the canonical path remains
+inside the workspace. Stop on content-exclusion, permission/policy,
+workspace-boundary, or unknown failures. Report a missing path only when the
+independent probe also fails; do not broaden the search or substitute another
+artifact.
+
+## Collection path
+
+Use this path only when no usable coverage evidence exists and the user asked for
+analysis that requires it.
+
+1. Read `references/setup-discovery.md`.
+2. Prefer existing Cobertura discovered under the requested root.
+3. If none exists, invoke `run-tests` for repository overlay, platform, runner,
+   and command selection, and have it collect Cobertura once per entry point.
+4. Analyze the resulting Cobertura. Compute CRAP only if risk analysis was
+   explicitly requested.
+
+When the workspace contains the project/test manifests needed by this path,
+perform discovery directly and delegate collection to `run-tests`. Do not ask
+the user to attach files or pre-run coverage that the current workspace lets
+you inspect and generate.
+
+Do not modify production code. Any incidental test-project change needed for
+collection is owned by `run-tests`; include that change and its revert command
+in the final analysis.
+
+The automatic collection path is for SDK-style projects. For classic non-SDK or
+`packages.config` projects, use only a repository-owned coverage command. If none
+exists, stop and request Cobertura XML. Never migrate the project, inject an
+SDK-style provider, create a wrapper project, or report substitute coverage from
+another assembly.
+
+## Interpretation and arithmetic invariants
+
+- A line hit proves execution, not both decision outcomes.
+- `condition-coverage="50% (1/2)"` proves one reported outcome ran, but not which
+  one. Recommend forcing the opposite outcome. Without source, never invent likely
+  predicates or claim whether true or false is missing. State that compound
+  predicates need independently exercised operands and short-circuit combinations
+  when applicable; do not infer the exact combinations without source or fuller XML.
+- Derive overall totals from Cobertura's covered/valid line counts. For target
+  `T`, required covered lines are `ceiling(valid lines × T)`.
+- Projected coverage is `(current covered lines + newly covered distinct lines) /
+  valid lines`. State assumptions such as fully covering a method.
+- When asked whether one member can reach a target, show its maximum projected
+  total and at least one concrete sufficient combination of supplied members or
+  line gains. If no supplied combination is sufficient, say so.
+- For a multi-member target, name the exact combination and resulting covered /
+  valid total; saying only "combine it with another member" is incomplete.
+- Reconcile member gaps against project totals. Method line ranges can overlap or
+  omit class-level lines, so do not sum method counts as project truth.
+- Never call one member the **sole**, **entire**, or **all** remaining gap unless
+  its distinct uncovered lines exactly reconcile with the project total and no
+  other below-threshold member remains.
+- Name every supplied or extracted below-threshold member, but keep detail
+  proportional: lead with the blockers, summarize the remainder in one sentence
+  or a compact table.
+
+## Response contract
+
+Answer the user's question in the first 2–4 sentences.
+
+- **Excerpt or arithmetic question:** one explanation plus the next test or member
+  priority. No dashboard.
+- **Existing-report interpretation or plateau:** overall line/branch coverage,
+  blocking members, reconciled target impact, and 1–3 recommendations. Use at
+  most one compact table.
+- **Explicit risk/CRAP request:** top 3 actual hotspots by default, supporting
+  complexity/coverage/CRAP values, remaining flagged count, and 1–3 priorities.
+  Exclude fully covered low-risk methods from the hotspot table. Never exceed 10
+  rows unless the user requests a larger count. For refactoring safety, rank risky
+  methods by CRAP rather than raw coverage alone, then name comparatively safe
+  well-covered methods separately.
+- **Explicit full report request:** read `references/output-format.md`. Save the
+  report only then.
+
+Report only artifacts that exist. Do not announce inaccessible output paths or
+failed optional file writes when no file was requested.
+
+## Optional reports
+
+HTML/CSV/markdown files are not part of normal analysis. Generate them only when
+the user explicitly requests report files or a CI artifact.
+
+1. Deliver the direct coverage/risk answer first.
+2. For a full markdown report, read `references/output-format.md` and save it.
+3. For HTML/CSV, then read `references/report-generation.md`. Do not install
+   ReportGenerator before the direct answer, and do not retry a failed install.
+
+## Validation
+
+- Confirm a supplied report was used without test execution or tool installation.
+- Reconcile covered, valid, and uncovered line totals before projecting impact.
+- Confirm every stated blocker comes from supplied or extracted evidence.
+- If CRAP was requested, spot-check one score using `references/guidelines.md`.
+- If files were requested, verify they exist before reporting their paths.
+
+## Common Pitfalls
+
+- **Existing report triggers setup work** — stop. Analyze the named artifact first.
+- **Generic analysis triggers CRAP** — stop. CRAP requires explicit risk intent.
+- **One method is called the entire gap** — reconcile distinct uncovered lines and
+  the full below-threshold set first.
+- **A small request gets a dashboard** — scale down to a direct answer or one table.
+- **No Cobertura from collection** — report the collection failure; do not invent
+  substitute coverage.
+- **Compiler-generated method names** — verify suspicious async, lambda, or local
+  function names against source before presenting them as user-authored members.
+- **Test exit code 1** — coverage may still exist; proceed with a warning. Other
+  nonzero build failures stop the collection path.
+
+## Reference navigation
+
+- Read scripts/Compute-CrapScores.ps1 when working on Compute CrapScores.
+- Read scripts/CoverageData.ps1 when working on CoverageData.
+- Read scripts/Extract-MethodCoverage.ps1 when working on Extract MethodCoverage.