vouchington-tooling 0.1.3 → 0.1.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vouchington-tooling",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "Vouchington CLI and extractable tooling libraries.",
   "homepage": "https://github.com/vouchington/vouchington-tooling/tree/main/packages/vouchington-tooling#readme",
   "bugs": {

package/skills/github-issue/SKILL.md

@@ -8,17 +8,55 @@ description: Search, create, update, link, or assess GitHub issues using the rep
 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.
 
-1. Confirm GitHub authentication and the explicitly authorized repository. Search open and relevant
-   closed issues before creating work; return a likely duplicate rather than filing one.
-2. Verify paths and current behavior named in an issue. A discovered blocker does not widen an
-   accepted implementation scope without the required local decision.
-3. Write a self-contained issue: problem, desired outcome, ownership boundaries, concrete areas,
-   validation, and any external dependency. Apply only existing labels and milestones according to
-   live local taxonomy.
-4. Link a pull request with a closing reference only when it fully resolves the issue. Use a
-   non-closing relationship with an explanation when work remains.
-5. For updates or closure recommendations, inspect current state and evidence first. Preserve
-   history and report the action, URL, and resulting metadata.
-
-This skill does not choose a default repository, permit cross-repository writes, create taxonomy,
-or prescribe a CLI wrapper. Consumer wrappers define authorization and local mechanics.
+## 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. Treat insufficient permission or capability, missing or inaccessible data, identity
+changes, and mismatches as a hard deny that approval cannot override.
+
+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
+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.
+
+## 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.
+4. Fetch the complete live taxonomy. Apply matching existing labels and a selected existing milestone
+   without separate approval. 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. Report a partial failure without
+   retrying creation. Preserve history and report the action, URL, labels, and milestone.
+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.
+
+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.
+
+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.

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

@@ -9,11 +9,14 @@ Use for issue hygiene, priority normalization, and milestone assignment. Read lo
 `CLAUDE.md`, and live taxonomy guidance before acting.
 
 1. Confirm repository identity and fetch the live labels, milestone descriptions, and all required
-   in-scope issue or pull-request evidence before mutating anything.
+   in-scope issue or pull-request evidence. Before mutating, enforce 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 and milestones. Do not create taxonomy, close work, rewrite bodies,
-   or alter titles unless the caller separately authorizes that scope.
+3. Apply only existing labels and milestones without requesting separate label approval. 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 changed while protected metadata

package/skills/retrospective-distill/SKILL.md

@@ -14,7 +14,9 @@ Use when completed retrospectives or journals should become durable follow-up wo
 3. Verify each candidate against the current base and 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
-   evidence embedded in the body. Follow local approval and taxonomy policy before creating them.
+   evidence embedded in the body. 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 under the repository's retention rules; report
    created, updated, skipped, and deferred themes with reasons.
 

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

@@ -15,8 +15,13 @@ local configuration edits or live taxonomy mutation; read local `AGENTS.md` and
 3. Audit aliases, ambiguity, unused labels, missing descriptions, color consistency, milestone
    overlap, delivery gaps, and path-label coverage.
 4. Return exact recommendations with migration impact and separate safe cleanup from decisions that
-   require product or scheduling judgment.
-5. Re-fetch current state immediately before any explicitly authorized mutation.
+   require 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
+   [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, issues, or local files for a recommendation-only
 request. This skill does not define a repository's taxonomy or automation file locations; a

package/skills/revisit-followups/SKILL.md

@@ -17,8 +17,10 @@ issue policy, and review-record conventions first.
 4. Group related candidates into self-contained issue drafts that preserve the original evidence and
    explain why the work remains needed.
 5. Remain read-only unless the caller or consumer wrapper explicitly authorizes issue creation. If
-   authorized, create only the approved candidates, then clean up temporary collection artifacts
-   and report skipped, covered, and created items.
+   authorized, route every candidate through
+   [github-issue](../github-issue/SKILL.md), including its denied-external tracking behavior; do not
+   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.