vouchington-tooling 0.20.0 → 0.22.0

package/skills/dotnet-test-authoring/SKILL.md

@@ -5,17 +5,16 @@ description: Add maintainable .NET tests with appropriate unit, app, and integra
 
 # .NET test authoring
 
-Place tests at the narrowest layer that proves the behavior. Batch native or external selection
-where the project requires it, isolate process and filesystem state, and assert serialized contracts
-instead of private implementation details. Keep test helpers typed and reusable only when they remove
-repeated setup without hiding important expectations.
+Apply [test-authoring](../test-authoring/SKILL.md).
 
-Consumer wrappers own solution layout, test frameworks, native dependencies, and coverage policy.
+- Place a test at the narrowest layer that proves the behavior.
+- Batch native or external selection where the project requires it.
+- Isolate process and filesystem state.
+- Assert a serialized contract. Do not assert a private implementation detail.
+- Keep a helper typed and reusable only when it removes repeated setup without hiding an
+  expectation.
+- Keep portable library tests separate from rendered application tests.
+- Batch compatible native targets in one selection pass so one shared build validates that source
+  set.
 
-Keep portable library tests separate from rendered application tests; batch compatible native targets
-in one selection pass so a shared build validates the same source set.
-
-Before finishing an assertion, name a concrete defect in the code under test that would make it fail;
-an `Assert.True(true)` or a re-implemented computation compared against itself passes for every input
-and proves nothing, so treat [tautological tests](../test-authoring/references/tautological-tests.md)
-as a defect even when coverage looks satisfied.
+Consumer wrapper owns: solution layout, test frameworks, native dependencies, and coverage policy.

package/skills/git-commit-checklist/SKILL.md

@@ -5,7 +5,7 @@ description: Use before staging and committing changes to verify scope, validati
 
 # Git commit checklist
 
-Use before every commit. Read local `AGENTS.md`, `CLAUDE.md`, contribution guidance, and hook
+Use before every commit. Read local `AGENTS.md`, contribution guidance, and hook
 output first; they own commit format, required trailers, file-size limits, and validation commands.
 
 1. Inspect `git status` and the complete diff. Stage only files that implement the accepted task.
@@ -17,5 +17,5 @@ output first; they own commit format, required trailers, file-size limits, and v
 5. Re-read the staged diff and commit message before committing. Do not amend another author's
    work or rewrite history unless local policy and explicit authorization allow it.
 
-This skill does not prescribe branch names, file-size budgets, commit conventions, PR templates,
-or push commands. Supply those through repository-local instructions or a consumer wrapper.
+Local instructions or the consumer wrapper own: branch names, file-size budgets, commit
+conventions, pull-request templates, and push commands.

package/skills/github-actions-authoring/SKILL.md

@@ -5,53 +5,55 @@ description: Author or redesign GitHub Actions workflows around event-driven orc
 
 # GitHub Actions authoring
 
-Never poll in CI. A workflow must react to a state transition, not repeatedly ask whether remote
-state has changed. Read [github-actions-checklist](../github-actions-checklist/SKILL.md) first, then
-every applicable `AGENTS.md` and `CLAUDE.md`. Repository-local policy and the consumer wrapper own
-runner labels, permissions, action pins, concurrency, secrets, and required-check names.
+Never poll in CI. A workflow reacts to a state transition. Read
+[github-actions-checklist](../github-actions-checklist/SKILL.md) first, then every applicable
+`AGENTS.md`. Repository-local policy and the consumer wrapper own runner labels,
+permissions, action pins, concurrency, secrets, and required-check names.
 
 ## Design the event graph
 
-1. Name the producer, the durable transition it emits, and the consumer that owns the next action.
-2. Use `needs` for jobs in one workflow and `workflow_call` for a reusable workflow whose caller
-   must await its result. When a consumer must run after failure or skip, give it an explicit status
-   condition and inspect `needs.<job>.result`; the implicit success condition skips it otherwise.
-3. Use `workflow_run` when a completed workflow is the trusted event boundary. Validate the exact
-   source workflow, repository, branch or pull-request head, conclusion, and artifacts before acting.
-   The receiving workflow must already exist on the default branch, and GitHub starts at most three
-   chained `workflow_run` levels; plan rollout explicitly and collapse deeper chains into one DAG.
-4. Use `repository_dispatch` for a cross-repository transition or authenticated external callback.
-   Authenticate the sender, pass immutable correlation data, validate it against the source, and make
-   duplicate delivery safe. Its receiving workflow must also already exist on the default branch,
-   so introduce and verify the receiver before enabling senders.
-5. Prefer provider-native completion events, callbacks, queues, or state-machine transitions for
-   deployments and services. A scheduled reconciliation workflow may repair missed events, but it
-   must inspect a snapshot once and exit; it must not wait for convergence.
+- Name the producer, the durable transition it emits, and the consumer that owns the next action.
+- Use `needs` for jobs in one workflow. Use `workflow_call` when the caller must await a reusable
+  workflow. When a consumer must run after failure or skip, give it an explicit status condition and
+  read `needs.<job>.result`. The implicit success condition skips it otherwise.
+- Use `workflow_run` when a completed workflow is the trusted event boundary. Validate the source
+  workflow, repository, branch or pull-request head, conclusion, and artifacts before acting.
+- The `workflow_run` receiver must already exist on the default branch. GitHub chains at most three
+  `workflow_run` levels. Plan that rollout, and collapse a deeper chain into one DAG.
+- Use `repository_dispatch` for a cross-repository transition or an authenticated external callback.
+  Authenticate the sender, pass immutable correlation data, validate it against the source, and make
+  duplicate delivery safe. The receiver must already exist on the default branch before senders are
+  enabled.
+- Prefer a provider-native completion event, callback, queue, or state-machine transition for a
+  deployment or service.
+- A scheduled reconciliation workflow may repair a missed event. It inspects one snapshot and exits.
+  It does not wait for convergence.
 
 ## Persistent workspaces
 
-Check out the full tree and prevent sparse-checkout configuration with a YAML-aware policy over
-tracked workflow and action files. Correct the producer of unsafe workspace state: writable workspace
-bind mounts use a non-root identity whose ownership and write access are compatible with the runner.
-Do not make each job traverse the whole workspace before checkout to repair permissions. Drain and
-migrate an already contaminated runner once. At runtime, repair may cover bounded known generated
-paths; a workspace-wide fallback must stay failure-gated, same-filesystem, directory-only, and batched,
-with path-count and timing evidence in its diagnostics.
+Apply the persistent-workspace rules in
+[github-actions-checklist](../github-actions-checklist/SKILL.md).
 
 ## Reject polling designs
 
-Do not add a sleep-and-read loop, repeated run/check/deployment/lease/service queries, a CLI waiter,
-or recursive redispatch whose purpose is to observe remote state eventually changing. Timeouts cap
-cost but do not make polling event-driven. If the producer cannot emit a usable event, add a bridge
-at the producer or provider boundary and let that bridge dispatch the correlated completion event.
-
-Bounded retries are allowed only for the same failed operation when failure is transient and the
-operation is idempotent. Local process readiness checks are allowed when the process runs inside the
-job and cannot emit a workflow event. Neither exception permits repeated observation of remote state.
+- Do not add a sleep-and-read loop, a repeated query of a run, check, deployment, lease, or
+  service, a CLI waiter, or a recursive redispatch whose purpose is to watch remote state change.
+- A timeout caps cost. It does not make polling event-driven.
+- If the producer cannot emit a usable event, add the bridge at the producer or provider boundary
+  and let that bridge dispatch the correlated completion event.
+- Bounded retries are allowed only for the same failed operation, and only when the failure is
+  transient and the operation is idempotent.
+- A local process readiness check is allowed when that process runs inside the job and cannot emit
+  a workflow event.
+- Neither exception allows repeated observation of remote state.
 
 ## Validate the result
 
-Test accepted, rejected, duplicate, stale, and out-of-order events. Preserve required-check names
-and prove that every terminal producer outcome causes one terminal consumer outcome. Run the local
-workflow checker and affected tests, then inspect the completed event graph for credentials crossing
-untrusted boundaries, missing correlation fields, and any remaining polling path.
+- Test accepted, rejected, duplicate, stale, and out-of-order events.
+- Preserve required-check names. Prove that every terminal producer outcome causes one terminal
+  consumer outcome.
+- Run the local workflow checker and affected tests. Inspect the event graph for credentials
+  crossing an untrusted boundary, a missing correlation field, and any remaining polling path.
+
+Consumer wrapper owns: runner labels, permissions, action pins, concurrency, secrets, and
+required-check names.

package/skills/github-actions-checklist/SKILL.md

@@ -6,97 +6,105 @@ description: Use when editing GitHub Actions workflows or composite actions to k
 # GitHub Actions checklist
 
 Use before editing a workflow or composite action. Repository-local instructions own runners,
-approved action pinning, concurrency naming, secrets, permissions, and workflow-only PR rules.
+approved action pins, concurrency names, secrets, permissions, and workflow-only pull-request rules.
+Apply this baseline unless a stricter local rule overrides it.
 
-Apply this portable baseline unless a stricter repository-local rule overrides it:
+## Triggers and required checks
 
-- Use `pull_request` for pull-request workflows in private repositories. Reserve
-  `pull_request_target` for base-owned orchestration in public repositories or narrowly scoped
-  Dependabot/Renovate automation. A privileged workflow must never check out or execute untrusted
-  pull-request content.
-- Load [github-actions-authoring](../github-actions-authoring/SKILL.md) when changing orchestration.
-  Do not poll remote workflow, deployment, lease, service, or health state.
-- Required checks must be actual workflow jobs that execute or aggregate the work they report.
-  Workflow code must not create or publish check runs or commit statuses merely to synthesize a
-  required context, copy another workflow's conclusion, or bypass the event graph. A purpose-built
-  external CI or analysis integration may report its own result; do not use its API as a relay for
-  work owned by GitHub Actions.
-- On `main`, or the consumer's configured default branch, split test jobs by domain such as web and
-  backend instead of hiding unrelated suites in one monolithic test job. Keep domain job names stable
-  when they are required checks, and use a real bounded fan-in job only when the merge contract needs
-  one combined result.
-- Serialize test runs for the same pull request or default branch with a stable concurrency group. For
-  pull requests, use `cancel-in-progress: true` so a superseded head replaces the active run. On
-  `main`, or the consumer's configured default branch, use `cancel-in-progress: false` so the active
-  run finishes before the newest pending revision starts. GitHub may replace an older pending main
-  run with the newest pending revision; preserving every intermediate queued revision is not required.
-  When one workflow handles both events, make `cancel-in-progress` conditional on the pull-request
-  event while keeping the PR number or branch ref in the concurrency group.
-- Give every concrete job a timeout of no more than 30 minutes. A caller job that invokes a reusable
-  workflow through top-level `jobs.<job_id>.uses` cannot accept `timeout-minutes`; enforce the bound
-  on every concrete job inside the called workflow. If the underlying operation cannot terminate
-  inside that bound, decompose it into event-driven phases; lowering or moving the timeout alone does
-  not fix the design. Preserve a required job or check name with a bounded fan-in job when splitting
-  work would otherwise change the repository's merge contract. Each underlying phase must also have
-  a deadline of no more than 30 minutes and support cancellation, rollback, or an explicit terminal
-  retained/recovery state. An event callback may report completion; it must not hide a longer-running
-  operation in another service.
-- Prefer GitHub-hosted runners for public and private repositories. Choose the smallest hosted runner
-  the job fits, such as `ubuntu-slim` for a short job that needs no Docker daemon, and use a full VM
-  or native-architecture runner only for work the smaller runner cannot do. A consumer that still
+- Use `pull_request` for pull-request workflows in private repositories.
+- Reserve `pull_request_target` for base-owned orchestration in a public repository, or for a
+  narrowly scoped Dependabot or Renovate workflow.
+- A privileged workflow must not check out or execute untrusted pull-request content.
+- When changing orchestration, load
+  [github-actions-authoring](../github-actions-authoring/SKILL.md). Do not poll remote workflow,
+  deployment, lease, service, or health state.
+- Required checks must be actual workflow jobs that run or aggregate the work they report.
+- Workflow code must not create or publish check runs or commit statuses to synthesize a required
+  context, copy another workflow's conclusion, or bypass the event graph.
+- An external CI or analysis integration may report its own result. Do not relay GitHub Actions
+  work through its API.
+
+## Tests, concurrency, and timeouts
+
+- On `main`, or the consumer's configured default branch, split test jobs by domain, such as web
+  and backend. Keep required-check job names stable. Add a bounded fan-in job only when the merge
+  contract needs one combined result.
+- Serialize test runs for the same pull request or default branch with one stable concurrency group.
+- For pull requests, set `cancel-in-progress: true`. On `main`, or the consumer's configured default
+  branch, set `cancel-in-progress: false` so the active run finishes before the newest pending
+  revision starts. GitHub may replace an older pending main run with the newest pending revision;
+  preserving every intermediate queued revision is not required.
+- When one workflow handles both events, make `cancel-in-progress` conditional on the pull-request
+  event. Keep the pull-request number or branch ref in the group.
+- Give every concrete job `timeout-minutes` of at most 30 minutes. A top-level `jobs.<job_id>.uses`
+  caller cannot accept `timeout-minutes`; set it on every concrete job in the called workflow.
+- If the operation cannot finish inside that bound, split it into event-driven phases. Lowering or
+  moving the timeout does not fix the design. Preserve a required job or check name with a bounded
+  fan-in job when the split would otherwise change the merge contract.
+- Each underlying phase also has a deadline of no more than 30 minutes and supports cancellation,
+  rollback, or an explicit terminal retained or recovery state. A callback may report completion. It
+  must not hide a longer-running operation in another service.
+- Keep each job's `timeout-minutes` below any hard platform limit of its runner so the job's own
+  cancellation fires first and `always()`/`cancelled()` cleanup steps still run. Example: no more
+  than 14 minutes on a runner with a 15-minute hard cap that `timeout-minutes` cannot raise.
+- Give every long-running, network-bound, or waiting step its own `timeout-minutes` inside the job
+  budget. Bound every network call, such as `curl --connect-timeout … --max-time …`.
+
+## Runners and persistent workspaces
+
+- Prefer GitHub-hosted runners for public and private repositories. Choose the smallest hosted
+  runner the job fits, such as `ubuntu-slim` for a short job that needs no Docker daemon. Use a full
+  VM or native-architecture runner only for work the smaller runner cannot do. A consumer that still
   requires self-hosted or disposable runners names its approved labels in repository-local policy.
-- Keep each job's `timeout-minutes` below any hard platform limit of its runner — for example, no
-  more than 14 minutes on a runner with a 15-minute hard cap that `timeout-minutes` cannot raise —
-  so the job's own cancellation fires first and `always()`/`cancelled()` cleanup steps still run,
-  instead of the runner being killed outright once the platform limit is reached. Give every
-  long-running, network-bound, or waiting step its own `timeout-minutes` inside the job budget, and
-  bound every network call, such as `curl --connect-timeout … --max-time …`.
-- Ephemeral hosted runners start from a clean workspace. Do not add workspace-cleanup steps for them,
-  and check out with `persist-credentials: false` unless a later step must push with that token.
+- Ephemeral hosted runners start from a clean workspace. Do not add workspace-cleanup steps for
+  them, and check out with `persist-credentials: false` unless a later step must push with that
+  token.
 - Moving a job from a self-hosted or other persistent runner to a GitHub-hosted one drops every
-  piece of runner-local state the job's steps assumed was already there, not just the workspace.
-  Audit for state that used to persist for free: browser installs (a Playwright, Cypress, or
-  Puppeteer cache), package-manager stores (pnpm/npm, Go modules, a Rust `target/` directory,
-  Gradle), `apt-get install` steps that used to be a no-op because the package was already present,
-  and Docker image pulls that used to hit a warm local image store. A step or action comment
-  claiming a tool "persists between runs so caching is not needed" describes the old runner and
-  becomes false the moment `runs-on` changes; replace that assumption with a keyed `actions/cache`
-  step instead. Re-derive `timeout-minutes` from a real passing run on the new runner rather than
-  carrying over a budget calibrated on a warm host — the same job can look intermittently flaky
-  purely because every step now starts cold.
-- Persistent workspaces must check out the full tree. Do not configure sparse checkout; enforce that
-  prohibition with a YAML-aware check over intended tracked workflow and action files, with fixtures
-  for accepted and rejected shapes.
-- Fix workspace ownership at the producer. A container with a writable workspace bind mount must use
-  a non-root identity whose ownership and write access are compatible with the runner workspace. Do not
-  add an unconditional, pre-checkout, workspace-wide permission or ownership traversal to recover
-  persistent runners. Migrate an already contaminated workspace once while the runner is drained.
-  Normal runtime repair may cover bounded known generated paths. A necessary workspace-wide fallback
-  must stay failure-gated, same-filesystem, directory-only, and batched, and record path count and timing
-  evidence.
-- Pin every repository-backed external `uses:` reference—anything other than a local `./...`
-  action—to a full lowercase 40-character Git SHA followed immediately by its machine-maintainable
-  version comment, such as `# v4.2.0`, so Dependabot can update both. Pin `docker://...` actions to an
-  immutable `@sha256:` image digest instead of a Git SHA. Keep GitHub Actions dependency updates
-  enabled.
+  piece of runner-local state the job assumed was already there. Audit browser installs (a
+  Playwright, Cypress, or Puppeteer cache), package-manager stores (pnpm/npm, Go modules, a Rust
+  `target/` directory, Gradle), `apt-get install` steps that used to be a no-op because the package
+  was already present, and Docker image pulls that used to hit a warm local image store. A comment
+  that a tool "persists between runs so caching is not needed" describes the old runner and becomes
+  false the moment `runs-on` changes; replace that assumption with a keyed `actions/cache` step
+  instead. Re-derive `timeout-minutes` from a real passing run on the new runner rather than
+  carrying over a budget calibrated on a warm host.
+- A persistent workspace checks out the full tree. Do not configure sparse checkout. Enforce that
+  with a YAML-aware check over intended tracked workflow and action files, with accepted and
+  rejected fixtures.
+- Fix workspace ownership at the producer. A writable workspace bind mount uses a non-root identity
+  whose ownership and write access match the runner workspace.
+- Do not add an unconditional pre-checkout workspace-wide permission or ownership traversal.
+- Migrate a contaminated workspace once, while the runner is drained.
+- Routine repair may cover bounded known generated paths. A workspace-wide fallback must be
+  failure-gated, same-filesystem, directory-only, and batched,
+  and must record path count and timing.
+
+## Pinning
+
+- Pin every repository-backed external `uses:` reference — anything other than a local `./...`
+  action or a `$/` self-repository reference — to a full lowercase 40-character Git SHA and its
+  immediate machine-maintainable version comment, such as `# v4.2.0`, so Dependabot can update both.
+- A `$/` reference is the same repository at the running commit. It must not include an `@ref`.
+- Pin `docker://...` actions to an immutable `@sha256:` image digest. Keep GitHub Actions dependency
+  updates enabled.
 - Workflow tests and fixtures must not assert an action dependency's exact SHA or version. Assert
-  the action identity and Git SHA shape, or derive the dependency ref from the workflow under test,
-  so dependency-update pull requests can change pins without synchronized fixture edits. This does
-  not prohibit asserting an exact source revision in `with.ref` when exact-head checkout is a
-  workflow security invariant.
+  the action identity and Git SHA shape, or read the ref from the workflow under test.
+- This does not prohibit asserting an exact source revision in `with.ref` when exact-head checkout
+  is a workflow security invariant.
+
+## Edit
 
-1. Read every applicable `AGENTS.md` and `CLAUDE.md` from the repository root through the workflow,
-   plus relevant CI documentation and callers. Apply the closest instruction only when rules
-   conflict. Identify trusted and untrusted inputs and every credential boundary.
+1. Read every applicable `AGENTS.md` from the repository root through the workflow,
+   plus CI docs and callers. On conflict, apply the closest instruction. Name trusted inputs,
+   untrusted inputs, and every credential boundary.
 2. Give each job the least permissions it needs. Keep untrusted pull-request content out of shell
    interpolation, privileged tokens, and write-capable steps.
-3. Apply the portable check, test-topology, concurrency, pinning, runner, trigger, and timeout
-   baseline plus any stricter consumer policy. Keep checkout refs, artifact boundaries, caches, and
-   concurrency behavior explicit.
-4. Validate changed YAML with the local workflow checker and run the affected workflow tests or
-   scripts. Update local CI documentation when behavior or operator expectations change.
-5. Review the final diff for privilege escalation, accidental secret exposure, unsafe quoting,
-   unsupported runner assumptions, and unreachable workflow paths.
+3. Apply this baseline and any stricter consumer policy. Keep checkout refs, artifact boundaries,
+   caches, and concurrency explicit.
+4. Validate changed YAML with the local workflow checker and run the affected tests or scripts.
+   Update local CI docs when behavior or operator expectations change.
+5. Review the diff for privilege escalation, secret exposure, unsafe quoting, unsupported runner
+   assumptions, and unreachable paths.
 
-This skill intentionally has no default runner labels, action SHAs, workflow directories,
-concurrency scheme, or release policy. A consumer wrapper supplies those values.
+Consumer wrapper owns: runner labels, action SHAs, workflow directories, concurrency scheme, and
+release policy.

package/skills/github-issue/SKILL.md

@@ -5,91 +5,95 @@ description: Search, create, update, link, or assess GitHub issues using the rep
 
 # GitHub issues
 
-Use for durable follow-ups and pull-request linkage. Read local `AGENTS.md`, `CLAUDE.md`, issue
-templates, and repository-routing policy before making any remote mutation.
+Use for durable follow-ups and pull-request linkage. Read local `AGENTS.md`, issue
+templates, and repository-routing policy before any remote mutation.
 
 ## Mutation authority
 
-Caller authorization is required before any issue or taxonomy mutation; credential capability does
-not grant scope. Resolve the authenticated identity, current repository, and requested target without
-owner-prefix or visibility assumptions. Immediately before every write, refetch the exact target and
-require its canonical identity to still match and the repository not to be archived. Issue operations
-also require issues to be enabled and `viewerPermission` of `TRIAGE`, `WRITE`, `MAINTAIN`, or `ADMIN`;
-issue creation additionally requires `viewerCanCreateIssues`. Applying existing metadata to a pull
-request uses the same permission set but does not require issues to be enabled. Creating, changing,
-or deleting taxonomy definitions requires `WRITE`, `MAINTAIN`, or `ADMIN` plus the operation-specific
-API capability — project-write to create, rename, or close a project. Treat insufficient permission
-or capability, missing or inaccessible data, identity changes, and mismatches as a hard deny that
-approval cannot override. Narrowly within that rule: adding an item to an existing project uses the
-same permission set as applying existing metadata, plus project-write API capability — adding an
-item mutates project membership even though it needs no separate approval; missing project scope or
-capability is a hard deny of the project step alone — skip it, report the gap, and never work around
-it, while the issue and its other metadata still proceed.
+- Caller authorization is required before any issue or taxonomy mutation. A credential does not
+  grant scope.
+- Resolve the authenticated identity, current repository, and requested target. Do not assume an
+  owner prefix or visibility.
+- Immediately before every write, refetch the exact target. Its canonical identity must still
+  match, and the repository must not be archived.
+- Issue operations require issues to be enabled and `viewerPermission` of `TRIAGE`, `WRITE`,
+  `MAINTAIN`, or `ADMIN`. Issue creation additionally requires `viewerCanCreateIssues`.
+- Applying existing metadata to a pull request uses that same permission set and does not require
+  issues to be enabled.
+- Creating, changing, or deleting taxonomy definitions requires `WRITE`, `MAINTAIN`, or `ADMIN`
+  plus the operation-specific API capability. Creating, renaming, or closing a project requires
+  project-write.
+- Insufficient permission or capability, missing or inaccessible data, an identity change, or a
+  mismatch is a hard deny. Approval cannot override it.
+- Adding an item to an existing project uses the same permission set as applying existing metadata,
+  plus project-write. That add mutates project membership and needs no separate approval.
+- Missing project scope or capability denies the project step only. Skip it, report the gap, and
+  do not work around it. The issue and its other metadata still proceed.
 
-When an external creation target is denied, never write there. Search for and create or reuse a
-tracking issue in the current repository, or a consumer-selected tracker. Immediately before that
-write, refetch the destination repository and apply the issue-operation gate above. Include the
-intended upstream repository and a copy-ready report so a human can decide whether to file it. Before
-naming that upstream repository anywhere in the report, resolve it and compare the returned canonical
-name against the name being written — a renamed repository's redirect resolves successfully under the
-stale name, so existence alone proves nothing. This comparison serves report accuracy, not the
-mutation-authority gate above: a rename is not the hard-deny mismatch that gate defines, so report the
-canonical name in its place; when the name does not resolve at all, route the follow-up to the current
-repository instead of naming an unreachable target. Before copying details to a less-restricted
-destination, remove private repository identity, paths, links, code, and findings; if redaction would
-make the report unusable, require explicit destination approval or return the draft without mutation.
-Authorization to file the external issue includes this tracking fallback unless the caller opts out;
-report the reroute explicitly. If no tracker passes, return the draft without mutation. Never fall back
-silently or to an unverified
-repository.
+## Denied external target
+
+- Do not write to a denied external creation target.
+- Search for, then create or reuse, a tracking issue in the current repository or a
+  consumer-selected tracker. Immediately before that write, refetch the destination and apply the
+  issue-operation gate above.
+- Include the intended upstream repository and a copy-ready report.
+- Before naming that upstream repository, resolve it and compare the returned canonical name with
+  the name being written. A rename redirect resolves under the stale name, so existence is not
+  identity. This check is report accuracy, not the hard-deny mismatch above: write the canonical
+  name. When the name does not resolve, route the follow-up to the current repository and do not
+  name the unreachable target.
+- Before copying details to a less-restricted destination, remove private repository identity,
+  paths, links, code, and findings. If redaction would make the report unusable, require explicit
+  destination approval or return the draft without mutation.
+- Authorization to file the external issue includes this tracking fallback unless the caller opts
+  out. Report the reroute. If no tracker passes, return the draft without mutation.
+- Do not fall back silently, and do not fall back to an unverified repository.
 
 ## Issue workflow
 
-1. Search open and relevant closed issues in the selected destination; return a likely duplicate
-   rather than filing one. Verify paths and current behavior named in the issue.
-2. Before editing, commenting, relating, closing, or otherwise changing state, refetch the issue and
-   its current discussion. Verify the requested mutation is still authorized and supported by that
-   evidence. Close only when the documented outcome and acceptance evidence show the work is
-   resolved; otherwise leave state unchanged and report the gap.
-3. Write a self-contained issue with the problem, desired outcome, ownership boundaries, concrete
-   areas, validation, and external context. A discovered blocker does not widen implementation scope.
+1. Search open issues and relevant closed issues in the destination. Return a likely duplicate
+   instead of filing one. Verify the paths and current behavior the issue names.
+2. Before editing, commenting, relating, closing, or otherwise changing state, refetch the issue
+   and its discussion. Confirm the mutation is still authorized and supported. Close only when the
+   documented outcome and acceptance evidence show the work is resolved. Otherwise leave state
+   unchanged and report the gap.
+3. Write a self-contained issue: problem, desired outcome, ownership boundaries, concrete areas,
+   validation, and external context. A discovered blocker does not widen implementation scope.
 4. Fetch the complete live taxonomy, including open projects. Apply matching existing labels and a
-   selected existing milestone without separate approval. Select an existing open project for
-   strategic, initiative-level tracking and a milestone for repo-local release or sequencing
-   tracking — the choice turns on the initiative's nature, not how many repositories it touches, so a
-   single-repo strategic initiative can carry a project, and an initiative that needs both a
-   cross-cutting strategic view and repo-local sequencing may carry both; an issue belongs to at
-   most one project and not every issue needs one. Before adding an item, check its project
-   membership and that of any item the project's own automation could pull in alongside it, such as
-   a parent issue's sub-issues; skip the add and report the conflict if any of them already belongs
-   to a different project, instead of creating a second membership. Adding an item to an existing,
-   described project needs no separate approval, the same as applying a milestone — but creating,
-   renaming, or closing a project is a separately authorized taxonomy operation, like milestone
-   creation. A missing project scope or permission skips the project step; report the gap and never
-   work around it. Never set a project item's status to a value that closes the issue unless closing
-   it is separately authorized: GitHub's built-in Auto-close issue project workflow closes the issue
-   when its status changes to Done. When creating a plan issue from a source issue that already has a
-   milestone, apply that same existing milestone. When the source issue already has a project,
-   refetch its current memberships and apply the same project only if exactly one accessible, open
-   membership exists; otherwise skip the project step and report the conflict rather than guess. Omit
-   a missing optional milestone; a missing required milestone blocks the issue, and milestone creation
-   is a separately authorized taxonomy operation. For a missing label, use
-   [review-github-issue-taxonomy](../review-github-issue-taxonomy/SKILL.md): obtain explicit approval
-   for its exact repository, name, description, and color before creating it. Omit a declined
-   optional label; a missing required label blocks the issue.
-5. Refetch the created or updated issue and verify its metadata, including project membership. When
-   an item was added to a project, re-read the project rather than assuming only that item changed —
-   automation such as auto-adding a parent issue's sub-issues can pull in additional items, including
-   into a second project. Report a partial failure without retrying creation. Preserve history and
-   report the action, URL, labels, milestone, and project.
-6. Link a pull request with a closing reference only when it fully resolves the issue. Keep
-   cross-repository references fully qualified; PR creation authority remains separate.
-7. Use native sub-issues only for real hierarchy, blocked-by relationships only for genuine known
-   dependencies, and prose links for merely related work. Read every created relationship back.
+   selected existing milestone with no separate approval.
+   - Use an existing open project for strategic, initiative-level tracking, and a milestone for
+     repo-local release or sequencing. Choose by the initiative, not by how many repositories it
+     touches. A single-repo strategic initiative can have a project. An initiative can have both.
+     An issue belongs to at most one project, and not every issue needs one.
+   - Before adding a project item, check that item and any item the project's automation could
+     pull in with it, such as a parent issue's sub-issues. If any already belongs to a different
+     project, skip the add and report the conflict.
+   - Adding an item to an existing, described project needs no separate approval. Creating,
+     renaming, or closing a project is a separate taxonomy operation, as is creating a milestone.
+   - Missing project scope or permission skips the project step. Report the gap and do not work
+     around it.
+   - Do not set a project status that closes the issue unless closing is separately authorized.
+     GitHub's Auto-close issue workflow closes the issue when status becomes Done.
+   - When a plan issue's source already has a milestone, apply that same milestone. When the source
+     already has a project, refetch memberships and apply that project only when exactly one
+     accessible open membership exists. Otherwise skip the project and report the conflict.
+   - Omit a missing optional milestone. A missing required milestone blocks the issue. Omit a
+     declined optional label. A missing required label blocks the issue.
+   - For a missing label, use
+     [review-github-issue-taxonomy](../review-github-issue-taxonomy/SKILL.md) and get explicit
+     approval of the exact repository, name, description, and color before creating it.
+5. Refetch the created or updated issue and verify metadata, including project membership. After a
+   project add, re-read the project: automation can pull in more items, including into a second
+   project. Report a partial failure without retrying creation. Preserve history and report the
+   action, URL, labels, milestone, and project.
+6. Link a pull request with a closing reference only when it fully resolves the issue. Fully
+   qualify cross-repository references. Pull-request creation authority stays separate.
+7. Use native sub-issues only for a real hierarchy, blocked-by only for a known dependency, and
+   prose links for related work. Read every created relationship back.
 
-For batch creation, preflight every entry before writing any issue and fail the whole batch when one
-entry is invalid. A partial transport failure stops further creation and reports every issue already
-created; never retry successful entries.
+For a batch, preflight every entry before writing any issue. One invalid entry fails the whole
+batch. A partial transport failure stops further creation and reports every issue already created.
+Do not retry an entry that succeeded.
 
-This skill supplies no repository allowlist, taxonomy, issue template, credential, or CLI wrapper.
-Consumer wrappers define local defaults and may impose stricter policy, but may not weaken this gate.
+Consumer wrapper owns: repository allowlist, taxonomy, issue template, credential, and CLI wrapper.
+It may tighten this gate and may not weaken it.

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

@@ -5,11 +5,13 @@ description: Apply Vitest patterns for Next.js components, routes, and server-si
 
 # Next.js Vitest test authoring
 
-Apply [vitest-test-authoring](../vitest-test-authoring/SKILL.md) first. Mock framework navigation,
-headers, and server-only boundaries at the framework edge, then test component behavior through
-rendered output and user-visible state. Keep API-response fixtures representative and avoid testing
-framework internals. Use browser tests for behavior that cannot be represented in the test runtime.
+Apply [vitest-test-authoring](../vitest-test-authoring/SKILL.md) first.
 
-Consumer wrappers own framework mock helpers, render libraries, and route fixture conventions.
+- Mock framework navigation, headers, and server-only boundaries at the framework edge.
+- Test component behavior through rendered output and user-visible state.
+- Keep API-response fixtures representative. Do not test framework internals.
+- Use a browser test for behavior the test runtime cannot represent.
+- Read [framework boundaries](references/framework-boundaries.md) for module shape and server-only
+  cases.
 
-Read [framework boundaries](references/framework-boundaries.md) for module shape and server-only cases.
+Consumer wrapper owns: framework mock helpers, render libraries, and route fixture conventions.