vouchington-tooling 0.20.0 → 0.22.0

package/skills/npm-publishing/SKILL.md

@@ -5,43 +5,44 @@ description: Bootstrap an npm package and give a human the exact commands to pub
 
 # npm publishing bootstrap
 
-Prepare the local package, but leave public registry and trusted-publisher mutations to the human.
-Read every applicable `AGENTS.md` and `CLAUDE.md` from the repository root through the package.
-Repository-local policy and the consumer wrapper own the package path and name, npm scope, GitHub
-repository, release workflow, build commands, and whether a laptop may publish.
+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,
+GitHub repository, release workflow, build commands, and whether a laptop may publish.
 
 ## Prepare the package
 
-1. Resolve the absolute repository root, package directory relative to that root, exact npm package
-   name, `owner/repository`, and release workflow filename. The workflow value is the case-sensitive
-   filename under `.github/workflows`, not a path. Do not leave placeholders in the final commands.
-2. Confirm npm 11.15 or newer, account-level two-factor authentication, and write access to the npm
-   package or scope. Inspect the workflow on the repository's default branch: it must grant
-   `id-token: write`, use a supported runner, install a trusted-publishing-capable npm version, and
-   publish this package.
-3. When the package does not exist in the registry, create the smallest useful stub module in its
-   intended directory. Follow neighboring package conventions for metadata, source, exports, types,
-   license, README, build output, and workspace registration. Do not replace an existing module with
-   a stub or publish a version already present in the registry.
-4. Build the package as required, then inspect the publication lifecycle and exact payload with
-   `npm publish <package-directory> --access public --dry-run`. Stop if it includes secrets,
-   environment files, source maps, unrelated workspace files, or missing runtime/type entrypoints.
-   This dry run must include `prepublishOnly`; a pack-only check is insufficient when that lifecycle
-   script can change the payload.
-5. If the package already exists, have the human run `npm trust list <package-name>` before any
-   mutation. Omit the initial publish command. If a trust relationship already exists, report it and
-   omit the trust-creation command rather than revoking or replacing it.
+- Resolve the absolute repository root, the package directory relative to that root, the exact npm
+  package name, `owner/repository`, and the release workflow filename. The workflow value is the
+  case-sensitive filename under `.github/workflows`, not a path. Leave no placeholders in the final
+  commands.
+- Confirm npm 11.15 or newer, account-level two-factor authentication, and write access to the
+  package or scope.
+- On the default branch, the workflow must grant `id-token: write`, use a supported runner, install
+  an npm version that can trusted-publish, and publish this package.
+- When the package does not exist in the registry, create the smallest useful stub in its intended
+  directory. Follow neighboring packages for metadata, source, exports, types, license, README,
+  build output, and workspace registration.
+- Do not replace an existing module with a stub. Do not publish a version already in the registry.
+- Build the package, then inspect the payload with
+  `npm publish <package-directory> --access public --dry-run`. Stop if it includes secrets,
+  environment files, source maps, unrelated workspace files, or a missing runtime or type
+  entrypoint. The dry run must include `prepublishOnly`. A pack-only check misses that script.
+- If the package already exists, have the human run `npm trust list <package-name>` before any
+  mutation. Omit the initial publish command. If trust already exists, report it and omit trust
+  creation. Do not revoke or replace it.
 
 ## Hand off the mutations
 
-Do not run a real `npm publish` or a mutating `npm trust` subcommand. Explain that the first command
-creates an externally visible, effectively irreversible package version and the second grants the
-named workflow publish authority. Include the publish command only when bootstrapping a package that
-does not exist; an existing package proceeds directly to trust setup when its trust list is empty.
-Tell the human to append a current one-time password after each final `--otp=` without sharing or
-recording it. Warn that the requested `--otp=` form can expose the OTP in shell history and process
-arguments, and tell the human to follow their local secret-handling policy. Give the applicable
-commands with fully resolved values and in this order:
+- Do not run a real `npm publish` or a mutating `npm trust` subcommand.
+- Say that the first command creates an externally visible, effectively irreversible package
+  version, and the second grants the named workflow publish authority.
+- Include the publish command only when bootstrapping a package that does not exist. An existing
+  package with an empty trust list goes straight to trust setup.
+- Tell the human to append a current one-time password after each final `--otp=` and not to share
+  or record it. Warn that `--otp=` can expose the OTP in shell history and process arguments, and
+  to follow local secret-handling policy.
+- Give the applicable commands with resolved values, in this order:
 
 ```sh
 cd /absolute/repository/root
@@ -54,11 +55,14 @@ npm trust github @scope/package \
   --otp=
 ```
 
-The `cd` target must be the directory from which the relative publish path resolves. If local policy
-prohibits publishing from the current machine, say so and identify the approved environment while
-preserving the same ordered commands. Ask the human to confirm the package payload, package name,
-repository, workflow filename, and publish permission immediately before running them.
+- The `cd` target is the directory from which the relative publish path resolves.
+- If local policy prohibits publishing from this machine, say so and name the approved environment.
+  Keep the same command order.
+- Ask the human to confirm the payload, package name, repository, workflow filename, and publish
+  permission immediately before running the commands.
+- Afterward, have the human verify any newly published version and run `npm trust list` again.
+- Do not retry an authorization or registry failure blindly. Do not fall back to a long-lived npm
+  token without explicit direction.
 
-Afterward, have the human verify any newly published package version and run
-`npm trust list @scope/package` again. Do not retry authorization or registry failures blindly, and do
-not fall back to a long-lived npm token without explicit direction.
+Consumer wrapper owns: package path and name, npm scope, GitHub repository, release workflow, build
+commands, and whether a laptop may publish.

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

@@ -6,28 +6,24 @@ description: Organize existing GitHub issues and pull requests with the reposito
 # Organize GitHub issues
 
 Use for issue hygiene, priority normalization, milestone assignment, and project membership. Read
-local `AGENTS.md`, `CLAUDE.md`, and live taxonomy guidance before acting.
+local `AGENTS.md`, and live taxonomy guidance before acting.
 
-1. Confirm repository identity and fetch the live labels, milestone descriptions, open project
-   descriptions, and all required in-scope issue or pull-request evidence. Before mutating, enforce
-   the operation-specific gate from [github-issue](../github-issue/SKILL.md); pull-request metadata
+1. Confirm repository identity. Fetch live labels, milestone descriptions, open project
+   descriptions, and the in-scope issue or pull-request evidence. Before a mutation, apply the
+   operation-specific gate from [github-issue](../github-issue/SKILL.md). Pull-request metadata
    does not require issues to be enabled.
-2. Classify from the permitted metadata and discussion evidence, not implementation guesses. Keep
-   automation, ownership, and provenance labels unless local policy explicitly permits changes.
-3. Apply only existing labels, milestones, and projects without requesting separate label approval;
-   an issue belongs to at most one project, and not every issue needs one. Before adding a project,
-   check the issue's membership and that of any item the project's own automation could pull in
-   alongside it, such as sub-issues; skip the add and report the conflict on any existing membership
-   instead of creating a second one. Never set a project item's status to a value that closes the
-   issue unless the caller separately authorizes closing it. Do not create taxonomy, close work,
-   rewrite bodies, or alter titles unless the caller separately authorizes that scope.
-4. In review mode, report the exact proposed metadata changes without mutating. In apply mode, make
-   only necessary, idempotent updates.
-5. Refetch every touched item and verify the requested metadata, including project membership,
-   changed while protected metadata stayed intact. When an item was added to a project, report any
-   additional item the project's own automation pulled in, such as a parent issue's sub-issues,
-   rather than assuming only the requested item changed. Report changed, unchanged, and ambiguous
-   items separately.
+2. Classify from the permitted metadata and discussion. Do not guess from the implementation. Keep
+   automation, ownership, and provenance labels unless local policy explicitly allows a change.
+3. Apply only existing labels, milestones, and projects without requesting separate label approval.
+   Follow [github-issue](../github-issue/SKILL.md) for single-project membership, auto-added
+   sub-issues, and a status that closes the issue. Do not create taxonomy, close work, rewrite
+   bodies, or change titles unless the caller separately authorizes that scope.
+4. In review mode, report the exact proposed metadata changes and do not mutate. In apply mode,
+   make only necessary, idempotent updates.
+5. Refetch every touched item. Verify the requested metadata, including project membership, and
+   confirm protected metadata stayed intact. After a project add, report any additional item the
+   project's automation pulled in, such as a parent issue's sub-issues. Report changed, unchanged,
+   and ambiguous items separately.
 
-This skill does not define priorities, labels, milestones, projects, clarification policy, or
-default scope. A consumer wrapper supplies the repository-specific taxonomy and permissions.
+Consumer wrapper owns: priorities, labels, milestones, projects, clarification policy, default
+scope, and permissions.

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

@@ -6,14 +6,15 @@ description: Use when changing JavaScript package metadata, dependencies, script
 # Package metadata checklist
 
 Use before changing `package.json`, a lockfile, workspace metadata, or a package entrypoint. Read
-every applicable `AGENTS.md` and `CLAUDE.md` from the repository root through the owning package,
+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,
 dependency age/version policy, registry, release process, and package layout.
 
 1. Identify the owning package and every consumer of the changed script, dependency, export, or
    binary. Prefer existing workspace utilities before adding a dependency.
 2. Use the repository's package manager for dependency changes. Update the lockfile when it records
-   the affected metadata; avoid lockfile churn for metadata-only edits it does not record. Keep peer,
+   the affected metadata; avoid lockfile churn for metadata-only edits it does not record. Keep
+   peer,
    optional, development, and runtime dependencies in their intended sections.
 3. For a published package, verify exports, types, files, binaries, and build output match the
    package's supported import and installation paths.
@@ -22,6 +23,5 @@ dependency age/version policy, registry, release process, and package layout.
    authorization.
 5. Review the lockfile and generated metadata for unrelated churn before committing.
 
-This skill supplies no version range, workspace topology, registry, package-manager command, or
-release convention. Put those repository-specific choices in local instructions or a consumer
-wrapper.
+Local instructions or the consumer wrapper own: version range, workspace topology, registry,
+package-manager command, and release convention.

package/skills/planning/SKILL.md

@@ -6,7 +6,7 @@ description: Create an evidence-backed implementation plan for a repository chan
 # Planning
 
 Use before implementation work that needs a durable plan. Repository-local `AGENTS.md`,
-`CLAUDE.md`, issue templates, and planning conventions override this portable foundation.
+`AGENTS.md`, issue templates, and planning conventions override this portable foundation.
 
 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.
@@ -24,5 +24,5 @@ Use before implementation work that needs a durable plan. Repository-local `AGEN
 For cross-cutting changes, read [impact discovery](references/impact-discovery.md) before selecting
 tests or concluding that a surface has no dependents.
 
-Do not invent a plan template, default repository, issue taxonomy, dependency graph tool, or
-approval workflow. A consumer wrapper owns those choices.
+Consumer wrapper owns: plan template, default repository, issue taxonomy, dependency graph tool,
+and approval workflow.

package/skills/playwright-authoring/SKILL.md

@@ -5,14 +5,15 @@ description: Author reliable Playwright browser tests, fixtures, selectors, and
 
 # Playwright authoring
 
-Use stable, accessible locators and assert user-observable outcomes. Establish data, authentication,
-and server state through supported fixtures or APIs; do not rely on test ordering or arbitrary waits.
-Keep each scenario independently repeatable, use auto-waiting assertions, and capture diagnostics on
-failure. Prefer browser coverage for real browser interactions rather than duplicating unit tests.
+Apply [test-authoring](../test-authoring/SKILL.md).
 
-Consumer wrappers own environments, credentials, personas, fixtures, and suite commands.
+- Use a stable, accessible locator. Assert a user-observable outcome.
+- Establish data, authentication, and server state through a supported fixture or API.
+- Do not rely on test order or an arbitrary wait.
+- Keep each scenario independently repeatable. Use an auto-waiting assertion. Capture diagnostics
+  on failure.
+- Use the browser for a real browser interaction. Do not repeat a unit test there.
+- Read [browser reliability](references/browser-reliability.md) for locator, waiting, state, and
+  network rules.
 
-Read [browser reliability](references/browser-reliability.md) for locator, waiting, state, and network rules.
-
-Read [tautological tests](../test-authoring/references/tautological-tests.md) before finishing any
-assertion that is not obviously falsifiable by a defect in the flow under test.
+Consumer wrapper owns: environments, credentials, personas, fixtures, and suite commands.

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

@@ -5,11 +5,15 @@ description: Diagnose and improve PostgreSQL performance in Node.js applications
 
 # PostgreSQL and Node.js performance
 
-Measure query plans and workload shape before changing code. Select only required columns, bound
-result sets, paginate or stream large reads, batch writes within explicit transaction limits, and
-keep connection-pool usage bounded. Validate query changes with representative cardinality and
-watch latency, memory, lock time, and connection pressure together.
+Measure the query plan and the workload shape before changing code.
 
-Consumer wrappers own schema ownership, operational thresholds, pooling configuration, and rollout.
+- Select only the required columns.
+- Bound each result set. Paginate or stream a large read.
+- Batch writes inside an explicit transaction limit.
+- Keep connection-pool usage bounded.
+- Validate a query change at representative cardinality. Watch latency, memory, lock time, and
+  connection pressure together.
+- Read [performance patterns](references/performance-patterns.md) before changing a high-volume
+  path.
 
-Read [performance patterns](references/performance-patterns.md) before changing high-volume paths.
+Consumer wrapper owns: schema ownership, operational thresholds, pooling configuration, and rollout.

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

@@ -5,12 +5,15 @@ description: Design PostgreSQL partitions and indexes that use time-ordered UUID
 
 # PostgreSQL partitioning with UUIDv7
 
-Partition only after confirming lifecycle, retention, and query predicates benefit from it. Treat a
-UUIDv7 as time ordered but not as a replacement for explicit business timestamps where semantics
-matter. Align partition keys, primary keys, indexes, constraints, and query predicates so partition
-pruning is observable. Plan creation, retention, migration, and verification as one deployable
-lifecycle, including rollback and independent-reader compatibility.
+Partition only after lifecycle, retention, and query predicates show that it helps.
 
-Consumer wrappers own partition intervals, migration tooling, retention policy, and deploy sequencing.
+- Treat a UUIDv7 as time ordered. Where the meaning matters, keep an explicit business timestamp.
+- Align the partition key, primary key, indexes, constraints, and query predicates so partition
+  pruning is observable.
+- Plan creation, retention, migration, and verification as one deployable lifecycle. Include
+  rollback and independent-reader compatibility.
+- Read [partition lifecycle](references/partition-lifecycle.md) before a schema or retention
+  migration.
 
-Read [partition lifecycle](references/partition-lifecycle.md) before a schema or retention migration.
+Consumer wrapper owns: partition intervals, migration tooling, retention policy, and deploy
+sequencing.

package/skills/pr-description/SKILL.md

@@ -6,7 +6,7 @@ description: Draft or review a self-contained pull-request description with summ
 # Pull-request description
 
 Use before opening or updating a pull request, or when reviewing PR hand-off quality. Read local
-`AGENTS.md`, `CLAUDE.md`, pull-request template, and issue-linking policy first.
+`AGENTS.md`, pull-request template, and issue-linking policy first.
 
 Include enough context for a reviewer with no prior conversation:
 
@@ -19,5 +19,6 @@ Include enough context for a reviewer with no prior conversation:
 - A compact diagram only when it materially clarifies a multi-component flow or lifecycle.
 
 Use the repository's approved PR tooling and preserve sections managed by its review automation.
-Do not invent required headings, a source issue rule, merge policy, repository command, or hosted
-review system. Consumer wrappers own those mechanics.
+
+Consumer wrapper owns: required headings, source-issue rule, merge policy, repository command, and
+hosted review system.

package/skills/retrospective/SKILL.md

@@ -5,24 +5,23 @@ description: Produce a concise evidence-based retrospective for a completed task
 
 # Retrospective
 
-Use at task completion or session close-out when the repository has a retrospective workflow.
-Read the local `AGENTS.md`, `CLAUDE.md`, and journal guidance first.
+Use at task completion or session close-out when the repository has a retrospective workflow. Read
+local `AGENTS.md`, and journal guidance first.
 
-1. Check whether a retrospective already exists and append only a material delta when local policy
-   calls for that behavior.
+1. Check whether a retrospective already exists. Append only a material delta when local policy
+   says to append.
 2. Gather verifiable facts from the repository's approved status, validation, issue, and journal
    sources. Do not estimate unknown facts from memory or transcripts.
 3. Summarize the outcome, plan-versus-actual differences, validation evidence, recurring friction,
-   and actionable process improvements. Keep one-off noise separate from repeatable root causes.
-   Preserve the repository attribution of the source entries in the retrospective record when the
-   journal supports it; a retrospective spanning repositories names every represented repository.
-4. Save through the repository's required durable mechanism and report the record identifier plus
-   any follow-up decisions.
+   and actionable process improvements. Keep one-off noise separate from a repeatable root cause.
+   Preserve each source entry's repository attribution when the journal supports it. A retrospective
+   that spans repositories names every represented repository.
+4. Save through the repository's required durable mechanism. Report the record identifier and any
+   follow-up decisions.
 
-Use raw evidence only for local verification. Save only bounded structured facts or redacted summaries
-in a durable retrospective; never embed unredacted logs, command output, environment dumps, provider
-payloads, or transcript content there.
+Use raw evidence only for local verification. Save only bounded structured facts or redacted
+summaries in a durable retrospective; never embed unredacted logs, command output, environment
+dumps, provider payloads, or transcript content there.
 
-Do not prescribe transcript access, retention, a report schema, a journal provider, or issue
-filing policy. Consumer wrappers add those local contracts without weakening this minimization
-boundary.
+Consumer wrappers add transcript access, retention, a report schema, a journal provider, and issue
+filing policy. They cannot weaken this minimization boundary.

package/skills/retrospective-distill/SKILL.md

@@ -6,29 +6,29 @@ description: Distill completed session records into a small set of verified, act
 # Retrospective distillation
 
 Use when completed retrospectives or journals should become durable follow-up work. Read local
-`AGENTS.md`, `CLAUDE.md`, issue policy, and journal retention rules before any mutation.
+`AGENTS.md`, issue policy, and journal retention rules before any mutation.
 
 1. Enumerate only completed, eligible session records. For repository-scoped work, filter sessions
-   by repository membership and use only entries attributed to that repository. Keep untagged legacy
-   records unclassified instead of inferring their repository. Leave in-progress sessions intact.
-2. Cluster findings by root cause, favoring a few broad actionable themes over many narrow issues.
+   by repository membership and use only entries attributed to that repository. Leave untagged
+   legacy records unclassified. Do not infer their repository. Leave in-progress sessions intact.
+2. Cluster findings by root cause. Prefer a few broad actionable themes over many narrow issues.
    Treat a finding already linked to an open tracker as context, not a duplicate.
-3. Verify each candidate against the current base and search existing issues and open changes before
+3. Verify each candidate against the current base. Search existing issues and open changes before
    drafting. Skip work that is complete, explicitly rejected, or already covered.
 4. Draft self-contained issues with the problem, concrete proposed work, relevant areas, and
    validation. Route every authorized creation through
    [github-issue](../github-issue/SKILL.md), including its repository gate, label approval, and
    denied-external tracking behavior.
-5. Archive only records that were fully processed across every represented repository under the
-   repository's retention rules. A one-repository pass leaves a multi-repository session active
-   until its other repositories have been reviewed. Report
-   created, updated, skipped, and deferred themes with reasons.
+5. Archive only records fully processed across every represented repository, under the repository's
+   retention rules. A one-repository pass leaves a multi-repository session active until the other
+   repositories are reviewed. Report created, updated, skipped, and deferred themes with reasons.
 
 Use source records only for local verification and leave them in the repository's approved journal
-or retention system. Public issue bodies contain only the minimum bounded facts or redacted summaries
-needed to establish the problem, proposed work, relevant areas, and validation. Never embed
-unredacted logs, command output, environment details, provider payloads, or transcript content.
+or retention system. Public issue bodies contain only the minimum bounded facts or redacted
+summaries needed to establish the problem, proposed work, relevant areas, and validation. Never
+embed unredacted logs, command output, environment details, provider payloads, or transcript
+content.
 
 This skill supplies no journal API, issue repository, labels, milestones, projects, archival
-command, or approval model. Consumer wrappers cannot weaken this export boundary; they provide
-only those local details.
+command, or approval model. Consumer wrappers cannot weaken this export boundary; they provide only
+those local details.

package/skills/review-ci-logs/SKILL.md

@@ -5,25 +5,24 @@ description: Audit CI failures or noisy logs, identify the root cause, and recom
 
 # Review CI logs
 
-Use when investigating CI failures, repeated workflow noise, or misleading diagnostics. Read local
-`AGENTS.md`, `CLAUDE.md`, workflow guidance, and CI documentation before inspecting runs.
+Use when investigating a CI failure, repeated workflow noise, or misleading diagnostics. Read local
+`AGENTS.md`, workflow guidance, and CI documentation before inspecting runs.
 
-1. Confirm the repository and select representative failed and successful runs within a bounded
-   window. For a supplied run, inspect only that run.
-2. Download logs to a temporary directory instead of streaming archives into the working context.
-   Inspect failed steps and representative large entries, then remove temporary artifacts.
-3. Classify findings as a real error, misleading output, downstream cascade, necessary diagnostic,
-   or volume-only concern. Identify the first repository-owned root cause.
-4. For persistent-workspace failures, identify the producer of sparse state or unsafe ownership before
-   proposing cleanup. Reject unconditional pre-checkout workspace traversals. Bounded known generated
-   paths may be repaired routinely; a workspace-wide fallback must be failure-gated, same-filesystem,
-   directory-only, and batched. Require path-count and timing evidence, plus a drained one-time migration
-   and producer-side fix such as a compatible non-root writable workspace mount when runner state is
-   contaminated.
+1. Confirm the repository. Select representative failed and successful runs inside a bounded window.
+   For a supplied run, inspect only that run.
+2. Download logs to a temporary directory. Do not stream archives into the working context. Inspect
+   failed steps and representative large entries, then remove the temporary artifacts.
+3. Classify each finding as a real error, misleading output, a downstream cascade, a necessary
+   diagnostic, or a volume-only concern. Identify the first repository-owned root cause.
+4. For a persistent-workspace failure, name the producer of sparse state or unsafe ownership before
+   proposing cleanup. Reject an unconditional pre-checkout workspace traversal. A compliant repair
+   is the one in [github-actions-checklist](../github-actions-checklist/SKILL.md).
 5. Prefer one bounded fix that preserves non-zero exits, primary errors, artifacts, summaries, and
-   diagnostic evidence. Do not hide stderr, globally quiet output, or add retries to mask a cause.
-6. Add focused regression evidence, run local workflow validation, compare before and after output
-   where meaningful, and report deferred findings without creating issues unless authorized.
+   diagnostic evidence. Do not hide stderr, globally quiet output, or add a retry that masks the
+   cause.
+6. Add focused regression evidence, run local workflow validation, and compare before and after
+   output where that comparison is meaningful. Report deferred findings. Do not create issues unless
+   authorized.
 
-This skill supplies no workflow names, log-retention policy, CI provider command, retry policy, or
-scheduled automation. Consumer wrappers provide those local details.
+Consumer wrapper owns: workflow names, log retention, the CI provider command, retry policy, and
+scheduled automation.

package/skills/review-github-issue-taxonomy/SKILL.md

@@ -5,30 +5,33 @@ description: Audit GitHub labels, milestones, projects, and path-label automatio
 
 # Review GitHub issue taxonomy
 
-Use when the taxonomy itself needs review. Remain read-only unless the caller explicitly authorizes
-local configuration edits or live taxonomy mutation; read local `AGENTS.md` and `CLAUDE.md` first.
+Use when the taxonomy itself needs review. Stay read-only unless the caller explicitly authorizes
+local configuration edits or a live taxonomy mutation. Read local `AGENTS.md` first.
 
-1. Confirm repository identity and fetch live labels, descriptions, colors, usage, milestones, open
-   and closed projects, and their current scope.
-2. Identify automation-owned labels and inspect local label automation before recommending a rename,
+1. Confirm repository identity. Fetch live labels, descriptions, colors, usage, milestones, open and
+   closed projects, and their current scope.
+2. Identify automation-owned labels. Inspect local label automation before recommending a rename,
    deletion, or rule change.
 3. Audit aliases, ambiguity, unused labels, missing descriptions, color consistency, milestone
-   overlap, delivery gaps, and path-label coverage. Audit projects too: a milestone theme duplicated
-   across repositories is a candidate project, and a project holding only routine, non-initiative
-   work — regardless of how many repositories it touches — is a candidate milestone; repository count
-   alone is not a miscategorization signal. Flag a project with no description, an empty or stale project, a closed
-   project with open items, an issue that belongs to more than one project, and a project's own
-   automation for auto-adding a parent issue's sub-issues left enabled where the at-most-one-project
-   rule applies — it can silently duplicate membership.
-4. Return exact recommendations with migration impact and separate safe cleanup from decisions that
-   require product or scheduling judgment. Applying an existing label is not taxonomy creation and
+   overlap, delivery gaps, and path-label coverage. Audit projects against
+   [github-issue](../github-issue/SKILL.md):
+   - A milestone theme duplicated across repositories is a candidate project.
+   - A project that holds only routine, non-initiative work is a candidate milestone. Repository
+     count is not the signal.
+   - Flag a project with no description, an empty or stale project, a closed project with open
+     items, and an issue that belongs to more than one project.
+   - Flag auto-add of a parent issue's sub-issues where the at-most-one-project rule applies. It
+     can put an item in a second project.
+4. Return exact recommendations with migration impact. Separate safe cleanup from decisions that
+   need product or scheduling judgment. Applying an existing label is not taxonomy creation and
    needs no separate approval from the authorized issue operation.
-5. Before creating a label, stop for explicit approval naming its exact repository, name,
-   description, and color. Re-fetch current state and enforce the taxonomy-definition gate from
+5. Before creating a label, stop for explicit approval of its exact repository, name, description,
+   and color. Re-fetch current state and apply the taxonomy-definition gate from
    [github-issue](../github-issue/SKILL.md): require `WRITE`, `MAINTAIN`, or `ADMIN` and the
    label-specific API capability immediately before the approved mutation. `viewerCanCreateIssues`
    applies only to issue creation. Approval for an issue or another label does not transfer.
 
 Do not create or change labels, milestones, projects, issues, or local files for a
-recommendation-only request. This skill does not define a repository's taxonomy or automation file
-locations; a consumer wrapper supplies those integrations and local mechanics.
+recommendation-only request.
+
+Consumer wrapper owns: the repository taxonomy and the local automation file locations.

package/skills/revisit-followups/SKILL.md

@@ -5,7 +5,7 @@ description: Review recently completed work and repository instructions for genu
 
 # Revisit follow-ups
 
-Use to turn explicit deferred work into a curated backlog. Read local `AGENTS.md`, `CLAUDE.md`,
+Use to turn explicit deferred work into a curated backlog. Read local `AGENTS.md`,
 issue policy, and review-record conventions first.
 
 1. Confirm the requested lookback window and collect only explicit deferred-action signals from
@@ -22,5 +22,5 @@ issue policy, and review-record conventions first.
    duplicate repository or label authorization. Then clean up temporary collection artifacts and
    report skipped, covered, and created items.
 
-Do not assume a review journal format, default lookback, hosting provider, repository, issue
-taxonomy, or confirmation mechanism. Consumer wrappers own those integrations.
+Consumer wrapper owns: review journal format, default lookback, hosting provider, repository,
+issue taxonomy, and confirmation mechanism.