claude-toolkit 0.9.0 → 0.11.0

package/core/skills/ct-testing-patterns/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ct-testing-patterns
-description: Generic test-driven development practices and patterns applicable to any language or test framework.
+description: Generic test-driven development practices and patterns applicable to any language or test framework. Use when writing tests, setting up a test suite, or deciding what to test at which layer
 ---
 
 # Testing Patterns
@@ -28,6 +28,8 @@ description: Generic test-driven development practices and patterns applicable t
 | Interaction | ~20%         | Component variants, user interactions, accessibility, visual regression      |
 | E2E         | ~10%         | Critical user journeys, authentication flows, cross-page workflows           |
 
+> **Scope:** This core skill owns the layering _decision_ below, the unit and interaction layers, and the cross-cutting E2E principles. Runner-specific E2E setup and execution live in the stack skills (e.g. `ct-playwright-patterns`) when a matching stack is installed.
+
 ### When to Use Which Layer
 
 | Question                                          | Layer                                  |
@@ -103,13 +105,9 @@ bun test path/to/file.test.ts  # single file
 
 Bun supports `describe`, `it`/`test`, `expect`, lifecycle hooks, and snapshot testing out of the box with no additional dependencies.
 
-## Test Pyramid
-
-See 3-Layer Testing Strategy above. Many unit tests (fast, focused) > some interaction tests (component sandbox) > few E2E tests (full flow). Aim for 70/20/10 distribution.
-
 ## Test Speed
 
-Three levers recur across every runner (Vitest, Playwright, Storybook browser mode). Stated once here; each stack skill carries the framework-specific syntax.
+Three levers recur across common runners (Vitest, Playwright, Storybook browser mode). Stated once here; each stack skill carries the framework-specific syntax.
 
 - **Parallelism sized to the runner.** Enable file-level parallelism (Vitest `fileParallelism`, Playwright `fullyParallel`), but cap workers to the runner's *real* vCPUs (`"50%"` or a measured count). GitHub standard runners are 2 vCPU (private) / 4 (public); oversubscribing thrashes.
 - **Shard across CI jobs, then merge the blob reports.** Sharding splits at the *file* level (`--shard=i/n`), so wall-clock is gated by the slowest shard -- balance file sizes. Always emit a blob report per shard (`--reporter=blob`) and merge it (`merge-reports` / `--merge-reports`) in a dependent job, or results and coverage are fragmented and incomplete.
@@ -117,7 +115,7 @@ Three levers recur across every runner (Vitest, Playwright, Storybook browser mo
 
 Profile before tuning, and never `sleep` to mask timing -- use the framework's auto-waiting (see Shared Principles).
 
-Per-runner config: `ct-vite-vitest-patterns`, `ct-playwright-patterns`, `ct-storybook-patterns`.
+Per-runner config, if the corresponding stack is installed: `ct-vite-vitest-patterns`, `ct-playwright-patterns`, `ct-storybook-patterns`.
 
 ## Anti-Patterns
 

package/core/skills/ct-typescript-conventions/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ct-typescript-conventions
-description: Strict TypeScript patterns for type safety, readability, and maintainable codebases.
+description: Strict TypeScript patterns for type safety, readability, and maintainable codebases. Use when writing or reviewing TypeScript, adding or tightening types, or deciding between type and interface
 ---
 
 # TypeScript Conventions
@@ -10,7 +10,7 @@ Strict mode enabled. Catch errors at compile time, not runtime.
 ## Rules
 
 - **No `any`** -- Use `unknown` + narrowing, generics, or specific types.
-- **`interface` for objects**, `type` for unions/intersections/utilities.
+- **Default to `type`.** Use `interface` only when you need `extends` (object inheritance). `type` aliases have an implicit index signature, so they stay assignable to `Record<string, unknown>`; interfaces do not.
 - **`as const`** for literal types and readonly tuples.
 - **Never disable strict checks.** Hard-to-type code = design issue.
 
@@ -42,19 +42,21 @@ type AsyncState<T> =
 
 ## `satisfies` Operator
 
-Validate a value matches a type without widening it. Preserves the narrowest inferred type while ensuring conformance.
+Validate a value conforms to a type while keeping the *narrowest inferred type* per property, instead of widening every property to the target's value type (as an explicit annotation would). Against a union-typed target, the matching literal is preserved.
 
 ```typescript
-type Route = { path: string; children?: Route[] };
-
-const routes = {
-  home: { path: "/" },
-  user: { path: "/user/:id", children: [{ path: "settings" }] },
-} satisfies Record<string, Route>;
-
-// routes.home.path is still "/" (literal), not string
+const config = {
+  mode: "production",
+  level: 3,
+} satisfies { mode: "development" | "production"; level: number };
+
+// config.mode is the literal "production" (not widened to string),
+// because the target property is a union of literals. A plain
+// annotation `const config: {...}` would widen it to the full union.
 ```
 
+Note: `satisfies` does not by itself narrow to literals against a _wide_ target -- e.g. `satisfies Record<string, string>` still infers `string` for each value, and `satisfies Record<string, { path: string }>` leaves each `path` as `string`. Combine with `as const` when you need literals preserved against a `string`-typed target.
+
 ## `const` Type Parameters
 
 Infer literal types from arguments without requiring callers to write `as const`:
@@ -68,6 +70,8 @@ function createConfig<const T extends readonly string[]>(names: T): Record<T[num
 const flags = createConfig(["debug", "verbose"]);
 ```
 
+The `as Record<T[number], boolean>` above is the narrow exception to anti-pattern #1: `Object.fromEntries` is typed to return a wide `Record<string, boolean>`, so a localized cast _at a generic helper's return_ -- where the signature already proves the tighter type -- is acceptable. Reach for type guards everywhere else.
+
 ## Template Literal Types
 
 Build precise string types from unions:

package/core/skills/ct-verification-before-completion/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ct-verification-before-completion
-description: Evidence-based completion claims -- never say "done" without proof that the work is correct.
+description: Evidence-based completion claims -- never say "done" without proof that the work is correct. Use when about to claim a task is done, fixed, or passing, or before committing or opening a PR
 ---
 
 # Verification Before Completion
@@ -21,6 +21,7 @@ Before claiming complete, run and show output for each:
 - Empty inputs (empty string, empty array, null, undefined)
 - Boundary values (zero, negative, max, off-by-one)
 - Invalid inputs (wrong types, malformed data, missing fields)
+- Concurrent access (simultaneous requests or operations)
 - Error paths (network failure, permission denied)
 
 Do not assume edge cases work because the happy path works.

package/docs/README.md

@@ -2,6 +2,10 @@
 
 Complete reference for all skills, commands, and agents provided by claude-toolkit.
 
+## Setup
+
+Run `bunx claude-toolkit` in your project — on the first run it creates `claude-toolkit.config.ts` (pre-filled from stack detection) and generates `.claude/`. Run it again anytime to regenerate; add `--update` to pull newly-detected stacks into the config. `.claude/` also regenerates automatically on install when the toolkit version changes. See the [README](../README.md#cli-commands) for the full CLI.
+
 ## Core Skills
 
 Skills that are always included regardless of stack configuration.

package/docs/commands/code-quality.md

@@ -1,4 +1,4 @@
-# /code-quality
+# /ct:code-quality
 
 > Run code quality checks (lint, typecheck, format) on a directory or file.
 
@@ -9,7 +9,7 @@
 ## Usage
 
 ```bash
-/code-quality [path]
+/ct:code-quality [path]
 ```
 
 ## Workflow
@@ -29,12 +29,6 @@ The command produces a structured report with:
 - **Format Issues** -- table with file and status
 - **Summary** -- total issues across files with actionable suggestions
 
-## Best Practices Reference
-
-| Topic | Guide |
-| --- | --- |
-| Recommended `tsconfig.json` settings | [TSConfig Cheat Sheet](../best-practices/typescript/tsconfig-cheat-sheet.md) |
-
 ## Notes
 
 - Always uses the project's own configuration; does not impose external rules

package/docs/commands/onboard.md

@@ -1,4 +1,4 @@
-# /onboard
+# /ct:onboard
 
 > Systematically explore and understand a codebase area, module, or task context.
 
@@ -9,7 +9,7 @@
 ## Usage
 
 ```bash
-/onboard [area]
+/ct:onboard [area]
 ```
 
 If no area is specified, starts from the project root.
@@ -56,15 +56,6 @@ If no area is specified, starts from the project root.
 - {Things that are unclear or undocumented}
 ```
 
-## Best Practices Reference
-
-Conventions to look for during onboarding:
-
-| Topic | Guide |
-| --- | --- |
-| TypeScript conventions and patterns | [TypeScript Best Practices](../best-practices/typescript/README.md) |
-| SolidJS conventions and patterns | [SolidJS Best Practices](../best-practices/solidjs/README.md) |
-
 ## Notes
 
 - Prioritizes understanding over completeness -- deeply understand 5 key files rather than skim 50

package/docs/commands/pr-review.md

@@ -1,4 +1,4 @@
-# /pr-review
+# /ct:pr-review
 
 > Perform a checklist-based code review on the current PR or a specified PR number.
 
@@ -9,7 +9,7 @@
 ## Usage
 
 ```bash
-/pr-review [pr-number]
+/ct:pr-review [pr-number]
 ```
 
 If no PR number is provided, diffs the current branch against the base branch.
@@ -83,17 +83,6 @@ The command evaluates all changed files against these criteria:
 ### Summary
 ```
 
-## Best Practices Reference
-
-Review criteria informed by these guides:
-
-| Review Area | Guide |
-| --- | --- |
-| Type safety: `any` usage, unsafe casts | [any & unknown](../best-practices/typescript/any-and-unknown.md) |
-| State modeling with unions | [Discriminated Unions](../best-practices/typescript/discriminated-unions.md) |
-| SolidJS-specific issues (props, reactivity) | [SolidJS Anti-Patterns](../best-practices/solidjs/anti-patterns.md) |
-| Performance: re-renders, reactivity mistakes | [SolidJS Performance](../best-practices/solidjs/performance.md) |
-
 ## Notes
 
 - References specific file names and line numbers

package/docs/commands/pr-summary.md

@@ -1,4 +1,4 @@
-# /pr-summary
+# /ct:pr-summary
 
 > Generate a structured pull request summary from the current branch.
 
@@ -9,7 +9,7 @@
 ## Usage
 
 ```
-/pr-summary
+/ct:pr-summary
 ```
 
 ## Workflow

package/docs/commands/proto-check.md

@@ -1,15 +1,15 @@
-# /proto-check
+# /ct:proto-check
 
 > Validate protobuf definitions for correctness, lint compliance, and backward compatibility.
 
 **Type:** Command (slash command)
-**Source:** [`core/commands/ct/proto-check.md`](../core/commands/ct/proto-check.md)
-**Allowed Tools:** Bash, Read, Glob, Grep
+**Source:** [`stacks/protobuf/commands/proto-check.md`](../stacks/protobuf/commands/proto-check.md) (installed only with the protobuf stack)
+**Allowed Tools:** Bash (scoped to `buf`/`protoc` and build commands), Read, Glob, Grep
 
 ## Usage
 
 ```
-/proto-check
+/ct:proto-check
 ```
 
 ## Workflow

package/docs/commands/ticket.md

@@ -1,4 +1,4 @@
-# /ticket
+# /ct:ticket
 
 > Work end-to-end on a ticket or issue: understand, explore, plan, implement, deliver.
 
@@ -9,7 +9,7 @@
 ## Usage
 
 ```
-/ticket [issue-number-or-description]
+/ct:ticket [issue-number-or-description]
 ```
 
 ## Phases

package/docs/skills/systematic-debugging.md

@@ -1,6 +1,6 @@
 # Systematic Debugging
 
-> Four-phase methodology for diagnosing and fixing bugs efficiently without guesswork.
+> Four-phase methodology for diagnosing and fixing bugs efficiently without guesswork. Use when investigating a bug, test failure, or unexpected behavior before proposing a fix
 
 **Type:** Core Skill (always included)
 **Source:** [`core/skills/ct-systematic-debugging/SKILL.md`](../core/skills/ct-systematic-debugging/SKILL.md)

package/docs/skills/testing-patterns.md

@@ -1,6 +1,6 @@
 # Testing Patterns
 
-> Generic test-driven development practices and patterns applicable to any language or test framework.
+> Generic test-driven development practices and patterns applicable to any language or test framework. Use when writing tests, setting up a test suite, or deciding what to test at which layer
 
 **Type:** Core Skill (always included)
 **Source:** [`core/skills/ct-testing-patterns/SKILL.md`](../core/skills/ct-testing-patterns/SKILL.md)
@@ -11,77 +11,90 @@ Principles and patterns for writing tests that catch bugs, enable refactoring, a
 
 ## TDD Cycle: Red, Green, Refactor
 
-1. **Red** -- Write a failing test that describes the desired behavior. Confirm it fails for the right reason.
-2. **Green** -- Write the minimal code to make the test pass. Do not optimize yet.
-3. **Refactor** -- Improve the code while keeping all tests green. Remove duplication, improve naming, simplify logic.
+1. **Red** -- Write a failing test for the desired behavior. Confirm it fails for the right reason.
+2. **Green** -- Write the minimal code to make it pass. No optimization yet.
+3. **Refactor** -- Clean up while keeping tests green.
 
 Commit at each stage. The cycle keeps scope small and provides a safety net for every change.
 
-## Key Principles
+## 3-Layer Testing Strategy
 
-### Test Behavior, Not Implementation
+```
+          /  E2E  \           Real browsers, full user flows
+         /----------\
+        / Interaction \       Component sandbox, behavior, a11y
+       /----------------\
+      /      Unit        \    Pure logic, signals, utilities
+     /--------------------\
+```
+
+| Layer       | Target Ratio | What to Cover                                                                |
+| ----------- | ------------ | ---------------------------------------------------------------------------- |
+| Unit        | ~70%         | Business logic, utilities, data transforms, reactive primitives, error paths |
+| Interaction | ~20%         | Component variants, user interactions, accessibility, visual regression      |
+| E2E         | ~10%         | Critical user journeys, authentication flows, cross-page workflows           |
 
-Tests should describe *what* the code does, not *how* it does it internally.
+> **Scope:** This core skill owns the layering decision below, the unit and interaction layers, and the cross-cutting E2E principles. Runner-specific E2E setup and execution live in the stack skills (e.g. `ct-playwright-patterns`) when a matching stack is installed.
 
-- **Good:** "returns the user's full name when first and last name are provided"
-- **Bad:** "calls `String.prototype.concat` with first name and space and last name"
+### When to Use Which Layer
 
-### Factory Pattern for Test Data
+| Question                                          | Layer                                  |
+| ------------------------------------------------- | -------------------------------------- |
+| Does this logic need a DOM?                       | **Unit** if no, **Interaction** if yes |
+| Does it involve multiple pages or navigation?     | **E2E**                                |
+| Am I testing a single component's visual states?  | **Interaction**                        |
+| Am I testing a reactive primitive (signal, memo)? | **Unit**                               |
+| Does it require authentication or real network?   | **E2E**                                |
+| Am I testing component accessibility?             | **Interaction** (axe-core)             |
+| Does it need the full server running?             | **E2E**                                |
 
-Create factory functions that produce valid test objects with sensible defaults. Accept overrides for the fields relevant to each test.
+## Test Behavior, Not Implementation
+
+Test _what_ code does (public interface, observable outputs), not _how_ (internal state, call counts). Implementation-coupled tests break on every refactor.
+
+## Factory Pattern
 
 ```
 function getMockUser(overrides = {}) {
-  return {
-    id: "user-1",
-    email: "test@example.com",
-    name: "Test User",
-    role: "member",
-    createdAt: new Date("2024-01-01"),
-    ...overrides,
-  };
+  return { id: "user-1", email: "test@example.com", name: "Test User", role: "member", ...overrides };
 }
-
-// Usage: only specify what matters for this test
 const admin = getMockUser({ role: "admin" });
 ```
 
-### Test File Organization
+New required fields update the factory once, not every test.
 
-- **Co-locate tests with source** or mirror the source directory structure
-- **One test file per module** -- name it `module.test.ext` or `module.spec.ext`
-- **Group related tests** using `describe` blocks
-- **Use descriptive test names** that read as sentences
+## Organization
 
-### Mocking Strategies
+- Co-locate tests or mirror source structure. One test file per module (`module.test.ext`).
+- Group with `describe`, name as sentences: `it("rejects expired tokens")`.
 
-- **Prefer real dependencies** when feasible (in-memory database, local test server)
-- **Mock at boundaries** -- external services only, not internal modules
-- **Keep mocks minimal** -- only mock the methods your code actually calls
-- **Verify mock contracts** -- ensure mocks match real API behavior
-- **Reset mocks between tests** -- prevent shared state and order-dependent failures
+## Shared Principles
 
-## Test Categories
+- **Prefer role-based queries.** Use `getByRole`, `getByLabel`, `getByText` over test IDs or CSS selectors.
+- **Never sleep.** Use framework-provided waiting mechanisms (`waitFor`, `findBy*`, web-first assertions).
+- **One assertion focus per test.** Multiple assertions are fine if they verify facets of the same behavior.
+- **Isolate tests.** No test should depend on another test's side effects. Reset state between tests.
 
-| Category | Scope | Speed | Quantity |
-|---|---|---|---|
-| **Unit tests** | Single function or class | Fast | Many |
-| **Integration tests** | Multiple components together | Slower | Some |
-| **End-to-end tests** | Full user flow | Slowest | Few |
+## Mocking Rules
 
-The ratio should be roughly pyramid-shaped: many unit tests, some integration tests, few E2E tests.
+- Prefer real dependencies (in-memory DB, local server) when feasible.
+- Mock at boundaries only (external APIs, email, payments), not internal modules.
+- Keep mocks minimal -- only methods your code calls. Reset between tests.
+- Verify mocks match the real API. Update when APIs change.
 
 ## Property-Based Testing
 
-When a function has a contract ("for all valid inputs X, property Y holds"), use property-based tests to verify across generated inputs instead of hand-picked examples:
+When a function has a contract ("for all valid inputs X, property Y holds"), use property-based tests to verify it across generated inputs instead of hand-picked examples:
 
 ```typescript
 // Instead of testing 3-4 specific inputs:
 test("sort is idempotent", () => {
-  fc.assert(fc.property(fc.array(fc.integer()), (arr) => {
-    const sorted = mySort(arr);
-    expect(mySort(sorted)).toEqual(sorted);
-  }));
+  fc.assert(
+    fc.property(fc.array(fc.integer()), (arr) => {
+      const sorted = mySort(arr);
+      expect(mySort(sorted)).toEqual(sorted);
+    }),
+  );
 });
 ```
 
@@ -89,7 +102,7 @@ Good candidates: serialization round-trips, math properties, parsers, encoding/d
 
 ## Bun Test Runner
 
-Bun includes a built-in test runner with no additional dependencies:
+Bun includes a built-in test runner. Use `bun test` for projects on the Bun runtime:
 
 ```bash
 bun test                       # run all *.test.ts files
@@ -98,21 +111,30 @@ bun test --coverage            # with code coverage
 bun test path/to/file.test.ts  # single file
 ```
 
-Supports `describe`, `it`/`test`, `expect`, lifecycle hooks, and snapshot testing out of the box.
+Bun supports `describe`, `it`/`test`, `expect`, lifecycle hooks, and snapshot testing out of the box with no additional dependencies.
+
+## Test Speed
+
+Three levers recur across common runners (Vitest, Playwright, Storybook browser mode). Stated once here; each stack skill carries the framework-specific syntax.
+
+- **Parallelism sized to the runner.** Enable file-level parallelism (Vitest `fileParallelism`, Playwright `fullyParallel`), but cap workers to the runner's _real_ vCPUs (`"50%"` or a measured count). GitHub standard runners are 2 vCPU (private) / 4 (public); oversubscribing thrashes.
+- **Shard across CI jobs, then merge the blob reports.** Sharding splits at the _file_ level (`--shard=i/n`), so wall-clock is gated by the slowest shard -- balance file sizes. Always emit a blob report per shard (`--reporter=blob`) and merge it (`merge-reports` / `--merge-reports`) in a dependent job, or results and coverage are fragmented and incomplete.
+- **Skip isolation where state is clean.** Per-file environment isolation is the safe default but the biggest run-speed cost. Disable it (Vitest `isolate: false`, `pool: 'threads'`) only for side-effect-free logic suites; keep it where tests mutate globals/env/timers.
+
+Profile before tuning, and never `sleep` to mask timing -- use the framework's auto-waiting (see Shared Principles).
+
+Per-runner config (if the stack is installed): `ct-vite-vitest-patterns`, `ct-playwright-patterns`, `ct-storybook-patterns`.
 
-## Anti-patterns
+## Anti-Patterns
 
-| Anti-pattern | Description |
-|---|---|
-| **Testing implementation details** | Asserting on internal state or private methods. Breaks on every refactor. |
-| **Overmocking** | When most of the test is mock setup, you are testing mocks, not code. |
-| **Copy-paste test cases** | Duplicated test code becomes a maintenance burden. Use factories and parameterized tests. |
-| **No assertions** | A test that runs code but asserts nothing provides false confidence. |
-| **Ignoring flaky tests** | A sometimes-failing test is either wrong or exposing a real bug. Fix or delete it. |
-| **Testing only the happy path** | Error cases, edge cases, and boundary conditions are where bugs live. |
+1. **Testing implementation** -- Asserting internal state or call counts breaks on refactors.
+2. **Overmocking** -- If most of the test is mock setup, you're testing mocks.
+3. **Copy-paste tests** -- Use factories and parameterized tests.
+4. **No assertions** -- Worse than no test. False confidence.
+5. **Ignoring flaky tests** -- Fix or delete; never skip indefinitely.
+6. **Happy path only** -- Error cases and boundary conditions are where bugs live.
 
 ## Trigger Conditions
 
 - **Keywords:** `test`, `spec`, `tdd`, `mock`, `factory`
 - **File patterns:** `**/*.test.ts`, `**/*.spec.ts`
-- **Excludes:** "e2e", "end-to-end"

package/docs/skills/typescript-conventions.md

@@ -1,6 +1,6 @@
 # TypeScript Conventions
 
-> Strict TypeScript patterns for type safety, readability, and maintainable codebases.
+> Strict TypeScript patterns for type safety, readability, and maintainable codebases. Use when writing or reviewing TypeScript, adding or tightening types, or deciding between type and interface
 
 **Type:** Core Skill (always included)
 **Source:** [`core/skills/ct-typescript-conventions/SKILL.md`](../core/skills/ct-typescript-conventions/SKILL.md)
@@ -36,21 +36,29 @@ Never use `any`. It disables type checking entirely.
 - Use generics when the type varies but has a consistent shape
 - Use specific types when you know the data shape
 
-### Interface vs Type
+### Type vs Interface
 
-- **Prefer `interface`** for object shapes -- extendable, clearer error messages
-- **Use `type`** for unions, intersections, mapped types, and utility types
+- **Default to `type`.** It covers object shapes, unions, intersections, mapped types, and utility types.
+- **Use `interface` only when you need `extends`** (an inheritance hierarchy or declaration merging).
 
 ```typescript
-// Object shape: use interface
-interface User {
+// Default: use type for object shapes
+type User = {
   id: string;
   email: string;
   role: UserRole;
-}
+};
 
-// Union: use type
+// Unions, intersections, utilities: type
 type UserRole = "admin" | "member" | "guest";
+
+// interface only when you need extends
+interface Animal {
+  name: string;
+}
+interface Dog extends Animal {
+  breed: string;
+}
 ```
 
 ### `as const` for Literal Types
@@ -96,7 +104,7 @@ type AsyncState<T> =
 
 ### `satisfies` Operator
 
-Validate a value conforms to a type without widening its inferred type:
+Validate a value conforms to a type while keeping the value's own narrower inferred type instead of collapsing to the annotation. Here it preserves the exact key set (`home`, `user`) rather than the index signature `Record<string, Route>`:
 
 ```typescript
 type Route = { path: string; children?: Route[] };
@@ -106,7 +114,9 @@ const routes = {
   user: { path: "/user/:id", children: [{ path: "settings" }] },
 } satisfies Record<string, Route>;
 
-// routes.home.path is "/" (literal), not string
+// routes.home and routes.user are known keys -- not `Route | undefined` from the index signature.
+// Note: routes.home.path is `string`, NOT the literal "/", because `Route` declares `path: string`,
+// which widens the literal. To keep a literal, target a narrower type (e.g. a union) or add `as const`.
 ```
 
 ### `const` Type Parameters
@@ -115,6 +125,9 @@ Infer literal types from arguments without requiring callers to write `as const`
 
 ```typescript
 function createConfig<const T extends readonly string[]>(names: T): Record<T[number], boolean> {
+  // `Object.fromEntries` is typed to return a wide `Record<string, boolean>`, so a single
+  // localized `as` at a generic helper's return boundary is acceptable here -- it keeps the
+  // public signature precise. This is the narrow exception to the "no `as` casts" anti-pattern.
   return Object.fromEntries(names.map(n => [n, false])) as Record<T[number], boolean>;
 }
 

package/docs/skills/verification-before-completion.md

@@ -1,6 +1,6 @@
 # Verification Before Completion
 
-> Evidence-based completion claims -- never say "done" without proof that the work is correct.
+> Evidence-based completion claims -- never say "done" without proof that the work is correct. Use when about to claim a task is done, fixed, or passing, or before committing or opening a PR
 
 **Type:** Core Skill (always included)
 **Source:** [`core/skills/ct-verification-before-completion/SKILL.md`](../core/skills/ct-verification-before-completion/SKILL.md)

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "claude-toolkit",
-	"version": "0.9.0",
+	"version": "0.11.0",
 	"description": "Reusable Claude Code configuration toolkit with stack-specific connectors",
 	"type": "module",
 	"bin": {
@@ -25,6 +25,8 @@
 		"typecheck": "tsc --noEmit",
 		"lint": "biome check --write",
 		"lint:check": "biome check",
+		"test": "bun test",
+		"postinstall": "bun bin/postinstall.mjs || node bin/postinstall.mjs || exit 0",
 		"prepare": "npx husky"
 	},
 	"lint-staged": {