@danieljvdm/dev-kit 0.11.3 → 0.13.0

package/skills/build-effect-apis/references/tanstack-start.md

@@ -0,0 +1,86 @@
+# TanStack Start integration
+
+TanStack Start modules are isomorphic unless an explicit boundary says
+otherwise. Choose one data-execution model before wiring Effect Atom.
+
+## Client-only atom data
+
+Use this when identity, focus signals, or other dependencies require browser
+globals.
+
+1. Mount one `RegistryProvider` around the application subtree whose client
+   navigations should share cache state.
+2. Put browser-dependent atom consumers behind `ClientOnly`.
+3. Keep the runtime, `AtomHttpApi.Service`, query families, and mutations as
+   client module singletons.
+4. Render a useful server fallback and accept that API fetching begins after
+   hydration.
+
+```tsx
+import { RegistryProvider } from "@effect/atom-react";
+import { ClientOnly, Outlet } from "@tanstack/react-router";
+
+export function Root() {
+  return (
+    <RegistryProvider defaultIdleTTL={60_000}>
+      <ClientOnly fallback={<AppSkeleton />}>
+        <Outlet />
+      </ClientOnly>
+    </RegistryProvider>
+  );
+}
+```
+
+`Atom.windowFocusSignal`, `localStorage`, `window`, and `document` belong in
+this client-only branch.
+
+## SSR or loader-owned data
+
+Prefer TanStack loaders or server functions when they already own SSR data.
+Pass loader data into the client state graph or keep the query loader-owned;
+avoid maintaining two independent server caches for the same request.
+
+When atom SSR is intentional:
+
+- create the registry and request-specific runtime/layers per request;
+- give serializable queries deterministic `serializationKey` values;
+- mount or run only the intended serializable atoms on the server;
+- dehydrate only intended values;
+- create the browser registry once and hydrate matching atom identities before
+  descendants read them;
+- use `HydrationBoundary` when the installed React adapter supports it.
+
+Process-global registries or memo maps can leak request-specific authentication
+and server state across users. Verify request isolation with concurrent SSR
+tests.
+
+## Focus is browser-only
+
+`Atom.windowFocusSignal` reads `window` and `document.visibilityState` when
+mounted. Keep focus-enabled consumers behind `ClientOnly`, or inject a no-op
+server signal and the browser signal on the client. `revalidateOnFocus: true`
+respects `staleTime`; `"always"` forces a request on each focus signal.
+
+## Separate API development
+
+When TanStack Start and the Effect API run as separate local processes, proxy a
+stable prefix and WebSocket upgrades through the app dev server:
+
+```ts
+export default defineConfig({
+  plugins: [tanstackStart(), react()],
+  server: {
+    proxy: {
+      "/api": {
+        target: "http://127.0.0.1:8787",
+        changeOrigin: true,
+        ws: true,
+      },
+    },
+  },
+});
+```
+
+Keep the client base URL aligned with proxy and production routing. If
+credentials cross origins, configure CORS and cookie/header behavior at the API
+edge and test the deployed topology, not only the same-origin development path.

package/skills/build-effect-apis/references/verification.md

@@ -0,0 +1,50 @@
+# Verification
+
+Test the contract spine at its seams. Use the repository's established Effect
+test integration and command authority.
+
+## Contract tests
+
+- Decode and re-encode representative request, success, and error values.
+- Prove branded path/query/header values reject invalid wire input.
+- Encode any `Schema.Class` headers exactly as generated clients receive them.
+- Assert each expected error carries the intended HTTP status and body encoding.
+- Compare or smoke-test generated OpenAPI when the public contract changes.
+
+## Server tests
+
+- Build every changed group and fail the test if an endpoint handler is missing.
+- Provide deterministic test layers for application services and middleware.
+- Prove each handler exposes only errors declared by its endpoint; exercise
+  expected reason mapping and unexpected failure defects separately.
+- Exercise success, declared failure, malformed input, and middleware rejection.
+- Assert cross-field boundary invariants before the service workflow runs.
+- Exercise raw routes separately and prove they enforce middleware-equivalent
+  identity/security rules.
+
+Use the installed `HttpApiTest` or an in-memory `HttpClient` when available;
+otherwise run the built HTTP application against representative requests. Avoid
+mocking below the contract so heavily that request encoding and response
+decoding are skipped.
+
+## Client tests
+
+- Derive the client from the same root API used by the server.
+- Provide every `requiredForClient` middleware with
+  `HttpApiMiddleware.layerClient` and assert that it transforms the request.
+- Assert params, query, headers, payload, and expected errors at least once for
+  every changed request shape.
+- For Atom clients, complete every applicable scenario routed through
+  `effect-atom-testing.md`; use a deterministic HTTP layer so request encoding,
+  invalidation, and lifecycle remain observable.
+
+## Completion matrix
+
+Account for every changed endpoint across these columns:
+
+| Contract                                         | Middleware                       | Handler/service                  | Client/query/mutation                          | Tests                            |
+| ------------------------------------------------ | -------------------------------- | -------------------------------- | ---------------------------------------------- | -------------------------------- |
+| Params, query, headers, payload, success, errors | Scope, provided services, errors | Identifier, invariants, workflow | Typed call shape, identity, cache/invalidation | Round-trip and boundary behavior |
+
+Completion means every changed endpoint has an entry in every applicable
+column and the repository's formatter, linter, typechecker, and tests pass.

package/skills/build-effect-clis/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: build-effect-clis
+description: Build and maintain command-line applications entirely with Effect. Use when creating or changing CLI commands, arguments, flags, subcommands, prompts, help, JSON output, dry-run or confirmation flows, platform services, child processes, Node/Bun entrypoints, or CLI integration tests.
+---
+
+# Build Effect CLIs
+
+Treat a CLI as an Effect application: the `Command` tree owns the user-facing
+contract, handlers adapt decoded input into application workflows, services own
+capabilities, and the executable entrypoint supplies platform Layers and runs
+the program. Do not introduce a separate CLI framework for new command work.
+
+Effect CLI and process APIs are version-sensitive. Read the target repository's
+`node_modules/effect/AGENTS.md` completely, follow its CLI and child-process
+references, and confirm exact signatures from the installed declarations before
+editing.
+
+## Build the command boundary
+
+1. Inventory the existing executable entrypoints, package scripts, command
+   tree, shared flags, prompts, application services, platform Layers, output
+   modes, and subprocess helpers. Finish when every way to invoke and test the
+   CLI is known.
+2. Read [command-design.md](references/command-design.md). Define arguments and
+   flags with `Argument` and `Flag`, compose commands with `Command`, and give
+   every public input useful help. Use `Effect.fn` handlers and yield the root
+   command when a subcommand needs shared parent input.
+3. Keep handlers thin. Decode user and file input at the boundary, enforce
+   cross-input invariants, then call an application service. Keep persistence,
+   network calls, orchestration, retries, and transactions in services.
+4. Keep expected operational failures typed with `Schema.TaggedError`; map
+   platform failures into application-owned errors near the adapter that knows
+   what the operation means. Let defects remain defects.
+5. Read [entrypoints-and-testing.md](references/entrypoints-and-testing.md).
+   Export the command tree without running it, wire one Node or Bun entrypoint,
+   and verify help, parsing, successful execution, expected failure, JSON
+   output, and every dry-run or confirmation path.
+
+## Optional branches
+
+- Read [processes-and-platform.md](references/processes-and-platform.md) when a
+  command reads files, inspects the environment, starts child processes,
+  streams their output, or differs between Node and Bun.
+- Use `Prompt` only for an intentionally interactive path. Keep required inputs
+  expressible as arguments or flags so automation never depends on a terminal.
+- Add `--dry-run` for commands that mutate important state and `--yes` for
+  explicitly authorized non-interactive confirmation. Never prompt in JSON or
+  CI-oriented modes.
+
+## CLI ownership rules
+
+- Let `Command`, `Argument`, and `Flag` own syntax, defaults, aliases, examples,
+  and help text.
+- Let schemas own untrusted structured input and machine-readable output.
+- Let handlers own CLI-to-application mapping and presentation selection.
+- Let services own reusable behavior and external capabilities.
+- Let Layers own implementations and runtime dependencies.
+- Let the executable entrypoint own `Command.run`, platform provisioning,
+  scopes, signal handling, and `NodeRuntime.runMain` or `BunRuntime.runMain`.
+- Keep stdout stable for primary or machine-readable output. Send diagnostics
+  and progress elsewhere; never mix prose into JSON output.

package/skills/build-effect-clis/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Build Effect CLIs"
+  short_description: "Build typed Effect command-line applications"
+  default_prompt: "Use $build-effect-clis to build a typed Effect CLI with clear commands, platform boundaries, and tests."

package/skills/build-effect-clis/references/command-design.md

@@ -0,0 +1,93 @@
+# Command design
+
+Model the CLI's public surface as a typed contract. Prefer a small root command,
+shared parent flags, focused subcommands, and Effect handlers.
+
+```ts
+import { Effect } from "effect";
+import { Argument, Command, Flag } from "effect/unstable/cli";
+
+const workspace = Flag.string("workspace").pipe(
+  Flag.withAlias("w"),
+  Flag.withDescription("Workspace to operate on"),
+  Flag.withDefault("personal"),
+);
+
+const root = Command.make("acme").pipe(
+  Command.withSharedFlags({
+    workspace,
+    verbose: Flag.boolean("verbose").pipe(
+      Flag.withAlias("v"),
+      Flag.withDescription("Print diagnostic output"),
+    ),
+  }),
+  Command.withDescription("Operate Acme projects"),
+);
+
+const deploy = Command.make(
+  "deploy",
+  {
+    environment: Argument.string("environment").pipe(
+      Argument.withDescription("Target environment"),
+    ),
+    dryRun: Flag.boolean("dry-run").pipe(
+      Flag.withDescription("Show the deployment plan without applying it"),
+    ),
+    json: Flag.boolean("json").pipe(Flag.withDescription("Print machine-readable JSON")),
+  },
+  Effect.fn("deployCommand")(function* ({ dryRun, environment, json }) {
+    const shared = yield* root;
+    const deployments = yield* Deployments;
+    const plan = yield* deployments.plan({ environment, workspace: shared.workspace });
+
+    if (dryRun) return yield* renderPlan(plan, { json });
+
+    const result = yield* deployments.apply(plan);
+    return yield* renderDeployment(result, { json });
+  }),
+).pipe(
+  Command.withDescription("Deploy a workspace"),
+  Command.withExamples([
+    {
+      command: "acme --workspace team deploy production --dry-run",
+      description: "Preview a production deployment",
+    },
+  ]),
+);
+
+export const command = root.pipe(Command.withSubcommands([deploy]));
+```
+
+## Input and help
+
+- Use arguments for essential positional identity and flags for optional
+  behavior. Prefer named flags when position would be ambiguous.
+- Give public commands, arguments, and non-obvious flags descriptions. Add
+  examples for quoting, shared flags, or surprising combinations.
+- Put cross-command inputs in `Command.withSharedFlags`; read them by yielding
+  the parent command instead of duplicating parsing or reading globals.
+- Use `Flag.choice` for closed vocabularies and schemas for structured values
+  loaded from JSON, files, or environment boundaries.
+- Keep aliases additive and unsurprising. Never give two concepts the same
+  short flag in one command path.
+
+## Interactive and automated use
+
+- Make every required value available non-interactively. A fallback `Prompt`
+  may improve terminal use but must not be the only way to supply input.
+- Prompt only after deterministic discovery cannot choose safely. Summarize the
+  detected state and the exact mutation before requesting confirmation.
+- Pair destructive execution with a genuine plan/apply split. `--dry-run` must
+  run the real discovery and planning logic while skipping writes.
+- Require explicit `--yes` or an equivalent authorization flag when a
+  non-interactive destructive path cannot prompt.
+
+## Output contract
+
+- Treat human and machine output as separate renderers over the same result.
+- In `--json` mode, emit one documented schema-encoded value to stdout. Send no
+  headings, spinners, progress, or warnings to stdout.
+- Use stderr for diagnostics and failures. Keep normal human output concise and
+  stable enough for users to understand without reading source.
+- Do not expose stack traces for expected failures. Preserve causes for logs and
+  tests, then render an actionable message at the executable boundary.

package/skills/build-effect-clis/references/entrypoints-and-testing.md

@@ -0,0 +1,59 @@
+# Entrypoints and testing
+
+Separate command definition from execution. Importing a command module in a test
+or another program must not parse `process.argv`, start fibers, or terminate the
+process.
+
+```ts
+// src/cli/command.ts
+export const command = root.pipe(Command.withSubcommands([deploy, status]));
+
+// src/bin/acme.ts
+import { NodeRuntime, NodeServices } from "@effect/platform-node";
+import { Effect } from "effect";
+import { Command } from "effect/unstable/cli";
+import { command } from "../cli/command";
+
+const program = Command.run(command, { version: VERSION }).pipe(
+  Effect.scoped,
+  Effect.provide(ApplicationLive),
+  Effect.provide(NodeServices.layer),
+);
+
+NodeRuntime.runMain(program, { disableErrorReporting: true });
+```
+
+Use `BunRuntime` and `BunServices` together when Bun owns the executable. Let
+`runMain` own signals, interruption, and process completion. Do not call
+`Effect.runPromise`, `process.exit`, or runtime globals inside command handlers.
+If expected errors need custom presentation, catch and render them immediately
+before `runMain` while preserving CLI control-flow errors such as help output.
+
+## Test at three seams
+
+1. Test application services directly with deterministic Layers. Cover domain
+   success, expected failure, interruption, and plan/apply separation without
+   involving argument parsing.
+2. Test thin command handlers through their services when CLI input mapping or
+   output-mode selection contains meaningful logic.
+3. Spawn the real executable for boundary behavior. At minimum cover:
+   - root and changed-command `--help`;
+   - representative valid arguments and flags;
+   - missing or invalid input and a non-zero exit;
+   - one expected operational failure with an actionable message;
+   - exact JSON output with no prose contamination;
+   - dry-run proving writes did not occur;
+   - confirmation behavior in both interactive and non-interactive modes.
+
+Run executable tests through Effect's child-process APIs with an explicit `cwd`,
+captured stdout/stderr, and controlled environment. Use the repository's normal
+runtime launcher and command authority; a test that bypasses the packaged or
+declared entrypoint does not prove the CLI works for users.
+
+## Completion checks
+
+- Ensure every executable TypeScript entrypoint belongs to a checked project.
+- Run the repository's formatter, linter, typechecker, and tests.
+- Execute `--help` through the real entrypoint.
+- Exercise a harmless dry-run or read-only command outside the source module.
+- Verify non-zero exits for parsing and expected operational failures.

package/skills/build-effect-clis/references/processes-and-platform.md

@@ -0,0 +1,73 @@
+# Processes and platform services
+
+Use Effect platform services inside CLI workflows. Keep direct `node:*`, Bun
+globals, `process`, filesystem calls, and shell execution at explicit adapters
+or the executable boundary.
+
+## Own subprocess behavior in a service
+
+```ts
+import { Context, Effect, Layer, Schema, String } from "effect";
+import { ChildProcess, ChildProcessSpawner } from "effect/unstable/process";
+
+export class ToolError extends Schema.TaggedError<ToolError>()("ToolError", {
+  command: Schema.String,
+  cause: Schema.Defect(),
+}) {}
+
+export class Tools extends Context.Service<
+  Tools,
+  {
+    readonly gitVersion: Effect.Effect<string, ToolError>;
+    changedFiles(baseRef: string): Effect.Effect<ReadonlyArray<string>, ToolError>;
+  }
+>()("app/Tools") {
+  static readonly layer = Layer.effect(
+    Tools,
+    Effect.gen(function* () {
+      const spawner = yield* ChildProcessSpawner.ChildProcessSpawner;
+      const gitVersion = spawner.string(ChildProcess.make("git", ["--version"])).pipe(
+        Effect.map(String.trim),
+        Effect.mapError((cause) => new ToolError({ command: "git --version", cause })),
+      );
+      const changedFiles = Effect.fn("Tools.changedFiles")(function* (baseRef: string) {
+        return yield* spawner
+          .lines(ChildProcess.make("git", ["diff", "--name-only", `${baseRef}...HEAD`]))
+          .pipe(
+            Effect.mapError(
+              (cause) =>
+                new ToolError({ command: `git diff --name-only ${baseRef}...HEAD`, cause }),
+            ),
+          );
+      });
+
+      return Tools.of({ changedFiles, gitVersion });
+    }),
+  );
+}
+```
+
+Pass the executable and arguments separately to `ChildProcess.make`; never
+construct a shell command from user input. Set `cwd` explicitly when repository
+identity matters. Provide `env` narrowly and choose `extendEnv` deliberately so
+tests and CI do not inherit accidental machine state.
+
+Use the smallest spawner operation that matches the contract:
+
+- `string` for bounded complete output;
+- `lines` for bounded line-oriented output;
+- `spawn` plus a scoped process handle for streaming, interactive, or
+  exit-code-sensitive work;
+- `ChildProcess.pipeTo` for a real pipeline without invoking a shell.
+
+When using `spawn`, consume stdout/stderr without deadlocking, inspect
+`handle.exitCode`, and wrap the whole process lifetime in `Effect.scoped`.
+Map platform failures once into an operation-specific error; do not expose a
+generic subprocess error throughout the application.
+
+## Keep the runtime choice at the edge
+
+Application services may require `FileSystem`, `Path`, `Terminal`, or
+`ChildProcessSpawner`, but they should not import `NodeServices` or `BunServices`.
+Provide the matching platform Layer only in the executable entrypoint. This
+keeps workflows reusable and lets tests provide deterministic substitutes.

package/skills/dev-kit/SKILL.md

@@ -66,6 +66,18 @@ external source ID is also a family, but expands to every approved skill from
 that source, so prefer individually relevant external skills. Include this
 skill as `dev-kit` when project agents should carry the toolkit procedure.
 
+Select skills bundled inside installed packages with the exact
+`<package>#<skill>` selector. The selector stays package-qualified in the
+manifest, lock, and CLI listings, and the installed output keeps that identity:
+the copied directory is named by flattening the package name (drop `@`, turn
+every other non-alphanumeric run into one dash) and appending the skill name,
+so `@tanstack/table-core#core` installs as `tanstack-table-core-core`. The
+copied `SKILL.md` frontmatter `name:` is rewritten to the same install name;
+everything else is verbatim. Symlink-mode targets still point at
+`node_modules`, so their frontmatter keeps the upstream bare name. Two selected
+skills that flatten to the same install name are rejected before any output
+changes.
+
 ```jsonc
 {
   "$schema": "./node_modules/@danieljvdm/dev-kit/schema/dev-kit.schema.json",
@@ -77,7 +89,6 @@ skill as `dev-kit` when project agents should carry the toolkit procedure.
     "vitePlus": {
       "hooks": { "enabled": true },
       "quality": {
-        "config": { "enabled": true },
         "workflow": { "enabled": true },
       },
     },
@@ -105,10 +116,16 @@ useful unified-toolchain overview, help and documentation entry points, and
 contradict the repository policy. Treat duplicate, overlapping, reversed, or
 unmatched managed markers as a conflict rather than guessing which content Dev
 Kit owns; remove a legacy owned Vite+ section during migration.
+When `effect` is a declared direct dependency and the installed package ships a
+regular `node_modules/effect/AGENTS.md` file, the managed section also directs
+agents to read that version-matched guide completely and use
+`node_modules/effect/src` for gaps. Omit the pointer when the package is absent,
+transitive, or too old to ship the guide; never generate a dangling path.
 The managed section also publishes the repository's command authority. Direct
-Vite+ projects must use `vp` built-ins and `vp run <task>`; managed quality
-projects use `vp run check` for the complete format/lint/test/typecheck suite
-and `vp run typecheck` for the Effect-patched compiler. Non-Vite+ projects run
+Vite+ projects must use `vp` built-ins and `vp run <task>`; projects using the
+recommended Vite+ factory use `vp run check` for the complete
+format/lint/test/typecheck suite and `vp run typecheck` for the Effect-patched
+compiler. Non-Vite+ projects run
 existing root quality scripts through `bun run`; package-manager metadata and
 lockfiles affect dependency-install guidance only. Never substitute another
 script runner or call raw `tsc`, test, lint, or format binaries when a project
@@ -122,27 +139,31 @@ place.
 
 Enable `setup.vitePlus.hooks` when an installed direct `vite-plus` dependency
 should manage Git hooks. Each apply checks the local `.vite-hooks/_` dispatcher,
-the portable `.vite-hooks/pre-commit` hook, and `core.hooksPath`, then runs the
-project-local `vp config --no-agent` when they need convergence. This recreates
-ignored dispatchers in linked worktrees. Preserve other hook managers; Dev Kit
+its internal `.gitignore`, the portable `.vite-hooks/pre-commit` hook, and
+`core.hooksPath`, then runs the project-local `vp config --no-agent` when they
+need convergence. This recreates ignored dispatchers in linked worktrees.
+Preserve other hook managers; Dev Kit
 refuses to replace an unrelated `core.hooksPath`. Use `VITE_GIT_HOOKS=0` or
 `HUSKY=0` to skip hook setup for an invocation.
 
-Enable `setup.vitePlus.quality.config` and
-`setup.vitePlus.quality.workflow` independently in supported Vite+/Effect
-repositories. Config owns canonical root `vite.config.ts`; workflow owns
-`.github/workflows/check.yml`; selecting one must not constrain the other's
-config, scripts, or TypeScript topology. Both require direct Dev Kit, compatible
-Vite+, Effect, Effect TypeScript-Go, and native TypeScript dependencies with
-`setup.effectTsgo.enabled`. Preserve unowned destinations and adopt only exact
-rendered matches.
-
-Managed config defines separate `check` and pure `typecheck` Vite tasks. Its
-default single-project strategy rejects project references; workspace mode
-requires explicit package directories with `typecheck` scripts and generates
-cached, dependency-ordered, bounded-concurrency filters. Keep project-reference
-builds custom. Workflow-only consumers may configure `workflow.beforeChecks`
-and `workflow.typecheck`; treat these commands as trusted manifest input.
+The repository always owns `vite.config.ts`. Compose
+`createRecommendedVitePlusConfig` from `@danieljvdm/dev-kit/vite-plus` there;
+Dev Kit never adopts, rewrites, or removes the config. The factory provides
+matching Oxlint/Oxfmt ignores, staged checks, and separate `check` and pure
+`typecheck` Vite tasks. Add repository/framework-generated paths through its
+`ignorePatterns` option, including any harness target paths that override the
+manifest defaults. Workspace mode accepts explicit package directories with
+pure `typecheck` scripts and generates cached, dependency-ordered,
+bounded-concurrency filters. Spread the returned top-level config before local
+options; spread a returned nested block before overriding that block, and merge
+nested collections such as `lint.rules` so the recommended rules remain active.
+
+Enable `setup.vitePlus.quality.workflow` to own only
+`.github/workflows/check.yml`. It requires direct Dev Kit, compatible Vite+,
+Effect, Effect TypeScript-Go, and native TypeScript dependencies with
+`setup.effectTsgo.enabled`. Preserve unowned workflows and adopt only an exact
+rendered match. Consumers may configure `workflow.beforeChecks` and
+`workflow.typecheck`; treat these commands as trusted manifest input.
 
 The workflow must use one frozen, script-suppressed install, then locked Dev Kit
 convergence before preparation or checks. Set up Bun from the consumer's
@@ -234,39 +255,42 @@ Enable the setup task in the same manifest:
 Install the exact `@effect/tsgo` and native `typescript` versions required by
 the installed dev-kit. Point `tsconfig.json` at
 `./node_modules/@effect/tsgo/schema.json` and configure the
-`@effect/language-service` compiler plugin. `dev-kit plan` validates these local
-dependencies; `dev-kit apply` patches once and then converges.
+`@effect/language-service` compiler plugin with Dev Kit's exported
+`recommendedEffectTsgoPlugin` profile: warnings for
+`anyUnknownInErrorContext` and `unsafeEffectTypeAssertion`; suggestions for
+`instanceOfSchema`, `nestedEffectGenYield`, `newSchemaClass`, and
+`preferSchemaTypeProperty`; plus a `src/**/*.ts` override that warns on
+`nodeBuiltinImport` and suggests `preferSchemaOverJson`. Copy the exact JSON
+profile from the README into JSON tsconfigs. In monorepos, child
+`compilerOptions.plugins` arrays replace rather than merge the root array, so
+workspace configs must inherit the root plugin without redeclaring it and the
+source override must be relative to the config that contains it. `dev-kit plan`
+validates the local dependencies; `dev-kit apply` patches once and then
+converges.
 
 Use `dev-kit tsgo patch --dry-run` for focused diagnosis. Use `--force` only
 after the user accepts a potentially commit-incompatible TypeScript binary.
 
 ## Oxlint and Oxfmt configurations
 
-Use Dev Kit's canonical Oxlint and Oxfmt objects in Vite+ projects:
+Use Dev Kit's composable factory in Vite+ projects:
 
 ```ts
-import { recommendedOxlintConfig } from "@danieljvdm/dev-kit/oxlint";
-import { recommendedOxfmtConfig } from "@danieljvdm/dev-kit/oxfmt";
+import { createRecommendedVitePlusConfig } from "@danieljvdm/dev-kit/vite-plus";
 import { defineConfig } from "vite-plus";
 
-export default defineConfig({
-  fmt: {
-    ...recommendedOxfmtConfig,
-  },
-  lint: {
-    extends: [recommendedOxlintConfig],
-    rules: {
-      // Project-specific rules apply after the shared preset.
-    },
-  },
-});
+export default defineConfig(
+  createRecommendedVitePlusConfig({
+    ignorePatterns: ["src/routeTree.gen.ts"],
+  }),
+);
 ```
 
-Use `lint.extends` instead of spreading the object so Vite+ composes nested
-rule maps correctly. Oxfmt has no inheritance mechanism, so spread its object
-before project-local options. Standalone `oxlint.config.ts` uses the same
-`extends: [recommendedOxlintConfig]`; standalone `oxfmt.config.ts` spreads the
-same `recommendedOxfmtConfig`. The shared lint preset enables `typeAware` for
+The factory composes the canonical Oxlint/Oxfmt objects, excludes tracked skill
+copies plus symlinked harness targets from both tools, and accepts additional
+project-owned ignores. Standalone `oxlint.config.ts` uses
+`extends: [recommendedOxlintConfig]`; standalone `oxfmt.config.ts` spreads
+`recommendedOxfmtConfig`. The shared lint preset enables `typeAware` for
 semantic lint rules but leaves `typeCheck` disabled. Effect TypeScript-Go
 projects must run the patched native compiler separately with
 `vp run typecheck` after `vp fmt --check`, `vp lint`, and `vp test`; Oxlint's
@@ -277,6 +301,12 @@ The Oxlint preset enables the fixable
 declarations grouped, requires a blank line before the next logical statement,
 and separates every `return` statement from the preceding statement.
 
+Vite+ 0.2.6 forwards the preset's JavaScript-plugin declarations but its native
+Oxlint path does not register or execute their rules. Treat native rules and
+Oxfmt as active through `vp`, and use standalone Oxlint when the `effect/*` or
+`stylistic/padding-line-between-statements` rules must be enforced. Re-enable a
+Vite+ execution assertion when a supported release adds JS-plugin execution.
+
 The Oxlint preset registers Dev Kit's shared Effect plugin as `effect`, but
 does not enable its scope-sensitive rules globally. Effect projects should
 enable rules such as `effect/no-effect-run`, `effect/no-unsafe-promise`, and
@@ -290,8 +320,7 @@ in the consuming project.
 
 Manage skill outputs, the `setup.agentInstructions` marked sections, the
 `setup.claudeInstructions` link, the `setup.vitePlus.hooks` dispatcher, the
-independently opt-in `setup.vitePlus.quality` config and GitHub workflow, the
-`setup.effectSource` checkout, and the explicit `setup.effectTsgo` task.
-Dependency and `tsconfig.json` contributions remain deliberate user-owned
-edits. Custom Vite configs compose the Oxlint and Oxfmt package exports
-manually, leave managed config disabled, and may still use the managed workflow.
+opt-in `setup.vitePlus.quality.workflow`, the `setup.effectSource` checkout,
+and the explicit `setup.effectTsgo` task. `vite.config.ts`, dependency, and
+`tsconfig.json` contributions remain deliberate user-owned edits. Compose the
+Vite+ factory or lower-level Oxlint/Oxfmt exports locally.

package/skills/effect-architecture-audit/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: effect-architecture-audit
+description: Audit an Effect TypeScript codebase's services, Layers, dependency ownership, hidden requirements, test substitutes, Schema boundaries, assertions, unknown values, and typed error channels. Use for architecture reviews, service refactors, dependency-injection audits, and type-boundary investigations; do not use as a general Effect API reference.
+---
+
+# Audit Effect Architecture
+
+Read the target repository's `node_modules/effect/AGENTS.md` completely before
+evaluating Effect code. Follow its version-matched references for library APIs;
+use this skill only for the application-architecture judgments it does not own.
+
+Read [service-and-boundary-audit.md](references/service-and-boundary-audit.md),
+then:
+
+1. Establish the repository's local architecture and testing rules.
+2. Inventory every service, Layer, dependency path, runtime authority, test
+   substitute, and unsafe type boundary in scope.
+3. Trace each capability to its owner and composition root.
+4. Classify each candidate as a built-in capability, application authority,
+   technology adapter, explicit value, framework boundary, or pass-through
+   abstraction.
+5. Report evidence-backed findings and explicit keep decisions. Do not propose
+   a wrapper, service, or Schema merely to make the inventory symmetrical.
+
+When asked only to audit or review, stop after the findings. Implement changes
+only when the user also requests them.

package/skills/effect-architecture-audit/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Effect Architecture Audit"
+  short_description: "Audit Effect service and boundary ownership"
+  default_prompt: "Use $effect-architecture-audit to audit this Effect codebase's services, Layers, and type boundaries."