@cratis/pi 7.105.1 → 7.107.0

package/package/corpus/harnesses/copilot/instructions/profiles.instructions.md

@@ -87,6 +87,7 @@ profile includes neither Screenplay nor Stage.
 | Profile ID | Description | Automatically Includes |
 |---|---|---|
 | `cratis/engineering` | Engineering conventions and workflows | `cratis/engineering/core`, `cratis/engineering/csharp`, `cratis/engineering/elixir`, `cratis/engineering/go`, `cratis/engineering/kotlin`, `cratis/engineering/react`, `cratis/engineering/typescript` |
+| `cratis/engineering/core` | Shared engineering method skills: `cratis-ci-pipeline-performance`, `cratis-documentation-writing`, `cratis-engineering-ci-gates`, `cratis-engineering-consolidation-guard`, `cratis-engineering-decision-record`, `cratis-engineering-docs-authoring`, `cratis-engineering-effect-boundaries`, `cratis-engineering-issue-hygiene`, `cratis-engineering-local-cross-repo-verification`, `cratis-engineering-regression-cluster`, `cratis-engineering-release-trains`, `cratis-engineering-review-rounds`, `cratis-release-notes`, `cratis-technical-examples` | (no child profiles) |
 | `cratis/engineering/csharp` | C# engineering conventions, .NET engineering skills, and framework Orleans jobs (`cratis-orleans-jobs`, alongside `orleans.md`) | `cratis/engineering/core`, `cratis/engineering/dotnet` |
 | `cratis/engineering/dotnet` | Upstream .NET engineering workflows | `cratis/engineering/dotnet/performance`, `cratis/engineering/dotnet/diagnostics`, `cratis/engineering/dotnet/msbuild`, `cratis/engineering/dotnet/orleans`, `cratis/engineering/dotnet/testing`, `cratis/engineering/dotnet/refactoring` |
 | `cratis/engineering/dotnet/performance` | Microbenchmarking, performance patterns, SIMD, and profiling | (no child profiles) |

package/package/corpus/harnesses/copilot/instructions/pull-requests.instructions.md

@@ -126,9 +126,10 @@ intents do not.
   name the exact breaking change(s), who is affected and how, and the
   resulting version number. A generic "ready to ship?" is not this checkpoint —
   say plainly that this release breaks compatibility and needs a yes.
-- Proceed to merge only on an explicit, affirmative answer to that question.
-  A prior general instruction to "ship" or "land this" does not answer it,
-  even when it named `major` as the intended label.
+- A human merges a `major` PR, after answering that question with an explicit
+  yes. An agent never merges it, even after the confirmation. A prior general
+  instruction to "ship" or "land this" does not answer it, even when it named
+  `major` as the intended label.
 - This checkpoint is per release, not per conversation — a human confirming
   one major release does not pre-authorize the next one.
 
@@ -156,7 +157,7 @@ A non-release pull request must satisfy the relevant required checks like any ot
 
 ### Group small related changes into one pull request
 
-Do not open a pull request per task when the tasks belong to the same body of work. Several small merged PRs become several releases, and a stream of near-empty patch releases makes the release history useless for the people it is written for. Collect related work — a set of CI gates, a group of fixes in one area, the steps of one refactor — onto **one branch, as separate commits**, and open **one** pull request. Commits stay one-logical-unit-each; the pull request is the release boundary, and the release boundary should be a coherent, describable change.
+Do not open a pull request per task when the tasks belong to the same body of work. Several small merged PRs become several releases, and a stream of near-empty patch releases makes the release history useless for the people it is written for. Collect related work — a set of CI gates, a group of fixes in one area, the steps of one refactor — onto **one branch, as separate commits**, and open **one** pull request. Commits stay one-logical-unit-each; the pull request is the release boundary, and the release boundary should be a coherent, describable change. Joining an open candidate, folding superseded PRs and the cut are in `cratis-engineering-release-trains`.
 
 **Before consolidating open PRs, review each PR’s release intent and workflow effects.** Integration may trigger completion/publication behavior on an absorbed PR. Use supported non-release intent where appropriate. A direct request to consolidate the named pull requests authorizes the necessary relabeling and merge; it does not authorize unrelated notifications.
 
@@ -177,4 +178,4 @@ Before marking code/automation work ready, select the affected-project gates tha
 - `yarn lint` — zero errors
 - `npx tsc -b` — zero TypeScript errors
 - Code follows all project coding standards and conventions
-- **Required CI checks pass.** After an authorized push, inspect checks and failure logs. Diagnose within a bounded attempt, fix in-scope causes, and re-run relevant gates after each fix. Report unrelated/environmental failures and missing authority as blockers rather than retrying indefinitely or silently waiving required checks. If a release job fails after a concurrent merge (the release for the tag exists for another commit), re-run it: it releases under the next version (release-action v1.4.2 fails the job rather than reporting success).
+- **Required CI checks pass.** After an authorized push, inspect checks and failure logs. Diagnose within a bounded attempt, fix in-scope causes, and re-run relevant gates after each fix. Report unrelated/environmental failures and missing authority as blockers rather than retrying indefinitely or silently waiving required checks. Waiting, cancelling and tiered local gates are in `cratis-engineering-ci-gates`. If a release job fails after a concurrent merge (the release for the tag exists for another commit), re-run it: it releases under the next version (release-action v1.4.2 fails the job rather than reporting success).

package/package/corpus/harnesses/copilot/instructions/review-reports.instructions.md

@@ -67,6 +67,12 @@ When a workflow requires a typed review envelope, preserve its schema and expres
 these sections, verdict meanings, and scope limits through its existing fields.
 Do not append a competing Markdown report or invent envelope fields.
 
+## Rounds
+
+A follow-up round reviews only the delta since the last reviewed commit and carries prior
+findings forward. Cap the rounds and prefer one structural fix over looping. See
+`cratis-engineering-review-rounds`.
+
 ## Reviewer independence
 
 - **[contract]** Run a reviewer on a different provider family than the author's model

package/package/corpus/product-sync.json

@@ -171,9 +171,9 @@
         }
       ],
       "synced": {
-        "version": "4.235.0",
-        "date": "2026-10-19",
-        "by": "Cratis/AI#837"
+        "version": "4.244.0",
+        "date": "2026-10-20",
+        "by": "Cratis/AI#891"
       },
       "covers": {
         "skills": [

package/package/corpus/prompts/ship-changes.prompt.md

@@ -15,7 +15,7 @@ branch → commits → PR → merge → issue disposition → cleanup workflow.
 
 - **What changed** — brief description of the work (used for branch name and PR title)
 - **Label** — exactly one of `no-release`, `patch`, `minor`, or `major`, selected from the repository's release contract and applied in `gh pr create --label <intent>`
-- **Related issue** — optional exact repository and issue number; if unknown, search read-only first. Comment on or close it only when the user's request includes that effect; otherwise prepare the disposition as a proposal. In repositories released by `cratis/release-action`, a delivered issue is closed by release-action through `(#n)` in the description, but release-action does not run for a `no-release` PR, so `(#n)` closes nothing there; elsewhere follow the repository's own release and issue-closing process.
+- **Related issue** — optional exact repository and issue number; if unknown, search read-only first. Comment on or close it only when the user's request includes that effect; otherwise prepare the disposition as a proposal. In repositories released by `cratis/release-action`, a delivered issue is closed by release-action through `(#n)` in the description, but release-action does not run for a `no-release` PR, so `(#n)` closes nothing there; elsewhere follow the repository's own release and issue-closing process. Keep the issue current and close it with a reason per `cratis-engineering-issue-hygiene`.
 
 Invoking this prompt is direct authority for the standard branch, commit, push, pull-request,
 requested-label, merge, and branch-cleanup effects. Do not pause to ask for separate approval at
@@ -24,8 +24,8 @@ and verify required checks before merging.
 
 **Exception: a `major` label does not carry merge authority.** Prepare the branch, commits, push,
 and PR labeled `major` as usual, then stop before merging. Ask a human to confirm the breaking
-change(s), who is affected, and the resulting version number, and merge only on an explicit
-affirmative answer to that specific question — see
+change(s), who is affected, and the resulting version number; the human merges it after an
+explicit yes to that specific question, and an agent never does — see
 [`pull-requests.md`](../rules/pull-requests.md#a-major-release-needs-a-humans-explicit-go-ahead).
 Every other label proceeds through merge under this prompt's ordinary authority.
 
@@ -33,6 +33,19 @@ This prompt is for an explicit request to ship or land. If the user asked only t
 push, or only to open a PR, stop after that step: the narrower request does not become authority
 for the rest of the chain because this prompt happens to be loaded.
 
+## Before you branch
+
+Check for an open release candidate or PR in the repository before opening a new branch.
+Group related work onto one branch and one PR, and join an open candidate instead of starting
+another. The method is in the `cratis-engineering-release-trains` skill.
+
+## Waiting on checks and merging
+
+Push only when the ship bar is met: root cause understood, specs added, local gate green,
+review passed, issue and PR re-read, and no overlap with main. Then watch the exact run once
+instead of polling it. Merge only after required checks pass. The method is in the
+`cratis-engineering-ci-gates` skill. For review rounds, see `cratis-engineering-review-rounds`.
+
 ## Pull request description
 
 The description is published verbatim as the release notes, so it follows the contract in

package/package/corpus/rules/issue-assignment.md

@@ -29,3 +29,4 @@ up, or it looks abandoned while it is being done.
 The user's request to work on the issue is the authority for this assignment; do not ask
 before doing it. It authorizes assigning the issue and nothing else: commenting, labeling
 or closing still follow [pull-requests.md](./pull-requests.md) and the user's request.
+- **After claiming,** keep the issue current per `cratis-engineering-issue-hygiene`.

package/package/corpus/rules/profiles.md

@@ -86,6 +86,7 @@ profile includes neither Screenplay nor Stage.
 | Profile ID | Description | Automatically Includes |
 |---|---|---|
 | `cratis/engineering` | Engineering conventions and workflows | `cratis/engineering/core`, `cratis/engineering/csharp`, `cratis/engineering/elixir`, `cratis/engineering/go`, `cratis/engineering/kotlin`, `cratis/engineering/react`, `cratis/engineering/typescript` |
+| `cratis/engineering/core` | Shared engineering method skills: `cratis-ci-pipeline-performance`, `cratis-documentation-writing`, `cratis-engineering-ci-gates`, `cratis-engineering-consolidation-guard`, `cratis-engineering-decision-record`, `cratis-engineering-docs-authoring`, `cratis-engineering-effect-boundaries`, `cratis-engineering-issue-hygiene`, `cratis-engineering-local-cross-repo-verification`, `cratis-engineering-regression-cluster`, `cratis-engineering-release-trains`, `cratis-engineering-review-rounds`, `cratis-release-notes`, `cratis-technical-examples` | (no child profiles) |
 | `cratis/engineering/csharp` | C# engineering conventions, .NET engineering skills, and framework Orleans jobs (`cratis-orleans-jobs`, alongside `orleans.md`) | `cratis/engineering/core`, `cratis/engineering/dotnet` |
 | `cratis/engineering/dotnet` | Upstream .NET engineering workflows | `cratis/engineering/dotnet/performance`, `cratis/engineering/dotnet/diagnostics`, `cratis/engineering/dotnet/msbuild`, `cratis/engineering/dotnet/orleans`, `cratis/engineering/dotnet/testing`, `cratis/engineering/dotnet/refactoring` |
 | `cratis/engineering/dotnet/performance` | Microbenchmarking, performance patterns, SIMD, and profiling | (no child profiles) |

package/package/corpus/rules/pull-requests.md

@@ -125,9 +125,10 @@ intents do not.
   name the exact breaking change(s), who is affected and how, and the
   resulting version number. A generic "ready to ship?" is not this checkpoint —
   say plainly that this release breaks compatibility and needs a yes.
-- Proceed to merge only on an explicit, affirmative answer to that question.
-  A prior general instruction to "ship" or "land this" does not answer it,
-  even when it named `major` as the intended label.
+- A human merges a `major` PR, after answering that question with an explicit
+  yes. An agent never merges it, even after the confirmation. A prior general
+  instruction to "ship" or "land this" does not answer it, even when it named
+  `major` as the intended label.
 - This checkpoint is per release, not per conversation — a human confirming
   one major release does not pre-authorize the next one.
 
@@ -155,7 +156,7 @@ A non-release pull request must satisfy the relevant required checks like any ot
 
 ### Group small related changes into one pull request
 
-Do not open a pull request per task when the tasks belong to the same body of work. Several small merged PRs become several releases, and a stream of near-empty patch releases makes the release history useless for the people it is written for. Collect related work — a set of CI gates, a group of fixes in one area, the steps of one refactor — onto **one branch, as separate commits**, and open **one** pull request. Commits stay one-logical-unit-each; the pull request is the release boundary, and the release boundary should be a coherent, describable change.
+Do not open a pull request per task when the tasks belong to the same body of work. Several small merged PRs become several releases, and a stream of near-empty patch releases makes the release history useless for the people it is written for. Collect related work — a set of CI gates, a group of fixes in one area, the steps of one refactor — onto **one branch, as separate commits**, and open **one** pull request. Commits stay one-logical-unit-each; the pull request is the release boundary, and the release boundary should be a coherent, describable change. Joining an open candidate, folding superseded PRs and the cut are in `cratis-engineering-release-trains`.
 
 **Before consolidating open PRs, review each PR’s release intent and workflow effects.** Integration may trigger completion/publication behavior on an absorbed PR. Use supported non-release intent where appropriate. A direct request to consolidate the named pull requests authorizes the necessary relabeling and merge; it does not authorize unrelated notifications.
 
@@ -176,4 +177,4 @@ Before marking code/automation work ready, select the affected-project gates tha
 - `yarn lint` — zero errors
 - `npx tsc -b` — zero TypeScript errors
 - Code follows all project coding standards and conventions
-- **Required CI checks pass.** After an authorized push, inspect checks and failure logs. Diagnose within a bounded attempt, fix in-scope causes, and re-run relevant gates after each fix. Report unrelated/environmental failures and missing authority as blockers rather than retrying indefinitely or silently waiving required checks. If a release job fails after a concurrent merge (the release for the tag exists for another commit), re-run it: it releases under the next version (release-action v1.4.2 fails the job rather than reporting success).
+- **Required CI checks pass.** After an authorized push, inspect checks and failure logs. Diagnose within a bounded attempt, fix in-scope causes, and re-run relevant gates after each fix. Report unrelated/environmental failures and missing authority as blockers rather than retrying indefinitely or silently waiving required checks. Waiting, cancelling and tiered local gates are in `cratis-engineering-ci-gates`. If a release job fails after a concurrent merge (the release for the tag exists for another commit), re-run it: it releases under the next version (release-action v1.4.2 fails the job rather than reporting success).

package/package/corpus/rules/review-reports.md

@@ -66,6 +66,12 @@ When a workflow requires a typed review envelope, preserve its schema and expres
 these sections, verdict meanings, and scope limits through its existing fields.
 Do not append a competing Markdown report or invent envelope fields.
 
+## Rounds
+
+A follow-up round reviews only the delta since the last reviewed commit and carries prior
+findings forward. Cap the rounds and prefer one structural fix over looping. See
+`cratis-engineering-review-rounds`.
+
 ## Reviewer independence
 
 - **[contract]** Run a reviewer on a different provider family than the author's model

package/package/corpus/skills/cratis-ci-pipeline-performance/SKILL.md

@@ -134,7 +134,7 @@ OS or framework matrix. Default: full matrix on `schedule` and
 rule states this). Pitfall: the full matrix needs an owner who reads its failures.
 
 **Flaky and hung jobs.** Fits failure-bound workflows. Default: a
-`timeout-minutes` on every job, `--blame-hang`, retry only a diagnosed flake, and
+`timeout-minutes` on every job, `--blame-hang` with a mini dump, retry only a diagnosed flake, and
 quarantine a test with an issue. Pitfall: a blanket rerun hides the defect and
 doubles minutes. Read `references/flaky-and-hung-jobs.md`.
 

package/package/corpus/skills/cratis-ci-pipeline-performance/references/flaky-and-hung-jobs.md

@@ -25,12 +25,14 @@ cost runner-minutes and developer trust; diagnose before retrying.
 
 ```bash
 dotnet test Repo.slnx --configuration Release --no-build \
-  --blame-hang --blame-hang-timeout 5m --blame-crash \
+  --blame-hang --blame-hang-timeout 5m --blame-hang-dump-type mini \
+  --blame-crash --blame-crash-dump-type mini \
   --results-directory TestResults
 ```
 
 - This is the VSTest form. Microsoft.Testing.Platform projects use their own
-  crash and hang dump extensions and options; do not mix the two sets of switches.
+  crash and hang dump extensions and options (`--hangdump-type Mini`, `--crashdump-type Mini`); do not mix the two sets of switches.
+- Read the stack (for example `dotnet-dump analyze <file>` then `clrstack -all`), keep the text output, and delete the `.dmp` file. Use a full dump only for a named investigation that needs heap contents.
 - Upload `TestResults` as an artifact with `if: ${{ !cancelled() }}`, so the dump
   survives the failure.
 

package/package/corpus/skills/cratis-code-review/SKILL.md

@@ -177,6 +177,9 @@ correction before merge. Style preferences and maintainability improvements
 without such a consequence belong in Suggestions. Apply the shared verdict
 vocabulary to those findings.
 
+For a follow-up round after blockers were fixed, review only the delta and carry prior
+findings forward; see `cratis-engineering-review-rounds`.
+
 ## What breaks
 
 - **The review restates the compiler.** The gates were not run first, so

package/package/corpus/skills/cratis-code-review/verification.json

@@ -5,6 +5,7 @@
   "assertions": [
     { "kind": "skill-contains", "value": ".cratis/ai/rules/review-reports.md" },
     { "kind": "skill-contains", "value": "Correctness regressions, broken contracts" },
-    { "kind": "skill-contains", "value": "Style preferences and maintainability improvements" }
+    { "kind": "skill-contains", "value": "Style preferences and maintainability improvements" },
+    { "kind": "skill-contains", "value": "cratis-engineering-review-rounds" }
   ]
 }

package/package/corpus/skills/cratis-engineering-ci-gates/LICENSE

@@ -0,0 +1,2 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the canonical Cratis/AI repository for the full license text.

package/package/corpus/skills/cratis-engineering-ci-gates/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: cratis-engineering-ci-gates
+description: Run CI-matched local gates and watch exact workflow runs without polling or wasting checks. Use when choosing a local gate or tier, deciding how to wait for CI, starting a blocking watch, or deciding which superseded runs to cancel. Not for grouping deliveries (use cratis-engineering-release-trains), review iterations (use cratis-engineering-review-rounds), or editing workflows for speed (use cratis-ci-pipeline-performance).
+license: LICENSE
+compatibility: Requires git and the GitHub CLI (gh).
+---
+
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Run the gate once, then watch the exact run
+
+Operate checks; do not redesign workflows here. Read
+[verification-discipline.md](../../rules/verification-discipline.md) for phase
+budgets and exit-status handling, and
+[pull-requests.md](../../rules/pull-requests.md#quality-gates) for required checks.
+Read [capability-is-not-authority.md](../../rules/capability-is-not-authority.md)
+before an external effect. A request to verify does not authorize a push.
+
+## Derive the local gate
+
+1. Read `.github/workflows/` and the repository's tier policy. Follow reusable
+   workflows and invoked scripts. Extract commands, solution and test selection,
+   configuration, warning settings, analyzers, lint and formatting checks.
+2. Prefer the repository's existing gate script. If none exists, keep a small
+   local runner under `.ai-work/`, with each phase's real exit status preserved.
+   Do not substitute only the touched projects for the final gate.
+3. **Tier 1** is the whole-solution build with CI's configuration and warning
+   settings, lint/format, and every non-integration test project. For example,
+   use Release with warnings as errors when that is what CI uses.
+4. **Tier 2** adds integration tests. The repository's tier policy decides
+   whether they run locally. The default is CI-backed integration only if CI
+   runs that coverage, it passes before merge, and reviewer notes say it was
+   deferred to CI. If CI lacks that coverage, do not claim it is verified.
+5. Name anything CI runs that cannot run locally: services, platforms, secrets
+   or hosted checks. Say what ran instead and what remains unverified before
+   pushing. Missing coverage is not a local pass.
+
+Use affected-project checks while coding and writing specifications. Build once
+at the end: run the full local gate when the work is believed complete, not after
+every edit. Do not repeat a passing gate on unchanged inputs for reassurance.
+When several deliveries form one candidate, the assembler runs the final gate
+on the assembled state; deliveries bring targeted results. A changed state after
+a failure needs the required gate again.
+
+Keep build, lint and test phases separate, each with a deadline. Stop on failure;
+do not run dependent phases or hide a producer's exit status behind a filter.
+Report the exact command and result. Put verification and deferred coverage in
+reviewer comments, not the release-note description.
+
+## Wait without polling
+
+After an authorized push, capture the full head SHA and discover the run for the
+intended workflow. For example:
+
+```bash
+head_sha=$(git rev-parse HEAD)
+gh run list --repo OWNER/REPO --workflow ci.yml --commit "$head_sha" \
+  --json databaseId,headSha,event,status
+```
+
+Select the exact run ID, not the newest run by time or branch alone. Disambiguate
+multiple events or dispatches for the same SHA. Capture one ID per required
+workflow. If no matching run is visible, report that no run was captured; do not
+start a status-query loop or guess an ID.
+
+Start one blocking watch for that run, with a deadline sized to the repository:
+
+```bash
+gh run watch <id> --repo OWNER/REPO --exit-status
+```
+
+A background job, if the harness has one, can hold the same blocking watch.
+Never re-query status by hand. Use the watch's completion and exit status, not
+repeated `gh run list`, `gh run view` or PR-check requests while waiting.
+
+Say: "Waiting on CI run <id> for the current PR head." Do independent work while
+it runs. If none remains, end the turn. If the watch cannot finish in the session,
+leave a handoff under `.ai-work/` with the SHA, run ID and outstanding checks;
+report the wait as incomplete, not successful. A watch timeout does not cancel
+the remote run and is not a failed-test diagnosis.
+
+## Diagnose once, fix together
+
+After the run completes with a failure:
+
+1. Read the failed logs once, for example
+   `gh run view <id> --repo OWNER/REPO --log-failed`.
+2. Check other jobs in that completed run, for example
+   `gh run view <id> --repo OWNER/REPO --json jobs`. Account for every failure,
+   including independent failures beyond the first red job.
+3. Fix all in-scope causes together. Report unrelated or unavailable causes as
+   blockers rather than silently waiving them. Re-run the required local gate
+   on the fixed state, then push once when the request authorizes it.
+4. Rerun a job only for a diagnosed flake, including a demonstrated transient
+   infrastructure failure, and only after the run completes. For example,
+   `gh run rerun <id> --repo OWNER/REPO --failed` retries failed jobs. Watch the
+   resulting attempt once. A deterministic failure needs a fix, not a retry.
+
+Never put a CI skip token in a title or commit. Do not spend a push on each
+individual fix or use CI to discover whether speculative fixes compile.
+
+## Cancel only owned, superseded work
+
+Cancellation needs a reason and an exact target. Within an authorized shipping
+or folding request, cancel only runs started by the session's own superseded or
+folded pushes. Anyone else's run needs the owner's agreement. Merely sharing a
+branch or finding a duplicate run does not establish ownership.
+
+Before acting, inspect each candidate, for example:
+
+```bash
+gh run view <id> --repo OWNER/REPO \
+  --json workflowName,event,headBranch,headSha,status,createdAt
+```
+
+Confirm the initiating push, workflow and SHA against the superseding head or
+folded PR. Inspect the workflow's jobs if its effects are unclear. Never cancel
+a release, publish or deploy run, regardless of ownership or workflow name.
+Do not cancel a check whose result a queued or running publication needs, or a
+required check about to gate a merge. Another owner's watched merge run needs
+that owner's agreement. Even with agreement, release, publish and deploy runs
+and checks needed by publication remain protected.
+
+Re-read immediately before cancelling so drift cannot widen the target. Do not
+cancel by branch, name or age alone, or use a bulk cancellation command. Once
+confirmed, for example:
+
+```bash
+gh run cancel <id> --repo OWNER/REPO
+```
+
+Report one line naming the run ID and superseding or folding reason. If ownership
+or downstream use is uncertain, leave it running and report the uncertainty.
+
+## Integration and containers
+
+Run local integration only when the tier policy calls for it or a bounded
+cross-repository proof needs it. Give every container phase and Docker call a
+deadline, including startup, image builds, tests and teardown. A background job
+is not a timeout or a cleanup policy.
+
+Keep track of the containers and networks created by the phase. On success,
+failure, timeout or abandonment, stop and remove only those owned resources.
+Use exact IDs or a task-specific Compose project; confirm ownership before
+removal. Do not restart a shared daemon or stop another task's services.
+Never run `docker system prune -a` or `docker image prune -a`.
+
+When a test run hangs, ask for a mini hang dump (`--blame-hang-dump-type mini` on VSTest, `--hangdump-type Mini` on Microsoft.Testing.Platform). Read the stack (for example `dotnet-dump analyze <file>` then `clrstack -all`), keep the text output, and delete the `.dmp` file. Use a full dump only for a named investigation that needs heap contents.
+
+For a repository's Compose test setup, one scoped teardown example is
+`docker compose -p <task-project> down`, under its own deadline. Do not add
+volume deletion unless those volumes are disposable and owned by this task.
+Keep secrets out of logs and artifacts per
+[secrets.md](../../rules/secrets.md).
+
+## What breaks
+
+- An affected-project build presented as Tier 1 leaves other projects unchecked.
+- A green Tier 1 presented as integration proof hides coverage deferred to CI.
+- Watching a branch's newest run can report success for the wrong SHA.
+- Manual polling duplicates the watch and wastes time without improving proof.
+- Blind retries and one push per failure spend checks without fixing the run.
+- Broad container cleanup destroys resources the phase does not own.
+
+## How it is proven
+
+The derived local commands exit successfully on the final state. The blocking
+watch for each required run exits successfully for the exact head SHA, including
+integration coverage deferred to CI. A timeout, cancellation, missing check or
+unobserved result stays unverified. Report local results, CI results and omissions
+separately; no inventory or receipt substitutes for running the checks.

package/package/corpus/skills/cratis-engineering-issue-hygiene/LICENSE

@@ -0,0 +1,2 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the canonical Cratis/AI repository for the full license text.

package/package/corpus/skills/cratis-engineering-issue-hygiene/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: cratis-engineering-issue-hygiene
+description: Keep GitHub issues current and reduce unfinished work with a single-writer status block and reasoned disposition. Use when maintaining an issue status block, deciding who may claim an issue, whether to close completed work, or whether to file a necessary follow-up. Not for grouping deliveries (use cratis-engineering-release-trains), review iterations (use cratis-engineering-review-rounds), workflow optimization (use cratis-ci-pipeline-performance), or CI operations (use cratis-engineering-ci-gates).
+license: LICENSE
+compatibility: Requires git and the GitHub CLI (gh).
+---
+
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Leave fewer issues, with a truthful description
+
+An issue must make sense to a reader outside the session. Keep its present state
+in the description and meaningful events in the timeline. Before any mutation,
+read [capability-is-not-authority.md](../../rules/capability-is-not-authority.md).
+The request authorizes its named effects, not arbitrary filing or closing.
+
+## One writer and a clear claim
+
+One person or session owns all body edits, comments and disposition for a named
+issue. Delegated workers report findings to that owner. An explicit handoff can
+transfer the named issue, but the previous writer must stop editing it. GitHub
+body edits are not conditional writes; a last-minute reread alone cannot prevent
+two writers from overwriting each other.
+
+Before starting, read the issue, comments, assignees and any status block. Follow
+[issue-assignment.md](../../rules/issue-assignment.md) to claim it. Do not replace
+an existing assignment. If another writer is already active, coordinate rather
+than starting a parallel edit. A failed assignment is not a blocker to the work.
+
+When the request covers maintaining the issue, set the status block to
+**In progress** before coding. Keep it true as work moves: **In review** for the
+open PR, **Blocked** with the dependency, **Paused** when no active work remains,
+and **Done** only when delivery is confirmed. Never leave In progress behind
+when the writer stops.
+
+## Put the status block in the description
+
+Preserve the original problem statement and all text outside the managed block.
+Append the block if absent. Stop for coordination if markers are malformed,
+duplicated or already managed by another active writer. A minimal template is:
+
+```markdown
+<!-- agent-status:start -->
+## Status
+**State:** In progress
+**Scope:** Deliver the agreed behavior and its regression specification.
+**Approach:** Fix the shared decision and exercise it through the public API.
+**PR:** Not opened.
+**Delivered:** Nothing yet.
+**Remaining:** Implement, verify, review and deliver.
+**Follow-ups:** None.
+<!-- agent-status:end -->
+```
+
+Replace the example with the real scope and remaining work. Use public PR or
+issue URLs when they exist. Summarize a local plan; never link its file path.
+Do not put local paths, harness commands, credentials or private context in
+public issue or PR text. Read [secrets.md](../../rules/secrets.md) before handling
+output, and [local-work-artifacts.md](../../rules/local-work-artifacts.md) before
+creating the private working copy.
+
+For example, read the body into an ignored local working file:
+
+```bash
+gh issue view <n> --repo OWNER/REPO --json body --jq .body > .ai-work/issue-body.md
+```
+
+Edit only the managed block in that file. Immediately before writing, re-read
+both the issue and any linked PR. Read the remote body again:
+
+```bash
+gh issue view <n> --repo OWNER/REPO --json body
+```
+
+Compare it with the body used to prepare the edit. If anything changed, preserve
+those changes and recompose from the fresh body. If concurrent edits continue,
+stop and coordinate with the other writer. Do not write a stale whole body.
+After a clean comparison, write the complete preserved body back, for example:
+
+```bash
+gh issue edit <n> --repo OWNER/REPO --body-file .ai-work/issue-body.md
+gh issue view <n> --repo OWNER/REPO --json body
+```
+
+Verify the block changed as intended and the surrounding content stayed intact.
+Do not paste the private working-file path into the issue.
+
+## Description versus comment
+
+Edit the status block for current scope, decisions, approach, checklist, linked
+PRs, dependencies and what remains. The description alone should explain the
+present state. Do not rewrite other people's text or replace the original report.
+
+Comment only for an event worth notifying readers about: a decision or scope
+change with its reason, a human blocker, a delivery milestone or a closing
+summary. Each comment stands alone: what happened, why it matters, what comes
+next. Use absolute public URLs. Do not repeat the block as a comment or post
+"working on it", tool output, test counts, receipts or model/session chatter.
+
+Re-read the issue and PR before every key step: starting, changing scope,
+updating public state, filing follow-ups, merging or disposing of the issue.
+For example, use `gh issue view <n> --repo OWNER/REPO --comments` and
+`gh pr view <pr> --repo OWNER/REPO`. Do not act on an old summary after drift.
+
+## Make the open-issue count go down
+
+1. **Fix before filing.** Fix a small, in-scope finding in the same files and
+   risk area as the active change. Do not widen scope to improve the count.
+   Review advisories are fixed cheaply inline or dropped, not filed as issues.
+2. **File only when needed and authorized.** A real defect that cannot be fixed
+   now, or a follow-up delivery truly requires, may need an issue. Search open
+   and closed issues first, for example
+   `gh issue list --repo OWNER/REPO --state all --search "<area> in:title,body"`.
+   Reuse an existing issue instead of duplicating it; comment only when that
+   effect is authorized and adds necessary context.
+3. Group related findings into one checklist issue per area. Include concrete,
+   testable `## Acceptance criteria`. No speculative hardening, ideas or
+   "investigate later" issues. If filing is outside the request, list necessary
+   follow-ups in the report instead of creating them.
+4. **Close what is done**, through the correct delivery mechanism below. Partial
+   delivery stays open with exactly what remains. Do not manufacture completion
+   or create extra issues merely to move unfinished scope elsewhere.
+5. Prefer bounded issues that can be finished completely over starting large
+   epics. Report completed dispositions, not how many new issues were produced.
+
+## Close with a reason, through the owning mechanism
+
+Read [pull-requests.md](../../rules/pull-requests.md#issue-references) before
+changing issue references or disposition. Confirm the actual PR state, release
+intent and repository workflow; a merged PR is not proof of a published release.
+
+- **Release-action delivery:** for a fully delivered issue, the delivering
+  release-note bullet ends with `(#n)`. Release-action closes it at release;
+  do not close it by hand. If release is pending, keep that dependency visible.
+- **Manual completion:** only for a `no-release` PR or a repository without
+  release-action, and only when the request includes closing. Confirm all scope
+  is delivered and no required PR is open, unmerged, reverted or failing. Set
+  Done and close with reason `completed` and a public delivery link.
+- **Duplicate or obsolete:** only with clear evidence and authority. Use reason
+  `not planned`, explain why, and link the canonical issue or superseding work.
+  If uncertain, leave it open and report the question.
+- **Partial or unauthorized disposition:** leave it open with truthful remaining
+  scope or report the proposed disposition. Do not invent follow-up authority.
+
+For an authorized manual completion, for example:
+
+```bash
+gh issue close <n> --repo OWNER/REPO --reason completed \
+  --comment "Delivered in <public PR URL>. The agreed behavior is available."
+```
+
+A duplicate uses `--reason "not planned"` and a specific canonical public URL.
+No closing keywords are needed in the PR description; follow the owning rule.
+
+## End-of-work audit
+
+List issues touched by this work and reconcile each against its PR and release.
+For example, `gh issue list --repo OWNER/REPO --assignee @me --state open` helps
+find assigned work, but does not replace the list of issues actually touched.
+Check merged PRs for completed work still open; distinguish pending release-action
+closure from an authorized manual disposition. Verify closure through the issue's
+actual state, not an assumption about merging.
+
+Leave no issue In progress without an active writer. For unfinished work, set
+Paused or Blocked with what remains and what it waits for. Reconcile follow-ups
+with existing issues. Perform only authorized mutations; otherwise report the
+proposed changes and the blocker. Summarize completed issues, pending release
+closures and unfinished scope without publishing local paths or harness details.
+
+## How it is proven
+
+Read the final body and state, for example with
+`gh issue view <n> --repo OWNER/REPO --json body,state`. The original report is
+intact, the status block matches the actual PR and release, and any authorized
+closure is observable. Until release-action runs, pending closure is not Done.
+
+## What breaks
+
+- Two body writers lose each other's updates even if both reread first.
+- A status comment buries current state and needlessly notifies subscribers.
+- Manual closure before release bypasses release-action's delivery contract.
+- Filing every advisory grows the backlog without a necessary delivery.
+- Stale In progress blocks the next person without anyone doing the work.

package/package/corpus/skills/cratis-engineering-local-cross-repo-verification/SKILL.md

@@ -27,7 +27,9 @@ Also use this loop for:
 Prefer a release/preview for trivial changes, external consumers unable to use
 the local feed, or CI-only behavior this loop cannot reproduce.
 
-**Local verification replaces waiting, not shipping.** After local proof, release
+**Local verification replaces waiting, not shipping.** Other waits a candidate
+can avoid are in [cratis-engineering-release-trains](../cratis-engineering-release-trains/SKILL.md).
+After local proof, release
 the producer through the normal authorized workflow and bump the consumer to the
 released version. Local feeds, pins and images never go into production or a PR.
 Single-repository work needs its own regression specs, not this overlay. Released

package/package/corpus/skills/cratis-engineering-release-trains/LICENSE

@@ -0,0 +1,2 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the canonical Cratis/AI repository for the full license text.