genesis-compiler 1.10.19 → 1.10.20

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

@@ -0,0 +1,259 @@
+---
+name: genesis-identity-pass
+description: Give software a visual identity of its own (one seed colour, artwork drawn in code for each kind of content, a logo, empty states, a loading screen and a sign-in page) through an explicitly requested identity pass over the whole app, a named section, or the agent's own changes. Use when asked for a visual identity, a look, artwork or a logo, or to make an app look designed rather than like a default template.
+---
+
+# Genesis identity pass
+
+Give the software a look of its own, drawn in code, so it reads as designed
+rather than as a default template. An identity 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
+
+An identity pass request may arrive as a complete Genesis-generated prompt or
+as a direct request such as `Give the app its visual identity`.
+
+If the current task already contains `GENESIS CONTEXT` whose task is
+`identity-pass`, continue with it directly. Do not generate another prompt.
+
+Otherwise, before resolving scope, run the Genesis `prompt --task identity-pass`
+operation once using the invocation rule above. For a bare 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 identity pass
+guidance and any project customization with the portable contract below.
+
+## 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.
+
+- **The whole app (default).** Every screen or view a person sees, the shell,
+  sign-in, the loading screen, the logo and the icons. An identity is
+  app-wide, so this is the scope when none is stated.
+- **A section.** A named area (a module, a route subtree, a set of screens):
+  it receives the app's existing identity, such as art for a new kind of
+  content and its empty states.
+- **The changes.** Your own changes for the current task, or explicit commits,
+  established and resolved as for Deslop: the screens they add or change
+  receive the existing identity.
+
+A narrower scope in an app with no identity yet still needs the foundation
+(the seed, the colour module and the logo, steps 1 and 2 below): build it, and
+report that the rest of the app does not have the identity yet.
+
+## Study the software first
+
+Before drawing anything, run the software and look at its screens, and read the
+Blueprint. Write a short look spec, a few lines kept for the report:
+
+- what the software is for, who uses it, and the tone that suits it;
+- its **content kinds**: the categories people browse, pick or make (recipes
+  by course, workouts by type, books by genre, levels by world). Take them
+  from the data the software already has; do not invent a taxonomy the
+  product lacks. Art that follows the categories helps people recognise an
+  item at a glance;
+- the **style option** below that fits, with the reason, and the seed colour.
+
+## Choose a style option
+
+The look is a choice, not a fixed recipe. Pick the option that fits, or the one
+the person or the project already uses:
+
+- **Calm interface, energetic artwork.** The default for content apps, where
+  people browse, pick or make items. Interface surfaces stay quiet and the
+  generated artwork carries the colour and the energy, so the content stays at
+  the centre and the interface stays readable in both schemes.
+- **Quiet tool.** For work tools, dashboards, administration and developer
+  tools, and command-line programs. The identity lives in the seed colour, the
+  logo, the type and the empty states, with little or no artwork in lists,
+  where density and quick scanning matter more.
+- **The project's own brand.** When the project already has brand colours, a
+  logo or a style guide, follow them: the brand colour becomes the seed and its
+  other colours become named roles. Never redraw a brand's own logo.
+
+Games and other expressive software usually have an art direction already. The
+pass then brings the same discipline to it (one source for its colours, seeded
+variation, contrast, reduced motion) instead of replacing it.
+
+## Build the identity
+
+Draw everything in code when possible: no stock photos, no downloaded images,
+and no new dependency for drawing. Drawn art scales, follows the palette, costs
+little, works offline and carries no licence risk. Artwork the person supplies,
+and a brand's own files, are used as given. Keep the code small and direct, as
+the engineering approach asks: one art component, one colour module, motifs as
+data.
+
+1. **One seed colour.** Generate the interface's colour schemes (light and
+   dark, where the platform has both) from one seed through the technology's
+   own theme mechanism, never by picking each colour by hand: one decision
+   keeps every role consistent, and both schemes follow when it changes. A
+   deep, slightly cool seed usually keeps its character in both schemes.
+   Colour roles the software needs of its own, such as one per content kind,
+   are named theme colours harmonised toward the seed, each with the roles for
+   writing on it and for a container, working in both schemes.
+2. **Every non-interface colour in one place.** Artwork gradients, the logo,
+   the sign-in panel, share images and avatar colours are named constants in
+   one module, each with a short comment saying where it is used. Interface
+   code uses theme roles only, never a literal colour. A colour scattered
+   through screens cannot follow the brand and drifts; this is "Data: one
+   source for each fact" in
+   `.agents/skills/genesis-project/references/sanity-checks.md`.
+3. **Artwork for each content kind.** One art component (a cover) draws an
+   item's art from its kind and a seed, the item's stable id or slug:
+   - per kind, a palette in the colour module: two gradient colours, an accent
+     and a light colour. Each kind has its own distinct gradient, and a brand
+     kind serves items without one;
+   - per kind, a **motif**: a few simple, bold geometric shapes that say what
+     the kind is (a bowl and rising steam for soups, a climbing line for
+     running, stacked spines for books, a leaf for plants). Describe each motif
+     as data (a shape name and its attributes) drawn by one renderer, so a new
+     kind is new data rather than new code;
+   - a **seeded random generator**, so the same item always draws the same art
+     and each item differs a little while staying recognisably its kind. For
+     example, mulberry32 over an FNV-1a hash of `kind:seed`:
+
+     ```js
+     function randomFor(kind, seed) {
+       let h = 2166136261;
+       for (const c of `${kind}:${seed}`) h = Math.imul(h ^ c.charCodeAt(0), 16777619);
+       let s = h >>> 0;
+       return () => {
+         s = (s + 0x6d2b79f5) >>> 0;
+         let n = Math.imul(s ^ (s >>> 15), 1 | s);
+         n = (n + Math.imul(n ^ (n >>> 7), 61 | n)) ^ n;
+         return ((n ^ (n >>> 14)) >>> 0) / 4294967296;
+       };
+     }
+     ```
+
+     Each seed moves the motif's centre a little (right of centre leaves room
+     for text), tilts the gradient within about 25 degrees either way, and
+     scatters a few soft dots behind the motif (small, in the light colour, at
+     low opacity). Never seed from the clock or an unseeded random: the art
+     would change on every load;
+   - drawing: thick strokes with round caps, two or three opacity levels, and
+     the accent used once per motif as its focal point. A wide 2:1 drawing
+     cropped to fill its box serves a card, a strip and a thumbnail alike.
+     Gradients and other definitions get ids unique to their kind and seed, so
+     two covers on one page never share one. The art is decorative: hide it
+     from assistive technology and let the item's title carry the meaning.
+4. **Where the identity appears**, where the software has these:
+   - **content cards** in lists and libraries: the art across the top, then the
+     title, the byline, a short description, chips (kind, level) and one meta
+     line (date, people). A "Featured" group can come before the rest;
+   - **a hero card and a profile header**: a strip of art with the avatar
+     overlapping its lower edge;
+   - **empty states**: a small cover with the state's icon on a disc in its
+     middle, a one-line title, a short hint and one action that gets the
+     person going. An empty screen is often a new person's first one;
+   - **the logo**: a rounded tile with the brand gradient and one bold symbolic
+     mark in two accent colours with a light core. The same drawing is the
+     favicon and the app icons. Draw it inline where possible rather than as a
+     cached image, so it follows the colour module;
+   - **the opening or loading screen**, shown before the software's code runs:
+     the logo, the name and a one-line tagline, with a way to reload if startup
+     fails. Its motion is gentle and stops when reduced motion is asked for;
+   - **sign-in**: on wide windows, a brand panel (a glow from the brand colour
+     into a dark ink, the logo, the name, the tagline and three short lines on
+     what the software does, with a large faint accent ring and a few soft light
+     bubbles); on phones, the logo and the name over a strip of art;
+   - a **command-line program** shows its name and tagline in help and version
+     output and maps its colours to the terminal's, with no colour when
+     `NO_COLOR` is set or the output is not a terminal; a **game** carries the
+     identity on its title and loading screens and its icons.
+5. **Polish that keeps the identity calm.** Follow the selected Stack's UI pass
+   rules for layout; in addition:
+   - while loading, show skeletons with the shape of the real content rather
+     than a spinner, so nothing jumps when the data arrives;
+   - numbers that change use tabular figures (`font-variant-numeric:
+     tabular-nums` on the web), so they do not shift as they change;
+   - a new item entering a list may pop in briefly (from about 0.6 scale,
+     fading in over about 600 ms), with no motion when reduced motion is asked
+     for;
+   - phone navigation follows the platform's own pattern for its size, and a
+     navigation drawer with nothing in it is removed.
+6. **Contrast.** Writing on any content or identity colour reaches at least
+   4.5:1 (WCAG AA for body text) in every scheme; aim for about 5.4:1 with white
+   writing on identity colours, since art and gradients vary beneath it.
+   Measure the ratios rather than judging by eye.
+
+## Boundaries
+
+- The pass changes how the software looks and adds only the few words an
+  identity needs (a tagline, the sign-in lines, empty-state hints). It does not
+  change what the software does: no feature, field, action, permission,
+  validation or data change. New words go through the project's translation
+  mechanism where it has one. A defect, missing behavior or test gap you notice
+  is a follow-up finding, left unchanged.
+- The selected Stack's identity pass guidance says where each piece lives;
+  the identity never breaks a design rule the Stack marks as must-fix.
+- **Fix at the owner.** When the framework itself blocks a result, report the
+  exact framework change instead of overriding it in the app's styles.
+- You may add the art components, the colour module, the logo and icon files,
+  the loading screen and their styles, place the art in screens, and update
+  tests whose markup changed; every behavior assertion stays. Do not edit
+  `.genesis/`, Git metadata, dependency directories, generated build output,
+  retained migration history, or external resources.
+
+## Prove it
+
+- Take screenshots of the main list, a detail page, an empty state, sign-in
+  (wide and phone) and the profile, at phone and desktop widths (390 and 1280
+  pixels on the web), in light and dark, through the host's managed browser or
+  a temporary browser test. Look at every one. Keep them out of the
+  repository's tracked files, delete temporary test files, and close every
+  browser you start.
+- Confirm that every content kind has its own art, that the same item draws the
+  same art on every load (render one seed twice, or reload and compare), and
+  that two items of one kind differ.
+- Measure the contrast of writing on each identity colour in both schemes.
+- Confirm that nothing shifts while loading: compare the skeleton and the
+  loaded frame, or read the platform's layout-shift measure.
+- Run the checks the Stack guidance names and the focused tests of the
+  affected screens.
+- Update the Blueprint with a short paragraph describing the look in plain
+  words: the style option, the seed's character, and the art for each kind of
+  content. It is product intent, so it names no files.
+
+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 look spec (style option, seed, content kinds and their motifs), what
+changed, files changed, the checks, contrast figures and screenshots actually
+taken (with their paths), and follow-up findings left unchanged.
+
+Once the pass has finished, end with the prompt's `PASS RECORD` step: the
+Genesis `passes done identity-pass` operation records it in `genesis/passes.json`, an
+uncommitted change that lands in the pass's own commit. A pass that stopped
+early, was abandoned or still has failing checks is not recorded.

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Genesis identity pass"
+  short_description: "Give the app a visual identity of its own"
+  default_prompt: "Use $genesis-identity-pass to give the whole app its visual identity."

package/skills/genesis-project/references/sanity-checks.md

@@ -284,7 +284,9 @@ across screens, navigation, layout at the standard widths, focus, the real
 sign-in); a new browser check is an assertion in the existing test that already
 reaches that screen, and a new browser test file is for a new flow. The app's
 own delays (retry backoff, debounce, polling) run on a fake clock, never in
-real time.
+real time. A test's own time limit covers only its own work: what it needs
+is loaded when its file loads, not inside the timed test, so a slow first load
+on a busy machine cannot fail it.
 
 **Check:** after every run, read the suite time, each phase's time
 (preparation, import, sign-in, tests) and the slowest files. A wall time close
@@ -313,6 +315,9 @@ advance the clock instead, unless another test already proves that path.
   existing browser test could carry the one layout assertion for nothing.
 - A browser test waited out the app's two retries of a failed request in real
   time, 3 s on every run.
+- A test loaded its modules inside its 20 s limit, and on a busy machine
+  after a fresh install the loading alone used it up; loading them with the
+  file moved about 9 s out of the test, which then took under a second.
 
 **Outer limit:** a suite running for hours (a small app's for an hour),
 preparation in minutes, or a limit ten times the measured need. A new test

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

@@ -0,0 +1,166 @@
+---
+name: genesis-quality-pass
+description: Make software hold up in real use through an explicitly requested quality pass over the whole app, a named section, or the agent's own changes, covering loading, empty and error states, nothing jumping, edge cases, every refusal explained to the person, and accessibility basics, verified by actually using it. Use when asked for a quality pass, polish, robustness, or to check every state and edge case.
+---
+
+# Genesis quality pass
+
+Make the software behave well in the situations people really meet, and prove
+it by using it. A quality 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 quality pass request may arrive as a complete Genesis-generated prompt or as
+a direct request such as `Quality pass` or `Quality pass the Orders section`.
+
+If the current task already contains `GENESIS CONTEXT` whose task is
+`quality-pass`, continue with it directly. Do not generate another prompt.
+
+Otherwise, before resolving scope, run the Genesis `prompt --task quality-pass`
+operation once using the invocation rule above. For a bare `Quality 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 quality pass guidance and any project customization with the portable
+contract below.
+
+## 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.
+
+- **The whole app (default).** Every screen, command and flow a person uses.
+- **A section.** A named area (a module, a route subtree, a set of screens or
+  commands): every screen and flow in it, touched or not.
+- **The changes.** Your own changes for the current task, or explicit commits,
+  established and resolved as for Deslop: the screens and flows they create or
+  change.
+
+If the scope is ambiguous, ask which section or changes.
+
+## List the states before changing anything
+
+For each screen, command or flow in scope, write down what it shows or does,
+where its data comes from, and each state it can be in: loading, empty, partial,
+full, failed, refused, slow or offline, and first use. Mark which states exist
+and which are missing or wrong. A missing state stays invisible in a demonstration
+with good data and is often the first thing a real person meets.
+
+## Apply the quality contract
+
+The sanity checks guide
+(`.agents/skills/genesis-project/references/sanity-checks.md`) sections
+"Screens in use", "The wait a person sees", "Inputs and access" and "Tests that
+prove behavior" describe what good looks like. This pass works through the
+whole scope with them and fixes what it finds:
+
+- **Loading.** A wait shows a stable placeholder in the shape of what arrives,
+  never a blank screen, so nothing jumps when the data does. An action shows
+  that it is working and cannot be sent twice. Long work in a command-line
+  program reports progress.
+- **Empty.** An empty view says what would be there and offers the next useful
+  action. A first-use empty state differs from "nothing matches this filter",
+  which offers clearing the filter.
+- **Errors.** A failure says what happened, in the person's words, and what
+  they can do; it offers a retry where retrying can help, keeps what the person
+  typed, appears where the failure happened (beside the field, in the panel
+  that failed) and never covers the next action. A failure is never silent and
+  never a raw code or stack trace.
+- **Nothing jumps.** Layout keeps its place through loading, arriving data,
+  feedback and errors, and feedback never covers the control the person reaches
+  for next.
+- **Edge cases.** Try the ones that apply: very long and very short text,
+  missing optional values, zero, one and many items, large numbers, dates near
+  midnight and in another time zone, duplicates, a double click or double
+  submit, refresh or back in the middle of an action, two tabs, an expired
+  session, a slow or dropped connection. Fix what breaks, or report it.
+- **Every refusal explained.** When the software refuses (invalid input, a
+  missing permission, a limit, a conflict, missing setup), the person sees what
+  was refused, why, and what they can do about it, in words they understand.
+  The server keeps the refusal's status, code and message to the client, and
+  the client shows that message rather than a generic failure. A refusal stays
+  a refusal: this pass explains it and never loosens it.
+- **Accessibility basics.** Every control can be reached and used from the
+  keyboard in a sensible order, with visible focus; every field and icon-only
+  control has a name; status, selection and errors are never shown by colour
+  alone; contrast is at least WCAG AA in every scheme; text still works at 200%
+  zoom; motion stops when reduced motion is asked for; touch targets are about
+  48 pixels; meaningful images have text alternatives and decorative ones are
+  hidden. A command-line program uses meaningful exit codes, writes errors to
+  standard error, has `--help` and honours `NO_COLOR`; a game offers
+  remappable controls and subtitles for its speech where it has them.
+
+## Use it
+
+Verification is using the software as a person does, through its real
+interface (a browser, a terminal, a device), not reading its code:
+
+- use it as a new person (first run, no data) and as a returning one with
+  realistic data (hundreds of items, long names, a long history);
+- walk each flow in scope to its end, then force each state: slow the network
+  or the server, go offline, make the server fail, empty the list, enter wrong
+  input, act without permission;
+- go through each flow once with the keyboard only;
+- take screenshots of each state you changed at phone and desktop widths (390
+  and 1280 pixels on the web), in light and dark, and look at every one. Keep
+  them out of the repository's tracked files, delete temporary test files, and
+  close every browser and process you start;
+- lock in each fix with a test at the cheapest level that proves it, as the
+  sanity checks guide's "Tests: time" describes, and run the focused tests of
+  the affected areas and the checks the Stack guidance names.
+
+## Boundaries
+
+- The pass changes behavior only to handle a state or an edge case and to
+  explain a refusal. It adds no feature and changes no permission, product rule
+  or stored data; a larger gap is a follow-up finding, left unchanged.
+- The selected Stack's quality pass guidance names where states, errors and
+  refusals live in its technology; follow it.
+- **Fix at the owner.** When the framework itself blocks a result, report the
+  exact framework change instead of working around it in the app.
+- You may edit source, styles, messages 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,
+the states listed for each screen or flow with what was missing and what
+changed, the edge cases tried and their results, the refusals reworded, the
+accessibility checks, the screenshots and tests actually taken and run (with
+their paths), files changed, and follow-up findings left unchanged.
+
+Once the pass has finished, end with the prompt's `PASS RECORD` step: the
+Genesis `passes done quality-pass` operation records it in `genesis/passes.json`, an
+uncommitted change that lands in the pass's own commit. A pass that stopped
+early, was abandoned or still has failing checks is not recorded.

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Genesis quality pass"
+  short_description: "Make every state, edge case and refusal hold up in use"
+  default_prompt: "Use $genesis-quality-pass to quality pass the whole app."

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

@@ -109,3 +109,8 @@ commit. Never amend or rewrite the selected commits. Summarize the resolved
 scope and any commit identities, what changed, files changed, the checks and
 screenshots actually taken (with their paths), and follow-up findings left
 unchanged.
+
+Once the pass has finished, end with the prompt's `PASS RECORD` step: the
+Genesis `passes done ui-pass` operation records it in `genesis/passes.json`, an
+uncommitted change that lands in the pass's own commit. A pass that stopped
+early, was abandoned or still has failing checks is not recorded.

package/src/cli-commands.js

@@ -14,6 +14,8 @@ import {
   inspectEnvironment,
   inspectStackSection,
   inspectSubsystems,
+  inspectPasses,
+  recordPassDone,
   inspectProject,
   inspectSkills,
   installCodex,
@@ -70,6 +72,7 @@ async function execute({ command, operands, options }, { signal, hostContext = n
   }
   if (command === 'migrate') return migrate({ projectRoot, stackPackages });
   if (command === 'skills') return syncSkills({ projectRoot, stackPackages });
+  if (command === 'passes') return { action: 'done', ...await recordPassDone({ projectRoot, pass: operands[1] }) };
   if (command === 'adopt') {
     return adoptProject({ projectRoot, request: operands.join(' '), stackPackages });
   }
@@ -148,7 +151,13 @@ async function execute({ command, operands, options }, { signal, hostContext = n
         }),
       };
     }
-    const inspections = { subsystems: inspectSubsystems, environment: inspectEnvironment, project: inspectProject, skills: inspectSkills };
+    const inspections = {
+      subsystems: inspectSubsystems,
+      environment: inspectEnvironment,
+      project: inspectProject,
+      skills: inspectSkills,
+      passes: inspectPasses,
+    };
     return {
       inspection: operands[0],
       ...await inspections[operands[0]]({ projectRoot, stackPackages }),

package/src/cli.js

@@ -26,6 +26,7 @@ const USAGE = `Usage:
   genesis stack list
   genesis stack add <piece...>
   genesis skills sync
+  genesis passes done <pass>
   genesis templates list
   genesis templates apply <catalogue:technology/variant>
   genesis context <path...>
@@ -38,9 +39,10 @@ const USAGE = `Usage:
   genesis inspect environment
   genesis inspect project
   genesis inspect skills
+  genesis inspect passes
   genesis inspect section <name>
   genesis prompt [request...]
-  genesis prompt --task <start|adopt|work|deslop|ui-pass|program|blueprint|describe|review> [request...]
+  genesis prompt --task <start|adopt|work|deslop|ui-pass|identity-pass|quality-pass|data-pass|program|blueprint|describe|review> [request...]
   genesis verify
   genesis check
 
@@ -61,7 +63,7 @@ prompt to the agent you already use. Review all edits through the ordinary Git
 diff, then run genesis verify for the Stack's concrete checks.
 `;
 
-const COMMANDS = new Set(['adopt', 'check', 'codex', 'collaboration', 'context', 'engineering', 'hook', 'index', 'init', 'inspect', 'migrate', 'parsers', 'prompt', 'skills', 'stack', 'templates', 'verify']);
+const COMMANDS = new Set(['adopt', 'check', 'codex', 'collaboration', 'context', 'engineering', 'hook', 'index', 'init', 'inspect', 'migrate', 'parsers', 'passes', 'prompt', 'skills', 'stack', 'templates', 'verify']);
 
 function parseCommand(argv) {
   if (argv.length === 0 || argv.includes('--help') || argv.includes('-h') || argv[0] === 'help') {
@@ -176,6 +178,10 @@ function parseCommand(argv) {
     if (operands.length !== 1 || operands[0] !== 'sync') {
       fail('CLI_SKILLS_ACTION_REQUIRED', 'Command skills requires exactly: sync.');
     }
+  } else if (command === 'passes') {
+    if (operands.length !== 2 || operands[0] !== 'done') {
+      fail('CLI_PASSES_ACTION_REQUIRED', 'Command passes requires exactly: done <pass>.');
+    }
   } else if (command === 'codex') {
     if (operands.length !== 1 || operands[0] !== 'install') {
       fail('CLI_CODEX_ACTION_REQUIRED', 'Command codex requires exactly: install.');
@@ -183,12 +189,12 @@ function parseCommand(argv) {
   } else if (command === 'context' && operands.length === 0) {
     fail('CONTEXT_PATH_REQUIRED', 'Command context requires at least one project path.');
   } else if (command === 'inspect') {
-    const ordinaryInspection = operands.length === 1 && ['environment', 'project', 'skills', 'subsystems'].includes(operands[0]);
+    const ordinaryInspection = operands.length === 1 && ['environment', 'passes', 'project', 'skills', 'subsystems'].includes(operands[0]);
     const sectionInspection = operands.length >= 2 && operands[0] === 'section';
     if (!ordinaryInspection && !sectionInspection) {
       fail(
         'CLI_INSPECT_TARGET_REQUIRED',
-        'Command inspect requires project, environment, skills, subsystems, or section <name>.',
+        'Command inspect requires project, environment, skills, passes, subsystems, or section <name>.',
       );
     }
   } else if (command === 'hook' && (operands.length !== 1 || !['discover', 'session', 'turn'].includes(operands[0]))) {
@@ -304,6 +310,17 @@ function writeResult(command, result) {
     else line(process.stdout, `Parsers verified: ${result.languages.join(', ')}`);
     return;
   }
+  if (command === 'inspect' && result.inspection === 'passes') {
+    for (const pass of result.passes) {
+      line(process.stdout, `${pass.id}: ${pass.title} — ${pass.description}`);
+      line(process.stdout, `  recommended ${pass.recommend.hint}; Stack guidance: ${pass.stackGuidance ? 'yes' : 'no'}; last run: ${pass.lastRun ?? 'never'}`);
+    }
+    return;
+  }
+  if (command === 'passes') {
+    line(process.stdout, `${result.pass}: recorded ${result.lastRun} in ${result.path}`);
+    return;
+  }
   if (command === 'inspect' && result.inspection === 'skills') {
     line(process.stdout, `Agent Skills: ${result.status}`);
     for (const skill of result.skills) line(process.stdout, `  - ${skill.name}: ${skill.status}`);

package/src/index/agent-skills.js

@@ -17,6 +17,7 @@ import { parse as parseYaml } from 'yaml';
 
 import { asDiagnostic, GenesisError } from './errors.js';
 import { claudeSkillLinks } from './claude-hooks.js';
+import { PASSES } from './passes.js';
 import { sha256, stableJson, writeFileAtomic } from './utils.js';
 
 const packageRoot = fileURLToPath(new URL('../../', import.meta.url));
@@ -34,12 +35,13 @@ const SKILL_FIELDS = new Set([
   'allowed-tools',
 ]);
 
-const CORE_SKILLS = [
+// Every project's Genesis workflow skills: the project and Program skills, and one for each pass.
+export const CORE_SKILL_NAMES = Object.freeze([
   'genesis-project',
   'genesis-program',
-  'genesis-deslop',
-  'genesis-ui-pass',
-].map((name) => ({
+  ...PASSES.map(({ task }) => `genesis-${task}`),
+]);
+const CORE_SKILLS = CORE_SKILL_NAMES.map((name) => ({
   component: null,
   package: null,
   path: `skills/${name}`,

package/src/index/assets.js

@@ -1,5 +1,7 @@
 import { readFile } from 'node:fs/promises';
 
+import { PASSES } from './passes.js';
+
 const root = new URL('../../', import.meta.url);
 const assets = {
   start: new URL('prompts/start.txt', root),
@@ -9,8 +11,7 @@ const assets = {
   adopt: new URL('prompts/adopt.txt', root),
   work: new URL('prompts/work.txt', root),
   describe: new URL('prompts/describe.txt', root),
-  deslop: new URL('prompts/deslop.txt', root),
-  'ui-pass': new URL('prompts/ui-pass.txt', root),
+  ...Object.fromEntries(PASSES.map(({ task }) => [task, new URL(`prompts/${task}.txt`, root)])),
   program: new URL('prompts/program.txt', root),
   blueprint: new URL('prompts/blueprint.txt', root),
   review: new URL('prompts/review.txt', root),

package/src/index/contracts.js

@@ -2,6 +2,7 @@ export const GENESIS_CONTRACTS = Object.freeze({
   subsystems: 'genesis.subsystems.v0',
   projectInspection: 'genesis.project-inspection.v1',
   promptTasks: 'genesis.prompt-tasks.v1',
+  passes: 'genesis.passes.v1',
   templates: 'genesis.templates.v1',
   templateApplication: 'genesis.template-application.v1',
   collaboration: 'genesis.collaboration.v1',