@@ -46,10 +46,10 @@ When the trace cannot resolve with the files at hand, drop the finding.
 
 ## Severity ladder
 
-| Level | Criteria |
-|-------|----------|
+| Level      | Criteria                                                                                                                                                                                                                                       |
+| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | **medium** | New optimistic-mutation code that bypasses `Atom.optimistic` / `Atom.optimisticFn` and rolls its own pending state. Or a mixed read/write where the read goes through the plain query atom and the write goes through the optimistic mutation. |
-| **low** | Subtle defects in an `Atom.optimisticFn` reducer that work today but degrade under racing (clock-based identity, missing `Atom.family` wrapper, computed-once captures of `scopeId`). |
+| **low**    | Subtle defects in an `Atom.optimisticFn` reducer that work today but degrade under racing (clock-based identity, missing `Atom.family` wrapper, computed-once captures of `scopeId`).                                                          |
 
 Do not invent `high`. Pick `low` when in doubt and explain why.
 
@@ -103,9 +103,7 @@ export const updateSecretOptimistic = Atom.family((scopeId: ScopeId) =>
     Atom.optimisticFn({
       reducer: (current, arg: { path: { secretId: SecretId }; payload: { value: string } }) =>
         Result.map(current, (rows) =>
-          rows.map((r) =>
-            r.id === arg.path.secretId ? { ...r, value: arg.payload.value } : r,
-          ),
+          rows.map((r) => (r.id === arg.path.secretId ? { ...r, value: arg.payload.value } : r)),
         ),
       fn: updateSecret,
     }),
@@ -136,8 +134,12 @@ export interface PendingSecret {
   readonly value: string;
 }
 
-export const useSecretsWithPending = (scopeId: ScopeId) => { /* ... */ };
-export const usePendingSecrets = () => { /* ... */ };
+export const useSecretsWithPending = (scopeId: ScopeId) => {
+  /* ... */
+};
+export const usePendingSecrets = () => {
+  /* ... */
+};
 ```
 
 Flag any new entry in `PendingResource` and any new `use<X>WithPending` / `usePending<X>` hook. The file is closed for new patterns.
 
@@ -96,7 +96,7 @@ throw new Error("Missing source");
 Good in `Effect.gen`:
 
 ```ts
-return yield* new SourceNotFoundError({ sourceId });
+return yield * new SourceNotFoundError({ sourceId });
 ```
 
 Good in combinators:
@@ -112,13 +112,13 @@ If a third-party interface requires throwing, keep the throw at the adapter edge
 Prefer yielding the error directly in generator code:
 
 ```ts
-return yield* new SourceNotFoundError({ sourceId });
+return yield * new SourceNotFoundError({ sourceId });
 ```
 
 Do not write:
 
 ```ts
-return yield* Effect.fail(new SourceNotFoundError({ sourceId }));
+return yield * Effect.fail(new SourceNotFoundError({ sourceId }));
 ```
 
 Use `Effect.fail(...)` in non-generator combinator code:
@@ -167,16 +167,14 @@ Effect.ignore(
 Bad in domain code:
 
 ```ts
-program.pipe(Effect.orDie)
-Effect.die(error)
+program.pipe(Effect.orDie);
+Effect.die(error);
 ```
 
 Good:
 
 ```ts
-program.pipe(
-  Effect.mapError((cause) => new DomainError({ message: "Operation failed", cause })),
-)
+program.pipe(Effect.mapError((cause) => new DomainError({ message: "Operation failed", cause })));
 ```
 
 `Effect.die`, `Effect.dieMessage`, `Effect.orDie`, and `Effect.orDieWith` turn typed failures into defects. Use them only at a true runtime boundary where the host cannot represent typed failures, and keep that usage behind a narrow lint suppression with a `boundary:` reason. Do not use `orDie` to avoid threading an error type through normal Effect code.
@@ -305,16 +303,19 @@ Bad:
 const connectionError = (message: string) =>
   new McpConnectionError({ transport: "remote", message });
 
-return yield* connectionError("Endpoint URL is required");
+return yield * connectionError("Endpoint URL is required");
 ```
 
 Good:
 
 ```ts
-return yield* new McpConnectionError({
-  transport: "remote",
-  message: "Endpoint URL is required",
-});
+return (
+  yield *
+  new McpConnectionError({
+    transport: "remote",
+    message: "Endpoint URL is required",
+  })
+);
 ```
 
 Helpers are allowed only when they do real work, such as:
 
@@ -6,16 +6,19 @@ description: Runbook for releasing the `executor` CLI package (stable and beta).
 # Executor CLI release runbook
 
 ## Authoritative doc
+
 `RELEASING.md` at repo root is the source of truth. This skill encodes the owner's preferences on top of it.
 
 ## What the `executor` CLI actually ships
 
 The CLI binary bundles:
+
 - `apps/cli/**` — CLI source + daemon
 - `apps/local/**` — the web UI (embedded as a virtual module via `apps/cli/src/build.ts:178`) + drizzle migrations (`build.ts:205`)
 - `packages/**` — `core`, `kernel`, `hosts/mcp`, `runtime-quickjs`, and every plugin under `packages/plugins/**`
 
 Does **not** ship in the CLI:
+
 - `apps/cloud/**` (Cloudflare Workers deployment)
 - `apps/marketing/**`, `apps/desktop/**`
 - `examples/**`, `tests/**`
@@ -37,14 +40,17 @@ The owner doesn't want GitHub's auto-generated "PR title by @user" list. Release
 **`apps/cli/release-notes/next.md` is the canonical user-facing changelog.** Per-package workspace `CHANGELOG.md` files are one-line stubs required by `changesets/action@v1` (the GitHub Action wrapping the CLI in `release.yml`) — it reads each bumped package's `CHANGELOG.md` to build the Version Packages PR description and crashes with `ENOENT` if any is missing. The stubs satisfy that read; don't put release content in them.
 
 ### How it's wired
+
 `apps/cli/src/release.ts` reads `apps/cli/release-notes/next.md` and uses
 its contents as the GitHub Release body. If the file is missing or empty,
 falls back to `gh release create --generate-notes`. There's no
 per-version archive in the repo — historical release bodies live on
 GitHub Releases (durable, indexed, linkable).
 
 ### Writing conventions
+
 Structure release-notes files as:
+
 ```
 ## Highlights
 ### <user-facing story>     # e.g. "Per-user OAuth for OpenAPI and MCP sources"
@@ -74,17 +80,20 @@ External contributor bullets end with `Thanks @<user> (#PR)`:
 Do not `Thanks` maintainers, bots, or the repo owner — the lint script rejects `@claude`, `@anthropic`, `@github-actions`, `@dependabot`, `@renovate`, `@rhyssullivan`, `@rhys-sullivan`. Run `bun run lint:release-notes` before pushing notes.
 
 ### When drafting from `git log`
+
 - Look at `git diff v<last>..HEAD -- README.md` first — it's the best single view of user-facing changes.
 - Read commit messages in bulk (`git log --oneline v<last>..HEAD -- apps/cli apps/local packages`), then bucket by theme before writing prose.
 - Don't list every commit. Merge PRs and refactor-chain commits into one line.
 
 ### Pairing with changesets
+
 - A `.changeset/*.md` describes the version bump (semver level + a short summary for the Version Packages PR description). It is **not** the user-facing changelog.
 - If your PR adds a `.changeset/*.md` for the `executor` package, also edit `apps/cli/release-notes/next.md` for the user-facing story. They have different audiences.
 - The `.changeset/*.md` body can be a one-liner pointing at the release-notes section it expands; users read the GitHub release body, not the changeset.
 - Frontmatter is `"executor": patch` (or `minor`/`major` if owner says so).
 
 ### Starting a new release cycle
+
 There's no post-release rename step. When you start work on the next
 release, replace the existing `next.md` content with new entries — the
 previous cycle's content is already preserved on the matching `vX.Y.Z`
 
@@ -16,7 +16,7 @@ sources/connections.
 
 - A list query atom (`Atom.optimistic` wraps the query)
 - Plus one or more mutation atoms that change rows in that list (create / update / delete)
-- And you want the UI to reflect the change *immediately* on click, before the server roundtrip
+- And you want the UI to reflect the change _immediately_ on click, before the server roundtrip
 
 If you only need the UI to be "eventually consistent" (i.e. you're fine waiting
 ~200ms for the server response and the existing reactivity refetch), skip
@@ -109,10 +109,7 @@ existing `reactivityKeys` plumbing still applies — pass them in the call.
 ```typescript
 import { useAtomValue, useAtomSet } from "@effect-atom/atom-react";
 
-import {
-  policiesOptimisticAtom,
-  updatePolicyOptimistic,
-} from "../api/atoms";
+import { policiesOptimisticAtom, updatePolicyOptimistic } from "../api/atoms";
 import { policyWriteKeys } from "../api/reactivity-keys";
 
 export function PoliciesPage() {
@@ -203,10 +200,7 @@ export const removePolicyOptimistic = Atom.family((scopeId: ScopeId) =>
           path: { scopeId: ScopeId; policyId: PolicyId };
           reactivityKeys?: ReadonlyArray<unknown>;
         },
-      ) =>
-        Result.map(current, (rows) =>
-          rows.filter((r) => r.id !== arg.path.policyId),
-        ),
+      ) => Result.map(current, (rows) => rows.filter((r) => r.id !== arg.path.policyId)),
       fn: removePolicy,
     }),
   ),
@@ -244,7 +238,7 @@ read, optimistic create/update/remove, no custom state.
 
 ## When you must NOT use this
 
-- The mutation has cross-cutting effects on data that *isn't* in the same list
+- The mutation has cross-cutting effects on data that _isn't_ in the same list
   (e.g. a single mutation invalidates `tools` AND `policies`). Reactivity keys
   still handle that — optimistic only paints the list-local change.
 - You need to show transient UI state that isn't a row property (toasts,