genesis-compiler 1.10.20 → 1.10.22

package/skills/genesis-deslop/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: genesis-deslop
-description: Deslop the agent's own task changes or explicitly selected commits through a behavior-preserving cleanup pass. Use when asked to Deslop, simplify current work, remove repeated helpers, clarify ownership, or align changed code with established project and technology patterns.
+description: Deslop the agent's own task changes, explicitly selected commits or the whole app through a behavior-preserving cleanup pass. Use when asked to Deslop, simplify current work, remove repeated helpers, clarify ownership, or align changed code with established project and technology patterns.
 ---
 
 # Genesis Deslop
@@ -46,12 +46,19 @@ continue with it directly. Do not generate another prompt.
 Otherwise, before resolving Git scope, run the Genesis
 `prompt --task deslop` operation once using the invocation rule above. For a
 bare `Deslop` request, pass no request argument. When the user names a count,
-commit, or range, pass that exact request as one safely quoted argument. Treat
+commit, or range, pass that exact request as one safely quoted argument. When
+the user asks for the Deslop pass or the whole app, pass Deslop's own pass
+request, `Deslop the whole app.`, exactly; Genesis then adds the pass's `PASS RUN`
+and `PASS RECORD` steps. 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 technology-specific Deslop 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,
+`Deslop the whole app deeply.`, exactly;
+Genesis then adds the run's `DEEP RUN` section.
+
 ## Resolve the cleanup scope
 
 Inspect `git status --short` and the staged and unstaged diffs before editing.
@@ -59,6 +66,13 @@ A dirty worktree is allowed; a prior commit is not required. Preserve the
 existing index and unrelated work. Do not stage, stash, commit, or discard
 changes as a prerequisite or as part of cleanup.
 
+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.
+
 Resolve the user's scope as follows:
 
 - With no stated scope, select only your own changes for the current task,
@@ -73,6 +87,14 @@ Resolve the user's scope as follows:
   deslop; do not silently select the latest commit or somebody else's work.
 - An explicit commit, first-parent count, or range takes precedence over the
   default, regardless of who authored those changes.
+- The whole app, which Deslop's pass request `Deslop the whole app.` names, is
+  the project's own source: every file the project writes and maintains, in
+  every subsystem, whoever changed it and whenever. It never includes generated
+  output or build artifacts, vendored or copied third-party code, dependency
+  directories or lockfiles, retained migration history, or Genesis-derived
+  files under `.genesis/`. Ownership does not narrow this scope, but uncommitted
+  edits by the user or other agents stay as they are. Work through it one
+  subsystem at a time, using the Program's subsystem map.
 - “The last commit” means `HEAD` against its first parent.
 - “The last N commits” means the net surviving change from the first parent
   before those N commits through `HEAD`.
@@ -147,7 +169,26 @@ operation. Summarize the resolved scope and any selected commit identities,
 what became simpler, the behaviors checked before and after, files changed,
 checks actually run, and follow-up findings left unchanged.
 
-Once the pass has finished, end with the prompt's `PASS RECORD` step: the
-Genesis `passes done deslop` 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.
+When the prompt ends with a `PASS RECORD` step, take it once the pass has
+finished: the Genesis `passes done deslop` 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 Deslop
+of your own changes, a section or commits 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:
+
+- each file read in full for code harder to follow than it needs to be, parts
+  grown too big to hold in mind at once, and logic that does one job in
+  different words, each tick naming the behaviours checked before and after;
+- the cross-subsystem item: helpers and logic duplicated across subsystems,
+  including one job written in different words, and a pattern one subsystem
+  follows that another ignores.
+
+Deslop's limits hold in a deep run: behaviour stays as it is, and a defect
+found stays a follow-up finding, left unchanged.

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

@@ -52,12 +52,23 @@ 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.
 
+When the user asks for a deep run of this pass, pass its Deep request,
+`Give the whole app its visual identity 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 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.
@@ -253,7 +264,21 @@ 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.
+When the prompt ends with a `PASS RECORD` step, take it once the pass has
+finished: the Genesis `passes done identity-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 an
+identity 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 screen, every kind of content, each empty state, the loading screen,
+  sign-in, the logo and the icons;
+- the cross-subsystem item: colours, artwork or type defined outside the one
+  module and theme, and any screen the identity has not reached.

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

@@ -0,0 +1,132 @@
+---
+name: genesis-master-pass
+description: Run the project's passes deeply, one after another, through an explicitly requested Master pass over the whole app or the changes since its last completed run, every pass or the ones named, each as that pass's own Deep run, committed and tested before the next starts, with a ledger that lets an interrupted Master pass continue and one combined report. Use when asked for a Master pass, to run every pass, or to run several passes deeply in turn.
+---
+
+# Genesis Master pass
+
+Run the selected passes deeply, one after another, so the software comes out of
+each one committed and tested before the next starts. A Master 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 Master pass request may arrive as a complete Genesis-generated prompt or as a
+direct request such as `Master pass` or `Master pass (security, data, deslop)
+the whole app.`
+
+If the current task already contains `GENESIS CONTEXT` whose task is
+`master-pass`, continue with it directly. Do not generate another prompt.
+
+Otherwise, run the Genesis `prompt --task master-pass` operation once using the
+invocation rule above. For a bare `Master pass`, pass no request argument: it
+runs every pass the project offers over the whole app. When the user names
+passes, pass `Master pass (<their names>) the whole app.` with the names
+separated by commas; a pass's id or title works, with or without "pass". When
+the user asks for the changes since the last completed Master pass, pass that
+run's request from `genesis inspect passes --json` exactly. Genesis refuses a
+name it offers no pass for and names the passes it does; tell the user. Treat
+the printed prompt as the instructions for this same turn and do not generate
+it again.
+
+## What the Master pass adds, and what it does not
+
+The prompt's `MASTER PASS` section lists the passes to run, in order, each with
+the exact request of its own Deep run. Run them in that order, whatever order
+they were named in: the review first, so every later pass starts from tested
+work, then security, so later passes build on the access it fixes, and Deslop
+last, so it cleans up after what the others changed. If you see a reason in
+this project for another order, say so in the report rather than changing it.
+
+Each pass runs as that pass's own Deep run, from its own prompt. Its `DEEP RUN`
+section says how the checklist, evidence, chunks, agents, commits and report
+work, and its skill says what its lens adds and what it may change. The Master
+pass never restates, shortens or loosens that guidance; it adds only the order,
+the checkpoint between passes, the ledger and the combined report.
+
+## Keep the Master ledger
+
+Before the first pass, write the Master ledger at the path the `MASTER PASS`
+section names. It lives in Git's own directory, outside the project's tracked
+files, so an interrupted Master pass finds it again. Record the request, the
+commit it starts from, and each listed pass with its status (to do, running,
+done or skipped), the path of its checklist (the one its `DEEP RUN` names), its
+commits and its checklist count. Update it as each pass starts and finishes.
+
+When a ledger for the same request is already there and not finished, continue
+from it: passes marked done stay done, and a pass marked running continues its
+own checklist from its first unticked item. Any other ledger is replaced.
+
+## Run each pass
+
+For each listed pass, in order:
+
+1. Mark it running in the ledger.
+2. Generate its prompt with the Genesis `prompt` operation and the exact
+   request listed for it, for example `prompt --task security-pass "Security
+   pass the whole app deeply."`, and follow that prompt in full as this pass's
+   instructions, through its own `PASS RECORD` step, which records the pass on
+   its own so its next run since its last completed one starts there.
+3. Where the host can run several agents, the pass gives its chunks to them as
+   its `DEEP RUN` says, as many as the host's test budget and limits allow, and
+   you coordinate them. The passes themselves run one after another, never at
+   the same time, because each one starts from the tree the last one committed.
+4. Checkpoint before the next pass starts: every change of this pass is
+   committed, in small commits of one checklist item or concern each with
+   messages that say what changed and why; nothing is left uncommitted; and the
+   pass's final whole-suite run passed on the committed tree. Record its
+   commits and checklist count in the ledger and mark it done.
+
+A pass that cannot finish, such as one whose failing checks it cannot fix,
+stops the Master pass there: report where it stopped and why, and do not start
+the next pass on a broken tree.
+
+Skip a pass that does not apply to this software, such as the UI or identity
+pass where the software has no screens, and write the reason in the ledger and
+the report. Never skip a pass because it is long or hard.
+
+## Record and report
+
+Once every listed pass is done or skipped, take the prompt's `PASS RECORD` step:
+the Genesis `passes done master-pass <pass id...>` operation, naming the passes
+it ran and leaving out those it skipped, records the Master pass in
+`genesis/passes-added.json`; commit that change as its last commit, so nothing is
+left uncommitted and its next run since the last one starts there.
+
+End with one combined report. Open with the passes run and skipped, and how the
+work was split across agents (or that it ran as one agent). Then, for each pass
+in order: its checklist count and how many ticks rest on each kind of evidence,
+what changed, its commits, its unticked items and the findings left unchanged.
+A pass that changes behaviour on purpose, such as the security, data or
+quality pass, states plainly what now behaves differently; a pass that keeps
+behaviour, such as Deslop, states that behaviour is unchanged and how that was
+proven. For a run since the last Master pass, say which files each pass read in
+full and which it only searched against the whole app. Close with the final
+whole-suite run on the committed tree.

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Genesis Master pass"
+  short_description: "Run every pass deeply, one after another, testing and committing after each"
+  default_prompt: "Use $genesis-master-pass to Master pass the whole app."

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

@@ -53,12 +53,23 @@ 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.
 
+When the user asks for a deep run of this pass, pass its Deep request,
+`Quality 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 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.
@@ -160,7 +171,22 @@ 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.
+When the prompt ends with a `PASS RECORD` step, take it once the pass has
+finished: the Genesis `passes done quality-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 quality
+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 screen and flow, with each of its states (loading, empty, partial,
+  failed, refused, offline, first use) as an item of its own, and every
+  refusal message;
+- the cross-subsystem item: the same state or refusal handled or worded
+  differently in different places.

package/skills/genesis-review/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: genesis-review
+description: Review the work against what the software should do through an explicitly requested review over the whole app, the changes since its last completed run, a named section or the current work, judging the tests (each changed behavior has one that would fail without it; none weakened or skipped), the gaps between intent, code and explanation, and costs that grow with the data, writing only tests and reporting everything else. Use when asked for a review, a review pass, or to check the tests and the work against the Blueprint.
+---
+
+# Genesis review
+
+Judge the work against what the software should do, and the tests against the
+work, and say plainly what was and was not verified. A review 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 review request may arrive as a complete Genesis-generated prompt or as a
+direct request such as `Review` or `Review the Orders section`.
+
+If the current task already contains `GENESIS CONTEXT` whose task is `review`,
+continue with it directly. Do not generate another prompt.
+
+Otherwise, before resolving scope, run the Genesis `prompt --task review`
+operation once using the invocation rule above. For a bare `Review` request,
+pass no request argument. When the user names a section, commits or the
+current work, 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.
+
+When the user asks for a deep run of this pass, pass its Deep request,
+`Review 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 work (default).** The relationship between the Blueprint, the code, the
+  Program and the tests as they stand now.
+- **The whole app.** Every behavior the project's own source exposes and the
+  tests that prove it.
+- **A section or the changes.** A named area, explicit commits, or the current
+  task's changes: the behavior they create or change and its tests.
+
+If the scope is ambiguous, ask which section or changes.
+
+## Boundaries
+
+- The prompt says what a review judges. It edits only tests: it adds or updates
+  the tests changed behavior lacks and changes no product code, Blueprint,
+  Program, Stack or other file. Every other finding is reported with the
+  smallest sensible correction, left unchanged.
+- Run the tests relevant to the scope; report what actually ran and what was not
+  verified, and never report an unrun check as passing.
+
+Leave the review as ordinary uncommitted work for a later normal commit. Never
+amend or rewrite selected commits.
+
+When the prompt ends with a `PASS RECORD` step, take it once the review has
+finished: the Genesis `passes done review` operation records it in `genesis/passes-added.json`,
+an uncommitted change that lands in the review's own commit. Genesis adds that
+step only to the pass's own runs, whose requests it writes itself, so a review
+of a section, commits, a base or the current work is never recorded as the
+pass; neither is a review 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 behavior the source exposes (operation, screen, command or job), each
+  with the test that would fail without it, or the missing test written or
+  reported;
+- every test file: whether it runs in the whole suite, what it proves, what it
+  costs, and any test weakened, skipped or loosened;
+- every list, batch and write path, with its query or call counts at a few rows
+  and at a realistic number;
+- the Blueprint, Program and `genesis/subsystems.md` entries against the code;
+- the cross-subsystem item: the same behavior tested in different ways or not
+  at all, a table with more than one owner, and work over a whole population
+  done inside a request.
+
+Review's limits hold in a deep run: it writes only tests, and every other
+finding is reported and left unchanged.

package/skills/genesis-review/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Genesis review"
+  short_description: "Review the work and its tests against what the app should do"
+  default_prompt: "Use $genesis-review to Review the whole app."