@tanstack/intent 0.0.14 → 0.0.19

package/meta/domain-discovery/SKILL.md

@@ -76,23 +76,33 @@ These rules override any other reasoning. No exceptions.
    STOP and WAIT for their reply. Do not answer your own questions. Do
    not infer answers from documentation. Do not skip questions because
    you believe you already know the answer.
-3. **Do not convert open-ended questions into multiple-choice,
+3. **Never ask factual questions you can answer by searching the
+   codebase.** Before asking any question, determine whether the answer
+   is a deterministic fact (how many X exist, what versions are
+   supported, which files implement Y) or a judgment call (which ones
+   matter, what should we prioritize, what do developers struggle with).
+   Factual questions must be answered by searching the code — grep,
+   glob, read files. Only ask the maintainer for priorities, opinions,
+   trade-offs, and implicit knowledge that cannot be found in code or
+   docs. Asking the maintainer a question whose answer is sitting in
+   the codebase wastes their time and erodes trust in the process.
+4. **Do not convert open-ended questions into multiple-choice,
    yes/no, or confirmation prompts.** The question templates in each
    sub-section are open-ended by design. Present them as open-ended
    questions. The maintainer's unprompted answers surface knowledge that
    pre-structured options suppress.
-4. **Minimum question counts are enforced.** Each sub-section specifies
+5. **Minimum question counts are enforced.** Each sub-section specifies
    a question count range (e.g. "2–4 questions"). You must ask at least
    the minimum number. Asking zero questions in any sub-section is a
    protocol violation.
-5. **STOP gates are mandatory.** At the boundaries marked `── STOP ──`
+6. **STOP gates are mandatory.** At the boundaries marked `── STOP ──`
    below, you must halt execution and wait for the maintainer's response
    or acknowledgment before proceeding. Do not continue past a STOP gate
    in the same message.
-6. **If the maintainer asks to skip an interview phase**, explain the
+7. **If the maintainer asks to skip an interview phase**, explain the
    value of the phase and what will be lost. Proceed with skipping only
    if they confirm a second time.
-7. **Rich documentation makes interviews MORE valuable, not less.**
+8. **Rich documentation makes interviews MORE valuable, not less.**
    When docs are comprehensive, the interview surfaces what docs miss:
    implicit knowledge, AI-specific failure modes, undocumented tradeoffs,
    and the maintainer's prioritization of what matters most. Never
@@ -115,6 +125,15 @@ reading exhaustively yet.
 4. **AGENTS.md or .cursorrules** — if the library already has agent
    guidance, read it. This is high-signal for what the maintainer
    considers important
+5. **All in-repo documentation** — list every `.md` file in the `docs/`
+   directory (and any other documentation directories like `guides/`,
+   `reference/`, `wiki/`). Read every file. This is NOT the exhaustive
+   external doc reading from Phase 3 — this is reading what the
+   maintainer committed to the repository, which is fast and
+   high-signal. In-repo docs often contain migration guides, backward
+   compatibility notes, architecture decisions, and other context that
+   prevents you from asking factual questions the docs already answer.
+   Do not sample a subset — read them all before the first interview.
 
 ### 1b — Read peer dependency constraints
 
@@ -258,13 +277,57 @@ sample a subset and extrapolate.
 3. **API reference** — scan for exports, type signatures, option shapes
 4. **Changelog for major versions** — API renames, removed exports,
    behavioral changes
-5. **GitHub issues and discussions** — scan for frequently reported
-   confusion, common misunderstandings, recurring questions. Also look
-   for what users are implicitly arguing for architecturally — not just
-   "people are confused about X" but "users keep expecting X to work
-   like Y, which reveals a tension between [design force] and [design force]."
-   If no web access, check for FAQ.md, TROUBLESHOOTING.md, or docs/faq
-   as proxies.
+5. **GitHub issues and discussions** — this is one of the highest-yield
+   sources for failure modes and skill content. Docs describe intended
+   behavior; issues reveal actual behavior and real developer confusion.
+
+   **How to search.** Use `gh search issues` and `gh search prs` (or the
+   GitHub web search UI) against the library's repo. Run multiple passes:
+   - **High-engagement issues:** sort by reactions or comments to find the
+     problems that affect the most developers. These are skill-worthy
+     even if already fixed — agents trained on older data still hit them.
+   - **Label-based scans:** look for labels like `bug`, `question`,
+     `documentation`, `breaking-change`, `good first issue`, `FAQ`,
+     `help wanted`. Each label category yields different signal:
+     - `bug` + `closed` → failure modes with known fixes (wrong/correct pairs)
+     - `question` → developer confusion that skills should preempt
+     - `breaking-change` → migration-boundary mistakes
+   - **Keyword searches:** search for the skill's primary APIs, hooks,
+     and config options by name. E.g. `useQuery stale` or `hydration SSR`.
+   - **Recent vs. historical:** scan the last 6–12 months of open issues
+     for current pain points. Then scan older closed issues for patterns
+     that are now fixed but still appear in agent training data.
+
+   **GitHub Discussions** are equally important when the repo uses them.
+   Discussions surface "how do I..." patterns and architectural questions
+   that issues don't capture. Search the Discussions tab (or use
+   `gh api` to query discussions) for:
+   - Unanswered or long-thread questions (signal: docs are insufficient)
+   - Threads marked as "Answered" with a non-obvious solution (skill content)
+   - Recurring themes across multiple threads (systemic confusion)
+
+   **What to extract from issues/discussions:**
+   - Frequently reported confusion patterns → candidate failure modes
+   - Workarounds that developers use before a fix ships → "wrong pattern"
+     examples that agents will reproduce
+   - Recurring "how do I X with Y" threads → composition skill candidates
+   - Misunderstandings about defaults or config → skill content gaps
+   - Feature requests with many upvotes that change API design → signals
+     of where the API surface is unintuitive
+   - What users are implicitly arguing for architecturally — not just
+     "people are confused about X" but "users keep expecting X to work
+     like Y, which reveals a tension between [design force] and
+     [design force]"
+
+   **What NOT to extract:** one-off bugs already fixed, feature requests
+   unrelated to current API surface, issues about build tooling or CI
+   that don't affect library usage patterns.
+
+   **Fallback.** If no web access is available, check for FAQ.md,
+   TROUBLESHOOTING.md, docs/faq, or KNOWN_ISSUES.md as proxies. Also
+   scan the repo's `.github/ISSUE_TEMPLATE/` for hints about common
+   issue categories.
+
 6. **Source code** — verify ambiguities from docs, check defaults, find
    assertions and invariant checks. For monorepos, read the 2–3 core
    packages deeply. For adapter packages, read one representative adapter
@@ -289,6 +352,10 @@ Log every:
   rejects a subtype of X
 - Source assertion: any `if (!x) throw`, `invariant()`, or `assert()` with
   the error message text
+- Issue/discussion pattern: any recurring confusion, workaround, or
+  misunderstanding surfaced from GitHub issues or discussions — note the
+  issue/discussion URL, the core misunderstanding, and whether it's
+  resolved or still active
 
 ### What to extract from migration guides specifically
 
@@ -390,14 +457,16 @@ For each skill, extract failure modes that pass all three tests:
 
 **Where to find them:**
 
-| Source               | What to extract                                                    |
-| -------------------- | ------------------------------------------------------------------ |
-| Migration guides     | Every breaking change → old pattern is the wrong code              |
-| Doc callouts         | Any "note", "warning", "avoid" with surrounding context            |
-| Source assertions    | `throw` and `invariant()` messages describe the failure            |
-| Default values       | Undocumented or surprising defaults that cause wrong behavior      |
-| Type precision       | Source type more restrictive than docs imply                       |
-| Environment branches | `typeof window`, SSR flags, `NODE_ENV` — behavior differs silently |
+| Source               | What to extract                                                      |
+| -------------------- | -------------------------------------------------------------------- |
+| Migration guides     | Every breaking change → old pattern is the wrong code                |
+| Doc callouts         | Any "note", "warning", "avoid" with surrounding context              |
+| Source assertions    | `throw` and `invariant()` messages describe the failure              |
+| Default values       | Undocumented or surprising defaults that cause wrong behavior        |
+| Type precision       | Source type more restrictive than docs imply                         |
+| Environment branches | `typeof window`, SSR flags, `NODE_ENV` — behavior differs silently   |
+| GitHub issues        | Recurring bug reports with workarounds → wrong/correct code pairs    |
+| GitHub discussions   | "How do I…" threads with non-obvious answers → missing skill content |
 
 Target 3 failure modes per skill minimum. Complex skills target 5–6.
 
@@ -574,6 +643,12 @@ Adapt from this bank of gap-targeted question templates:
   What should an agent know about using them together?"
 - "The API reference shows [type signature], but the guide examples use
   a different shape. Which is accurate?"
+- "I found [N] GitHub issues/discussions where developers struggled with
+  [X]. The common workaround seems to be [Y] — is that the recommended
+  approach, or is there a better pattern that should be documented?"
+- "GitHub discussions show developers repeatedly asking how to combine
+  [feature A] with [feature B]. Is there an intended integration pattern,
+  or is this a gap in the current API?"
 
 ### 4c — AI-agent-specific failure modes (2–4 questions)
 

package/meta/feedback-collection/SKILL.md

@@ -36,7 +36,7 @@ during the session:
 
 - **Loaded and used:** Skills you read and actively followed.
 - **Available but not loaded:** Skills that were installed (discoverable via
-  `intent list`) but you never read. This is important — many issues stem from
+  `npx @tanstack/intent@latest list`) but you never read. This is important — many issues stem from
   the agent not loading the right skill, not from the skill itself being wrong.
 
 ### 1b: Gap detection
@@ -172,6 +172,25 @@ Determine the target repo from the skill's package. The repo is typically
 derivable from the `repository` field in the package's `package.json`, or
 from the `sources` field in the SKILL.md frontmatter.
 
+### Link to existing issues/discussions
+
+Before creating a new issue, search the target repo for existing issues or
+discussions that match the feedback. Use `gh search issues` or the GitHub
+web search with keywords from the "What Failed" and "Missing" sections.
+
+- If an **open issue** already describes the same problem, comment on it
+  with the feedback instead of creating a duplicate. Reference the skill
+  name and version in your comment.
+- If a **closed issue** describes a problem the skill still gets wrong
+  (regression or stale skill content), reference the closed issue in the
+  new feedback issue body: `Related to #[number] — this was fixed in the
+library but the skill still describes the old behavior.`
+- If a **discussion thread** covers the same topic, link to it in the
+  feedback issue body so maintainers can see the community context.
+
+This prevents duplicate issues and gives maintainers richer context for
+improving skills.
+
 ### Privacy check
 
 Before submitting, determine whether the user's project is public or private.

package/meta/generate-skill/SKILL.md

@@ -111,6 +111,49 @@ cannot already know:
   - Framework-specific gotchas (hydration, hook rules, provider ordering)
 - **Constraints and invariants** — ordering requirements, lifecycle rules,
   things enforced by runtime assertions
+- **Issue/discussion-sourced patterns** — real developer mistakes and
+  confusion surfaced from GitHub issues and discussions (see below)
+
+### 2b — Scan GitHub issues and discussions
+
+Before writing the skill body, search the library's GitHub repo for issues
+and discussions relevant to THIS skill's topic. This step is important for
+both initial generation and regeneration — community feedback reveals
+failure modes that docs miss.
+
+**Search strategy:**
+
+1. Search issues for the skill's primary APIs, hooks, and config options
+   by name (e.g. `useQuery invalidation`, `createRouter middleware`)
+2. Filter to high-signal threads: sort by reactions/comments, focus on
+   closed bugs with workarounds and open questions with long threads
+3. Search Discussions (if the repo uses them) for "how do I…" threads
+   related to the skill's topic
+4. Check for issues labeled `bug`, `question`, `breaking-change` that
+   mention concepts this skill covers
+
+**What to incorporate:**
+
+- **Recurring bug workarounds** → add as Common Mistakes entries with
+  wrong/correct code pairs. Cite the issue URL in the `Source` field.
+- **Frequently asked questions** → if the answer is non-obvious, add it
+  to Core Patterns or as a dedicated pattern section
+- **Misunderstandings about defaults** → add to Common Mistakes with the
+  incorrect assumption as the "wrong" pattern
+- **Resolved issues that changed behavior** → if the old behavior is
+  still in agent training data, add as a migration-boundary mistake
+
+**What NOT to incorporate:**
+
+- One-off bugs already fixed with no broader pattern
+- Feature requests for APIs that don't exist yet
+- Issues about tooling, CI, or build that don't affect library usage
+- Stale threads (>2 years old) about behavior that has fundamentally changed
+
+**Fallback:** If no web access is available, check for FAQ.md,
+TROUBLESHOOTING.md, or docs/faq in the repo. Also check whether the
+domain_map.yaml already contains issue-sourced failure modes from
+domain-discovery — use those directly.
 
 ### What NOT to extract
 
@@ -353,12 +396,20 @@ output in this order:
 When regenerating a stale skill (triggered by skill-staleness-check):
 
 1. Read the existing SKILL.md and the source diff that triggered staleness
-2. Determine which sections are affected by the change
-3. Update only affected sections — preserve all other content
-4. If a breaking change occurred, add the old pattern as a new Common
+2. Scan GitHub issues and discussions opened since the skill was last
+   generated (use `library_version` or file timestamps as the baseline).
+   Look for new failure modes, resolved confusion, or changed patterns
+   related to this skill's topic. Apply the same search strategy from
+   Step 2b but scoped to the time window since last generation.
+3. Determine which sections are affected by the source change AND by
+   any new issue/discussion findings
+4. Update only affected sections — preserve all other content
+5. If a breaking change occurred, add the old pattern as a new Common
    Mistake entry (wrong/correct pair)
-5. Bump `library_version` in frontmatter
-6. Validate the complete file against Step 5 checks
+6. If issues/discussions reveal new failure modes not in the existing
+   skill, add them to Common Mistakes with issue URLs as sources
+7. Bump `library_version` in frontmatter
+8. Validate the complete file against Step 5 checks
 
 Do not rewrite the entire skill for a minor source change. Surgical
 updates preserve review effort and reduce diff noise.

package/meta/templates/workflows/check-skills.yml

@@ -7,7 +7,7 @@
 # Triggers: new release published, or manual workflow_dispatch.
 #
 # Template variables (replaced by `intent setup`):
-#   {{PACKAGE_NAME}}  — e.g. @tanstack/query
+#   {{PACKAGE_LABEL}} — e.g. @tanstack/query or my-workspace workspace
 
 name: Check Skills
 
@@ -36,12 +36,12 @@ jobs:
           node-version: 20
 
       - name: Install intent
-        run: npm install {{PACKAGE_NAME}}
+        run: npm install -g @tanstack/intent
 
       - name: Check staleness
         id: stale
         run: |
-          OUTPUT=$(npx @tanstack/intent stale --json 2>&1) || true
+          OUTPUT=$(intent stale --json 2>&1) || true
           echo "$OUTPUT"
 
           # Check if any skills need review
@@ -81,7 +81,7 @@ jobs:
             const summary = lines.join('\n');
 
             const prompt = [
-              'Review and update the following stale intent skills for {{PACKAGE_NAME}}:',
+              'Review and update the following stale intent skills for {{PACKAGE_LABEL}}:',
               '',
               ...stale.map(s => '- ' + s.skill + ': ' + s.reasons.join(', ')),
               '',

package/meta/templates/workflows/{notify-playbooks.yml → notify-intent.yml}

@@ -9,9 +9,9 @@
 #     as the INTENT_NOTIFY_TOKEN repository secret.
 #
 # Template variables (replaced by `intent setup`):
-#   {{PACKAGE_NAME}}  — e.g. @tanstack/query
-#   {{DOCS_PATH}}     — e.g. docs/**
-#   {{SRC_PATH}}      — e.g. packages/query-core/src/**
+#   {{PAYLOAD_PACKAGE}} — e.g. @tanstack/query or my-workspace workspace
+#   {{DOCS_PATH}}       — e.g. docs/**
+#   {{SRC_PATH}}        — e.g. packages/query-core/src/**
 
 name: Notify Intent
 
@@ -46,7 +46,7 @@ jobs:
           event-type: skill-check
           client-payload: |
             {
-              "package": "{{PACKAGE_NAME}}",
+              "package": "{{PAYLOAD_PACKAGE}}",
               "sha": "${{ github.sha }}",
               "changed_files": ${{ steps.changes.outputs.files }}
             }

package/meta/tree-generator/SKILL.md

@@ -40,7 +40,7 @@ Every skill has a `type` field in its frontmatter. Valid types:
 | `composition` | Integration between two or more libraries                  | `electric-drizzle`        |
 | `security`    | Audit checklist or security validation                     | `electric-security-check` |
 
-Agents discover skills via `tanstack intent list` and read them directly
+Agents discover skills via `npx @tanstack/intent list` and read them directly
 from `node_modules`. Framework skills declare a `requires` dependency on
 their core skill so agents load them in the right order.
 
@@ -274,7 +274,7 @@ packages/
 │   └── package.json             # Add "skills" to files array
 ```
 
-Run `intent edit-package-json` to wire each package's `package.json`
+Run `npx @tanstack/intent@latest edit-package-json` to wire each package's `package.json`
 automatically (adds `"skills"`, `"bin"`, and `"!skills/_artifacts"` to the
 `files` array, and adds the `bin` entry if missing).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tanstack/intent",
-  "version": "0.0.14",
+  "version": "0.0.19",
   "description": "Ship compositional knowledge for AI coding agents alongside your npm packages",
   "license": "MIT",
   "type": "module",
@@ -14,7 +14,8 @@
       "types": "./dist/index.d.mts"
     },
     "./intent-library": {
-      "import": "./dist/intent-library.mjs"
+      "import": "./dist/intent-library.mjs",
+      "types": "./dist/intent-library.d.mts"
     }
   },
   "bin": {
@@ -32,7 +33,7 @@
     "tsdown": "^0.19.0"
   },
   "scripts": {
-    "prepack": "pnpm run build",
+    "prepack": "npm run build",
     "build": "tsdown src/index.ts src/cli.ts src/setup.ts src/intent-library.ts src/library-scanner.ts --format esm --dts",
     "test:lib": "vitest run",
     "test:types": "tsc --noEmit"

package/dist/scanner-CECGXgox.mjs

@@ -1,4 +0,0 @@
-import "./utils-CDJzAdjD.mjs";
-import { t as scanForIntents } from "./scanner-CY40iozO.mjs";
-
-export { scanForIntents };

package/dist/scanner-CY40iozO.mjs

@@ -1,218 +0,0 @@
-import { i as resolveDepDir, n as getDeps, r as parseFrontmatter } from "./utils-CDJzAdjD.mjs";
-import { existsSync, readFileSync, readdirSync } from "node:fs";
-import { join, relative, sep } from "node:path";
-
-//#region src/scanner.ts
-function detectPackageManager(root) {
-	if (existsSync(join(root, ".pnp.cjs")) || existsSync(join(root, ".pnp.js"))) throw new Error("Yarn PnP is not yet supported. Add `nodeLinker: node-modules` to your .yarnrc.yml to use intent.");
-	if (existsSync(join(root, "deno.json")) && !existsSync(join(root, "node_modules"))) throw new Error("Deno without node_modules is not yet supported. Add `\"nodeModulesDir\": \"auto\"` to your deno.json to use intent.");
-	if (existsSync(join(root, "pnpm-lock.yaml"))) return "pnpm";
-	if (existsSync(join(root, "bun.lockb")) || existsSync(join(root, "bun.lock"))) return "bun";
-	if (existsSync(join(root, "yarn.lock"))) return "yarn";
-	if (existsSync(join(root, "package-lock.json"))) return "npm";
-	return "unknown";
-}
-function validateIntentField(_pkgName, intent) {
-	if (!intent || typeof intent !== "object") return null;
-	const pb = intent;
-	if (pb.version !== 1) return null;
-	if (typeof pb.repo !== "string" || !pb.repo) return null;
-	if (typeof pb.docs !== "string" || !pb.docs) return null;
-	const requires = Array.isArray(pb.requires) ? pb.requires.filter((r) => typeof r === "string") : void 0;
-	return {
-		version: 1,
-		repo: pb.repo,
-		docs: pb.docs,
-		requires
-	};
-}
-/**
-* Derive an IntentConfig from standard package.json fields when no explicit
-* `intent` field is present. A package with a `skills/` directory signals
-* intent support; `repo` and `docs` are derived from `repository` and
-* `homepage`.
-*/
-function deriveIntentConfig(pkgJson) {
-	let repo = null;
-	if (typeof pkgJson.repository === "string") repo = pkgJson.repository;
-	else if (pkgJson.repository && typeof pkgJson.repository === "object" && typeof pkgJson.repository.url === "string") {
-		repo = pkgJson.repository.url;
-		repo = repo.replace(/^git\+/, "").replace(/\.git$/, "").replace(/^https?:\/\/github\.com\//, "");
-	}
-	const docs = typeof pkgJson.homepage === "string" ? pkgJson.homepage : void 0;
-	if (!repo) return null;
-	const intentPartial = pkgJson.intent;
-	const requires = intentPartial && Array.isArray(intentPartial.requires) ? intentPartial.requires.filter((r) => typeof r === "string") : void 0;
-	return {
-		version: 1,
-		repo,
-		docs: docs ?? "",
-		requires
-	};
-}
-function discoverSkills(skillsDir, _baseName) {
-	const skills = [];
-	function walk(dir) {
-		let entries;
-		try {
-			entries = readdirSync(dir, {
-				withFileTypes: true,
-				encoding: "utf8"
-			});
-		} catch {
-			return;
-		}
-		for (const entry of entries) {
-			if (!entry.isDirectory()) continue;
-			const childDir = join(dir, entry.name);
-			const skillFile = join(childDir, "SKILL.md");
-			if (existsSync(skillFile)) {
-				const fm = parseFrontmatter(skillFile);
-				const relName = relative(skillsDir, childDir).split(sep).join("/");
-				const desc = typeof fm?.description === "string" ? fm.description.replace(/\s+/g, " ").trim() : "";
-				skills.push({
-					name: typeof fm?.name === "string" ? fm.name : relName,
-					path: skillFile,
-					description: desc,
-					type: typeof fm?.type === "string" ? fm.type : void 0,
-					framework: typeof fm?.framework === "string" ? fm.framework : void 0
-				});
-				walk(childDir);
-			}
-		}
-	}
-	walk(skillsDir);
-	return skills;
-}
-function topoSort(packages) {
-	const byName = new Map(packages.map((p) => [p.name, p]));
-	const visited = /* @__PURE__ */ new Set();
-	const sorted = [];
-	function visit(name) {
-		if (visited.has(name)) return;
-		visited.add(name);
-		const pkg = byName.get(name);
-		if (!pkg) return;
-		for (const dep of pkg.intent.requires ?? []) visit(dep);
-		sorted.push(pkg);
-	}
-	for (const pkg of packages) visit(pkg.name);
-	return sorted;
-}
-async function scanForIntents(root) {
-	const projectRoot = root ?? process.cwd();
-	const packageManager = detectPackageManager(projectRoot);
-	const nodeModulesDir = join(projectRoot, "node_modules");
-	const packages = [];
-	const warnings = [];
-	if (!existsSync(nodeModulesDir)) return {
-		packageManager,
-		packages,
-		warnings
-	};
-	const packageDirs = [];
-	let topEntries;
-	try {
-		topEntries = readdirSync(nodeModulesDir, {
-			withFileTypes: true,
-			encoding: "utf8"
-		});
-	} catch {
-		return {
-			packageManager,
-			packages,
-			warnings
-		};
-	}
-	for (const entry of topEntries) {
-		if (!entry.isDirectory() && !entry.isSymbolicLink()) continue;
-		const dirPath = join(nodeModulesDir, entry.name);
-		if (entry.name.startsWith("@")) {
-			let scopedEntries;
-			try {
-				scopedEntries = readdirSync(dirPath, {
-					withFileTypes: true,
-					encoding: "utf8"
-				});
-			} catch {
-				continue;
-			}
-			for (const scoped of scopedEntries) {
-				if (!scoped.isDirectory() && !scoped.isSymbolicLink()) continue;
-				packageDirs.push({ dirPath: join(dirPath, scoped.name) });
-			}
-		} else if (!entry.name.startsWith(".")) packageDirs.push({ dirPath });
-	}
-	const foundNames = /* @__PURE__ */ new Set();
-	/**
-	* Try to register a package with a skills/ directory. Reads its
-	* package.json, validates intent config, discovers skills, and pushes
-	* to `packages`. Returns true if the package was registered.
-	*/
-	function tryRegister(dirPath, fallbackName) {
-		const skillsDir = join(dirPath, "skills");
-		if (!existsSync(skillsDir)) return false;
-		let pkgJson;
-		try {
-			pkgJson = JSON.parse(readFileSync(join(dirPath, "package.json"), "utf8"));
-		} catch {
-			warnings.push(`Could not read package.json for ${dirPath}`);
-			return false;
-		}
-		const name = typeof pkgJson.name === "string" ? pkgJson.name : fallbackName;
-		if (foundNames.has(name)) return false;
-		const intent = validateIntentField(name, pkgJson.intent) ?? deriveIntentConfig(pkgJson);
-		if (!intent) {
-			warnings.push(`${name} has a skills/ directory but could not determine repo/docs from package.json (add a "repository" field or explicit "intent" config)`);
-			return false;
-		}
-		packages.push({
-			name,
-			version: typeof pkgJson.version === "string" ? pkgJson.version : "0.0.0",
-			intent,
-			skills: discoverSkills(skillsDir, name)
-		});
-		foundNames.add(name);
-		return true;
-	}
-	for (const { dirPath } of packageDirs) tryRegister(dirPath, "unknown");
-	const walkVisited = /* @__PURE__ */ new Set();
-	function walkDeps(pkgDir, pkgName) {
-		if (walkVisited.has(pkgName)) return;
-		walkVisited.add(pkgName);
-		let pkgJson;
-		try {
-			pkgJson = JSON.parse(readFileSync(join(pkgDir, "package.json"), "utf8"));
-		} catch {
-			warnings.push(`Could not read package.json for ${pkgName} (skipping dependency walk)`);
-			return;
-		}
-		for (const depName of getDeps(pkgJson)) {
-			if (foundNames.has(depName) || walkVisited.has(depName)) continue;
-			const depDir = resolveDepDir(depName, pkgDir, pkgName, nodeModulesDir);
-			if (!depDir) continue;
-			tryRegister(depDir, depName);
-			walkDeps(depDir, depName);
-		}
-	}
-	for (const pkg of [...packages]) walkDeps(join(nodeModulesDir, pkg.name), pkg.name);
-	let projectPkg = null;
-	try {
-		projectPkg = JSON.parse(readFileSync(join(projectRoot, "package.json"), "utf8"));
-	} catch (err) {
-		if (!(err && typeof err === "object" && "code" in err && err.code === "ENOENT")) warnings.push(`Could not read project package.json: ${err instanceof Error ? err.message : String(err)}`);
-	}
-	if (projectPkg) for (const depName of getDeps(projectPkg, true)) {
-		if (walkVisited.has(depName)) continue;
-		const depDir = join(nodeModulesDir, depName);
-		if (existsSync(join(depDir, "package.json"))) walkDeps(depDir, depName);
-	}
-	return {
-		packageManager,
-		packages: topoSort(packages),
-		warnings
-	};
-}
-
-//#endregion
-export { scanForIntents as t };

package/dist/setup-CANkTz55.d.mts

@@ -1,18 +0,0 @@
-//#region src/setup.d.ts
-interface AddLibraryBinResult {
-  shim: string | null;
-  skipped: string | null;
-}
-interface EditPackageJsonResult {
-  added: string[];
-  alreadyPresent: string[];
-}
-interface SetupGithubActionsResult {
-  workflows: string[];
-  skipped: string[];
-}
-declare function runAddLibraryBin(root: string): AddLibraryBinResult;
-declare function runEditPackageJson(root: string): EditPackageJsonResult;
-declare function runSetupGithubActions(root: string, metaDir: string): SetupGithubActionsResult;
-//#endregion
-export { runEditPackageJson as a, runAddLibraryBin as i, EditPackageJsonResult as n, runSetupGithubActions as o, SetupGithubActionsResult as r, AddLibraryBinResult as t };