@cratis/pi 7.101.0 → 7.103.0

package/package/corpus/skills/platform-detection/SKILL.md

@@ -0,0 +1,230 @@
+---
+name: platform-detection
+description: 'Identifies a .NET project''s test platform, framework, command mode, and SDK-style versus classic project system, resolving global.json, project, packages.config, Directory.Build.props, and Directory.Packages.props precedence for MSTest, xUnit, NUnit, and TUnit. Use when asking "which test platform or framework?", "VSTest or MTP?", or "what runner does this project use?", including bridge settings, UseVSTest opt-outs, and conflicting VSTest/MTP configuration. Not for running or filtering tests, commands, flags, TRX, dumps, or test-command errors (use run-tests), or for hot-reload or migration requests.'
+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/platform-detection/SKILL.md; see NOTICE) -->
+
+# Test Platform and Framework Detection
+
+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.
+
+Determine **which test platform** (VSTest or Microsoft.Testing.Platform) and **which test framework** (MSTest, xUnit, NUnit, TUnit) a project uses.
+
+## Response contract
+
+Honor the user's requested labels and order exactly, substituting the actual
+classification for every placeholder. Start with the verdict: never put a
+heading, scratch analysis, tool syntax, or an echoed template before it. Follow
+with one concise evidence sentence naming the repository facts needed to justify
+every requested classification. When `Framework` is requested, name the package
+or project SDK that identifies it. Use a second sentence only for a conflict, an
+incomplete configuration, or target-framework-specific differences.
+
+`Platform` means the platform that actually executes tests: **VSTest** or
+**MTP**. If conflicting or incomplete configuration prevents execution, report
+it as unavailable rather than inventing a successful platform.
+
+Never classify the executed platform from `global.json` `test.runner` alone.
+That setting selects `dotnet test` command mode; even an explicit `VSTest`
+value can bridge to an executable MTP application. Continue through the project
+runner, bridge, and output-shape signals before writing `Platform:`.
+
+Apply this scope gate before drafting the evidence:
+
+| User asks for | Evidence to include | Omit |
+|---------------|---------------------|------|
+| Platform and framework | Final runner selector and its winning source; package or project SDK identifying the framework; when needed, the property that makes it executable | Command mode; common SDK facts; `OutputType` unless it is missing or conflicting |
+| The single deciding signal | That runner-selection property, why its source wins, and why a competing package does not select or imply VSTest; still name the package or project SDK identifying a requested framework | Bridge, `OutputType`, SDK mode, and unrelated prerequisites when the configuration is complete |
+| Platforms per target framework | Only the conditional final values that differ by target | Common properties and project-wide SDK commentary |
+| Explicit opt-out | Final `UseVSTest` value and its winning source | Superseded defaults unless they create a conflict |
+| `dotnet test` mode | The separate command-mode and executed-platform classifications | None of the requested axes |
+
+If the requested labels omit `dotnet test mode`, do not state or explain command
+mode anywhere in the response. An exact bridge property may still be decisive
+platform evidence, but do not turn it into SDK or CLI-mode commentary.
+When the user asks which single signal decides between an explicit runner
+property and `Microsoft.NET.Test.Sdk`, the evidence sentence must say both that
+the runner property selects MTP and that `Microsoft.NET.Test.Sdk` does not
+select or imply VSTest.
+
+When import precedence decides a property, state why the winning source wins
+(for example, it is imported later or its condition applies), not merely that it
+contains the final value or overrides another assignment.
+
+Keep the explanation on the requested axis:
+
+- An SDK version pin in `global.json` is context, not a platform selector. Claim
+  that `global.json` selects VSTest or native MTP only when its `test.runner`
+  setting actually does so.
+- If `UseVSTest=true` is decisive, say that directly. Do not speculate about an
+  absent `test.runner` or describe SDK pinning as an additional platform choice.
+- If command mode was not requested, do not add it, even when it was needed
+  internally to determine the executed platform.
+
+When a classic-project request also asks for the command family, add a direct
+line such as `Command family: MSBuild + vstest.console.exe`; do not turn it into
+an optional alternative or add an unnecessary build qualifier.
+
+For a file-backed request, enumerate the following configuration names once,
+then read every relevant file that is present in one batched operation:
+`global.json`, `.csproj`, `packages.config`, `Directory.Build.props`,
+`Directory.Build.targets`, `Directory.Packages.props`, and explicit imported
+`.props` / `.targets`. A setting absent from the project file may be defined by
+an import, so never infer its final value from the `.csproj` alone. Do not search
+the web or inspect unrelated files when repository configuration is sufficient.
+
+Resolve properties in the actual MSBuild import order, not with a fixed
+"project beats props" rule. For every applicable target framework:
+
+1. Follow the import graph and conditions. A later applicable assignment wins.
+   `Directory.Build.props` is normally imported before the project body, so an
+   unconditional project assignment normally overrides it; later `.targets`
+   can override the project again.
+2. Record the final value and its winning source for `UseVSTest`, the framework
+   runner selector, `TestingPlatformDotnetTestSupport`, and `OutputType`.
+3. Treat `Directory.Packages.props` as version evidence unless it also contains
+   relevant properties. Resolve package/SDK versions before applying
+   version-dependent defaults.
+4. Never infer a property from package presence. A package or SDK default counts
+   only when that resolved version actually supplies it and no later assignment
+   overrides it.
+
+## Detecting the project system
+
+Classify the project before selecting a CLI:
+
+- Root `Sdk` attribute or `<Sdk>` declaration: SDK-style.
+- `ToolsVersion`, `Microsoft.Common.props` / `Microsoft.CSharp.targets` imports,
+  explicit `<Reference>` and `<Compile Include>` items: classic non-SDK.
+- `packages.config`: classic NuGet dependency management.
+
+Classic projects can still use VSTest-compatible adapters, but `dotnet test` is
+not automatically a valid invocation. Preserve repository scripts/CI commands,
+commonly MSBuild followed by `vstest.console.exe`. Mention `MSTest.exe` only
+when repository configuration or documentation establishes that legacy runner.
+
+## Detecting the test framework
+
+Read the `.csproj`, adjacent `packages.config`, and
+`Directory.Build.props` / `Directory.Packages.props` and look for:
+
+| Package or SDK reference | Framework |
+|--------------------------|-----------|
+| `MSTest` metapackage, `<Project Sdk="MSTest.Sdk[/version]">`, or `<Sdk Name="MSTest.Sdk">` | MSTest |
+| `MSTest.TestFramework` + `MSTest.TestAdapter` | MSTest (also valid for v3/v4) |
+| `xunit`, `xunit.v3`, `xunit.v3.mtp-v1`, `xunit.v3.mtp-v2`, `xunit.v3.core.mtp-v1`, `xunit.v3.core.mtp-v2` | xUnit |
+| `NUnit` + `NUnit3TestAdapter` | NUnit |
+| `TUnit` | TUnit (MTP only) |
+
+In classic projects, package IDs and versions may appear only in
+`packages.config`, while the project contains assembly `<Reference>` elements
+with `HintPath` values. Use both sources.
+
+## Detecting the executed test platform
+
+If the user explicitly requests `dotnet test` mode, read
+[`references/command-mode.md`](references/command-mode.md) before answering.
+Do not load that reference or mention command mode for a
+platform/framework-only request.
+
+For an SDK 8/9 request that explicitly asks about command mode and has no
+effective bridge, state all three facts in one causal sentence: the runner makes
+the project MTP-capable, `dotnet test` remains in VSTest mode, and the missing
+bridge means VSTest actually executes the tests. Mention that native MTP command
+mode starts with SDK 10 only when it helps explain that result.
+
+When execution is permitted and neither the prompt nor `global.json` identifies
+the SDK, run `dotnet --version` once. For read-only identification requests that
+prohibit execution, do not probe the installed SDK; use repository facts and
+state any necessary SDK assumption.
+
+After resolving final property values, classify in this order:
+
+1. Final `UseVSTest=true` selects VSTest. If `global.json` simultaneously
+   selects native MTP command mode, report `Platform: unavailable` because the
+   command mode and project opt-out conflict.
+2. A native-MTP selection in `global.json` executes a compatible MTP
+   application with final `OutputType=Exe` on MTP. A VSTest-only,
+   library-output, or opted-out project is unavailable.
+3. On SDK 8/9, an enabled MTP runner plus final
+   `TestingPlatformDotnetTestSupport=true` plus final `OutputType=Exe` executes
+   on MTP.
+4. If the runner is enabled but the bridge is absent or false, a dual-capable
+   MSTest, NUnit, or xUnit project remains on VSTest: the runner establishes MTP
+   capability, but SDK 8/9 `dotnet test` cannot reach it and the VSTest adapter
+   executes the tests instead. If the bridge is true but no runner is enabled,
+   the project also remains on VSTest.
+5. A runner and bridge with non-executable output is incomplete and unavailable.
+   An MTP-only framework that cannot be reached by the selected SDK path is also
+   unavailable, not VSTest.
+
+Keep each signal's role exact:
+
+- The runner property selects the test application.
+- `TestingPlatformDotnetTestSupport=true` lets SDK 8/9 `dotnet test` reach that
+  application.
+- `OutputType=Exe` supplies the executable host shape. It does **not** select or
+  enable MTP.
+
+Do not confuse the `MSTest` metapackage with the `MSTest.Sdk` project SDK.
+`PackageReference Include="MSTest"` plus `EnableMSTestRunner=true` enables the
+MSTest MTP runner, but it does **not** implicitly set
+`TestingPlatformDotnetTestSupport`.
+
+MSTest.Sdk enables the MTP runner by default. Check its resolved version and
+evaluated properties for bridge behavior: version 3.8 supplies
+`TestingPlatformDotnetTestSupport` unless a later assignment overrides it,
+while newer SDKs on .NET 10 may expect native MTP mode instead.
+`<UseVSTest>true</UseVSTest>` opts back into VSTest.
+
+| Signal | Meaning |
+|--------|---------|
+| `<Project Sdk="MSTest.Sdk...">` with no `UseVSTest` | MTP application; inspect the resolved SDK version and evaluated bridge property |
+| `MSTest` metapackage + `<EnableMSTestRunner>true>` | MTP runner enabled; does not imply the VSTest-to-MTP bridge |
+| `<UseMicrosoftTestingPlatformRunner>true` | Deciding xUnit runner-selection signal |
+| `<EnableMSTestRunner>true>` / `<EnableNUnitRunner>true>` | Deciding MSTest/NUnit runner-selection signal |
+| `TestingPlatformDotnetTestSupport=true` | Execution prerequisite for a VSTest-to-MTP bridge, not the runner-selection signal |
+| `Microsoft.Testing.Platform` package | MTP-capable application; not decisive by itself |
+| `TUnit` | MTP-only framework |
+| Final evaluated `<OutputType>Exe</OutputType>` | Required executable host shape for package-based MTP applications |
+
+`Microsoft.NET.Test.Sdk` alone is not decisive; it can remain for compatibility
+in an MTP-enabled project. When an explicit override decides the result, name
+the final override and its source, not the superseded default.
+When a runner-selection property competes with `Microsoft.NET.Test.Sdk`, say
+that the runner property selects MTP and `Microsoft.NET.Test.Sdk` does **not**
+select or imply VSTest. It may remain as compatibility support, but that is
+secondary. `TestingPlatformDotnetTestSupport=true` is a bridge prerequisite, not
+the runner-selection signal; never say that this property alone enables the
+bridge. For a request asking which single signal decides, stop there. Omit
+bridge or host-shape prerequisites when the configuration is complete, and add
+them only when needed to explain why the selected runner cannot execute.
+Likewise, when an enabled runner is overridden or unreachable, state both axes
+causally: the runner property makes the project MTP-capable, but the final
+`UseVSTest`/bridge/output setting determines which platform actually executes.
+Name the runner selector before using a package reference only to identify the
+framework.
+
+Use causal evidence, not a bag of signals. For example:
+
+```text
+Platform: MTP
+Framework: NUnit
+
+Directory.Build.props supplies final EnableNUnitRunner=true and
+TestingPlatformDotnetTestSupport=true, so NUnit executes on MTP.
+```
+
+For an incompatible configuration, give one minimal alignment choice after the
+verdict without modifying files: either select the project's configured
+platform globally or remove the project opt-out to use the globally selected
+platform.
+
+### Conditional and per-target-framework properties
+
+Evaluate runner and bridge properties for each target framework. If conditions
+produce different executed platforms, report each target explicitly (for
+example, `net8.0: VSTest`, `net9.0: MTP`) rather than collapsing the project to
+one global platform.

package/package/corpus/skills/platform-detection/references/command-mode.md

@@ -0,0 +1,27 @@
+# `dotnet test` Command Mode
+
+Read this reference only when the user explicitly asks for command mode or
+supplies a `dotnet test mode:` output label.
+
+Command mode and executed test platform are separate axes. Command mode controls
+CLI syntax; VSTest mode can still bridge to an MTP test application.
+
+## Selection
+
+- SDK 10+ with `global.json` `"test": { "runner":
+  "Microsoft.Testing.Platform" }` selects native MTP mode.
+- SDK 10+ with runner `VSTest` or no `test` section selects VSTest mode.
+- SDK 8/9 supports only VSTest mode.
+
+Report the requested axes separately:
+
+```text
+dotnet test mode: VSTest
+Platform: MTP
+Framework: MSTest
+```
+
+A complete VSTest-to-MTP bridge still reports `dotnet test mode: VSTest` and
+`Platform: MTP`. Native MTP reports `dotnet test mode: native MTP`. If native
+MTP selection conflicts with a VSTest opt-out or incompatible project shape,
+report `Platform: unavailable` rather than inventing successful execution.

package/package/corpus/skills/profiling/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Managed Code
+
+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/profiling/NOTICE

@@ -0,0 +1,50 @@
+.NET Profiling
+Copyright (c) 2026 Managed Code
+Licensed under the MIT License. See LICENSE.
+
+Upstream source: https://github.com/managedcode/dotnet-skills/blob/2d8fba176a33b9872d5de35ec71d9ec71112ee26/catalog/Tools/Profiling/skills/profiling/SKILL.md
+
+Changes made by Cratis:
+
+LICENSE:
+- Copy upstream MIT license and copyright verbatim.
+
+SKILL.md:
+- Bootstrap step 4 records commands in task notes or the report instead of editing `AGENTS.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.
+- Add --version <x> placeholders to tool installations; pin the version.
+- Prefix official tool downloads/installs with marked approval/pinned-version guidance and privileged/perfcollect examples with explicit root/container-security approval, where present.
+- Scope upstream general workflow advice to this skill's stated task; it does not govern unrelated tasks.
+- Indent approval guard lines to keep the surrounding nested Markdown lists intact.
+- 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.
+
+references/commands.md:
+- Add --version <x> placeholders to tool installations; pin the version.
+- Replace obsolete dotnet-counters list examples with ps/monitor, as used elsewhere in this skill.
+- Prefix official tool downloads/installs with marked approval/pinned-version guidance and privileged/perfcollect examples with explicit root/container-security approval, where present.
+- Add or normalize the top Contents list from existing headings; preserve section content.
+
+references/profiling.md:
+- Add --version <x> placeholders to tool installations; pin the version.
+- Prefix official tool downloads/installs with marked approval/pinned-version guidance and privileged/perfcollect examples with explicit root/container-security approval, where present.
+- Add or normalize the top Contents list from existing headings; preserve section content.
+
+references/patterns.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):
+- SKILL.md: - `dotnet tool install --global dotnet-counters --version <x>`
+- SKILL.md: - `dotnet tool install --global dotnet-trace --version <x>`
+- SKILL.md: - `dotnet tool install --global dotnet-gcdump --version <x>`
+- SKILL.md: - direct-download fallback when global tools are not suitable:
+- SKILL.md: - use the official Microsoft Learn download links for `dotnet-counters`, `dotnet-trace`, and `dotnet-gcdump`
+- references/commands.md: dotnet tool install --global dotnet-counters --version <x>
+- references/commands.md: dotnet tool install --global dotnet-trace --version <x>
+- references/commands.md: dotnet tool install --global dotnet-dump --version <x>
+- references/commands.md: dotnet tool install --global dotnet-gcdump --version <x>
+- references/profiling.md: dotnet tool install --global dotnet-counters --version <x>
+- references/profiling.md: dotnet tool install --global dotnet-trace --version <x>
+- references/profiling.md: dotnet tool install --global dotnet-gcdump --version <x>

package/package/corpus/skills/profiling/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: profiling
+description: 'Uses the free official .NET diagnostics CLI tools for profiling and runtime investigation in a repository: CPU, GC pressure, allocation growth, exception storms, lock contention, and slow code. Use when a .NET application needs performance or runtime profiling. Not for replacing realistic performance or load tests with ad-hoc tracing, production heap collection without a pause-risk plan, crash dumps (use dump-collect), or benchmark design (use microbenchmarking).'
+compatibility: Requires a .NET app or process to inspect; respects the repo's `AGENTS.md` commands first.
+license: MIT
+---
+
+<!-- Modified by Cratis from managedcode's original (MIT): frontmatter, applicability, navigation and the changes listed in NOTICE. Upstream: https://github.com/managedcode/dotnet-skills (catalog/Tools/Profiling/skills/profiling/SKILL.md; see NOTICE) -->
+
+# .NET Profiling
+
+Use only within this skill's stated task; general workflow advice does not apply to unrelated tasks. Cratis rules in `.cratis/ai/rules/` (including `csharp.md`, `specs.csharp.md`, and `orleans.md`) and the `cratis-*` skills win where they differ. Write outputs only to the task's `.ai-work/<task>/` folder; run collection commands there, not in `profile-output/`.
+
+## Trigger On
+
+- the repo needs performance or runtime profiling for a .NET application
+- the user asks about slow code, high CPU, GC pressure, allocation growth, exception storms, lock contention, or startup diagnostics
+- the team wants official CLI-based diagnostics without depending on `dnx`
+
+## Value
+
+- produce a concrete project delta: code, docs, config, tests, CI, or review artifact
+- reduce ambiguity through explicit planning, verification, and final validation skills
+- leave reusable project context so future tasks are faster and safer
+
+## Do Not Use For
+
+- replacing realistic performance tests or load tests with ad-hoc tracing alone
+- production heap collection when the pause risk has not been accepted
+- GUI-only workflows that the repo cannot automate or document
+
+## Inputs
+
+- the nearest `AGENTS.md`
+- target application, process, or startup path
+- the symptom being investigated: CPU, memory, GC, contention, exceptions, or startup
+
+## Quick Start
+
+1. Read the nearest `AGENTS.md` and confirm scope and constraints.
+2. Run this skill's `Workflow` through the `Ralph Loop` until outcomes are acceptable.
+3. Return the `Required Result Format` with concrete artifacts and verification evidence.
+
+## Workflow
+
+1. Build and run a realistic target first:
+   - prefer `Release`
+   - prefer realistic config, inputs, and data volume
+2. Start with the lightest useful tool:
+   - `dotnet-counters` for live health signals
+   - `dotnet-trace` for CPU, exception, contention, GC, and startup traces
+   - `dotnet-gcdump` for managed heap inspection when memory shape matters
+3. Prefer installed CLI tools over `dnx` one-shot execution so the repo commands stay stable and reproducible.
+4. Capture one focused profile at a time instead of mixing every signal into one run.
+5. For CPU and general runtime hotspots, start with `dotnet-trace collect`.
+6. For live triage, start with `dotnet-counters monitor` on `System.Runtime`.
+7. For heap analysis, use `dotnet-gcdump` carefully and document the pause risk.
+8. After each change, rerun the same measurement path and compare before versus after.
+
+## Bootstrap When Missing
+
+If official .NET profiling tools are not available yet:
+
+1. Detect current state:
+   - `dotnet --info`
+   - `dotnet tool list --global`
+   - `command -v dotnet-counters`
+   - `command -v dotnet-trace`
+   - `command -v dotnet-gcdump`
+2. Choose the install path deliberately:
+   - preferred machine-level install:
+     > **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>`
+   > **Cratis:** Downloads or installs a tool: requires the user's approval; prefer a pinned version (`dotnet tool install <tool> --version <x>`)
+   - direct-download fallback when global tools are not suitable:
+     > **Cratis:** Downloads or installs a tool: requires the user's approval; prefer a pinned version (`dotnet tool install <tool> --version <x>`)
+     - use the official Microsoft Learn download links for `dotnet-counters`, `dotnet-trace`, and `dotnet-gcdump`
+3. Verify the installed tools resolve correctly:
+   - `dotnet-counters --version`
+   - `dotnet-trace --version`
+   - `dotnet-gcdump --version`
+4. Record the exact profiling commands in the task's `.ai-work/<task>/` notes or the final report (propose an `AGENTS.md` or project-doc change only when the user asks for one; managed corpus files are never edited by hand), for example:
+   - `dotnet-counters monitor --process-id PID --counters System.Runtime`
+   - `dotnet-trace collect --process-id PID --profile dotnet-common,dotnet-sampled-thread-time -o trace.nettrace`
+   - `dotnet-gcdump collect --process-id PID --output heap.gcdump`
+5. Run one bounded command and return `status: configured` or `status: improved`.
+6. If the repo intentionally standardizes on another profiling stack and does not want these tools, return `status: not_applicable`.
+
+## Deliver
+
+- explicit official .NET profiling commands
+- a clear profiling path for CPU, counters, and heap inspection
+- reproducible diagnostics commands that humans and agents can rerun
+
+## Validate
+
+- the chosen tool matches the actual symptom
+- commands target a realistic process and configuration
+- before/after comparisons use the same scenario
+- heap collection warnings are explicit when `dotnet-gcdump` is used
+
+## Ralph Loop
+
+Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.
+
+1. Plan first (mandatory):
+   - analyze current state
+   - define target outcome, constraints, and risks
+   - write a detailed execution plan
+   - list final validation skills to run at the end, with order and reason
+2. Execute one planned step and produce a concrete delta.
+3. Review the result and capture findings with actionable next fixes.
+4. Apply fixes in small batches and rerun the relevant checks or review steps.
+5. Update the plan after each iteration.
+6. Repeat until outcomes are acceptable or only explicit exceptions remain.
+7. If a dependency is missing, bootstrap it or return `status: not_applicable` with explicit reason and fallback path.
+
+### Required Result Format
+
+- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`
+- `plan`: concise plan and current iteration step
+- `actions_taken`: concrete changes made
+- `validation_skills`: final skills run, or skipped with reasons
+- `verification`: commands, checks, or review evidence summary
+- `remaining`: top unresolved items or `none`
+
+For setup-only requests with no execution, return `status: configured` and exact next commands.
+
+## Load References
+
+- [references/commands.md](references/commands.md)
+- [references/patterns.md](references/patterns.md)
+- [references/profiling.md](references/profiling.md)
+
+## Example Requests
+
+- "Profile this .NET app for CPU hotspots."
+- "Investigate GC pressure in this service."
+- "Capture counters and a trace from startup."
+- "Set up official .NET profiling tools for local investigations."