Agent instructions

For a non-trivial task, start with skills/rat-stack-mode.

This file is the repo law for agents and contributors. It holds commands, validation rules, architecture constraints, and project stop rules. Read VISION.md for intent before planning substantial work. VISION.md does not override this file. Pi sessions also load .pi/APPEND_SYSTEM.md and the repo-local extension .pi/extensions/project.ts.

Stack contract

Workspace package.json files declare the pinned stack. README.md summarizes it. Keep dependencies exact. Repo-local config wins. Record drift instead of silently migrating the project.

The base Effect plugin owns diagnostic severity. Child configs may add exact allowedUnstableApis only for modules warned about in that scope34. Do not use subtree prefixes, copy severity maps, or set ignoreEffectWarningsInTscExitCode to true.

Packages

Nouns

Commands

Run pnpm fix only when you intend to rewrite files. Finish with pnpm turbo run check test build.

Deploy

Follow ship and skills/ship/references/project.md for deployment commands, approval, checks, and recovery.

Release the ratstack package

Fence (cheating is uncomfortable)

Why lives in AGENTS.md / VISION.md. The stack and hooks are the enforceable fence. Fence wins over prose.

If a hook fails, fix the failure. Do not disable the fence.

Source-first Effect / XState work

Before writing, reviewing, or refactoring Effect or XState code, read the installed Effect package’s AGENTS.md first, for example packages/core/node_modules/effect/AGENTS.md. It ships with the installed version, so it is never stale. Then inspect vendored source for the pinned versions. Populate mirrors:

pnpm vendor:agent-sources
# or
./scripts/vendor-agent-sources.sh --refresh

Inventory: .agent_sources/README.md is generated in the local source mirror and is not part of this repository.

Refs are derived from the workspace pins, so bumping a package and re-running the script keeps them matched. The pi-effect tool reads the Effect mirror in place; it needs no link.

Mirrors are reference material, not runtime dependencies. Exclude them from typecheck, test, lint, and format. Do not vendor product-specific corpora in this template.

Source control

Preserve existing work. Inspect status before editing, stage only files changed for the current task, and do not commit generated output, secrets, or populated .agent_sources/github.com/ trees. Use the repository’s existing source-control tool; do not initialize or migrate one without approval. Never pass --no-verify to git.

Project law

A child project replaces this section on day one with its own product rules. These rules describe the rat-stack template, not the product in a clone. Keep durable product intent in VISION.md.

Architecture

A child project replaces this section on day one with its own architecture. Record module boundaries, dependency direction, data ownership, and state-machine seams here. Link deeper docs instead of duplicating them.

Wiki writing

Follow write-a-wiki-page for prose, visuals, code excerpts, and content-build diagnostics.

Web feature blueprint

apps/web/src/features/<name>/ holds a thin route and view. It reads the Model and sends Messages; components never handle transport, retries, or process startup. apps/web/src/client/<name>/ owns the Foldkit program: Model, Messages, update, and named Command.define definitions. Remote state lives in the Model, as Foldkit AsyncData or a foldkit/experimental Query. The capability in packages/core is the shared typed edge, imported by both sides. A cartridge owns durable behavior.

One send follows one path: feature → Message → update → named Command → RpcClient over the contract’s toRpcGroup → shared capability → server-side Durable Object or database cartridge. The server stays authoritative. The Command returns a result Message, and update folds it into the Model.

Worker autonomy ladder

A worker acts at the lowest rung that applies. Climb only when the rung below does not cover the step.

At rung 2 or 3, ask one question with a recommendation. Keep doing independent work while you wait. Red CI is work, not a question: reproduce it, fix it, and push.

Never end a turn “waiting” without a wake. Procedure: skills/rat-stack-mode/principles/own-your-wait.md.

Boundaries and sign-off

A child project replaces this section on day one with its own boundaries. This section names changes agents may make directly and changes that need owner approval.


Last changed 2026-11-02 in 7ff40bf. Source on GitHub. Change log.

Linked from

  1. A clean playground. rat-stack does real work with packages that stay easy to add and remove.
  2. add-a-lifecycle-machine. Learn how XState owns a lifecycle while Effect owns its work, errors, and services.
  3. add-a-store. Add persistence through a service named for an application job, with validation, vendor Layers, migrations, bounded reads, and shared backend tests.
  4. Build and run rat-stack (README.md). What is in the repo, how the example works, and how to run it.
  5. CAFE names the Cloudflare, Alchemy, Foldkit and Effect stack. CAFE is a named stack: Cloudflare runs the app, Alchemy declares it, Foldkit draws the UI, and Effect does the typed work.
  6. Effect + Alchemy peer patterns. Source-grounded patterns from repos on nearby Effect and Alchemy pins.
  7. Effect 4 study: September 2026. Dated Effect 4 source studies from September 2026; current versions live in pins.md.
  8. gardener. Keep rat-stack current and clean. Update exact dependency versions, learn from repos on the same versions, and add lint rules before cleanup.
  9. investigate-a-failure. Find the cause of a crash, wrong output, flaky test, or slow run with evidence, fix it at its source, and leave a notebook a person can learn from. Use when something fails intermittently, when the first fix idea is "raise the timeout" or "swap the version", or when asked "why does this break" or "make this stable".
  10. keep-or-cut. Learn which pieces depend on each other, then keep only the ones your project needs.
  11. learn-alchemy. Learn how Alchemy 2 turns an Effect program into a planned Cloudflare deployment.
  12. learn-rat-stack. Trace a capability through Effect, XState, five projections, the CLI, and Alchemy. Try hosted search and read.
  13. Purpose and boundaries of rat-stack (VISION.md). What this starter is for and what a useful copy should keep.
  14. ship. Learn how to ship a change through merge, CI, release, stage deployment, rollout, verification, rollback and flags.
  15. uncomplect. Find responsibilities that a rat-stack design combines, separate them into capabilities, cartridges, machines, features, and clients, and enforce that separation through types and checks. Use when asked to simplify, review, or replace a design, "what would Rich Hickey do", "optimize for deletion", or "define this error out of existence".