@cratis/pi 7.102.0 → 7.103.0

package/package/corpus/skills/profiling/references/profiling.md

@@ -0,0 +1,190 @@
+# Official .NET Profiling Tools
+
+## Contents
+
+- What This Skill Uses
+- Installation Paths
+- Release-First Rule
+- First-Line Live Triage with dotnet-counters
+- CPU and Runtime Tracing with dotnet-trace
+- Exceptions, Contention, and JIT Clues
+- Heap Investigation with dotnet-gcdump
+- Practical Investigation Order
+- Useful Guardrails
+
+## What This Skill Uses
+
+This skill standardizes on official CLI-based .NET diagnostics tools:
+
+- `dotnet-counters` for live metrics and exported counters
+- `dotnet-trace` for trace capture and hotspot investigation
+- `dotnet-gcdump` for managed heap snapshots
+
+It intentionally avoids `dnx`-only flows so the commands remain explicit and durable in repo docs.
+
+## Installation Paths
+
+Preferred install path for frequent local diagnostics:
+
+```bash
+# Cratis: Downloads or installs a tool: requires the user's approval; prefer a pinned version (`dotnet tool install <tool> --version <x>`)
+dotnet tool install --global dotnet-counters --version <x>
+# Cratis: Downloads or installs a tool: requires the user's approval; prefer a pinned version (`dotnet tool install <tool> --version <x>`)
+dotnet tool install --global dotnet-trace --version <x>
+# Cratis: Downloads or installs a tool: requires the user's approval; prefer a pinned version (`dotnet tool install <tool> --version <x>`)
+dotnet tool install --global dotnet-gcdump --version <x>
+```
+
+Verify the tools:
+
+```bash
+dotnet-counters --version
+dotnet-trace --version
+dotnet-gcdump --version
+```
+
+If global tools are not suitable, use the official Microsoft Learn direct-download links for each tool:
+
+- `dotnet-counters`
+- `dotnet-trace`
+- `dotnet-gcdump`
+
+## Release-First Rule
+
+Profile realistic builds and realistic scenarios:
+
+```bash
+dotnet build -c Release
+dotnet run -c Release --project ./src/MyApp/MyApp.csproj
+```
+
+Avoid profiling Debug builds unless the debugging overhead itself is the question.
+
+## First-Line Live Triage with dotnet-counters
+
+Use `dotnet-counters` first when you need fast feedback about:
+
+- CPU usage
+- GC activity
+- allocation growth
+- exception rate
+- working set
+- thread pool pressure
+
+List candidate processes:
+
+```bash
+dotnet-counters ps
+```
+
+Monitor runtime counters:
+
+```bash
+dotnet-counters monitor --process-id PID --counters System.Runtime
+```
+
+Export counters for later comparison:
+
+```bash
+dotnet-counters collect --process-id PID --counters System.Runtime --format json -o counters.json
+```
+
+For startup diagnostics:
+
+```bash
+dotnet-counters monitor --counters System.Runtime -- dotnet exec ./bin/Release/net10.0/MyApp.dll
+```
+
+## CPU and Runtime Tracing with dotnet-trace
+
+Use `dotnet-trace` when counters show that deeper investigation is needed.
+
+List candidate processes:
+
+```bash
+dotnet-trace ps
+```
+
+Capture a focused general-purpose trace:
+
+```bash
+dotnet-trace collect --process-id PID --profile dotnet-common,dotnet-sampled-thread-time -o trace.nettrace
+```
+
+Capture GC-heavy detail:
+
+```bash
+dotnet-trace collect --process-id PID --profile gc-verbose -o gc.nettrace
+```
+
+Trace startup directly:
+
+```bash
+dotnet-trace collect -- dotnet exec ./bin/Release/net10.0/MyApp.dll
+```
+
+Get a top-method summary from a captured trace:
+
+```bash
+dotnet-trace report trace.nettrace topN --number 20
+```
+
+Convert for external viewers when needed:
+
+```bash
+dotnet-trace convert trace.nettrace --format Speedscope
+```
+
+## Exceptions, Contention, and JIT Clues
+
+`dotnet-trace` is the main CLI path when you need:
+
+- exception-heavy traces
+- contention signals
+- JIT and runtime event visibility
+
+Keep the run focused and compare the same scenario before and after each fix.
+
+## Heap Investigation with dotnet-gcdump
+
+Use `dotnet-gcdump` when you need managed heap composition rather than CPU stacks.
+
+List candidate processes:
+
+```bash
+dotnet-gcdump ps
+```
+
+Capture a heap snapshot:
+
+```bash
+dotnet-gcdump collect --process-id PID --output heap.gcdump
+```
+
+Get a heap summary report:
+
+```bash
+dotnet-gcdump report heap.gcdump
+```
+
+Important warning:
+
+- `dotnet-gcdump collect` triggers a full Gen 2 GC
+- this can pause the target process for a long time on large heaps
+- do not use it casually on latency-sensitive production paths
+
+## Practical Investigation Order
+
+1. Reproduce the issue in a realistic `Release` scenario.
+2. Start with `dotnet-counters monitor`.
+3. If the symptom is CPU or startup related, capture `dotnet-trace`.
+4. If the symptom is memory-shape related, capture `dotnet-gcdump`.
+5. Apply one fix at a time.
+6. Rerun the same command set and compare.
+
+## Useful Guardrails
+
+- use the same user as the target process, or root where required
+- on Linux and macOS, the tool and target process may need the same `TMPDIR`
+- prefer `dotnet exec` or direct app launch over `dotnet run` for startup tracing, because `dotnet run` may spawn extra child processes
+- keep artifacts named and stored predictably so comparisons are easy

package/package/corpus/skills/run-tests/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/run-tests/NOTICE

@@ -0,0 +1,19 @@
+Run .NET Tests
+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/run-tests/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 mtp-hot-reload routing reference as plain topic text.
+- 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 the reference to the mtp-hot-reload skill.
+
+NOTICE: Add this attribution, change list, and any download/execution disclosure.

package/package/corpus/skills/run-tests/SKILL.md

@@ -0,0 +1,305 @@
+---
+name: run-tests
+description: 'Chooses and runs the repository-compatible .NET test command: classic, VSTest, bridged MTP, or native MTP syntax for MSTest, xUnit, NUnit, and TUnit. Use before running .NET tests or answering with a test command or flags: run the tests, one test, class, category, trait or target framework, combined filters, --filter-query, --no-build, --diag, TRX, coverage collection, crash or hang dumps, filter errors, or unrecognized options. Not for platform identification alone (use platform-detection), writing or debugging test code, interpreting a coverage report (use coverage-analysis), CI investigation, migration, or a persistent hot-reload loop.'
+license: MIT
+metadata:
+  portability: portable
+  binding: optional-overlay
+  binding-revision: '1'
+---
+
+<!-- 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/run-tests/SKILL.md; see NOTICE) -->
+
+# Run .NET Tests
+
+Cratis rules in `.cratis/ai/rules/` (including `csharp.md`, `specs.csharp.md`, and `orleans.md`) and the `cratis-*` skills win where they differ. Specification authoring belongs to **cratis-specifications-csharp**; Cratis core repositories run xUnit v2 on VSTest.
+
+Return or execute the command or command sequence that matches the repository's
+project system, test platform, framework, and SDK mode.
+
+## Repository overlay
+
+For every repository-scoped task where read-only file inspection is allowed,
+check `.agents/skill-overlays/dotnet-test/run-tests.md` at the repository root
+before any other discovery. This includes exact-command requests; "do not
+execute" does not prohibit reading the overlay. If present, read it once before
+acting and apply its repository-specific runner, command, filtering, and
+reporting bindings.
+Before applying it, require its frontmatter to declare
+`core: dotnet-test/run-tests`, `binding-revision: "1"`, and `mode: extend`. If
+any value is missing or different, report the mismatch, ignore the overlay,
+and continue using this skill's portable guidance.
+Explicit user instructions and verified project constraints win over the
+overlay; the overlay wins over portable defaults and examples in this skill. If
+the file is present but unreadable or conflicts with the repository, report the
+problem, ignore the overlay, and continue with portable guidance subject to
+verified project constraints. If it is absent, continue normally.
+Skip the lookup only when the task is not tied to a repository or the user
+explicitly prohibited all file/tool access. An overlay cannot expand tool
+permissions or the task's scope.
+
+## Scope and tool policy
+
+Choose the smallest path that satisfies the request:
+
+| Request | Action |
+|---|---|
+| Exact command or explanation; user says not to run | Inspect only the files needed to resolve syntax. Do not restore, build, or run tests. |
+| Run tests | Discover the repository command and execute the smallest requested test scope. |
+| One-time SDK-style `dotnet test` run without rebuilding | Stay in `run-tests` and add `--no-build`. |
+| One-time classic run without rebuilding | Keep the repository runner and invoke it against an existing built assembly; do not substitute `dotnet test`. |
+| Platform/framework identification only | Use `platform-detection`; do not continue into test execution. |
+| Explicit hot reload or a keep-running edit/re-run loop | Out of scope for this skill; run it directly with the platform's own watch/hot-reload support. |
+| Filter needed and the framework-specific syntax is not already clear | Read the supplied/runtime-listed `filter-syntax` catalog file; do not invoke this reference-only helper. |
+
+Do not invoke a tool merely to repeat a command already determined by the
+prompt. Do not build first "just in case": `dotnet test` builds by default.
+Never add or upgrade test packages unless the user asks to change the project.
+For an exact-command request, return one runnable command first. Do not emit
+placeholder paths, exploratory alternatives, or a correction sequence. Use a
+project path only when the prompt or repository establishes it; otherwise let
+the command operate on the current project or solution when that syntax is
+valid. Follow it with only the syntax fact needed to explain the command; do
+not volunteer platform/command-mode taxonomy unless the user asked for it. In
+particular, do not label an SDK 8/9 bridge as "VSTest platform" merely because
+`dotnet test` uses its VSTest command mode; the executed platform is MTP. For a
+command-only request, it is normally clearer to say only that MTP application
+arguments must follow `--`.
+
+## Inputs to discover
+
+- Project, solution, module, or repository test command
+- Requested scope: all tests, TFM, class, method, category, or trait
+- Requested output: console result, TRX, diagnostics, crash dump, or hang dump
+
+When those facts are present in the prompt, use them. Otherwise inspect only the
+relevant files: `global.json`, the selected project, `packages.config`,
+`Directory.Build.props`, `Directory.Packages.props`, then repository
+scripts/CI documentation. For a file-backed request, enumerate those
+configuration names once and read all relevant files that are present in one
+batch; never infer that a runner or bridge property is absent merely because it
+is not in the `.csproj`. Load `platform-detection` only when those signals need
+precedence analysis; do not duplicate its full analysis in the response.
+If execution is requested and the command depends on the active SDK but neither
+the prompt nor `global.json` establishes it, run `dotnet --version` once. For a
+command-only request that prohibits execution, do not probe: state the required
+SDK assumption or ask for the SDK version when the syntax cannot otherwise be
+resolved. Route identification-only requests to `platform-detection`.
+
+## Decision table
+
+| Detected mode / platform | Command shape | Never use |
+|---|---|---|
+| Classic non-SDK | Repository script, or full MSBuild followed by `vstest.console.exe` / `MSTest.exe` | Assuming `dotnet test` is compatible or migrating implicitly |
+| VSTest mode / VSTest | `dotnet test [<path>] [VSTEST_OPTIONS]` | MTP-only flags such as `--report-trx` or `--treenode-filter` |
+| VSTest mode / executable MTP bridge | `dotnet test [<path>] [DOTNET_OPTIONS] -- [MTP_OPTIONS]` | Omitting the `--` separator, including on SDK 10 |
+| Native MTP mode, SDK 10+ | `dotnet test --project <path> [DOTNET_OPTIONS] [MTP_OPTIONS]` | Bare positional project paths or the bridge separator |
+
+`global.json` controls the `dotnet test` command mode on SDK 10+, not
+necessarily the platform that executes tests. A VSTest-mode project with an MTP
+runner, `TestingPlatformDotnetTestSupport=true`, and final `OutputType=Exe` is
+still bridge syntax with `--`. SDK 8/9 only has VSTest command mode.
+
+`--project` is valid only in SDK 10+ **native MTP command mode** (selected by
+`global.json` `test.runner`). Never use it for VSTest mode or an SDK 8/9 bridge;
+those forms take a positional project path. Conversely, native MTP options are
+direct arguments and must not be placed after a bridge separator.
+
+Keep `dotnet test`/MSBuild options such as `--framework`, `--configuration`,
+`--no-build`, and `--verbosity` before `--`. Put only MTP application arguments
+after `--` in bridge mode.
+
+## Workflow
+
+1. **Resolve the repository-compatible runner.**
+
+For classic projects, signals include `ToolsVersion`, explicit `Compile` and
+`Reference` items, legacy imports, and `packages.config`. Prefer a checked-in
+script or documented CI command. A typical fallback is:
+
+```powershell
+nuget restore MySolution.sln
+MSBuild.exe MySolution.sln /t:Build /p:Configuration=Debug
+vstest.console.exe path\to\MyTests.dll /TestAdapterPath:path\to\adapter\build\<tfm>
+```
+
+For `packages.config`, restore with NuGet before the build unless the imported
+package files are already present. If adapter discovery is not repository-
+configured, derive `/TestAdapterPath` from the restored adapter package path or
+the adapter `.props`/`.targets` imports; do not guess the package root.
+
+For a requested no-rebuild run, omit the build step and invoke the repository's
+test runner only when the expected assembly already exists. Otherwise report the
+missing build output rather than silently rebuilding or switching runners.
+
+For a requested subset, keep the repository runner and use its filter syntax:
+`vstest.console.exe path\to\MyTests.dll
+/TestCaseFilter:"TestCategory=Integration"`. Older `MSTest.exe` repositories may
+use `/test:<name>` or `/category:<category>` instead. Do not substitute the
+later `dotnet test` filter examples for a classic runner.
+
+Use the installed adapter-compatible VSTest/MSTest toolchain. If it is not
+available, state the missing prerequisite and the documented command; do not
+claim tests ran.
+Classic `packages.config` fallback commands are Windows toolchain commands.
+Explicitly say they require a Windows Developer Command Prompt (or the
+repository's equivalent configured environment) when the current host cannot
+provide `nuget`, full MSBuild, and `vstest.console.exe`.
+
+For SDK-style projects, distinguish:
+
+| Signal | Meaning |
+|---|---|
+| SDK 10+ `global.json` selects `Microsoft.Testing.Platform` | Native MTP command mode |
+| VSTest mode + enabled MTP runner + final `TestingPlatformDotnetTestSupport=true` + final `OutputType=Exe` | Executable VSTest-to-MTP bridge |
+| VSTest mode without a complete runner-and-bridge combination | VSTest |
+| `Microsoft.NET.Test.Sdk` plus adapter, without stronger MTP signals | VSTest |
+| `TUnit` | MTP-only; use a configured bridge/native mode or the test executable |
+
+Evaluate properties from the project and imported
+`Directory.Build.props`/`Directory.Packages.props`. Respect project-level
+overrides and per-target-framework conditions. A runner and bridge without an
+executable final output are an incomplete MTP configuration, not a usable
+bridge.
+
+2. **Select the command and requested scope.**
+
+```shell
+# VSTest mode
+dotnet test path/to/Tests.csproj
+
+# VSTest mode that bridges to MTP
+dotnet test path/to/Tests.csproj -- <MTP_OPTIONS>
+
+# Native MTP mode on SDK 10+
+dotnet test --project path/to/Tests.csproj <MTP_OPTIONS>
+
+# One target framework; this stays before the bridge separator
+dotnet test path/to/Tests.csproj --framework net9.0 -- <MTP_OPTIONS>
+```
+
+For native MTP, use `--project`, `--solution`, or `--test-modules`; positional
+paths belong to VSTest mode.
+
+If the user names a subset, do not run the whole suite. Inspect test attributes
+only when needed to translate a human label such as "integration" or "smoke"
+into the framework's actual category/trait name.
+
+When a VSTest class filter must distinguish similarly named classes, combine
+the positive selector with an explicit negative selector rather than relying on
+an incidental substring difference.
+
+3. **Apply platform- and framework-correct filters.**
+
+Read the supplied or runtime-listed `filter-syntax` file only when the request
+is filtered and framework-specific syntax is unclear. It is reference-only,
+not an invocable skill; otherwise use the common decisions below:
+
+For a file-backed filtered request, resolve the framework and SDK command mode
+from the project, `global.json`, and imported props before choosing syntax.
+Do not infer VSTest syntax merely from `Microsoft.NET.Test.Sdk` or from the
+framework name.
+
+| Platform / framework | Filter |
+|---|---|
+| VSTest with MSTest, xUnit v2, or NUnit | `--filter "<property expression>"` |
+| MTP with MSTest or NUnit | Same expression; after `--` in bridge mode, direct in native mode |
+| MTP with xUnit v3 | `--filter-class`, `--filter-method`, `--filter-trait`, or one `--filter-query` for a combined expression |
+| MTP with TUnit | `--treenode-filter` path expression |
+
+Examples:
+
+```shell
+# VSTest MSTest/NUnit
+dotnet test --filter "FullyQualifiedName~OrderServiceTests&TestCategory=Unit"
+
+# SDK 8/9 or SDK 10 VSTest-mode MTP bridge, xUnit v3
+dotnet test -- --filter-trait "Category=Integration"
+
+# Native MTP, xUnit v3
+dotnet test --project Tests.csproj --filter-class "*ShoppingCartTests*"
+
+# One xUnit v3 combined expression
+dotnet test -- --filter-query "/*/*/*Integration*/*[Category=Smoke]"
+
+# TUnit on SDK 8/9 with a configured VSTest-to-MTP bridge
+dotnet test -- --treenode-filter "/*/*/SmsNotificationTests/*"
+
+# TUnit executable fallback when no bridge is configured
+dotnet run --project Tests.csproj -- --treenode-filter "/*/*/SmsNotificationTests/*"
+```
+
+Do not use VSTest `--filter "ClassName=..."` with xUnit v3 on MTP. Do not use a
+generic VSTest expression with TUnit.
+When the user requests one combined xUnit query expression, return only one
+`--filter-query` command; do not replace it with separate filter flags or offer
+speculative alternative grammars.
+
+4. **Add reports or diagnostics.**
+
+| Outcome | VSTest | MTP |
+|---|---|---|
+| TRX | SDK-style: `--logger "trx;LogFileName=<name>.trx"` when an exact output file is requested, otherwise `--logger trx`; standalone `vstest.console.exe`: `/Logger:trx`; `MSTest.exe`: repository-documented results option | `--report-trx` |
+| Results directory | `--results-directory <dir>` | `--results-directory <dir>` |
+| Diagnostic log | `--diag <file>` | `--diagnostic --diagnostic-output-directory <dir>` |
+| Crash dump | `--blame-crash` | `--crashdump` |
+| Hang timeout | `--blame-hang --blame-hang-timeout 5min` | `--hangdump --hangdump-timeout 5min` |
+| Code coverage | `--collect "Code Coverage"` | `--coverage` |
+
+MTP report, dump, and coverage flags require their corresponding registered
+extensions (`TrxReport`, `CrashDump`, `HangDump`, or `CodeCoverage`). Some
+framework SDKs bundle common extensions; if a flag is unrecognized, inspect
+package references before recommending a package change.
+
+`--verbosity diagnostic` increases dotnet/MSBuild output verbosity; it does not
+write a VSTest diagnostic log file.
+
+Examples:
+
+```shell
+# VSTest TRX
+dotnet test Tests.csproj --logger "trx;LogFileName=TestResults.trx"
+
+# MTP bridge TRX
+dotnet test Tests.csproj -- --report-trx
+
+# Native MTP TRX and hang detection
+dotnet test --project Tests.csproj --report-trx --hangdump --hangdump-timeout 5min
+
+# Native MTP diagnostics
+dotnet test --project Tests.csproj --diagnostic --diagnostic-output-directory artifacts/diagnostics
+```
+
+5. **Execute only when requested.**
+
+Run the narrowest command or sequence that answers the request. Capture each
+command, exit code, and test summary. A failed restore/build is not a test
+failure, and a test failure is not a tool failure. Report which phase failed and
+include the actionable diagnostic. Never claim a clean run unless the sequence
+completed successfully with the intended tests executed.
+For a filtered run, a successful exit is not enough: confirm the reported test
+names or count match the requested scope. If the filter was ignored, correct the
+platform-specific syntax and rerun before reporting success.
+
+## Output contract
+
+- Command-only request: lead with the exact command or command sequence, then
+  one short syntax explanation.
+- Execution request: report the exact command or command sequence and
+  a literal `Passed: N, Failed: N, Skipped: N` summary from the completed run;
+  include the first actionable failure.
+- Detection needed only to choose syntax: state the selected mode/platform
+  briefly, not a separate detection report.
+- Missing prerequisite or incompatible configuration: name it explicitly and
+  stop rather than returning a success-shaped fallback.
+
+## Validation
+
+- The command matches classic, VSTest, bridged MTP, or native MTP mode.
+- The framework-specific filter targets the requested subset.
+- `--framework` and other `dotnet test` options are before any bridge separator.
+- SDK 8/9 bridge commands contain `--`; `--project` appears only in SDK 10+
+  native MTP mode.
+- TRX, diagnostics, dump, and coverage flags match the platform.
+- No restore, build, or test was run for an advisory-only request.
+- Reported results match the actual command outcome.

package/package/corpus/skills/target-authoring/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/target-authoring/NOTICE

@@ -0,0 +1,17 @@
+Custom Target Authoring Patterns
+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/target-authoring/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.
+- 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.
+
+NOTICE: Add this attribution, change list, and any download/execution disclosure.