vouchington-tooling 0.16.1 → 0.17.0

package/dist/github-projects/index.d.mts

@@ -0,0 +1,4 @@
+export { auditProjectCompletion, formatProjectAdvisories, formatProjectAdvisoryReport, groupClosedIssuesByProject, } from './project-audit.mts';
+export type { ClosingIssueRef } from './project-audit.mts';
+export { buildIssueProjectItemsArgs, buildProjectItemsArgs, DEFAULT_PROJECT_COMPLETION_REMAINDER, fetchIssueProjectMemberships, findProjectCompletionSiblings, isProjectScopeError, } from './project-query.mts';
+export type { ProjectGroup, ProjectMembershipResult, ProjectRef, ProjectSibling, } from './project-query.mts';

package/dist/github-projects/index.mjs

@@ -0,0 +1,2 @@
+export { auditProjectCompletion, formatProjectAdvisories, formatProjectAdvisoryReport, groupClosedIssuesByProject, } from './project-audit.mjs';
+export { buildIssueProjectItemsArgs, buildProjectItemsArgs, DEFAULT_PROJECT_COMPLETION_REMAINDER, fetchIssueProjectMemberships, findProjectCompletionSiblings, isProjectScopeError, } from './project-query.mjs';

package/dist/github-projects/project-audit.d.mts

@@ -0,0 +1,32 @@
+import type { RunTextCommand } from '../gh-cli/index.mts';
+import { type ProjectGroup, type ProjectRef, type ProjectSibling } from './project-query.mts';
+/** One issue this change closes: a bare number, plus the `owner/repo` it lives in when that
+ * differs from the audited repo (`undefined` means the audited repo itself). */
+export type ClosingIssueRef = {
+    number: number;
+    repo?: string | undefined;
+};
+type ClosingIssueProjects = {
+    closingKey: string;
+    projects: ProjectRef[];
+};
+/**
+ * Groups a change's closing issues by the open project(s) each belongs to. An issue may belong to
+ * more than one open project (see `fetchIssueProjectMemberships`) — every one it belongs to gets
+ * its own group entry here, audited independently rather than picked arbitrarily.
+ */
+export declare function groupClosedIssuesByProject(entries: ReadonlyArray<ClosingIssueProjects>): Map<string, ProjectGroup>;
+/** Purely advisory formatting: there is no in-body disposition marker to check against, unlike a
+ * milestone-completion audit — every remaining sibling is reported unconditionally. */
+export declare function formatProjectAdvisories(siblings: ProjectSibling[]): string[];
+/** Formats advisory strings for display; `''` when there is nothing to show. */
+export declare function formatProjectAdvisoryReport(advisories: readonly string[]): string;
+/**
+ * Audits whether the projects a change's closing issues belong to are nearly complete, returning
+ * one advisory string per remaining open item — never throws, and callers decide what to do with
+ * the result (e.g. print it, never block on it). A missing/insufficient `project` scope, or a
+ * GraphQL call that fails with a scope error, collapses the whole audit to a single skipped-audit
+ * notice instead of failing. `remainder` overrides `DEFAULT_PROJECT_COMPLETION_REMAINDER`.
+ */
+export declare function auditProjectCompletion(runGh: RunTextCommand, repo: string, closingIssues: ReadonlyArray<ClosingIssueRef>, remainder?: number): Promise<string[]>;
+export {};

package/dist/github-projects/project-audit.mjs

@@ -0,0 +1,77 @@
+import { DEFAULT_PROJECT_COMPLETION_REMAINDER, fetchIssueProjectMemberships, findProjectCompletionSiblings, } from './project-query.mjs';
+function splitOwnerRepo(repo) {
+    const [owner, name] = repo.split('/');
+    if (owner === undefined || name === undefined) {
+        throw new Error(`expected "owner/repo", got "${repo}"`);
+    }
+    return [owner, name];
+}
+/**
+ * Groups a change's closing issues by the open project(s) each belongs to. An issue may belong to
+ * more than one open project (see `fetchIssueProjectMemberships`) — every one it belongs to gets
+ * its own group entry here, audited independently rather than picked arbitrarily.
+ */
+export function groupClosedIssuesByProject(entries) {
+    const grouped = new Map();
+    for (const { closingKey, projects } of entries) {
+        for (const project of projects) {
+            const group = grouped.get(project.id) ?? { keys: new Set(), project };
+            group.keys.add(closingKey);
+            grouped.set(project.id, group);
+        }
+    }
+    return grouped;
+}
+/** Purely advisory formatting: there is no in-body disposition marker to check against, unlike a
+ * milestone-completion audit — every remaining sibling is reported unconditionally. */
+export function formatProjectAdvisories(siblings) {
+    return siblings.map((sibling) => `${sibling.key} ("${sibling.title}") is still open in project "${sibling.projectTitle}" ` +
+        `(${sibling.projectUrl}), which this change is nearly completing.`);
+}
+/** Formats advisory strings for display; `''` when there is nothing to show. */
+export function formatProjectAdvisoryReport(advisories) {
+    if (advisories.length === 0)
+        return '';
+    return [
+        'Project completion advisory (non-blocking, no disposition required):',
+        ...advisories.map((advisory) => `  - ${advisory}`),
+        '',
+    ].join('\n');
+}
+async function resolveClosingIssueProjects(runGh, issue, auditedOwner, auditedRepo) {
+    const [owner, repo] = issue.repo === undefined ? [auditedOwner, auditedRepo] : splitOwnerRepo(issue.repo);
+    const closingKey = `${owner}/${repo}#${issue.number}`.toLowerCase();
+    const result = await fetchIssueProjectMemberships(runGh, owner, repo, issue.number);
+    if (!result.ok) {
+        return {
+            closingKey,
+            projects: [],
+            scopeErrorMessage: result.scopeError ? result.error : undefined,
+        };
+    }
+    return { closingKey, projects: result.projects, scopeErrorMessage: undefined };
+}
+/**
+ * Audits whether the projects a change's closing issues belong to are nearly complete, returning
+ * one advisory string per remaining open item — never throws, and callers decide what to do with
+ * the result (e.g. print it, never block on it). A missing/insufficient `project` scope, or a
+ * GraphQL call that fails with a scope error, collapses the whole audit to a single skipped-audit
+ * notice instead of failing. `remainder` overrides `DEFAULT_PROJECT_COMPLETION_REMAINDER`.
+ */
+export async function auditProjectCompletion(runGh, repo, closingIssues, remainder = DEFAULT_PROJECT_COMPLETION_REMAINDER) {
+    if (closingIssues.length === 0)
+        return [];
+    const [auditedOwner, auditedRepo] = splitOwnerRepo(repo);
+    const resolved = await Promise.all(closingIssues.map((issue) => resolveClosingIssueProjects(runGh, issue, auditedOwner, auditedRepo)));
+    const scopeFailure = resolved.find((entry) => entry.scopeErrorMessage !== undefined);
+    if (scopeFailure !== undefined) {
+        return [`Project completion audit skipped: ${scopeFailure.scopeErrorMessage}`];
+    }
+    const groups = groupClosedIssuesByProject(resolved);
+    if (groups.size === 0)
+        return [];
+    const siblings = await findProjectCompletionSiblings(runGh, groups, remainder);
+    if (siblings.length === 0)
+        return [];
+    return formatProjectAdvisories(siblings);
+}

package/dist/github-projects/project-query.d.mts

@@ -0,0 +1,51 @@
+import type { RunTextCommand } from '../gh-cli/index.mts';
+/**
+ * A reasonable default for `findProjectCompletionSiblings`' `remainder` parameter: once this few
+ * other open items remain in a cross-repo GitHub Projects v2 project a change is touching, the
+ * project is worth calling out as nearly done. Callers may pass their own threshold instead.
+ */
+export declare const DEFAULT_PROJECT_COMPLETION_REMAINDER = 3;
+export type ProjectRef = {
+    id: string;
+    title: string;
+    url: string;
+};
+export type ProjectMembershipResult = {
+    ok: true;
+    projects: ProjectRef[];
+} | {
+    error: string;
+    ok: false;
+    scopeError: boolean;
+};
+export type ProjectGroup = {
+    keys: Set<string>;
+    project: ProjectRef;
+};
+export type ProjectSibling = {
+    key: string;
+    projectTitle: string;
+    projectUrl: string;
+    title: string;
+};
+export declare function isProjectScopeError(message: string): boolean;
+export declare function buildIssueProjectItemsArgs(owner: string, repo: string, number: number): string[];
+/**
+ * Fetches every OPEN project an issue belongs to. An issue can carry more than one `projectItems`
+ * node — a project workflow can add an issue to a project automatically — so this returns every
+ * open one rather than assuming, or requiring, exactly one; callers should audit each
+ * independently rather than picking one arbitrarily. Distinguishes a missing/insufficient
+ * `project` scope (`scopeError: true`; callers typically collapse to a single skipped-audit
+ * notice) from any other failure (callers typically degrade this one issue to "no memberships").
+ */
+export declare function fetchIssueProjectMemberships(runGh: RunTextCommand, owner: string, repo: string, number: number): Promise<ProjectMembershipResult>;
+export declare function buildProjectItemsArgs(projectId: string): string[];
+/**
+ * For each distinct project a change touches, enumerates that project's other open issue items
+ * across every repo it spans — a project has no per-repo scoping, so one query covers all of them
+ * (capped at the first 100 items). Silent (`[]`) once the remainder exceeds `remainder`
+ * (`DEFAULT_PROJECT_COMPLETION_REMAINDER` unless the caller passes its own). A per-project query
+ * failure degrades that one project to "no siblings audited" rather than throwing — every other
+ * project still completes.
+ */
+export declare function findProjectCompletionSiblings(runGh: RunTextCommand, groups: ReadonlyMap<string, ProjectGroup>, remainder?: number): Promise<ProjectSibling[]>;

package/dist/github-projects/project-query.mjs

@@ -0,0 +1,109 @@
+/**
+ * A reasonable default for `findProjectCompletionSiblings`' `remainder` parameter: once this few
+ * other open items remain in a cross-repo GitHub Projects v2 project a change is touching, the
+ * project is worth calling out as nearly done. Callers may pass their own threshold instead.
+ */
+export const DEFAULT_PROJECT_COMPLETION_REMAINDER = 3;
+// GitHub's real wording for a token missing the `project` scope on a ProjectV2 GraphQL field (an
+// insufficient-scopes error, not a 404 or a plain permission denial) — matched case-insensitively
+// against whatever the injected `runGh` surfaces in its thrown error message.
+const SCOPE_ERROR_RE = /insufficient_scopes|required scopes|['"]project['"]\s+scope/i;
+export function isProjectScopeError(message) {
+    return SCOPE_ERROR_RE.test(message);
+}
+export function buildIssueProjectItemsArgs(owner, repo, number) {
+    const query = 'query($owner:String!,$repo:String!,$number:Int!){repository(owner:$owner,name:$repo){issue(number:$number){projectItems(first:20){nodes{project{id title url closed}}}}}}';
+    return [
+        'api',
+        'graphql',
+        '-f',
+        `query=${query}`,
+        '-F',
+        `owner=${owner}`,
+        '-F',
+        `repo=${repo}`,
+        '-F',
+        `number=${number}`,
+    ];
+}
+/**
+ * Fetches every OPEN project an issue belongs to. An issue can carry more than one `projectItems`
+ * node — a project workflow can add an issue to a project automatically — so this returns every
+ * open one rather than assuming, or requiring, exactly one; callers should audit each
+ * independently rather than picking one arbitrarily. Distinguishes a missing/insufficient
+ * `project` scope (`scopeError: true`; callers typically collapse to a single skipped-audit
+ * notice) from any other failure (callers typically degrade this one issue to "no memberships").
+ */
+export async function fetchIssueProjectMemberships(runGh, owner, repo, number) {
+    try {
+        const json = await runGh(buildIssueProjectItemsArgs(owner, repo, number));
+        const parsed = JSON.parse(json);
+        const nodes = parsed.data?.repository?.issue?.projectItems?.nodes ?? [];
+        const projects = [];
+        for (const { project } of nodes) {
+            if (project == null ||
+                project.closed !== false ||
+                typeof project.id !== 'string' ||
+                typeof project.title !== 'string' ||
+                typeof project.url !== 'string') {
+                continue;
+            }
+            projects.push({ id: project.id, title: project.title, url: project.url });
+        }
+        return { ok: true, projects };
+    }
+    catch (err) {
+        const error = err instanceof Error ? err.message : String(err);
+        return { error, ok: false, scopeError: isProjectScopeError(error) };
+    }
+}
+export function buildProjectItemsArgs(projectId) {
+    const query = 'query($id:ID!){node(id:$id){... on ProjectV2{items(first:100){nodes{content{__typename ... on Issue{number title state repository{nameWithOwner}}}}}}}}';
+    return ['api', 'graphql', '-f', `query=${query}`, '-F', `id=${projectId}`];
+}
+function parseOpenProjectIssue(node) {
+    const content = node.content;
+    if (content == null || content['__typename'] !== 'Issue' || content.state !== 'OPEN')
+        return undefined;
+    const { number, title } = content;
+    const nameWithOwner = content.repository?.nameWithOwner;
+    if (typeof number !== 'number' ||
+        typeof title !== 'string' ||
+        typeof nameWithOwner !== 'string') {
+        return undefined;
+    }
+    return { key: `${nameWithOwner.toLowerCase()}#${number}`, title };
+}
+/**
+ * For each distinct project a change touches, enumerates that project's other open issue items
+ * across every repo it spans — a project has no per-repo scoping, so one query covers all of them
+ * (capped at the first 100 items). Silent (`[]`) once the remainder exceeds `remainder`
+ * (`DEFAULT_PROJECT_COMPLETION_REMAINDER` unless the caller passes its own). A per-project query
+ * failure degrades that one project to "no siblings audited" rather than throwing — every other
+ * project still completes.
+ */
+export async function findProjectCompletionSiblings(runGh, groups, remainder = DEFAULT_PROJECT_COMPLETION_REMAINDER) {
+    const results = await Promise.all(Array.from(groups.values()).map(async (group) => {
+        try {
+            const json = await runGh(buildProjectItemsArgs(group.project.id));
+            const parsed = JSON.parse(json);
+            const nodes = parsed.data?.node?.items?.nodes ?? [];
+            const open = nodes
+                .map(parseOpenProjectIssue)
+                .filter((item) => item !== undefined);
+            const remaining = open.filter((item) => !group.keys.has(item.key));
+            if (remaining.length > remainder)
+                return [];
+            return remaining.map((item) => ({
+                key: item.key,
+                projectTitle: group.project.title,
+                projectUrl: group.project.url,
+                title: item.title,
+            }));
+        }
+        catch {
+            return [];
+        }
+    }));
+    return results.flat();
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vouchington-tooling",
-  "version": "0.16.1",
+  "version": "0.17.0",
   "description": "Vouchington CLI and extractable tooling libraries.",
   "homepage": "https://github.com/vouchington/vouchington-tooling/tree/main/packages/vouchington-tooling#readme",
   "bugs": {
@@ -298,6 +298,11 @@
       "import": "./dist/gh-cli/index.mjs",
       "default": "./dist/gh-cli/index.mjs"
     },
+    "./github-projects": {
+      "types": "./dist/github-projects/index.d.mts",
+      "import": "./dist/github-projects/index.mjs",
+      "default": "./dist/github-projects/index.mjs"
+    },
     "./gh-api-shell-quoting": {
       "types": "./dist/gh-api-shell-quoting/index.d.mts",
       "import": "./dist/gh-api-shell-quoting/index.mjs",

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

@@ -41,8 +41,29 @@ Apply this portable baseline unless a stricter repository-local rule overrides i
   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.
-- Use GitHub-hosted runners only for public repositories. Private repositories use the consumer's
-  approved self-hosted or disposable runner labels.
+- 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
+  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.
+- 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.

package/skills/github-issue/SKILL.md

@@ -16,10 +16,15 @@ owner-prefix or visibility assumptions. Immediately before every write, refetch
 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.
+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.
 
 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
@@ -48,14 +53,32 @@ repository.
    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.
+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
+   cross-repo initiative work and a milestone for single-repo initiative work; 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

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

@@ -5,22 +5,29 @@ description: Organize existing GitHub issues and pull requests with the reposito
 
 # Organize GitHub issues
 
-Use for issue hygiene, priority normalization, and milestone assignment. Read local `AGENTS.md`,
-`CLAUDE.md`, and live taxonomy guidance before acting.
+Use for issue hygiene, priority normalization, milestone assignment, and project membership. Read
+local `AGENTS.md`, `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, enforce the operation-specific gate from
-   [github-issue](../github-issue/SKILL.md); pull-request metadata does not require issues to be
-   enabled.
+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
+   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 without requesting separate label approval. Do not
-   create taxonomy, close work, rewrite bodies, or alter titles unless the caller separately
-   authorizes that scope.
+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 changed while protected metadata
-   stayed intact. Report changed, unchanged, and ambiguous items separately.
+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.
 
-This skill does not define priorities, labels, milestones, clarification policy, or default scope.
-A consumer wrapper supplies the repository-specific taxonomy and permissions.
+This skill does not define priorities, labels, milestones, projects, clarification policy, or
+default scope. A consumer wrapper supplies the repository-specific taxonomy and permissions.

package/skills/planning/SKILL.md

@@ -17,7 +17,9 @@ Use before implementation work that needs a durable plan. Repository-local `AGEN
 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.
+   implementation when local policy requires one. 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.

package/skills/retrospective-distill/SKILL.md

@@ -25,6 +25,6 @@ or retention system. Public issue bodies contain only the minimum bounded facts
 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, archival command, or
-approval model. Consumer wrappers cannot weaken this export boundary; they provide only those local
-details.
+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.

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

@@ -1,6 +1,6 @@
 ---
 name: review-github-issue-taxonomy
-description: Audit GitHub labels, milestones, and path-label automation and return actionable taxonomy recommendations.
+description: Audit GitHub labels, milestones, projects, and path-label automation and return actionable taxonomy recommendations.
 ---
 
 # Review GitHub issue taxonomy
@@ -8,12 +8,17 @@ description: Audit GitHub labels, milestones, and path-label automation and retu
 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.
 
-1. Confirm repository identity and fetch live labels, descriptions, colors, usage, milestones, and
-   their current scope.
+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,
    deletion, or rule change.
 3. Audit aliases, ambiguity, unused labels, missing descriptions, color consistency, milestone
-   overlap, delivery gaps, and path-label coverage.
+   overlap, delivery gaps, and path-label coverage. Audit projects too: a milestone theme duplicated
+   across repositories is a candidate project, and a project confined to one repository is a
+   candidate milestone. 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
    needs no separate approval from the authorized issue operation.
@@ -23,6 +28,6 @@ local configuration edits or live taxonomy mutation; read local `AGENTS.md` and
    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
-consumer wrapper supplies those integrations and local mechanics.
+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.