voidmachine 0.0.0 → 4.0.0

package/core-assets/packs/pack-monorepo/skills/void-dependency-direction/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: void-dependency-direction
+description: Enforce the @repo/* import direction in a Turborepo workspace. Concrete violations + fixes. Composes with core:hexagonal-architecture and the boundary-direction-check hook.
+---
+
+# dependency-direction
+
+Use when adding an `import` statement that crosses a package boundary, or when fixing a `boundary-direction-check` hook violation. This skill is the **operational guide** for the rules core `void-hexagonal-architecture` and `boundary-direction-check` enforce mechanically.
+
+## The rule
+
+```
+@repo/core    →   nothing internal
+@repo/auth    →   @repo/core
+@repo/db      →   @repo/core
+@repo/ui      →   @repo/core
+@repo/<feat>  →   @repo/core   (and only @repo/core)
+apps/<app>    →   any @repo/*
+```
+
+**No `@repo/*` package imports another `@repo/*` except `@repo/core`.** All composition happens at the app level. If `@repo/billing` needs the user, it defines a port; the consuming app wires `@repo/auth`'s adapter into that port.
+
+This sounds restrictive. It is. It is what keeps the monorepo from collapsing into a hairball.
+
+## Why core is the only allowed dependency
+
+`@repo/core` ships **primitives** with no internal deps:
+
+- `logger` (pino)
+- `env` (Zod-validated env)
+- `errors` (typed error classes)
+- `Result`, `Option`, `pipe` (functional utilities)
+
+These are leaf utilities. Everything else is composition.
+
+## Common violation: `@repo/billing` wants the user
+
+**Wrong**:
+```ts
+// packages/billing/src/billing.service.ts
+import { db } from '@repo/db';                  // ✗
+import { getCurrentUser } from '@repo/auth';    // ✗
+
+export async function cancelSubscription() {
+  const user = await getCurrentUser();
+  await db.update(subscriptions)...
+}
+```
+
+**Right** — define the port in `@repo/billing`, wire the adapter in the app:
+
+```ts
+// packages/billing/src/billing.types.ts (port)
+export interface BillingPorts {
+  readonly userRepo: { findById(id: string): Promise<User | null> };
+  readonly subscriptionRepo: { update(id: string, p: Partial<Sub>): Promise<void> };
+}
+
+// packages/billing/src/billing.service.ts (pure)
+export function makeBillingService(ports: BillingPorts) {
+  return {
+    async cancelSubscription(userId: string) {
+      const user = await ports.userRepo.findById(userId);
+      // ... domain logic only
+    },
+  };
+}
+
+// apps/web/src/adapters/billing.ts (composition)
+import { makeBillingService } from '@repo/billing';
+import { db } from '@repo/db';
+import { userRepo, subRepo } from '@/repositories';
+export const billing = makeBillingService({ userRepo, subscriptionRepo: subRepo });
+```
+
+The app is the integration point. Packages are pure capabilities.
+
+## Common violation: types from another package
+
+**Wrong**:
+```ts
+// packages/billing/src/billing.types.ts
+import type { User } from '@repo/auth';  // ✗ types still create coupling
+```
+
+**Right** — declare your own User type narrowed to what billing needs:
+
+```ts
+// packages/billing/src/billing.types.ts
+export interface BillingUser {
+  readonly id: string;
+  readonly email: string;
+  readonly orgId: string;
+}
+```
+
+If `@repo/auth`'s `User` and `@repo/billing`'s `BillingUser` should be the same shape, factor the shape into `@repo/core/types`. But almost always, each package wants a narrower projection — that's good.
+
+## Common violation: `@repo/ui` calls a service
+
+**Wrong**:
+```tsx
+// packages/ui/src/UserAvatar.tsx
+import { getCurrentUser } from '@repo/auth';   // ✗
+export function UserAvatar() {
+  const user = use(getCurrentUser());          // ✗ side effect in UI
+  return <Avatar src={user.avatarUrl} />;
+}
+```
+
+**Right**:
+```tsx
+// packages/ui/src/Avatar.tsx (dumb prop-driven)
+export function Avatar({ src, fallback }: { src: string; fallback: string }) {
+  return <img src={src} alt={fallback} />;
+}
+
+// apps/web/src/components/CurrentUserAvatar.tsx (binding, NOT in @repo/ui)
+import { Avatar } from '@repo/ui';
+import { useCurrentUser } from '@/hooks';
+export function CurrentUserAvatar() {
+  const user = useCurrentUser();
+  return <Avatar src={user.avatarUrl} fallback={user.name} />;
+}
+```
+
+`@repo/ui` exports primitives with no I/O. Bindings to actual data live in apps.
+
+## The `apps/<app>` → `apps/<other-app>` rule
+
+**Never** import from another app:
+
+```ts
+// apps/web/src/foo.ts
+import { whatever } from '../../mobile/src/...';  // ✗ — even via @repo/* alias if you set it up
+```
+
+If two apps need the same code, that code goes in a `@repo/*` package. There is no "shared/" directory between apps.
+
+## When you genuinely need cross-package access
+
+You don't. Re-read the section on ports. If after that you still think you do, write an ADR (`void-decide`) documenting the exception with the reversal cost. 90% of "I need this" turns out to be "I forgot to define the port".
+
+## Mechanical enforcement
+
+The `boundary-direction-check` hook (core) blocks Edit/Write that introduces a forbidden import. Override by tagging the import line `// allow-boundary: <reason>` — but think hard first, because each exception is a small future grind.
+
+## Workflow
+
+1. **Before adding the import**, ask: does this cross a `@repo/*` boundary?
+2. **If yes**, ask: is the destination `@repo/core`? OK. Anything else? Stop.
+3. **Define a port** in your package, wire the adapter in the app.
+4. **If the hook complains**, do not tag-and-move-on. Refactor.
+
+## Composition
+
+- `void-hexagonal-architecture` — doctrine on ports + adapters direction (core).
+- `boundary-direction-check` hook (core) — mechanical gate.
+- `void-package-extraction` — most boundary problems come from premature extraction.
+- `void-service-package` — the 5+5 layout includes a `<name>.types.ts` precisely for owning your own types.

package/core-assets/packs/pack-monorepo/skills/void-dependency-direction/harness.yaml

@@ -0,0 +1,14 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: standard
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: active
+    codex: active
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/packs/pack-monorepo/skills/void-package-extraction/.source

@@ -0,0 +1,5 @@
+Sources for `void-package-extraction` skill (see `docs/plans/skill-audits/void-package-extraction.md` for the full audit):
+
+- No external source. Native 3-question decision gate for the monorepo-specific "should this be extracted into a package?" trade-off.
+
+Strategy: native. The gate is monorepo-specific; single-app code reorganization has no equivalent boundary cost, so nothing external was adapted.

package/core-assets/packs/pack-monorepo/skills/void-package-extraction/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: void-package-extraction
+description: Decide whether code in apps/<app>/ should be extracted into a new packages/<name>/ workspace. Most extractions are premature; this skill is the decision gate.
+---
+
+# package-extraction
+
+Use when you are tempted to move code out of `apps/<app>/src/` into a new `packages/<name>/`. The instinct is good — sharing is virtuous — but **80% of extractions are premature** and end up creating coupling without the reuse benefit.
+
+This skill is the gate. Composes with `void-service-package` (which is the creation workflow once you've decided yes).
+
+## When this skill triggers
+
+- "Let's extract this into a package so both apps can use it"
+- "This helper is generic, it shouldn't live in apps/"
+- "We're duplicating this in apps/web and apps/mobile"
+- Any review comment "extract to packages/"
+
+## The 3-question gate
+
+Extract if and only if **all three** answers are yes:
+
+1. **Are there ≥ 2 distinct consumers RIGHT NOW** (not "maybe later")? Distinct = different `apps/<name>/` packages.
+2. **Would inlining the code in both apps cost > 30 minutes of duplication discipline per change**? If a 5-line helper diverges, the answer is no.
+3. **Does the code own a CONCEPT, not just a function?** "billing engine" yes. "string utilities" no — those are scattered helpers, not a package.
+
+If you can't say yes to all three, **inline the code in each app instead**. Duplication is cheaper than the wrong boundary.
+
+## When NOT to extract
+
+- ✗ Code used in only one app, "in case we need it later" — YAGNI, extract when the second consumer appears
+- ✗ Helpers that wrap a single library function (`isValidEmail(s) { return z.string().email().safeParse(s).success }`) — copy 3 lines, don't add a package
+- ✗ React components used in only one app — they belong in `apps/<app>/src/components/`
+- ✗ Server logic specific to one app's route handlers — even if "feels generic", lives where it's used
+- ✗ Types only — types live next to their use; if shared, in `@repo/api-types` (one package for the contracts, not one per concept)
+
+## When YES to extract
+
+- ✓ Auth logic consumed by web + mobile + worker
+- ✓ A complete domain service (billing, scheduling, notifications) with own ports + adapters
+- ✓ UI primitives consumed by web + mobile (Tappable, tokens) — that is `@repo/ui`
+- ✓ A data model with its repository, shared by HTTP handlers and a background job
+
+## Cost of premature extraction
+
+- **Boundary thrashing**: API of the new package changes weekly because nobody knows what it should expose. PRs touching the package + every consumer.
+- **Wrong abstraction**: extracted too early, before the second consumer's needs were clear. The package overfits the first consumer; the second has to fight it.
+- **Import-direction violations**: the package starts importing from where it shouldn't (`@repo/db` from `@repo/billing`) because the boundary wasn't thought through.
+- **Build complexity**: another tsconfig, another package.json, another dist target.
+
+The cheap fix is to NOT extract until forced.
+
+## Workflow
+
+1. **Inline the duplication first.** Write the code in both apps. Live with it for one full feature cycle.
+2. **Observe drift.** Are the two copies diverging? If yes, they were never the same concept — keep them separate. If they stay identical, you have a real case for extraction.
+3. **Name the boundary in one sentence.** "This package owns <X>, exposes <Y>, is consumed by <Z>." If you can't, you're not ready.
+4. **Run `void-service-package`** to create it properly (5+5 layout, port direction).
+5. **Open a PR with ADR.** Extraction is structural; document via `void-decide`.
+
+## Reverse: when to UN-extract
+
+A package with one consumer for 6+ months should be inlined back. The boundary was a guess; reality says no. Reverse-extraction is a valid PR ("merge @repo/billing back into apps/web/src/services/billing").
+
+## Composition
+
+- `void-service-package` — the creation workflow (use this skill to decide, that one to create).
+- `void-decide` — extractions are ADR-worthy.
+- `void-dependency-direction` — extracted packages must respect `@repo/*` import direction.
+- `void-hexagonal-architecture` — extracted packages own ports; adapters live in consumer apps.

package/core-assets/packs/pack-monorepo/skills/void-package-extraction/harness.yaml

@@ -0,0 +1,14 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: standard
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: active
+    codex: active
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/packs/pack-monorepo/skills/void-service-package/.source

@@ -0,0 +1,5 @@
+Sources for `void-service-package` skill (see `docs/plans/skill-audits/void-service-package.md` for the full audit):
+
+- No external source. Native distillation of the `01-monorepo-layout.md` module (which describes the 5+5 topology) into a step-by-step package-creation workflow.
+
+Strategy: native. The module says "this is how packages look"; the skill says "here is exactly what to do to create one". Composes with hexagonal-architecture, DDD, and functional.

package/core-assets/packs/pack-monorepo/skills/void-service-package/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: void-service-package
+description: "Create or extend a packages/<name>/ service in a harness-monorepo workspace: the 5+5 file layout, @repo/* boundaries, ports-and-adapters direction. Composes with hexagonal-architecture, DDD."
+---
+
+# service-package
+
+Use when adding a new `packages/<name>/` package to a Turborepo workspace that follows the void-machine `pack-monorepo` conventions, or when extending an existing one. The pack module document defines the topology (see `claude/modules/01-monorepo-layout.md`); this skill is the **execution checklist** for creating one.
+
+If you are working in `apps/<app>/` business code, this skill does not apply — that is internal application code, not a shared package.
+
+## When this skill triggers
+
+- "Add a `@repo/billing` package" / "extract billing into its own package"
+- "Create a new shared service for X"
+- "Move logic from apps/web into a package so apps/api can use it too"
+- Any creation of a new directory under `packages/` at the top level
+
+## The 5+5 layout (mandatory)
+
+```
+packages/<name>/
+├── package.json
+├── tsconfig.json                            # extends ../../tsconfig.strict.json
+├── src/
+│   ├── <name>.service.ts                    # domain logic
+│   ├── <name>.repository.ts                 # I/O (DB, HTTP, queue)
+│   ├── <name>.helper.ts                     # pure functions
+│   ├── <name>.types.ts                      # Zod schemas + inferred TS types
+│   ├── index.ts                             # public barrel
+│   ├── <name>.service.test.ts
+│   ├── <name>.repository.test.ts
+│   ├── <name>.helper.test.ts
+│   ├── <name>.types.test.ts
+│   └── index.test.ts                        # contract tests on the barrel
+```
+
+The "5+5" is **five source files + five test files**, paired one-to-one. No `utils/`, no `lib/`, no `common/`. A file does one thing.
+
+## Direction of dependencies
+
+```
+service ─→ repository (port)   service ─→ helper   service ─→ types
+              ↑
+        adapter (in apps/<app>/src/adapters/<name>/)
+```
+
+- `service.ts` defines the **interface** the repository must satisfy (the port).
+- The concrete adapter lives in the **consuming app**, under `apps/<app>/src/adapters/`, not in this package.
+- `repository.ts` in this package may hold a default/in-memory implementation for tests, but the prod adapter is wired by the app.
+- `helper.ts` is pure. No I/O. No `Date.now()`. Take time as a parameter.
+
+If your package needs `@repo/db` directly: stop. Move the DB-touching code into an adapter in the consuming app. The package owns the **port**, not the adapter.
+
+## Allowed imports (enforced by `boundary-direction-check`)
+
+| This package | May import |
+|---|---|
+| `@repo/<name>` | `@repo/core` (logger, env, errors, Result/Option/pipe). Nothing else `@repo/*`. |
+
+If you find yourself needing to import another `@repo/*`, you are blurring layers. Two valid fixes:
+- Move the shared concept into `@repo/core`
+- Reshape the boundary so the consumer composes the two packages explicitly
+
+## `package.json` template
+
+```json
+{
+  "name": "@repo/<name>",
+  "version": "0.0.0",
+  "private": true,
+  "type": "module",
+  "exports": {
+    ".": {
+      "types": "./src/index.ts",
+      "default": "./src/index.ts"
+    }
+  },
+  "dependencies": {
+    "@repo/core": "workspace:*",
+    "zod": "catalog:"
+  },
+  "devDependencies": {
+    "tsconfig": "workspace:*",
+    "vitest": "catalog:"
+  },
+  "scripts": {
+    "test": "vitest run",
+    "typecheck": "tsc --noEmit"
+  }
+}
+```
+
+`exports` points at `src/index.ts` directly — Turborepo + tsup compile at the app boundary, packages stay as TS source for fast iteration.
+
+## Workflow
+
+1. **Confirm the boundary first.** Before any file, write one line in the PR description: *"This package owns X, exposes Y, and is consumed by Z."* If you cannot, the package is premature.
+2. **Create the directory + `package.json` + `tsconfig.json`** (extends `../../tsconfig.strict.json`).
+3. **Write the types file first** (`<name>.types.ts`): Zod schemas + inferred types. Tests assert that invalid payloads parse to errors.
+4. **Write the service.test.ts** describing the public behavior, then `service.ts` to make it pass (TDD strict, see `void-tdd`).
+5. **Write the helper + helper.test.ts** as pure-function tests (table-driven).
+6. **Write the repository port** (`repository.ts`): just the interface and a default in-memory implementation. Real DB adapter lives in the consuming app.
+7. **Export from `index.ts`** only what consumers must touch. No re-exports of internal helpers.
+8. **Add to `tsconfig.base.json` paths** if your monorepo uses TS path aliases (most do).
+9. **Run `bunx turbo run typecheck test --filter @repo/<name>`** before commit.
+
+## Anti-patterns
+
+- ✗ A `utils/` or `common/` directory — split into helpers per concern instead.
+- ✗ A `<name>.types.ts` that's only TypeScript types with no Zod schema — at boundaries you need runtime validation. Internal-only types live next to their use.
+- ✗ Importing the concrete DB into `service.ts` — wire the adapter in the app.
+- ✗ Re-exporting an entire submodule from `index.ts` (`export * from './internal'`) — list explicit names so the public surface is auditable.
+- ✗ Adding a sixth source file because "it doesn't fit anywhere" — that's a code smell. Either the boundary is wrong (split the package) or the file collapses into an existing one.
+
+## Composition
+
+- `void-hexagonal-architecture` — port direction enforced. Service defines port; adapter is in app, not package.
+- `void-domain-driven-design` — name the package per aggregate or capability, not per technical concern.
+- `void-functional` — `helper.ts` is pure; pass time, randomness, and side effects as parameters.
+- `void-tdd` — strict on `service.ts` and `helper.ts`; souple on `repository.ts` if it only forwards.
+- `void-typescript-strict` — `tsconfig.strict.json` is mandatory; no `any`, no `as` casts in committed code.

package/core-assets/packs/pack-monorepo/skills/void-service-package/harness.yaml

@@ -0,0 +1,14 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: standard
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: active
+    codex: active
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/packs/pack-monorepo/skills/void-turbo-pipeline-tuning/.source

@@ -0,0 +1,7 @@
+Sources for `void-turbo-pipeline-tuning` skill (see `docs/plans/skill-audits/void-turbo-pipeline-tuning.md` for the full audit):
+
+- Turborepo docs — official guidance on dependsOn, outputs, and cache keys
+- Vercel best-practices guide — remote-cache and pipeline tuning recommendations
+- Repeated stumbles on real monorepos — the "bug -> cause -> fix" table for the 5 most common pipeline failures
+
+Strategy: distill. Condenses Turborepo and Vercel guidance plus real-world failure patterns into a focused tuning skill, including when to leave defaults alone.

package/core-assets/packs/pack-monorepo/skills/void-turbo-pipeline-tuning/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: void-turbo-pipeline-tuning
+description: Configure turbo.json tasks correctly — dependsOn, outputs, cache keys, persistent tasks, remote cache. Get build speed right without over-engineering.
+---
+
+# turbo-pipeline-tuning
+
+Use when adding or modifying tasks in `turbo.json`, or when the monorepo's CI/local build feels slow. Turborepo's value is incremental caching; getting `dependsOn`, `outputs`, and cache keys right is the difference between "build in 4s" and "build in 90s".
+
+If you don't have `turbo.json` (single-app), this skill does not apply.
+
+## The 4 fields that matter
+
+```json
+{
+  "tasks": {
+    "build": {
+      "dependsOn": ["^build"],          // 1. order
+      "outputs": ["dist/**", ".next/**"],// 2. cache artifacts
+      "inputs": ["src/**", "tsconfig.json"], // 3. cache key (optional, smart default exists)
+      "cache": true                     // 4. on/off
+    }
+  }
+}
+```
+
+90% of pipeline bugs come from getting one of these wrong.
+
+## `dependsOn` cheatsheet
+
+- `^build` — depends on `build` of upstream workspace packages (the package's own deps)
+- `build` — depends on `build` of the SAME package (rare; usually you want `^build`)
+- `lint` — depends on `lint` of the SAME package
+- `^lint` — depends on `lint` of upstream (rare; lint usually doesn't depend on others)
+- `db:generate` — explicit task name in another package
+
+The mental model: `^X` = wait for X in workspace deps. Bare `X` = wait for X in this package.
+
+## `outputs` — get this right or kill cache
+
+If a task writes files Turborepo doesn't know about, the cache is **wrong** (next run reads stale outputs). Common misses:
+
+- ✗ `tsc --noEmit` writes nothing → `"outputs": []` (empty array, NOT omitted)
+- ✓ `next build` → `"outputs": [".next/**", "!.next/cache/**"]`
+- ✓ `tsup build` → `"outputs": ["dist/**"]`
+- ✓ `drizzle-kit generate` → `"outputs": ["drizzle/**", "src/**/__generated__/**"]`
+- ✗ Forgetting to list `dist/` → next consumer fails to import the freshly-built code
+
+When a task has NO outputs (typecheck, lint, test), explicitly `"outputs": []`. Otherwise Turbo assumes "everything" and bloats the cache.
+
+## `inputs` — most of the time, leave it alone
+
+Default is "all files in the package not in `.gitignore`". That's almost always right. Override only when:
+
+- A task reads files outside the package (rare, fragile) → list them explicitly
+- A task should NOT invalidate on certain file changes (e.g., README.md, *.md) → `"inputs": ["src/**", "package.json", "tsconfig.json"]` to scope
+
+Over-restricting `inputs` is the #1 source of "the cache lied to me" bugs. When in doubt, omit.
+
+## `cache: false` — when
+
+- Tasks with non-deterministic output (deploy, publish, OTA push)
+- Tasks that mutate external state (DB migration push, registry publish)
+- Watch / dev tasks (`"persistent": true` instead, see below)
+
+`dev` is the canonical persistent task:
+
+```json
+"dev": { "cache": false, "persistent": true }
+```
+
+`persistent: true` tells Turbo "this task never ends" so it doesn't wait for completion before considering downstream tasks runnable.
+
+## Remote cache: when to bother
+
+Remote cache (Vercel Remote Cache, Turbo's hosted, self-host) is worth it when:
+
+- Team ≥ 3 developers AND/OR
+- CI runs ≥ 10 times per day AND/OR
+- Build times ≥ 1 minute
+
+For solo dev with local cache only, skip. The setup overhead exceeds the benefit.
+
+Setup: `npx turbo login && npx turbo link`. CI: pass `TURBO_TOKEN` and `TURBO_TEAM` env vars.
+
+## Common bugs and fixes
+
+| Symptom | Likely cause | Fix |
+|---|---|---|
+| "Build seems to skip my changes" | Wrong `inputs` glob | Remove the inputs override; let Turbo default handle it |
+| "Downstream package imports stale code" | Missing `outputs` entry | Add `dist/**` (or whatever the build writes) |
+| "Cache key changes every run" | Generated file outside `outputs` | List the generated path in `outputs` |
+| "Turbo runs tasks in wrong order" | Missing `dependsOn: ["^build"]` | Add it |
+| "Full rebuild every CI run" | No remote cache OR build artifact ignored by .gitignore but not in outputs | Set up remote cache; verify outputs match |
+
+## When NOT to add a task
+
+- One-shot scripts: use a package.json script, not a Turbo task
+- Tasks that run < 1 second: not worth the overhead
+- Tasks specific to one developer's flow: keep in their shell history
+
+Turbo tasks are for things the team runs in CI or routinely locally. Keep the surface small.
+
+## Workflow
+
+1. **Sketch the dependency DAG on paper.** What runs before what? Across packages?
+2. **Write the minimal `dependsOn` + `outputs`** for each task. Don't overthink `inputs`.
+3. **`turbo build --dry-run`** to see the plan.
+4. **`turbo build --summarize`** to verify cache hits in CI.
+5. **If a cache miss surprises you, `turbo build --verbose`** shows the cache key inputs.
+
+## Composition
+
+- `void-service-package` — new packages need their tasks declared in turbo.json (build, typecheck, test).
+- `void-dependency-direction` — Turbo's `^build` only works correctly if package dependencies are well-declared in package.json.
+- `void-tdd` — `test` task must have `"outputs": []`; otherwise vitest's cache directory pollutes Turbo's cache.

package/core-assets/packs/pack-monorepo/skills/void-turbo-pipeline-tuning/harness.yaml

@@ -0,0 +1,14 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: standard
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: active
+    codex: active
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/packs/pack-nextjs/skills/void-cache-component-pattern/.source

@@ -0,0 +1,5 @@
+Sources for `void-cache-component-pattern` skill (see `docs/plans/skill-audits/void-cache-component-pattern.md` for the full audit):
+
+- No external source listed in the audit. Authored against the Next.js 16 Cache Components feature (cached-by-default model, 'use cache' / 'use no cache', revalidateTag/revalidatePath).
+
+Strategy: distill. Codified natively from the Next 16 cache model; no upstream skill was adapted.