vouchington-tooling 0.22.0 → 0.23.0

package/skills/manifest.json

@@ -4,180 +4,191 @@
     {
       "name": "agent-workflow",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
+      "pluginVersion": "0.9.0",
       "path": "agent-workflow/SKILL.md",
-      "prerequisites": ["github-issue"]
+      "prerequisites": ["github-issue", "pr-description", "review-ci-logs"]
     },
     {
       "name": "backend-vitest-test-authoring",
       "plugin": "vouchington-testing",
-      "pluginVersion": "0.1.0",
+      "pluginVersion": "0.2.0",
       "path": "backend-vitest-test-authoring/SKILL.md",
       "prerequisites": ["vitest-test-authoring"]
     },
     {
       "name": "blackboard",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
+      "pluginVersion": "0.9.0",
       "path": "blackboard/SKILL.md"
     },
     {
       "name": "dependabot",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
+      "pluginVersion": "0.9.0",
       "path": "dependabot/SKILL.md",
       "prerequisites": ["github-actions-checklist"]
     },
     {
       "name": "dotnet-test-authoring",
       "plugin": "vouchington-testing",
-      "pluginVersion": "0.1.0",
-      "path": "dotnet-test-authoring/SKILL.md"
+      "pluginVersion": "0.2.0",
+      "path": "dotnet-test-authoring/SKILL.md",
+      "prerequisites": ["test-authoring"]
     },
     {
       "name": "git-commit-checklist",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
+      "pluginVersion": "0.9.0",
       "path": "git-commit-checklist/SKILL.md"
     },
     {
       "name": "github-actions-authoring",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
+      "pluginVersion": "0.9.0",
       "path": "github-actions-authoring/SKILL.md",
       "prerequisites": ["github-actions-checklist"]
     },
     {
       "name": "github-actions-checklist",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
+      "pluginVersion": "0.9.0",
       "path": "github-actions-checklist/SKILL.md"
     },
     {
       "name": "github-issue",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
+      "pluginVersion": "0.9.0",
       "path": "github-issue/SKILL.md"
     },
     {
       "name": "nextjs-vitest-test-authoring",
       "plugin": "vouchington-testing",
-      "pluginVersion": "0.1.0",
+      "pluginVersion": "0.2.0",
       "path": "nextjs-vitest-test-authoring/SKILL.md",
       "prerequisites": ["vitest-test-authoring"]
     },
     {
       "name": "npm-publishing",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
+      "pluginVersion": "0.9.0",
       "path": "npm-publishing/SKILL.md"
     },
     {
       "name": "organize-github-issues",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
-      "path": "organize-github-issues/SKILL.md"
+      "pluginVersion": "0.9.0",
+      "path": "organize-github-issues/SKILL.md",
+      "prerequisites": ["github-issue"]
     },
     {
       "name": "package-json-checklist",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
+      "pluginVersion": "0.9.0",
       "path": "package-json-checklist/SKILL.md"
     },
     {
       "name": "planning",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
-      "path": "planning/SKILL.md"
+      "pluginVersion": "0.9.0",
+      "path": "planning/SKILL.md",
+      "prerequisites": ["github-issue"]
     },
     {
       "name": "playwright-authoring",
       "plugin": "vouchington-testing",
-      "pluginVersion": "0.1.0",
-      "path": "playwright-authoring/SKILL.md"
+      "pluginVersion": "0.2.0",
+      "path": "playwright-authoring/SKILL.md",
+      "prerequisites": ["test-authoring"]
     },
     {
       "name": "postgres-node-performance-tuning",
       "plugin": "vouchington-database",
-      "pluginVersion": "0.1.0",
+      "pluginVersion": "0.2.0",
       "path": "postgres-node-performance-tuning/SKILL.md"
     },
     {
       "name": "postgres-partitioning-uuid-v7",
       "plugin": "vouchington-database",
-      "pluginVersion": "0.1.0",
+      "pluginVersion": "0.2.0",
       "path": "postgres-partitioning-uuid-v7/SKILL.md"
     },
     {
       "name": "pr-description",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
+      "pluginVersion": "0.9.0",
       "path": "pr-description/SKILL.md"
     },
     {
       "name": "retrospective",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
+      "pluginVersion": "0.9.0",
       "path": "retrospective/SKILL.md"
     },
     {
       "name": "retrospective-distill",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
-      "path": "retrospective-distill/SKILL.md"
+      "pluginVersion": "0.9.0",
+      "path": "retrospective-distill/SKILL.md",
+      "prerequisites": ["github-issue"]
     },
     {
       "name": "review-ci-logs",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
-      "path": "review-ci-logs/SKILL.md"
+      "pluginVersion": "0.9.0",
+      "path": "review-ci-logs/SKILL.md",
+      "prerequisites": ["github-actions-checklist", "pr-description"]
     },
     {
       "name": "review-github-issue-taxonomy",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
-      "path": "review-github-issue-taxonomy/SKILL.md"
+      "pluginVersion": "0.9.0",
+      "path": "review-github-issue-taxonomy/SKILL.md",
+      "prerequisites": ["github-issue"]
     },
     {
       "name": "revisit-followups",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
-      "path": "revisit-followups/SKILL.md"
+      "pluginVersion": "0.9.0",
+      "path": "revisit-followups/SKILL.md",
+      "prerequisites": ["github-issue"]
     },
     {
       "name": "stacked-prs",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
+      "pluginVersion": "0.9.0",
       "path": "stacked-prs/SKILL.md"
     },
     {
       "name": "static-analysis-checklist",
       "plugin": "vouchington-workflow",
-      "pluginVersion": "0.7.0",
-      "path": "static-analysis-checklist/SKILL.md"
+      "pluginVersion": "0.9.0",
+      "path": "static-analysis-checklist/SKILL.md",
+      "prerequisites": ["github-actions-checklist"]
     },
     {
       "name": "storybook-authoring",
       "plugin": "vouchington-testing",
-      "pluginVersion": "0.1.0",
-      "path": "storybook-authoring/SKILL.md"
+      "pluginVersion": "0.2.0",
+      "path": "storybook-authoring/SKILL.md",
+      "prerequisites": ["test-authoring"]
     },
     {
       "name": "swift-test-authoring",
       "plugin": "vouchington-testing",
-      "pluginVersion": "0.1.0",
-      "path": "swift-test-authoring/SKILL.md"
+      "pluginVersion": "0.2.0",
+      "path": "swift-test-authoring/SKILL.md",
+      "prerequisites": ["test-authoring"]
     },
     {
       "name": "test-authoring",
       "plugin": "vouchington-testing",
-      "pluginVersion": "0.1.0",
+      "pluginVersion": "0.2.0",
       "path": "test-authoring/SKILL.md"
     },
     {
       "name": "vitest-test-authoring",
       "plugin": "vouchington-testing",
-      "pluginVersion": "0.1.0",
+      "pluginVersion": "0.2.0",
       "path": "vitest-test-authoring/SKILL.md",
       "prerequisites": ["test-authoring"]
     }

package/skills/nextjs-vitest-test-authoring/SKILL.md

@@ -1,10 +1,14 @@
 ---
 name: nextjs-vitest-test-authoring
-description: Apply Vitest patterns for Next.js components, routes, and server-side modules.
+description: Test Next.js components, routes, and server boundaries with Vitest.
 ---
 
 # Next.js Vitest test authoring
 
+Read applicable `AGENTS.md` and their declared adapter alias, otherwise
+`.agents/skills/nextjs-vitest-test-authoring/SKILL.md` from the repository root if present.
+Local policy overrides these defaults; do not reload an already-read adapter or canonical skill.
+
 Apply [vitest-test-authoring](../vitest-test-authoring/SKILL.md) first.
 
 - Mock framework navigation, headers, and server-only boundaries at the framework edge.

package/skills/npm-publishing/SKILL.md

@@ -1,10 +1,14 @@
 ---
 name: npm-publishing
-description: Bootstrap an npm package and give a human the exact commands to publish it publicly and configure GitHub trusted publishing.
+description: Prepare npm bootstrap and trusted publishing commands for a human.
 ---
 
 # npm publishing bootstrap
 
+Read applicable `AGENTS.md` and their declared adapter alias, otherwise
+`.agents/skills/npm-publishing/SKILL.md` from the repository root if present.
+Local policy overrides these defaults; do not reload an already-read adapter or canonical skill.
+
 Prepare the local package. Leave public registry writes and trusted-publisher mutations to the
 human. Read every applicable `AGENTS.md` from the repository root through the
 package. Repository-local policy and the consumer wrapper own the package path and name, npm scope,

package/skills/organize-github-issues/SKILL.md

@@ -1,10 +1,14 @@
 ---
 name: organize-github-issues
-description: Organize existing GitHub issues and pull requests with the repository's live taxonomy without inventing new taxonomy.
+description: Apply existing issue and PR taxonomy within the requested scope.
 ---
 
 # Organize GitHub issues
 
+Read applicable `AGENTS.md` and their declared adapter alias, otherwise
+`.agents/skills/organize-github-issues/SKILL.md` from the repository root if present.
+Local policy overrides these defaults; do not reload an already-read adapter or canonical skill.
+
 Use for issue hygiene, priority normalization, milestone assignment, and project membership. Read
 local `AGENTS.md`, and live taxonomy guidance before acting.
 

package/skills/package-json-checklist/SKILL.md

@@ -1,10 +1,14 @@
 ---
 name: package-json-checklist
-description: Use when changing JavaScript package metadata, dependencies, scripts, workspaces, or published entrypoints.
+description: Check package metadata, dependencies, entrypoints, and lockfiles.
 ---
 
 # Package metadata checklist
 
+Read applicable `AGENTS.md` and their declared adapter alias, otherwise
+`.agents/skills/package-json-checklist/SKILL.md` from the repository root if present.
+Local policy overrides these defaults; do not reload an already-read adapter or canonical skill.
+
 Use before changing `package.json`, a lockfile, workspace metadata, or a package entrypoint. Read
 every applicable `AGENTS.md` from the repository root through the owning package,
 applying the closest file only when rules conflict. Those instructions own package-manager version,

package/skills/planning/SKILL.md

@@ -1,28 +1,33 @@
 ---
 name: planning
-description: Create an evidence-backed implementation plan for a repository change or a justified no-change recommendation.
+description: Plan a repository change and save the decision outside Git.
 ---
 
 # Planning
 
-Use before implementation work that needs a durable plan. Repository-local `AGENTS.md`,
-`AGENTS.md`, issue templates, and planning conventions override this portable foundation.
+Read applicable `AGENTS.md` and their declared adapter alias, otherwise
+`.agents/skills/planning/SKILL.md` from the repository root if present.
+Local policy overrides these defaults; do not reload an already-read adapter or canonical skill.
+
+Use when a task needs a plan. Scale detail to uncertainty and impact; no fixed headings, tables,
+diagram, independent reviewer, or separate issue are required by this skill.
 
 1. State the desired outcome and compare no change, reuse, and alternative approaches. Choose the
    smallest durable option; ask before treating an unresolved product choice as settled.
 2. Read applicable instructions, documentation, current code, tests, and recent changes from a
    fresh base. Record which evidence supports each proposed path.
-3. Map affected owners, public contracts, migrations, operational boundaries, and tests. Use
-   independent review or exploration when the change is cross-cutting or uncertain.
-4. Specify implementation steps, file-level intent, validation, rollout, and any follow-up that is
-   truly outside the accepted scope. Distinguish existing paths from new paths.
-5. Validate and save the plan using the repository's required issue or document workflow before
-   implementation when local policy requires one. When creating a plan issue from a source issue
+3. Map affected owners, contracts, operational boundaries, and tests. Use independent review or
+   exploration when the change is cross-cutting or uncertain and local policy calls for it.
+4. Record the chosen approach, steps, validation, and unresolved decisions. Add rollout details
+   only when an established deployment contract requires them.
+5. Save the plan once outside Git: an existing issue, a PR description, or a durable native plan
+   file outside the repository. Do not commit task plans or count temporary scratch files as saved
+   plans. If no durable record is available, use an issue through the local issue workflow. Link
+   the record from the handoff instead of duplicating it. When creating a plan issue from a source issue
    that already has a milestone or project, apply that same existing milestone or project through
    [github-issue](../github-issue/SKILL.md).
 
 For cross-cutting changes, read [impact discovery](references/impact-discovery.md) before selecting
 tests or concluding that a surface has no dependents.
 
-Consumer wrapper owns: plan template, default repository, issue taxonomy, dependency graph tool,
-and approval workflow.
+Consumer wrapper owns: durable plan storage, repository, taxonomy, discovery tools, and approval.

package/skills/planning/references/impact-discovery.md

@@ -5,5 +5,7 @@ tests. Use the repository's graph or search tools where available; otherwise rec
 used and the uncertainty that remains. Select focused tests from real dependents, then include
 broader validation when a shared contract, package boundary, or generated artifact changes.
 
+Check source-issue paths against current source before relying on them; issue text is a snapshot.
+
 Do not treat a tool's incomplete graph as proof that no dependent exists. Escalate uncertain
 high-risk boundaries for independent review or a broader test selection.

package/skills/playwright-authoring/SKILL.md

@@ -1,10 +1,14 @@
 ---
 name: playwright-authoring
-description: Author reliable Playwright browser tests, fixtures, selectors, and user flows.
+description: Author reliable Playwright flows, fixtures, and assertions.
 ---
 
 # Playwright authoring
 
+Read applicable `AGENTS.md` and their declared adapter alias, otherwise
+`.agents/skills/playwright-authoring/SKILL.md` from the repository root if present.
+Local policy overrides these defaults; do not reload an already-read adapter or canonical skill.
+
 Apply [test-authoring](../test-authoring/SKILL.md).
 
 - Use a stable, accessible locator. Assert a user-observable outcome.

package/skills/postgres-node-performance-tuning/SKILL.md

@@ -1,10 +1,14 @@
 ---
 name: postgres-node-performance-tuning
-description: Diagnose and improve PostgreSQL performance in Node.js applications with large data volumes.
+description: Measure and improve PostgreSQL queries in Node.js services.
 ---
 
 # PostgreSQL and Node.js performance
 
+Read applicable `AGENTS.md` and their declared adapter alias, otherwise
+`.agents/skills/postgres-node-performance-tuning/SKILL.md` from the repository root if present.
+Local policy overrides these defaults; do not reload an already-read adapter or canonical skill.
+
 Measure the query plan and the workload shape before changing code.
 
 - Select only the required columns.

package/skills/postgres-partitioning-uuid-v7/SKILL.md

@@ -1,10 +1,14 @@
 ---
 name: postgres-partitioning-uuid-v7
-description: Design PostgreSQL partitions and indexes that use time-ordered UUIDv7 identifiers efficiently.
+description: Design PostgreSQL partitions and pruning around UUIDv7.
 ---
 
 # PostgreSQL partitioning with UUIDv7
 
+Read applicable `AGENTS.md` and their declared adapter alias, otherwise
+`.agents/skills/postgres-partitioning-uuid-v7/SKILL.md` from the repository root if present.
+Local policy overrides these defaults; do not reload an already-read adapter or canonical skill.
+
 Partition only after lifecycle, retention, and query predicates show that it helps.
 
 - Treat a UUIDv7 as time ordered. Where the meaning matters, keep an explicit business timestamp.

package/skills/pr-description/SKILL.md

@@ -1,24 +1,62 @@
 ---
 name: pr-description
-description: Draft or review a self-contained pull-request description with summary, root cause, validation, rollout, and issue context.
+description: Write a self-contained PR description backed by the final diff.
 ---
 
 # Pull-request description
 
-Use before opening or updating a pull request, or when reviewing PR hand-off quality. Read local
+Read applicable `AGENTS.md` and their declared adapter alias, otherwise
+`.agents/skills/pr-description/SKILL.md` from the repository root if present.
+Local policy overrides these defaults; do not reload an already-read adapter or canonical skill.
+
+Use before opening or updating a pull request, after diagnosing a CI failure, or at handoff. Read local
 `AGENTS.md`, pull-request template, and issue-linking policy first.
 
-Include enough context for a reviewer with no prior conversation:
+Keep the description understandable without the conversation. Its short visible core explains:
+
+- **Summary:** what changed, why, and the concrete before/after behavior. For a fix, explain its
+  root cause as well as the symptom. A reader should understand the outcome before implementation
+  details.
+- **Impact:** who or what is affected and how their behavior changes. Name the actual audience,
+  such as end users, staff, API clients, operators, or contributors. Keep material risks and
+  limitations visible. For internal work, describe the affected development or operational flow.
+
+Add detail only where the change warrants it:
+
+- For cost changes, state the direction and scope. Label figures as measured or estimated, name the
+  workload and assumptions, and link evidence. Say unmeasured when no defensible figure exists;
+  do not invent savings or claim a neutral cost without evidence. Follow the consumer's privacy
+  policy before reporting actual spending, and use approved aggregated or redacted evidence.
+- For database changes, inventory added, removed, and changed tables, columns, constraints, and
+  indexes. Explain the relationships and conformance to the consumer's schema rules, including
+  producer/consumer changes and any justified exceptions. Link the policy and concrete evidence.
+- For API, workflow, or independently deployed changes, explain the affected contract, lifecycle,
+  or operational safety. Follow the consumer's compatibility and deployment policy.
+- Use a before/after table or meaningful Mermaid diagram when it makes behavior, relationships,
+  workflow topology, or lifecycle easier to understand. Prose is sufficient for a simple change.
+
+Put long comparisons, inventories, diagrams, calculations, and failure evidence in collapsed
+`<details>` sections. Keep the short conclusions and material risks outside them. Keep the
+consumer's required visible core headings outside disclosure containers. Put opening/closing tags
+on separate lines, with a blank line after `</summary>` and before `</details>` so Markdown renders.
+Read [description examples](references/examples.md) when choosing a comparison, diagram, or failure
+record.
+
+Do not fill the description with routine local successful-test lists. This is a reporting rule,
+not permission to skip checks: execute required validation and retain its revision, exact scope,
+result, and any omission reason in the work's evidence record.
 
-- A concise summary of what changed and why.
-- The underlying root cause for a fix, not only its visible symptom.
-- Validation performed and any intentionally skipped checks with reasons.
-- Rollout, compatibility, operational safety, and follow-up context when the change affects a live
-  or independently deployed surface.
-- Correct issue relationships: close only issues fully resolved and explain any non-closing links.
-- A compact diagram only when it materially clarifies a multi-component flow or lifecycle.
+Include **Harness gaps** only after CI diagnosis establishes an omitted local verification or a
+proven local/CI mismatch. Link the first failing run/job and its exact head revision, compare the actual local and
+CI scope, explain the omission or difference, and record the durable correction or authorized
+linked follow-up. Distinguish an omitted check from one that passed locally. Unknown coverage is
+not evidence of a miss; classify genuine CI-only or external infrastructure failures separately.
+Retain confirmed gap records after CI turns green. Diagnose the failure through the repository's
+CI investigation workflow; a failed status alone does not establish a gap.
 
-Use the repository's approved PR tooling and preserve sections managed by its review automation.
+Use the repository's approved PR tooling and preserve sections managed by its review automation
+verbatim. Close only issues fully resolved and explain non-closing issue links. Apply this guidance
+to descriptions being created or updated, not a bulk rewrite of historical pull requests.
 
 Consumer wrapper owns: required headings, source-issue rule, merge policy, repository command, and
 hosted review system.

package/skills/pr-description/references/examples.md

@@ -0,0 +1,136 @@
+# Description examples
+
+These illustrative descriptions show how to keep conclusions visible while disclosing longer
+evidence. Use the consumer's actual headings, policy links, issue relationships, and run evidence.
+Do not copy a claim or figure unless the current change supports it.
+
+## Small behavior fix
+
+```markdown
+## Summary
+
+Reopening the review dialog now cancels its pending reset. Previously, the reset cleared the
+new selection because the timer outlived the closed state.
+
+## Impact
+
+Staff can close and reopen a review without losing the new selection. Closing normally still
+clears the old selection after the exit animation.
+```
+
+No diagram, cost calculation, database inventory, or local successful-test list is needed.
+
+## Database relationship change
+
+```markdown
+## Summary
+
+Recovery attempts now reference retained account identities through a foreign key. Previously,
+an unvalidated identifier could refer to an account that no longer existed.
+
+## Impact
+
+Operators can trace each attempt to a retained identity, and deletion cannot orphan recovery
+history. The API's recovery response is unchanged. Storage cost is unmeasured; retaining an
+identity row per deleted account adds storage proportional to account deletions.
+
+<details>
+<summary>Schema inventory and conformance</summary>
+
+| Object                                        | Before                  | After                             |
+| --------------------------------------------- | ----------------------- | --------------------------------- |
+| `account_identity` table                      | Absent                  | Retains each account's identity   |
+| `recovery_attempt.account_id` column          | Unvalidated UUID        | Removed                           |
+| `recovery_attempt.account_identity_id` column | Absent                  | Required foreign key              |
+| Foreign-key constraint                        | Absent                  | References `account_identity(id)` |
+| Lookup index                                  | Uses the removed column | Uses `account_identity_id`        |
+
+The relationship uses a typed column and concrete foreign key, as required by the repository's
+relational-storage policy. The current schema, recovery writer, account-deletion path, and
+operator query change together. There is no dual reader or writer.
+
+</details>
+```
+
+In a real description, link the consumer's policy and implementation evidence. Do not prescribe
+this consumer-specific retention or deployment policy for other repositories.
+
+## Workflow and cost change
+
+````markdown
+## Summary
+
+Test jobs now run once per revision. Previously, changing a pull request's draft status started
+a duplicate test run even though no test job consumed draft state.
+
+## Impact
+
+Contributors keep the checks already attached to their revision when marking it ready. Estimated
+runner use falls by one duplicate suite per draft-to-ready transition; the estimate assumes
+one transition and a 12-minute suite. Aggregate savings are unmeasured.
+
+<details>
+<summary>Before and after event flow</summary>
+
+```mermaid
+flowchart LR
+  subgraph Before
+    B1[Revision pushed] --> B3[Test suite]
+    B2[Draft marked ready] --> B4[Duplicate test suite]
+  end
+  subgraph After
+    A1[Revision pushed] --> A3[Test suite]
+    A2[Draft marked ready] --> A4[Merge eligibility only]
+  end
+```
+
+</details>
+````
+
+The diagram explains event ownership; a file list or arrows between the Summary and Impact sections
+would not clarify the behavior. Link the run measurements supporting a real estimate.
+
+## Harness gap: omitted local verification
+
+```markdown
+## Harness gaps
+
+CI found that the local pre-push command omitted the compiler-contract suite. The harness now
+includes that suite, and the missing public export is fixed.
+
+<details>
+<summary>Failure and durable correction</summary>
+
+The failed compiler-contract job on the first pushed revision reported the missing export.
+The pre-push record ran the component project only; the compiler-contract project was omitted
+because the command catalog did not include it. The catalog and pre-push selection now include
+the project, and a public-import regression covers this export.
+
+</details>
+```
+
+The actual record must link the failing run/job and exact head SHA, plus the local scope and
+correction evidence. Retain it when the corrected revision passes CI.
+
+## Harness gap: passed locally, failed in CI
+
+```markdown
+## Harness gaps
+
+The contract suite passed locally but failed in CI because the local runner selected the host
+architecture instead of the deployment target. Local validation now selects that target explicitly.
+
+<details>
+<summary>Local and CI scope difference</summary>
+
+The pre-push record and failing job used the same suite on the same revision. Their target
+configurations differed: local selected the host target, while CI compiled the deployment target.
+The local command now uses the deployment target, and a compiler regression covers the rejected
+cross-target import. This was a configuration mismatch, not an omitted suite.
+
+</details>
+```
+
+Link the concrete revision, failed job, local evidence, and correction in the actual record.
+An external service outage, unavailable CI-only credentials, or unknown local execution history
+does not support this claim. Explain such limitations separately when they affect the outcome.

package/skills/retrospective/SKILL.md

@@ -1,10 +1,14 @@
 ---
 name: retrospective
-description: Produce a concise evidence-based retrospective for a completed task or session when local workflow provides a durable record.
+description: Summarize completed work from verified facts and the session journal.
 ---
 
 # Retrospective
 
+Read applicable `AGENTS.md` and their declared adapter alias, otherwise
+`.agents/skills/retrospective/SKILL.md` from the repository root if present.
+Local policy overrides these defaults; do not reload an already-read adapter or canonical skill.
+
 Use at task completion or session close-out when the repository has a retrospective workflow. Read
 local `AGENTS.md`, and journal guidance first.