genesis-compiler 1.10.20 → 1.10.22

package/skills/genesis-security-pass/SKILL.md

@@ -0,0 +1,297 @@
+---
+name: genesis-security-pass
+description: Close the ways software can be misused through an explicitly requested security pass over the whole app, a named section, or the agent's own changes, covering authorization on every route, action and job, sign-in and sessions, input handling, secrets, production settings, dependencies and outbound requests, each finding proved by sending the input that breaks it and seeing it refused once fixed. Use when asked for a security pass, hardening, a security review that fixes what it finds, or to check who can do what.
+---
+
+# Genesis security pass
+
+Make the software refuse what it should refuse, and prove each refusal by
+trying to get past it. A security pass is explicit: never run it merely because
+implementation finished.
+
+Resolve the invocation before running the first Genesis operation. Do not use a
+Genesis operation or `genesis --version` as an availability probe.
+
+1. Read the repository-root `package.json`. Treat Genesis as project-pinned only
+   when that manifest's `name` is `genesis-compiler`, or its `dependencies`,
+   `devDependencies`, or `optionalDependencies` contain the exact
+   `genesis-compiler` key.
+2. For a project-pinned repository, invoke every Genesis CLI operation with
+   `npm exec --no -- genesis <arguments>`. This runs without fetching another
+   package. If the declared package is not installed, report that the project's
+   dependencies are not prepared; do not fall back to another Genesis version.
+3. Otherwise, do not try `npm exec`. Run `command -v genesis` (or the current
+   shell's equivalent `PATH` lookup). When it resolves an executable, invoke
+   `genesis <arguments>` directly.
+4. When neither source is available, stop and report that Genesis is
+   unavailable. Never install or update Genesis merely to satisfy a workflow
+   instruction.
+
+Successful invocation resolution is routine. Do not narrate whether Genesis is
+project-pinned or on `PATH`, and never describe direct `PATH` use as a fallback.
+Mention how the invocation was selected only when resolution fails or the user
+explicitly asks.
+
+Follow the configured Collaboration approach for user-facing updates, including
+its technical depth and response length. Report concrete progress,
+findings, or blockers; do not announce that you are following guidance.
+
+## Load the effective project instructions once
+
+A security pass request may arrive as a complete Genesis-generated prompt or
+as a direct request such as `Security pass` or `Security pass the billing
+section`.
+
+If the current task already contains `GENESIS CONTEXT` whose task is
+`security-pass`, continue with it directly. Do not generate another prompt.
+
+Otherwise, before resolving scope, run the Genesis `prompt --task security-pass`
+operation once using the invocation rule above. For a bare `Security pass`
+request, pass no request argument. When the user names a section, commits or
+your own changes, pass that exact request as one safely quoted argument. Treat
+the printed prompt as the instructions for this same turn; do not dispatch it
+to another agent and do not generate it again. This step composes the selected
+Stack's security pass guidance and any project customization with the portable
+contract below.
+
+When the user asks for a deep run of this pass, pass its Deep request,
+`Security pass the whole app deeply.`, exactly;
+Genesis then adds the run's `DEEP RUN` section.
+
+## Resolve the scope
+
+Inspect `git status --short` and the staged and unstaged diffs before editing.
+A dirty worktree is allowed. Preserve the existing index and unrelated work; do
+not stage, stash, commit, or discard changes as a prerequisite.
+
+When the prompt has a `PASS RUN` section, the request is one of the pass's own
+runs (the whole app, the changes since its last completed run judged against
+the whole app, or a deep run) or a run over the changes since a base commit the
+request names, and its scope is the one that section states, whatever the
+defaults below say. A deep run's prompt also has a `DEEP RUN`
+section; follow it with "Deep run" below.
+
+- **The whole app (default).** Every way in: each route, page, command,
+  action, message or socket handler, webhook, scheduled or background job,
+  file or document the software reads from outside, and every outbound call.
+- **A section.** A named area (a module, a route subtree, a subsystem): every
+  way into it, touched or not.
+- **The changes.** Your own changes for the current task, or explicit commits,
+  established and resolved as for Deslop: the ways in they create or change,
+  and the checks those depend on.
+
+If the scope is ambiguous, ask which section or changes.
+
+## Map the ways in first
+
+Read the engineering approach and these sections of the sanity checks guide
+(`.agents/skills/genesis-project/references/sanity-checks.md`): "Never do
+these", "Inputs and access", "Production settings" and "Tests that prove
+behavior". They describe what good looks like; this pass applies them across
+the whole scope and fixes what they find.
+
+Then list, for the scope, each way in with who may use it (anyone, a signed-in
+person, a role, a member of one tenant or workspace, the owner of a record, the
+system itself), what it reads and changes, each input it takes and where that
+input ends up (a query, a shell command, a template, a file path, a URL the
+server fetches, a message sent to someone), and the secrets it uses. List too
+the sign-in, sign-up, password reset, invitation and token flows, how sessions
+are kept and ended, and how a new deployment gets its first administrator. A
+hole is most often a way in that nobody listed, so the map comes first and
+every later step works through it.
+
+The areas below are advice with their reasons. Apply the ones that fit the
+software: a game without accounts has no password reset, a command-line
+program has no cookies, and a single-person tool may have no tenants. Say
+which areas do not apply, and why.
+
+## Authorization
+
+Every route, action and job refuses a caller without permission, because a
+check that exists only in the interface is skipped by anyone who sends the
+request directly.
+
+- **Decide access first.** Check who the caller is and what they may do before
+  anything else, including before validation answers. A caller without
+  permission who sends a malformed request gets the refusal, not a list of
+  field errors, which would describe what the endpoint accepts.
+- **Trust only the trusted context.** Who is acting, their role and their
+  tenant come from the signed-in session, a verified token or the job's own
+  identity, never from an id, role or tenant the client sends. A client-sent id
+  says which record is wanted; whether this caller may have it is decided on
+  the server every time.
+- **Refuse other people's ids.** Another tenant's or another person's ids are
+  refused everywhere: reading, changing, deleting, listing, exporting, and
+  linking them to your own records. Where possible, scope the query itself by
+  the caller's tenant or ownership, so a forgotten check finds nothing rather
+  than someone else's data.
+- **Fail closed.** A missing value, scope, role, tenant or collaborator (a
+  permission service, a policy, a configured list) refuses rather than allows.
+  "Nothing configured" must never mean "everyone allowed".
+- **Background work too.** A job, queue consumer or scheduled task acting for a
+  person carries that person's access and is held to it when it runs. A
+  webhook verifies its signature, or another proof of its sender, before it
+  trusts its body.
+- **Hidden is not protected.** A button that is not shown, an unlinked page or
+  a long URL still needs the server's check.
+
+## Authentication and sessions
+
+- **Rate-limit what can be guessed or is costly.** Sign-in, sign-up, password
+  reset, verification and one-time codes, invitations, and anything that sends
+  email or messages or costs money, limited per account and per source address
+  where possible, so guessing and flooding are slow and visible. Behind a
+  proxy, make sure the limit counts each client, not the proxy.
+- **Don't reveal who has an account.** Sign-in, sign-up and password reset
+  answer the same way whether or not the account exists ("If that address has
+  an account, we sent a link"), in about the same time.
+- **Keep sessions safely.** Where sessions ride on cookies, make them
+  `HttpOnly`, `Secure` in production and `SameSite` where the app allows it,
+  and protect changing requests against cross-site request forgery. Issue a
+  new session at sign-in, end it at sign-out, and expire it. Tokens and reset
+  links are random, expire, work once where they should, and are compared in
+  constant time.
+- **Store passwords for the purpose.** A slow, salted password hash made for
+  passwords; never a reversible form, and never in a log.
+
+## Input
+
+- **Validate at the boundary.** Check each input where it enters (type, size,
+  range, allowed values) and refuse what does not fit rather than repairing it
+  quietly, so the code behind can rely on what it gets.
+- **Nothing reaches an interpreter unescaped.** Parameterized queries, argument
+  lists instead of shell strings, the template engine's own escaping, and file
+  paths resolved and checked to stay inside the directory they belong to.
+  Markup a person writes is sanitized with an allow-list before anyone else
+  sees it. A value used as a regular expression is escaped or bounded.
+- **Uploads.** Check the type from the content as well as the name, cap the
+  size before reading the whole body, store files under names the server
+  chooses, outside anything served or run as code, and serve them so a browser
+  downloads rather than runs them.
+- **Cap the expensive.** Request bodies, page sizes, list lengths and costly
+  operations have limits, so one request cannot exhaust memory, the database
+  or a paid service.
+
+## Secrets
+
+- **None in code, the repository, logs, errors or client bundles.** Search
+  source, configuration, fixtures, tests, the repository's history where
+  possible, log output, error responses and the built client for keys,
+  tokens, passwords and connection strings. Secrets come from the environment
+  or a secret store when the software runs; the client gets only values meant
+  to be public.
+- **A committed secret is exposed.** Deleting it does not unexpose it: it must
+  be replaced at its issuer, which usually only the person can do. Report it;
+  never copy its value into the report, the chat or a test.
+- **Logs leave secrets out.** Passwords, tokens, session ids and personal data
+  a log has no need for stay out of logs and error reports.
+
+## Production
+
+- **Never development settings.** Production refuses to start without its
+  required settings rather than falling back to a development default: a fixed
+  secret, a debug mode, a local host, permissive cross-origin rules or a
+  development login. Debug pages, test accounts and sample data are off.
+- **The first visitor cannot take it over.** A new deployment gets its first
+  administrator from a setup secret only its operator can read, an invitation
+  or the deployment's owner, never from whoever signs up first.
+- **Errors don't leak.** A failure tells the person what happened in their
+  words and logs the details on the server; a response never carries a stack
+  trace, a query, a file path or internal versions.
+- **Headers fit the software.** A content security policy, transport security,
+  no content-type sniffing and framing protection where it serves web pages,
+  and cross-origin access only for the origins that need it.
+
+## Dependencies and outbound calls
+
+- **Known-vulnerable packages.** Run the ecosystem's dependency audit. Update a
+  vulnerable package to a fixed version, within its declared range where
+  possible, and report each one with no fix, saying whether the vulnerable part
+  is reachable.
+- **Outbound requests a person can aim.** Each request whose address user input
+  chooses (a webhook URL, a link preview, an import from a URL, an image
+  fetch) is checked against server-side request forgery: an allow-list where
+  possible; otherwise refuse loopback, private, link-local and cloud metadata
+  addresses after resolving the name and again on every redirect, and cap its
+  time and size. A redirect whose target a person chooses is held to the
+  software's own origins.
+
+## Try each finding
+
+Reading finds candidates; trying shows which are real. For each risk:
+
+1. Send the input that should break it, against a local or test copy the run
+   controls: a request without a session, as a caller without permission,
+   with another tenant's id, past the rate limit, with a crafted path, a shell
+   or query metacharacter, a script tag, a mistyped or oversized upload, a
+   private address as a URL.
+2. Record what happened. A finding is that request and the answer that should
+   have been a refusal.
+3. Fix it where the protection belongs (the shared policy, the query's scope,
+   the framework's own protection) rather than in one route, so the next way
+   in is protected too.
+4. Send the same input again and see it refused, with the status and message
+   the software uses for that refusal.
+5. Lock it in with a test that sends that input and expects the refusal. Watch
+   it fail once without the fix (undo the fix, run the test, restore it), so
+   the test is known to guard it.
+
+Also try the protections that already exist: send one input each declared
+protection should refuse and see it refused. A protection that is declared but
+never enforced is a finding.
+
+## Boundaries
+
+- **Never weaken a protection to make something pass.** Do not loosen a
+  permission, rate limit, validation, content security policy, sandbox or
+  header to make a test, build, deployment or feature work. When a protection
+  blocks something the person needs, explain the conflict and let them decide.
+- The pass changes how the software checks, refuses, escapes, stores secrets
+  and runs in production. It adds no feature and does not change who the
+  product means to allow to do what; when that intent is unclear (may a member
+  see another member's records?), ask the person and keep the stricter
+  behavior meanwhile.
+- Attacks are tried only against copies the run controls: local servers, test
+  databases and test accounts it creates. Never probe a production deployment,
+  a real person's account or another party's service, and never send real
+  email, messages or payments.
+- **Report what it can't fix.** A secret to replace, a product decision, a
+  hosting setting, a vulnerable dependency with no fix: each is reported with
+  what it needs and who must act. When the framework itself blocks a fix,
+  report the exact framework change instead of working around it in the app
+  (**fix at the owner**).
+- The selected Stack's security pass guidance names where its technology
+  decides access, scopes rows, limits requests, keeps sessions and secrets and
+  switches to production; follow it.
+- You may edit source, configuration, messages and tests in scope; every
+  existing behavior assertion stays. Update dependencies through the package
+  manager. Do not edit `.genesis/`, Git metadata, dependency directories,
+  generated build output, retained migration history, or external resources.
+
+Leave the pass as ordinary uncommitted work for review and a later normal
+commit. Never amend or rewrite selected commits. Summarize the resolved scope,
+the map of ways in, each finding with the input that broke it and the refusal
+seen after the fix, the test guarding each fix and its failing run without the
+fix, the protections tried that already held, the areas that do not apply and
+why, the dependency audit, files changed, checks actually run, and everything
+left unfixed with what it needs and who must act.
+
+When the prompt ends with a `PASS RECORD` step, take it once the pass has
+finished: the Genesis `passes done security-pass` operation records it in `genesis/passes.json`,
+an uncommitted change that lands in the pass's own commit. Genesis adds that
+step only to the pass's own runs, whose requests it writes itself, so a security pass
+of a section, commits or your own changes is never recorded as the pass;
+neither is a pass that stopped early, was abandoned or still has failing
+checks.
+
+## Deep run
+
+When the prompt has a `DEEP RUN` section, follow it: it says how the checklist,
+evidence, chunks, commits and report work for every pass. This pass adds to the
+checklist:
+
+- every way in from the map (each route, page, command, action, handler,
+  webhook, job, file read from outside and outbound call), every sign-in,
+  session and token flow, and every secret;
+- the cross-subsystem item: one resource guarded differently on different
+  ways in, and a protection applied on some ways in but not on others.

package/skills/genesis-security-pass/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Genesis security pass"
+  short_description: "Make every way in refuse what it should, each fix proved by an attack"
+  default_prompt: "Use $genesis-security-pass to security pass the whole app."

package/skills/genesis-speed-pass/SKILL.md

@@ -0,0 +1,351 @@
+---
+name: genesis-speed-pass
+description: Make software and its tests take the time their work needs through an explicitly requested speed pass over the whole app, a named section, or the agent's own changes, covering test speed (the whole suite, its preparation and each file), client speed (first load, navigation, requests and the main thread) and server speed (latency at realistic sizes, startup, hot paths and work that runs without use), each wait measured before and after, its cause fixed, and nothing weakened to get there. Use when asked for a speed pass, when tests, pages, saves, commands or startup are slow, or to find where the time goes.
+---
+
+# Genesis speed pass
+
+Make the software, and the tests that prove it, take the time their work
+needs, and prove each gain by measuring the same wait before and after. A
+speed pass is explicit: never run it merely because implementation finished.
+
+Resolve the invocation before running the first Genesis operation. Do not use a
+Genesis operation or `genesis --version` as an availability probe.
+
+1. Read the repository-root `package.json`. Treat Genesis as project-pinned only
+   when that manifest's `name` is `genesis-compiler`, or its `dependencies`,
+   `devDependencies`, or `optionalDependencies` contain the exact
+   `genesis-compiler` key.
+2. For a project-pinned repository, invoke every Genesis CLI operation with
+   `npm exec --no -- genesis <arguments>`. This runs without fetching another
+   package. If the declared package is not installed, report that the project's
+   dependencies are not prepared; do not fall back to another Genesis version.
+3. Otherwise, do not try `npm exec`. Run `command -v genesis` (or the current
+   shell's equivalent `PATH` lookup). When it resolves an executable, invoke
+   `genesis <arguments>` directly.
+4. When neither source is available, stop and report that Genesis is
+   unavailable. Never install or update Genesis merely to satisfy a workflow
+   instruction.
+
+Successful invocation resolution is routine. Do not narrate whether Genesis is
+project-pinned or on `PATH`, and never describe direct `PATH` use as a fallback.
+Mention how the invocation was selected only when resolution fails or the user
+explicitly asks.
+
+Follow the configured Collaboration approach for user-facing updates, including
+its technical depth and response length. Report concrete progress,
+findings, or blockers; do not announce that you are following guidance.
+
+## Load the effective project instructions once
+
+A speed pass request may arrive as a complete Genesis-generated prompt or as a
+direct request such as `Speed pass` or `Speed pass the Orders section`.
+
+If the current task already contains `GENESIS CONTEXT` whose task is
+`speed-pass`, continue with it directly. Do not generate another prompt.
+
+Otherwise, before resolving scope, run the Genesis `prompt --task speed-pass`
+operation once using the invocation rule above. For a bare `Speed pass`
+request, pass no request argument. When the user names a section, commits or
+your own changes, pass that exact request as one safely quoted argument. Treat
+the printed prompt as the instructions for this same turn; do not dispatch it
+to another agent and do not generate it again. This step composes the selected
+Stack's speed pass guidance and any project customization with the portable
+contract below.
+
+When the user asks for a deep run of this pass, pass its Deep request,
+`Speed pass the whole app deeply.`, exactly;
+Genesis then adds the run's `DEEP RUN` section.
+
+## Resolve the scope
+
+Inspect `git status --short` and the staged and unstaged diffs before editing.
+A dirty worktree is allowed. Preserve the existing index and unrelated work; do
+not stage, stash, commit, or discard changes as a prerequisite.
+
+When the prompt has a `PASS RUN` section, the request is one of the pass's own
+runs (the whole app, the changes since its last completed run judged against
+the whole app, or a deep run) or a run over the changes since a base commit the
+request names, and its scope is the one that section states, whatever the
+defaults below say. A deep run's prompt also has a `DEEP RUN`
+section; follow it with "Deep run" below.
+
+- **The whole app (default).** The test suite and its preparation, every
+  screen, view or command a person opens and the main actions in it, and
+  every route, job, loop or process the software runs.
+- **A section.** A named area (a module, a route subtree, a set of screens or
+  commands, a test folder): its tests, its screens and its server paths,
+  touched or not.
+- **The changes.** Your own changes for the current task, or explicit commits,
+  established and resolved as for Deslop: the tests, screens and paths they
+  create or change, and what they made slower.
+
+If the scope is ambiguous, ask which section or changes.
+
+## Measure first
+
+Read the engineering approach and these sections of the sanity checks guide
+(`.agents/skills/genesis-project/references/sanity-checks.md`): "How to use
+this guide", "Work that repeats or lingers", "The wait a person sees", "Tests:
+time", "Tests: each owns what it uses", "Tests: nothing hangs or lingers",
+"Screens in use" and "Data: loading a dataset". They describe what good looks
+like; this pass measures the whole scope against them and fixes what they
+find.
+
+Then list, for the scope, where people and developers wait: the whole test
+suite and each of its phases, the first screen and each navigation, the main
+actions from click or key press to result, the main routes, commands and jobs,
+startup, and any work that runs while nobody asks for anything. A guess about
+where time goes is usually wrong, and a fix aimed at the wrong place costs
+complexity for nothing, so measure each wait before changing anything:
+
+- **Measure what people meet.** Use a realistic build (the production build,
+  not a development server), realistic data sizes (hundreds of rows in each
+  list, long histories, large files) and, where it matters, a cold start as
+  well as a warm one. A development server, an empty database or a warm cache
+  hides most of what a person waits for.
+- **Record how each number was taken**: the machine and its load, the build,
+  the data size, cold or warm, so the measurement after can be taken the same
+  way. Take each one more than once, and compare like with like: the same
+  machine, load and data before and after.
+- **Prefer counts where they answer the question.** Requests, queries, bytes,
+  processes, renders and preparations per run change less with the machine
+  than clock times do. Use a clock for what only a clock shows, and split each
+  time into its parts (waiting, network, database, computing, rendering)
+  before choosing a fix.
+
+The areas below are advice with their reasons. Apply the ones that fit the
+software: a library has no screens, a command-line program has no first page
+load but has a start-up time, and a game measures frame times and level loads
+more than requests. Say which areas do not apply, and why.
+
+## Test speed
+
+Every person and agent pays for a slow suite on every run, and a slow suite
+gets run less, so defects land later.
+
+Measure:
+
+- the whole suite's wall time, and each phase: preparation (databases,
+  fixtures, builds, servers), loading code, signing in, and the tests;
+- each file's time, and the slowest files and tests;
+- whether files ran together: a wall time close to the sum of the files' times
+  means they ran one after another. Find why: a forced concurrency of one,
+  files that collide on a shared resource, or files marked to run alone
+  without a reason;
+- in each slow file, where its time goes: preparation repeated per file or
+  per test, a migration history replayed, fixed sleeps, polling, a server,
+  browser or build started per test, a sign-in per test, the software's own
+  retries and debounces waited out in real time, or a check made at an
+  expensive level (a browser) that a cheaper one (a unit or component test)
+  proves as well.
+
+Fix the cause, when possible in the shared harness so every file gains:
+
+- **Prepare once per run.** Build databases, fixtures, builds and servers once
+  per run, from a stored schema and seed checked by a digest of their sources,
+  and restore or reuse them from there; replay the full migration history
+  once, as its own check. Something every file only reads (a built app, a
+  generated project, a seeded snapshot) can be prepared once and shared
+  read-only, while a file that writes into it makes its own copy.
+- **Run files in parallel within the machine's test budget.** Isolate what
+  files would share (ports the system picks, temporary directories, a database
+  or schema per file, their own caches) rather than running them one at a
+  time. A file that truly holds a resource of the whole machine runs alone and
+  says why. Stay within the budget: an overloaded machine makes every test
+  slower and some of them flaky.
+- **Wait for events, not time.** Each sleep becomes a wait for the condition it
+  stood for. The software's own delays (retry backoff, debounce, polling) run
+  on a fake clock where the test runner allows it. A wait that often ends at
+  its cap is waiting for the wrong thing.
+- **Prove each behavior at the cheapest level that can.** Move a check that
+  needs no real browser into a unit or component test, and add a new browser
+  assertion to the test that already reaches that screen rather than a new
+  file that signs in again.
+- **Load what a test needs with its file**, not inside its timed body, so its
+  time limit covers only its own work.
+
+Never raise a time limit, add retries, or shrink realistic data or coverage to
+get faster: a raised limit hides the slowness, a retry hides a race, smaller
+data hides work done per row, and a dropped test or assertion stops proving
+behavior. A test that changes its input to skip a wait stops proving the
+skipped path; advance a fake clock instead. A limit far above the measured
+need is a finding too, since it lets the next slowdown pass unseen.
+
+Prove it with the whole suite's wall time before and after, on the same
+machine under the same load, with each phase and the slowest files, and the
+same tests and assertions passing. A faster suite that proves less is not
+faster.
+
+## Client speed
+
+People wait for the first screen, for each navigation, for each action to show
+its result, and for typing, scrolling or a frame that lags.
+
+Measure on a production build, with a cold cache and a warm one, realistic
+data and, where possible, the slower network and device the people who use it
+have:
+
+- what the first screen loads before it shows: scripts, styles, fonts and
+  images, their sizes compressed and not, the largest chunks and what pulls
+  each one in;
+- the network waterfall: requests made one after another that could run
+  together, and requests that wait for code that could have started them
+  sooner;
+- requests per screen and per action: the same request twice, a request per
+  item in a list, polling, and responses much larger than what the screen
+  shows;
+- the main thread: long tasks, re-rendering on each keystroke or tick, work
+  for content nobody can see (a list rendering every row), and for a game or
+  animation, the time per frame, its worst frames and what each spends it on.
+
+Fix the causes:
+
+- **Load what the screen needs.** Split code a screen does not need into
+  chunks loaded with the screens that do, so a library one screen uses does
+  not load on every screen, and keep the first screen's code to what every
+  screen needs.
+- **Batch requests, and drop duplicates.** Related records in one request
+  instead of one per item; one shared read for the same data, however many
+  components show it; independent requests started together.
+- **Drop needless polling.** A poll stands in for an event: listen for the
+  event where the software has one (a push, a socket message, the action that
+  changed the data). A poll that has to stay runs only while its result is
+  visible, as rarely as its purpose allows.
+- **Render what is visible.** Page or virtualize long lists, compute derived
+  values once per change rather than once per render, and move or split work
+  that blocks input.
+- **Keep what does not change.** Content-hashed assets cached for long, images
+  at the size they are shown, and data kept while it is fresh, with a stated
+  rule for when it changes.
+
+Prove it with the numbers before and after: what the first screen loads,
+requests per screen and per action, and the main actions' time from click to
+result, cold and warm.
+
+## Server speed
+
+Measure, on test copies at realistic data sizes:
+
+- latency of the main routes, commands and jobs, the first after a start and
+  later ones, each split into its parts: the database, outbound calls,
+  computing in the process, serializing the answer and waiting;
+- startup, from launch to ready to serve, and what it spends that time on;
+- the hot paths of the slow ones, with a profiler where the time is computing:
+  work repeated on every request whose answer does not change (reading
+  configuration or files, compiling templates or schemas, discovering
+  metadata, building clients or connections);
+- outbound calls made one after another that could run together, or made once
+  per item;
+- what runs while nobody asks for anything: the processes, servers, timers and
+  connections alive after the software has been idle a while, and the work
+  they do.
+
+Fix the causes:
+
+- **Do once what does not change.** Compute it at startup, or cache it with a
+  named owner and a stated rule for when it changes, instead of on every
+  request.
+- **Nothing runs without real use.** Start a process, server or worker when its
+  first real use comes, give it an owner that stops it when it goes idle, and
+  keep answers rather than idle processes.
+- **Run independent work together, within a bound.** Calls that do not depend
+  on each other run concurrently up to a limit, and a call per item becomes
+  one batch.
+- **Work nobody waits for leaves the request.** A slow side effect (sending
+  email, building a report, syncing elsewhere) goes to a queue or a job, so the
+  request answers once its own work is done.
+- **Start-up does only what serving needs.** Defer optional setup to its first
+  use, and keep maintenance out of the paths that serve people.
+- **Answers hold what is used.** Page or stream large answers, and send what
+  the screen shows rather than whole records.
+
+When the time is in the database, the data pass owns the cure: query counts
+that grow with the rows read, reads narrowed in code instead of in the query,
+and indexes for the filters the software really runs belong to the data pass
+skill (`.agents/skills/genesis-data-pass/SKILL.md`). Apply its method to that
+path, with its counts at a few rows and at a realistic size, or report the
+path as a data pass finding when it lies beyond the scope. This pass does not
+restate those rules; it measures the whole wait, end to end, and reports it
+before and after.
+
+## Measure again, and keep it
+
+For each wait:
+
+1. Take the measurement before, recorded as above.
+2. Fix the cause where it belongs (the shared test harness, the build's
+   configuration, the owner of the repeated work, the framework), not at one
+   call site, so the next test, screen or route is fast too.
+3. Take the same measurement after, the same way, and report both as absolute
+   numbers ("163 s to 41 s", "38 requests to 6"), never only as a ratio.
+4. Keep it where a count can guard it: a test that asserts the count (requests
+   per screen, queries per path, processes left after idle, preparations per
+   run, what the first screen's code imports), seen to fail once without the
+   fix. Assert counts rather than tight times, which change with the machine;
+   a time bound, where one is needed, is a generous outer limit set from the
+   measured need.
+5. Run the checks the Stack guidance names, and finish with one whole run of
+   the suite, timed.
+
+## Boundaries
+
+- **Never weaken anything to get faster.** Do not raise a time limit, add a
+  retry, skip, shard away or delete a test, drop an assertion, shrink realistic
+  data, loosen a check or a protection, serve stale data where fresh data is
+  needed, or drop work the product needs. Each hides the cause instead of
+  removing it. When the speed someone wants needs a trade (staler data, a
+  smaller feature, less coverage), explain the trade and let the person
+  decide.
+- The pass changes how the software and its tests spend time, never what they
+  do: no behavior, product rule or result changes. Every existing behavior
+  assertion stays, and a test moved to a cheaper level is named with where it
+  went.
+- Measure on copies the run controls: test databases it creates and drops,
+  local builds and local servers. Never measure against a development or
+  production database, and never load a production deployment or another
+  party's service.
+- Share the machine fairly: stay within its test budget, never fill a shared
+  machine with repeated full runs, and wait for long runs without polling.
+- **Fix at the owner.** When the framework, the test runner or a library causes
+  the slowness, report the exact change it needs instead of working around it
+  in the app.
+- **Report what it can't fix.** A slow outside service, a hosting limit or a
+  product decision is reported with its numbers, what it needs and who must
+  act.
+- The selected Stack's speed pass guidance names its test runner and the
+  machine's test budget, how its build splits client code, its request
+  patterns and how to time its server; follow it.
+- You may edit source, configuration, the test harness and tests in scope;
+  every existing behavior assertion stays. Do not edit `.genesis/`, Git
+  metadata, dependency directories, generated build output, retained
+  migration history, or external resources.
+
+Leave the pass as ordinary uncommitted work for review and a later normal
+commit. Never amend or rewrite selected commits. Summarize the resolved scope,
+each wait with how it was measured and its numbers before and after, each
+cause found and its fix, the whole suite's wall time before and after with its
+phases and slowest files, the tests guarding each fix and their failing run
+without it, the paths handed to the data pass, the areas that do not apply and
+why, files changed, checks actually run, and everything left unfixed with what
+it needs and who must act.
+
+When the prompt ends with a `PASS RECORD` step, take it once the pass has
+finished: the Genesis `passes done speed-pass` operation records it in `genesis/passes.json`,
+an uncommitted change that lands in the pass's own commit. Genesis adds that
+step only to the pass's own runs, whose requests it writes itself, so a speed
+pass of a section, commits or your own changes is never recorded as the pass;
+neither is a pass that stopped early, was abandoned or still has failing
+checks.
+
+## Deep run
+
+When the prompt has a `DEEP RUN` section, follow it: it says how the checklist,
+evidence, chunks, commits and report work for every pass. This pass adds to the
+checklist:
+
+- every slow test file and phase of the suite, every screen's first load and
+  each navigation, every main request, command and job, startup, and work that
+  runs while nobody asks for anything, each measured before and after;
+- the cross-subsystem item: the same work done in several places (repeated
+  setup, duplicate fetches, the same computation on several paths).

package/skills/genesis-speed-pass/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Genesis speed pass"
+  short_description: "Make tests, screens and requests fast, each wait measured before and after"
+  default_prompt: "Use $genesis-speed-pass to speed pass the whole app."