@damiangilgonzalez/harness 1.3.14 → 1.3.16

package/README.md

@@ -8,7 +8,7 @@
 
 [![npm](https://img.shields.io/npm/v/@damiangilgonzalez/harness?color=63d68a&labelColor=12161c&label=npm)](https://www.npmjs.com/package/@damiangilgonzalez/harness)
 [![downloads](https://img.shields.io/npm/dm/@damiangilgonzalez/harness?color=63d68a&labelColor=12161c&label=downloads)](https://www.npmjs.com/package/@damiangilgonzalez/harness)
-[![skills](https://img.shields.io/badge/skills-291-63d68a?labelColor=12161c)](#the-catalog)
+[![skills](https://img.shields.io/badge/skills-294-63d68a?labelColor=12161c)](#the-catalog)
 [![license](https://img.shields.io/badge/license-MIT-63d68a?labelColor=12161c)](LICENSE)
 [![stars](https://img.shields.io/github/stars/ericrisco/rsc-harness?color=63d68a&labelColor=12161c)](https://github.com/ericrisco/rsc-harness/stargazers)
 
@@ -205,7 +205,7 @@ $ rsc onboard
  ██████╗ ███████╗ ██████╗     ← animated gradient wordmark
  ██╔══██╗██╔════╝██╔════╝
  ██████╔╝███████╗██║
-  291 skills · one CLI · zero bloat
+  294 skills · one CLI · zero bloat
 
 How technical should the conversation be?
 How much accompaniment do you want?
@@ -244,7 +244,7 @@ rsc add youtube-api remotion-video   # …grow a channel, edit with Remotion
 rsc add fastapi --target claude,codex   # install into several assistants at once
 rsc install --profile minimal        # the base: orient + suggest + bro + unslop + show-me + eli5 + harness + init + teach
 rsc install --profile core           # floor + the full SDD workflow
-rsc install --profile full           # everything (all 291 skills)
+rsc install --profile full           # everything (all 294 skills)
 rsc install --profile full --without go
 rsc consult "I want to launch a SaaS"  # recommend only, no install
 rsc registry refresh                 # write .rsc/skill-registry.{json,md}
@@ -408,7 +408,7 @@ just asks in plain language.
 
 ## The catalog
 
-291 skills, grouped by what you're trying to do. Click any skill to read its
+294 skills, grouped by what you're trying to do. Click any skill to read its
 `SKILL.md`. It fires on its own when a task matches.
 
 ### 🧭 Core & control plane
@@ -587,7 +587,8 @@ inside `grill-with-docs`.
 
 | Skill | What it does |
 |---|---|
-| [implement](skills/implement/) | Builds one ticket from `to-tickets`. Ordinary work runs `superpowers:executing-plans` instead. |
+| [implement-spec](skills/implement-spec/) | Builds a whole spec from its `to-tickets` graph: parallel subagents in worktrees, one integration branch, `code-review` at the end. |
+| [implement](skills/implement/) | Builds one loose ticket from `to-tickets`. Ordinary work runs `superpowers:executing-plans` instead. |
 
 #### 3 · Interface
 
@@ -621,14 +622,15 @@ When the work touches a screen. Sixteen overlapping skills; pick the one that ma
 
 | The work | Order |
 |---|---|
-| Did not touch a screen | `code-review` |
-| Touched a screen | `revision-de-cambios` → `revision-interfaz` → `code-review` |
+| Did not touch a screen | `code-review` → `pr` |
+| Touched a screen | `revision-de-cambios` → `revision-interfaz` → `code-review` → `pr` |
 
 | Skill | What it does |
 |---|---|
 | [code-review](skills/code-review/) | Two axes in parallel: the repo's standards and the spec. |
 | [revision-de-cambios](skills/revision-de-cambios/) | Reviews the change, reads the removed lines and classifies each finding. Only if it touched a screen. |
 | [revision-interfaz](skills/revision-interfaz/) | Runs the six `mejor-*` skills as one report with a verdict. Only if it touched a screen. |
+| [pr](skills/pr/) | Writes the PR body: a visual summary, before/after evidence, and the merge danger (one-way or two-way door, blast radius). |
 | [handoff](skills/handoff/) | Compacts the session into a handoff document. Optional. |
 
 #### 9 · Other
@@ -638,6 +640,7 @@ When the work touches a screen. Sixteen overlapping skills; pick the one that ma
 | [teach](skills/teach/) | Teaching across sessions. |
 | [muscle-memory](skills/muscle-memory/) | A Python kata gym. |
 | [wait-what](skills/wait-what/) | Handbrake: stop and restate. |
+| [retro](skills/retro/) | Retrospective on a session: what to change in the agent's environment. You approve every change. |
 | [writing-for-agents](skills/writing-for-agents/) | How to write documents an agent consumes. |
 
 ---

package/manifest.json

@@ -1,7 +1,7 @@
 {
-  "version": "1.3.14",
+  "version": "1.3.16",
   "counts": {
-    "skills": 291,
+    "skills": 294,
     "agents": 34,
     "commands": 43,
     "fixedCommands": 10
@@ -1395,7 +1395,7 @@
     },
     {
       "id": "domain-modeling",
-      "description": "Build and refine the project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to keep the domain model up to date.",
+      "description": "Build and sharpen the project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.",
       "tags": [
         "domain-modeling",
         "glossary",
@@ -2467,6 +2467,23 @@
         "full"
       ]
     },
+    {
+      "id": "implement-spec",
+      "description": "Implement the result of /to-spec and /to-tickets in code, orchestrating parallel implementer subagents over the ticket graph.",
+      "tags": [
+        "implementation",
+        "spec",
+        "tickets",
+        "subagents",
+        "orchestration"
+      ],
+      "recommends": [],
+      "profiles": [
+        "core",
+        "ui",
+        "full"
+      ]
+    },
     {
       "id": "ingeniero-diseno-web",
       "description": "Build or redesign polished visual artifacts that render in a browser with HTML/CSS/JavaScript/React — pages, dashboards, prototypes, presentations, animations, UI mockups, and data visualizations. Use for visual front-end creation, design-system exploration, design critique, or explicit browser-based acceptance/QA. Not for back-end, CLI, non-visual code, or converting sources into long-form articles.",
@@ -3786,6 +3803,22 @@
         "full"
       ]
     },
+    {
+      "id": "pr",
+      "description": "Use when writing a PR body: a visual summary, before/after evidence, and the merge danger (one-way or two-way door, blast radius).",
+      "tags": [
+        "pull-request",
+        "review",
+        "evidence",
+        "risk"
+      ],
+      "recommends": [],
+      "profiles": [
+        "core",
+        "ui",
+        "full"
+      ]
+    },
     {
       "id": "presentations",
       "description": "Use when building, theming, or exporting a presentation deck — pitch, sales, keynote, board/QBR, leave-behind one-pager — from slide structure to a token-based theme to PDF or editable PPTX (Marp, Slidev, python-pptx). NOT the words (that is `marketing`), NOT the visual tokens (that is `design`), NOT the investor story arc (that is `pitch-deck`).",
@@ -4288,6 +4321,21 @@
       ],
       "profiles": []
     },
+    {
+      "id": "retro",
+      "description": "Conduct a retrospective on a coding session: find what in the agent's environment (navigation, checks, standards, steering files, tooling) should change so future runs go better.",
+      "tags": [
+        "retrospective",
+        "session-review",
+        "agent-environment"
+      ],
+      "recommends": [],
+      "profiles": [
+        "core",
+        "ui",
+        "full"
+      ]
+    },
     {
       "id": "review-management",
       "description": "Use when a public review needs an on-voice reply, when you need to earn more reviews legally, or when an aggregate rating is slipping across Google Business Profile, Trustpilot, the App Store or Google Play — including deciding reply versus flag, getting an unfair one-star removed rather than merely answered, and wiring programmatic replies. NOT a private support ticket against an SLA (that is `customer-support`), NOT churn, NPS or save plays (that is `retention`).",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@damiangilgonzalez/harness",
-  "version": "1.3.14",
+  "version": "1.3.16",
   "description": "A guided harness builder that turns your goal into a minimal, verified AI-agent setup using strict best practices.",
   "type": "module",
   "bin": {

package/scripts/install-apply.js

@@ -12,7 +12,7 @@ import {
 } from '../targets/agents.js';
 import { projectOptOuts } from '../targets/opt-outs.js';
 import { readState, writeState } from './lib/state.js';
-import { withDefaultSkillFloor } from './lib/default-skill-floor.js';
+import { withCodeFlowFloor, withDefaultSkillFloor } from './lib/default-skill-floor.js';
 import { readManifest, writeManifest } from './lib/manifest-file.js';
 import { createBackup } from './lib/backups.js';
 import {
@@ -354,6 +354,11 @@ export function ignoreLocalState(cwd = process.cwd(), target) {
   if (target) {
     const paths = targetPaths(target, undefined, cwd);
     const rel = (abs) => relative(cwd, abs).split(sep).join('/');
+    // `.claude/worktrees/` is where Claude Code puts the checkout of each isolated branch. Nothing
+    // ignored it, so every file of every worktree showed up as untracked: noise in `git status`, a
+    // `git add .` away from being committed, and the memory hook fingerprinted them all on each turn
+    // (54 s on a project with 964 of them, against a 5 s timeout).
+    if (target === 'claude') wanted.push(CLAUDE_WORKTREES);
     for (const id of Object.keys(readState(paths.stateFile).skills || {})) wanted.push(rel(paths.skillDir(id)));
     // The per-file ledger is derived AND platform-shaped (symlink here, real copy on
     // Windows), so committing it puts two incompatible inventories of one thing in one
@@ -530,7 +535,7 @@ export async function uninstall({ skillIds = [], agentIds = [], target, home, cw
 export function removeTargetInstall({ target, home, cwd = process.cwd() }) {
   const paths = targetPaths(target, home, cwd);
   const state = readState(paths.stateFile);
-  const ignored = [paths.stateFile];
+  const ignored = [paths.stateFile, ...(target === 'claude' ? [join(cwd, CLAUDE_WORKTREES)] : [])];
   const ownedIgnoreEntries = new Set(state.ignoreEntriesAdded || []);
   const owned = [
     ...Object.values(state.skills || {}).flatMap((entry) => entry.files || []),
@@ -626,7 +631,10 @@ export async function syncInstalled({ target, home, cwd = process.cwd(), dryRun
   // mandatory never reaches an existing harness: `add` and `install` apply the floor, sync did
   // not, and sync is the only one an upgrade runs. Applied only to a harness that already declares
   // something: a directory declaring nothing is not a harness missing its floor.
-  const declared = declaredRaw.length ? withDefaultSkillFloor(declaredRaw) : declaredRaw;
+  // Lo mismo con el flujo del gate: si el gate está conectado, sus skills llegan con el update.
+  const declared = declaredRaw.length
+    ? withCodeFlowFloor(withDefaultSkillFloor(declaredRaw), manifest?.onboarding?.plan?.policy)
+    : declaredRaw;
   const declaredAgents = state.explicitAgents?.length ? state.explicitAgents : (manifest?.agents || []);
   if (!declared.length && !declaredAgents.length) return dryRun ? { dryRun: true, synced: [], syncedAgents: [], paths: [] } : { synced: [], syncedAgents: [], backup: null };
   if (dryRun) {
@@ -656,6 +664,7 @@ export async function syncInstalled({ target, home, cwd = process.cwd(), dryRun
 // own knowledge — kept unless `withDocs` is set. Returns the paths touched.
 // Note: backups live under `.rsc/backups/`, which this removes — so purge does not
 // snapshot (a pre-purge backup would delete itself). It is the deliberate escape hatch.
+const CLAUDE_WORKTREES = '.claude/worktrees/';
 const RSC_IGNORE_HEADER = '# rsc local state (hooks, seals, logs) and managed skill links — machine-local';
 
 // Merge consecutive rsc blocks into the first: drop a repeated header and the blank seam before it

package/scripts/lib/default-skill-floor.js

@@ -9,3 +9,17 @@ export const DEFAULT_SKILL_FLOOR = Object.freeze(['orient', 'suggest', 'bro']);
 export function withDefaultSkillFloor(skillIds = []) {
   return [...new Set([...DEFAULT_SKILL_FLOOR, ...skillIds])];
 }
+
+// Las skills del flujo que nombra el gate de código (targets/hook-once.mjs), más `retro`.
+// Un proyecto con el gate conectado tiene que tenerlas todas: si el gate cambia y nombra una
+// skill nueva (`implement-spec`, `pr`), el update la trae en vez de dejar el gate apuntando a
+// algo que no está. Un proyecto sin gate (`codeHooks: false`) no recibe ninguna.
+export const CODE_FLOW_FLOOR = Object.freeze([
+  'grill-with-docs', 'wayfinder', 'to-spec', 'write-adr', 'to-tickets',
+  'implement-spec', 'implement', 'code-review', 'pr', 'retro',
+]);
+
+export function withCodeFlowFloor(skillIds = [], policy) {
+  if (policy?.codeHooks === false) return skillIds;
+  return [...new Set([...skillIds, ...CODE_FLOW_FLOOR])];
+}

package/scripts/lib/domains.js

@@ -27,7 +27,7 @@ export const DOMAINS = [
   { title: 'Motion & interface craft', ids: ['motion-craft', 'ui-engineering', 'variant-explorer'] },
   { title: 'Design & content craft', ids: ['design-loop', 'design', 'design-dna', 'presentations', 'course-storytelling', 'course-builder', 'technical-writing', 'translation-l10n'] },
   { title: 'Knowledge & meta', ids: ['knowledge-ops', 'codebase-onboarding', 'research-ops', 'continuous-learning', 'skill-scout', 'context-budget', 'roast-me', 'show-me', 'eli5', 'fable-operator'] },
-  { title: 'Personal catalog — workflow (Spanish)', ids: ['grill-me', 'grill-with-docs', 'grilling', 'wayfinder', 'to-spec', 'to-tickets', 'to-questionnaire', 'implement', 'revision-de-cambios', 'code-review', 'research', 'prototype', 'domain-modeling', 'handoff', 'write-adr', 'wait-what', 'writing-for-agents', 'claude-project-setup', 'muscle-memory', 'teach'] },
+  { title: 'Personal catalog — workflow (Spanish)', ids: ['grill-me', 'grill-with-docs', 'grilling', 'wayfinder', 'to-spec', 'to-tickets', 'to-questionnaire', 'implement', 'implement-spec', 'pr', 'retro', 'revision-de-cambios', 'code-review', 'research', 'prototype', 'domain-modeling', 'handoff', 'write-adr', 'wait-what', 'writing-for-agents', 'claude-project-setup', 'muscle-memory', 'teach'] },
   { title: 'Personal catalog — interface design (Spanish)', ids: ['flujo-interfaz', 'animar', 'diseno-apple', 'diseno-landing', 'ingeniero-diseno-web', 'leyes-de-percepcion', 'leyes-de-retencion', 'mejor-accesibilidad', 'mejor-colores', 'mejor-layout', 'mejor-redaccion', 'mejor-tipografia', 'mejor-ui', 'sitios-calidad-premio', 'tastemaker', 'video-a-superprompt', 'vocabulario-animacion', 'revision-interfaz'] },
 ];
 

package/skills/domain-modeling/{CONTEXT-FORMAT.md → GLOSSARY-FORMAT.md}

@@ -1,4 +1,4 @@
-# Formato de CONTEXT.md
+# Formato de GLOSSARY.md
 
 ## Estructura
 
@@ -31,18 +31,18 @@ _Evitar_: Comprador, usuario, cuenta
 
 ## Repos de contexto único vs. múltiple
 
-**Contexto único (la mayoría de los repos):** Un solo `CONTEXT.md` en la raíz del repo.
+**Contexto único (la mayoría de los repos):** Un solo `GLOSSARY.md` en la raíz del repo.
 
-**Múltiples contextos:** Un `CONTEXT-MAP.md` en la raíz lista los contextos, dónde viven y cómo se relacionan entre sí:
+**Múltiples contextos:** Un `GLOSSARY-MAP.md` en la raíz lista los contextos, dónde viven y cómo se relacionan entre sí:
 
 ```md
 # Mapa de Contextos
 
 ## Contextos
 
-- [Ordering](./src/ordering/CONTEXT.md) — recibe y rastrea los pedidos de clientes
-- [Billing](./src/billing/CONTEXT.md) — genera facturas y procesa pagos
-- [Fulfillment](./src/fulfillment/CONTEXT.md) — gestiona el picking y el envío en el almacén
+- [Ordering](./src/ordering/GLOSSARY.md) — recibe y rastrea los pedidos de clientes
+- [Billing](./src/billing/GLOSSARY.md) — genera facturas y procesa pagos
+- [Fulfillment](./src/fulfillment/GLOSSARY.md) — gestiona el picking y el envío en el almacén
 
 ## Relaciones
 
@@ -53,8 +53,8 @@ _Evitar_: Comprador, usuario, cuenta
 
 La skill infiere qué estructura aplica:
 
-- Si existe `CONTEXT-MAP.md`, léelo para encontrar los contextos
-- Si solo existe un `CONTEXT.md` en la raíz, es contexto único
-- Si no existe ninguno, crea un `CONTEXT.md` en la raíz de forma perezosa cuando se resuelva el primer término
+- Si existe `GLOSSARY-MAP.md`, léelo para encontrar los contextos
+- Si solo existe un `GLOSSARY.md` en la raíz, es contexto único
+- Si no existe ninguno, crea un `GLOSSARY.md` en la raíz de forma perezosa cuando se resuelva el primer término
 
 Cuando existen múltiples contextos, infiere a cuál corresponde el tema actual. Si no está claro, pregunta.

package/skills/domain-modeling/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: domain-modeling
-description: "Build and refine the project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to keep the domain model up to date."
+description: "Build and sharpen the project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR."
 tags: ["domain-modeling", "glossary", "architecture"]
 profiles: [core, ui, full]
 origin: damiangil
@@ -8,7 +8,7 @@ origin: damiangil
 
 # Modelado de Dominio
 
-Construye y afina activamente el modelo de dominio del proyecto a medida que diseñas. Esta es la disciplina *activa*: cuestionar términos, inventar escenarios límite y escribir el glosario y las decisiones en el momento en que se cristalizan. (Simplemente *leer* `CONTEXT.md` para sacar vocabulario no es esta skill — eso es un hábito de una línea que cualquier skill puede hacer. Esta skill es para cuando estás *cambiando* el modelo, no solo consumiéndolo.)
+Construye y afina activamente el modelo de dominio del proyecto a medida que diseñas. Esta es la disciplina *activa*: cuestionar términos, inventar escenarios límite y escribir el glosario y las decisiones en el momento en que se cristalizan. (Simplemente *leer* `GLOSSARY.md` para sacar vocabulario no es esta skill — eso es un hábito de una línea que cualquier skill puede hacer. Esta skill es para cuando estás *cambiando* el modelo, no solo consumiéndolo.)
 
 ## Estructura de ficheros
 
@@ -16,7 +16,7 @@ La mayoría de los repos tienen un único contexto:
 
 ```
 /
-├── CONTEXT.md
+├── GLOSSARY.md
 ├── docs/
 │   └── adr/
 │       ├── 0001-orders-event-sourced.md
@@ -24,29 +24,31 @@ La mayoría de los repos tienen un único contexto:
 └── src/
 ```
 
-Si existe un `CONTEXT-MAP.md` en la raíz, el repo tiene varios contextos. El mapa indica dónde vive cada uno:
+Si existe un `GLOSSARY-MAP.md` en la raíz, el repo tiene varios contextos. El mapa indica dónde vive cada uno:
 
 ```
 /
-├── CONTEXT-MAP.md
+├── GLOSSARY-MAP.md
 ├── docs/
 │   └── adr/                          ← decisiones de todo el sistema
 ├── src/
 │   ├── ordering/
-│   │   ├── CONTEXT.md
+│   │   ├── GLOSSARY.md
 │   │   └── docs/adr/                 ← decisiones específicas del contexto
 │   └── billing/
-│       ├── CONTEXT.md
+│       ├── GLOSSARY.md
 │       └── docs/adr/
 ```
 
-Crea los ficheros de forma perezosa: solo cuando tengas algo que escribir. Si no existe `CONTEXT.md`, créalo cuando se resuelva el primer término. Si no existe `docs/adr/`, créalo cuando haga falta el primer ADR.
+Si el repo todavía tiene un `CONTEXT.md` (o `CONTEXT-MAP.md`) de antes del cambio de nombre, renómbralo con `git mv` a `GLOSSARY.md` (o `GLOSSARY-MAP.md`) antes de seguir, y díselo al usuario en una línea.
+
+Crea los ficheros de forma perezosa: solo cuando tengas algo que escribir. Si no existe `GLOSSARY.md`, créalo cuando se resuelva el primer término. Si no existe `docs/adr/`, créalo cuando haga falta el primer ADR.
 
 ## Durante la sesión
 
 ### Contrasta contra el glosario
 
-Cuando el usuario use un término que entre en conflicto con el lenguaje ya existente en `CONTEXT.md`, señálalo de inmediato. "Tu glosario define 'cancelación' como X, pero parece que te refieres a Y — ¿cuál es?"
+Cuando el usuario use un término que entre en conflicto con el lenguaje ya existente en `GLOSSARY.md`, señálalo de inmediato. "Tu glosario define 'cancelación' como X, pero parece que te refieres a Y — ¿cuál es?"
 
 ### Afina el lenguaje difuso
 
@@ -60,11 +62,11 @@ Cuando se estén discutiendo relaciones del dominio, ponlas a prueba con escenar
 
 Cuando el usuario afirme cómo funciona algo, comprueba si el código coincide. Si encuentras una contradicción, sácala a la luz: "Tu código cancela Pedidos enteros, pero acabas de decir que la cancelación parcial es posible — ¿cuál es la correcta?"
 
-### Actualiza CONTEXT.md sobre la marcha
+### Actualiza GLOSSARY.md sobre la marcha
 
-Cuando un término quede resuelto, actualiza `CONTEXT.md` ahí mismo. No los acumules — captúralos según ocurren. Usa el formato de [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
+Cuando un término quede resuelto, actualiza `GLOSSARY.md` ahí mismo. No los acumules — captúralos según ocurren. Usa el formato de [GLOSSARY-FORMAT.md](./GLOSSARY-FORMAT.md).
 
-`CONTEXT.md` debe estar totalmente libre de detalles de implementación. No trates `CONTEXT.md` como una especificación, un borrador, ni un repositorio de decisiones de implementación. Es un glosario y nada más.
+`GLOSSARY.md` debe estar totalmente libre de detalles de implementación. No trates `GLOSSARY.md` como una especificación, un borrador, ni un repositorio de decisiones de implementación. Es un glosario y nada más.
 
 ### Ofrece ADRs con moderación
 

package/skills/implement-spec/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: implement-spec
+description: "Implement the result of /to-spec and /to-tickets in code, orchestrating parallel implementer subagents over the ticket graph."
+tags: ["implementation", "spec", "tickets", "subagents", "orchestration"]
+disable-model-invocation: true
+profiles: [core, ui, full]
+origin: damiangil
+---
+
+Te han dado una spec. Esa spec debería tener tickets asociados que describen cómo implementarla.
+
+El issue tracker debería estar descrito en `docs/agents/issue-tracker.md`. Si falta, pregunta al usuario dónde viven los tickets y cómo se cierra el trabajo (PR, issue, fichero).
+
+El objetivo es la spec entera implementada en una sola **rama de integración**, con cada ticket resuelto de la forma en que el issue tracker cierra el trabajo.
+
+Los tickets no son una lista de pasos. Son un **grafo de tareas** con relaciones de bloqueo entre ellos. Eso significa que siempre hay una **frontera** de tickets listos para cogerse.
+
+La comunicación con los subagentes debe ser escasa. Comunica sobre todo con **punteros de contexto**: a la spec, a los tickets, a las notas de investigación y a los commits anteriores. No dupliques información que ya está disponible a través de un puntero.
+
+Lanza los **subagentes implementadores** en segundo plano siempre que se pueda, para tener la máxima concurrencia.
+
+## Pasos
+
+1. Lee la spec y los tickets para entender el grafo de tareas.
+
+2. (opcional) Usa un **subagente explorador** para la exploración que pidan los tickets: ficheros relevantes del código o documentación externa. Asegúrate de que puede guardar ficheros: debe dejar sus notas en Markdown en una carpeta fuera del repo, accesible para todos los subagentes siguientes. Así los **subagentes implementadores** se centran en implementar y no en explorar.
+
+3. Crea la rama de integración. Si el issue tracker cierra el trabajo con PRs, o el usuario pide una, abre una PR en borrador después del primer merge del paso 5 (una rama sin commits por delante de main no puede abrirla), marcada como que cierra la spec y los tickets.
+
+4. Usa **subagentes implementadores** para implementar cada ticket, cada uno en su propio worktree y en su propia rama (`superpowers:using-git-worktrees`). Cada subagente implementador:
+   - confirma que su worktree parte de la rama de integración antes de empezar, y se reinicia sobre ella si no;
+   - llama a la herramienta Skill con `superpowers:test-driven-development` para construir el ticket;
+   - fusiona la punta de la rama de integración en su propia rama antes de decir que ha terminado.
+
+5. Cuando un **subagente implementador** termina, fusiona su trabajo en la rama de integración con un **subagente fusionador**.
+
+6. Si eso cambia la **frontera** de tickets disponibles, lanza más **subagentes implementadores** para los tickets nuevos. Así se mantiene la máxima concurrencia.
+
+7. Cuando todos los tickets estén completos, llama a la herramienta Skill con `code-review` sobre la rama de integración. Arregla todo lo que salga de la revisión en un único **subagente implementador**.
+
+8. Si existe una PR en borrador, márcala como lista para revisar y escribe su cuerpo con `pr`. Si no, resuelve cada ticket de la forma en que el issue tracker cierra el trabajo e informa de la rama de integración.
+
+9. Limpia todos los worktrees de los **subagentes implementadores**.

package/skills/implement-spec/evals/cases.yaml

@@ -0,0 +1,33 @@
+skill: implement-spec
+
+should_trigger:
+  - prompt: "Implementa la spec entera con sus tickets, en paralelo."
+    why: "Disparador directo de implement-spec: la spec completa sobre el grafo de tickets."
+  - prompt: "Ya tenemos la spec y los tickets; orquesta subagentes para construirlo todo."
+    why: "Disparador directo de implement-spec."
+  - prompt: "Lanza implementadores en worktrees para cada ticket de la spec y júntalo en una rama de integración."
+    why: "Disparador directo de implement-spec."
+  - prompt: "Implement the whole spec from /to-spec and /to-tickets."
+    why: "Disparador directo de implement-spec."
+  - prompt: "Construye todos los tickets de esta spec respetando los bloqueos entre ellos."
+    why: "Disparador directo de implement-spec: la frontera del grafo de tareas."
+
+should_not_trigger:
+  - prompt: "Implementa solo este ticket."
+    route_to: "implement"
+    why: "Un único ticket es el trabajo de implement, no de implement-spec."
+  - prompt: "Escribe la spec antes de implementar nada."
+    route_to: "to-spec"
+    why: "Escribir la spec es el trabajo de to-spec, no de implement-spec."
+  - prompt: "Descompón la spec en tickets primero."
+    route_to: "to-tickets"
+    why: "Descomponer en tickets es el trabajo de to-tickets, no de implement-spec."
+  - prompt: "Revisa el código de la rama de integración."
+    route_to: "code-review"
+    why: "Revisar el código es el trabajo de code-review, no de implement-spec."
+
+capability:
+  - scenario: "El usuario tiene una spec con tickets y quiere implementarla entera con subagentes en paralelo."
+    must_include:
+      - "rama de integración"
+      - "frontera"

package/skills/pr/CREDITS.md

@@ -0,0 +1,3 @@
+# Créditos
+
+El menú de visuales de la sección **Resumen** (pseudocódigo, árboles de llamadas, árboles de componentes, árboles de ficheros, Mermaid, diffs) y su guía de colocación vienen de la skill [`show-me`](https://github.com/humanlayer/humanlayer) de [Dex Horthy](https://github.com/dexhorthy), reproducida casi palabra por palabra y aplicada a un diff en lugar de a una conversación en vivo. La skill llega a este catálogo a través de `pr` en [mattpocock/skills](https://github.com/mattpocock/skills) (v1.3.1). `pr` no depende de `show-me` como skill (una dependencia rompería las instalaciones sueltas), así que el contenido va copiado en lugar de enlazado; este fichero es la atribución que llevaría esa dependencia.

package/skills/pr/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: pr
+description: "Use when writing a PR body: a visual summary, before/after evidence, and the merge danger (one-way or two-way door, blast radius)."
+tags: ["pull-request", "review", "evidence", "risk"]
+profiles: [core, ui, full]
+origin: damiangil
+metadata:
+  credits:
+    skill: show-me
+    author: Dex Horthy
+    organisation: Humanlayer
+    url: "https://github.com/humanlayer/skills/blob/main/plugins/show-me/skills/show-me/SKILL.md"
+---
+
+Usa esta plantilla para escribir el cuerpo de la PR:
+
+```markdown
+## Resumen
+
+<diagrama, esbozo de diff o árbol>
+
+## Evidencia
+
+- **Antes:** <captura/salida/ejecución de test que falla>
+  **Después:** <captura/salida/ejecución de test que pasa>
+
+## Peligro de fusión
+
+**Puerta:** <de un sentido o de dos sentidos>
+
+<opcional: descripción>
+
+**Radio de impacto:** <descripción en una palabra>
+
+<opcional: posibles consecuencias de fusionar>
+```
+
+## Secciones
+
+Sáltate los preámbulos y deja la prosa breve. Usa el lenguaje del dominio del usuario que está en `GLOSSARY.md`.
+
+### Resumen
+
+Elige la vista más pequeña que deje clara la idea clave.
+
+- Muestra una lógica o un algoritmo como pseudocódigo:
+
+```text
+on(save)
+  if content is unchanged
+    return cached result
+  write new content
+  return fresh result
+```
+
+- Muestra el flujo de control en ejecución como un árbol de llamadas:
+
+```text
+submitForm
+  createSession
+    persistPrompt
+    launchAgent
+  navigateToSession
+```
+
+- Muestra la estructura de la UI como un árbol de componentes, con el estado y los límites de módulo que importan:
+
+```text
+<SessionPage> (apps/example/src/routes/session.tsx)
+  useSessionEvents()
+  <SessionToolbar>
+    <RunSkillButton> (packages/ui)
+```
+
+- Muestra de qué se encarga cada fichero, o un refactor amplio, como un árbol de ficheros poco profundo:
+
+```text
+src/
+├── commands/       # interpreta las acciones del usuario
+├── sessions/       # guarda el estado de la sesión
+└── transport/      # envía las peticiones a la API
+```
+
+- Muestra la interacción entre componentes, el flujo de control o el flujo de datos con Mermaid:
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant UI
+    participant Daemon
+    User->>UI: choose command
+    UI->>Daemon: send expanded prompt
+    Daemon-->>UI: stream result
+```
+
+- Usa `diff` cuando lo importante es qué cambia y la forma de alrededor ya existe. Ajusta la forma del diff al tema.
+
+Para un cambio de componente:
+
+```diff
+ <SessionPage>
+   useSessionEvents()
+   <SessionToolbar>
++    <RunSkillButton />
+   <SessionTimeline>
++    <SkillResultCard />
+```
+
+Para un cambio en la disposición de ficheros:
+
+```diff
+ src/
+ ├── commands/
++│   └── show-me.ts       # expande el slash command
+ ├── sessions/
+-└── transport.ts
++└── transport/
++    ├── client.ts
++    └── stream.ts
+```
+
+Para un cambio en un árbol o pila de llamadas:
+
+```diff
+ submitForm
+   createSession
+     persistPrompt
++    expandSkillMention
+     launchAgent
+-  navigateToSession
++  navigateToSession
++    subscribeToEvents
+```
+
+Para un cambio de estado o de flujo de control:
+
+```diff
+ on(save)
+-  write content
++  if content is unchanged
++    return cached result
++  write new content
++  invalidate cache
+```
+
+- Muestra el bloque entero cuando casi todo es nuevo, cuando omitir contexto escondería de quién es algo o en qué orden va, o cuando el usuario necesita una forma objetivo que pueda copiar:
+
+```ts
+function expandSkill(command: string): string {
+  const skillName = command.slice(1);
+  return `use the ${skillName} skill`;
+}
+```
+
+#### Guía
+
+Pon cada visual junto al texto corto al que apoya. Quédate solo con las llamadas, ficheros, props, estados y límites que hacen falta para responder a la pregunta actual del usuario, o a las opciones para resolver el punto que se está discutiendo.
+
+Puedes usar uno de estos, puedes usar varios; es poco probable que uses todos. Usa tu criterio y no abrumes al usuario.
+
+### Evidencia
+
+Pruebas concretas de que el cambio funciona. Muestra un antes y un después.
+
+Las capturas de pantalla son lo mejor, cuando el entorno lo permite y el cambio es visual.
+
+La evidencia basada en ejecución va justo detrás: resultados de tests, salida de consola. Muestra el test exacto que antes fallaba y ahora pasa, en pseudocódigo.
+
+### Peligro de fusión
+
+Di si es una puerta de un sentido o de dos sentidos. Por una puerta de dos sentidos se puede volver atrás; por una de un sentido, no. Una PR que es barata de revertir tiene menos riesgo. Los cambios que implican acciones destructivas o decisiones difíciles de revertir son puertas de un sentido.
+
+El radio de impacto es el alcance posible de los efectos que introduce la PR. Considera todas las posibilidades. Ejemplos: saltos de layout, roturas para quien consume el código, el comportamiento en móvil, etc.

package/skills/pr/evals/cases.yaml

@@ -0,0 +1,33 @@
+skill: pr
+
+should_trigger:
+  - prompt: "Escribe el cuerpo de la PR de esta rama."
+    why: "Disparador directo de pr."
+  - prompt: "Abre la PR y explica el cambio con un diagrama y el antes y después."
+    why: "Disparador directo de pr: resumen visual y evidencia."
+  - prompt: "Write the PR description for these changes."
+    why: "Disparador directo de pr."
+  - prompt: "Prepara la descripción del pull request con el riesgo de fusionarlo."
+    why: "Disparador directo de pr: peligro de fusión y radio de impacto."
+  - prompt: "¿Qué pongo en la PR para que se revise rápido?"
+    why: "Disparador directo de pr."
+
+should_not_trigger:
+  - prompt: "Revisa el código de esta PR."
+    route_to: "code-review"
+    why: "Revisar el código es el trabajo de code-review, no de pr."
+  - prompt: "Haz el commit de estos cambios con un buen mensaje."
+    route_to: "git-workflow"
+    why: "El mensaje de commit es el trabajo de git-workflow, no de pr."
+  - prompt: "Implementa la spec entera."
+    route_to: "implement-spec"
+    why: "Implementar la spec es el trabajo de implement-spec, no de pr."
+  - prompt: "Escribe la spec de esta funcionalidad antes de tocar código."
+    route_to: "to-spec"
+    why: "Redactar la spec es el trabajo de to-spec, no de pr."
+
+capability:
+  - scenario: "El usuario quiere el cuerpo de una PR que se revise de un vistazo."
+    must_include:
+      - "Peligro de fusión"
+      - "Radio de impacto"

package/skills/retro/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: retro
+description: "Conduct a retrospective on a coding session: find what in the agent's environment (navigation, checks, standards, steering files, tooling) should change so future runs go better."
+tags: ["retrospective", "session-review", "agent-environment"]
+disable-model-invocation: true
+profiles: [core, ui, full]
+origin: damiangil
+---
+
+El usuario ha pedido una **retrospectiva**. Vas a proponer mejoras en el **entorno** del agente de código para que las próximas ejecuciones salgan mejor.
+
+## Pasos
+
+1. Llama a la herramienta Skill con `writing-for-agents` para tener la guía de estilo.
+
+2. Lee las fuentes primarias de la sesión que indique el usuario. Puede que tengas que buscar en los registros de sesión de esta máquina (en Claude Code, `~/.claude/projects/`). Si el usuario no indica ninguna, usa la sesión actual.
+
+3. Busca candidatos a mejora en estas categorías:
+
+- **Navegación**: ¿le costó al agente encontrar los ficheros correctos? ¿Hay dependencias ocultas entre ficheros? ¿Un **puntero de navegación** lo pondría más fácil? _Úsalo cuando_ la sesión tardó mucho en encontrar una información.
+- **Comprobaciones automáticas**: ¿hay comprobaciones automáticas que pillarían los errores que cometió el agente? Linting, tipos, tests, linters del sistema de ficheros. Lee primero el comando de comprobación del propio repo (los scripts `lint`/`check` de su `package.json` o de su herramienta de build, su workflow de CI), para que el hallazgo sea una comprobación que ya existe pero está sin conectar o rota en silencio, y no una reinvención. Un repo sin ninguna **barrera** (ni hook de pre-commit ni job de CI que ejecute su lint/typecheck/test) es en sí un hallazgo: un repo sin lint es una oportunidad perdida permanente, no un punto de partida neutro. _Úsalo cuando_ el agente cometió un error que una comprobación automática habría pillado, o el repo no tiene ninguna barrera.
+- **Estándares de código**: ¿hay que darle al **agente revisor** una regla nueva que haga cumplir? ¿Hay que quitar o aclarar una regla existente? Clasifica primero la infracción: una **mecánica** (un patrón sintáctico fijo, una API prohibida, una forma de import, una regla de ubicación de ficheros) lleva una comprobación determinista, sin más: una regla propia en el linter del repo, un hook de pre-commit nuevo o un job de CI nuevo, lo que salga más barato según el lenguaje y la barrera que ya tenga el repo. Por defecto, construye la comprobación antes que escribir la regla. Reserva `CODING_STANDARDS.md` para las **decisiones de criterio** de verdad (coherencia entre ficheros, "encaja con el estilo de alrededor", cualquier cosa que ninguna barrera pueda sustituir). _Úsalo cuando_ el agente revisor no pilló un error.
+- **AGENTS.md / CLAUDE.md global**: ¿hay instrucciones de dirección que deberían pasar a los estándares de código (o a comprobaciones automáticas)? _Úsalo cuando_ el fichero es especialmente grande, en el repo O en el ámbito global del usuario.
+- **Economía de herramientas**: ¿hizo el agente llamadas a herramientas caras que se podrían simplificar? ¿Hay alguna herramienta propia (CLIs, MCPs) que gaste muchos tokens? _Úsalo cuando_ el agente hizo una llamada cara.
+- **Instrucciones sin efecto**: busca instrucciones en los ficheros de dirección que no cambian el comportamiento del agente. _Úsalo cuando_ los ficheros de dirección son grandes y difíciles de manejar.
+- **Acceso a la información**: busca formas de darle al agente más acceso a la información. Volcar los logs del servidor de desarrollo, acceso de solo lectura a servicios de terceros. _Úsalo cuando_ el agente no tenía una información clave.
+
+4. Presenta estos candidatos al usuario, ordenados por gravedad. Tú no aplicas nada: el usuario decide qué se cambia.
+
+## Referencia
+
+### Implementación frente a revisión
+
+Recuerda que todo el trabajo pasa por dos fases: implementación y revisión. El agente que implementa es el que más **presión de contexto** tiene: se encarga de explorar, escribir el código y depurar los fallos.
+
+El agente revisor es el que menos presión de contexto tiene: recibe un diff, así que no tiene que explorar. Muchas veces no necesita escribir código ni depurar.
+
+Eso significa que el agente revisor debe ser el responsable de hacer cumplir los estándares de código, no el que implementa.
+
+### Ficheros
+
+Tienes acceso a varios ficheros en el repo:
+
+- `CLAUDE.md`/`AGENTS.md`: estos ficheros entran en la ventana de contexto de cualquier agente que trabaje en el repo. Hay que usarlos con muchísima moderación, normalmente solo para **punteros de navegación** a otros ficheros.
+- `CODING_STANDARDS.md`: este fichero se lee durante la revisión, no durante la implementación. Añade **punteros de navegación** a carpetas de docs si el fichero de estándares pasa de 1.000 líneas.
+- Docs: usa los docs como ficheros de referencia, señalados desde otros ficheros. Busca docs existentes antes de escribir otros nuevos.
+- Skills: usa skills para docs (porque su descripción entra en la ventana de contexto del agente) o para comandos que invoca el usuario. Sigue los consejos de la skill `writing-for-agents`.

package/skills/retro/evals/cases.yaml

@@ -0,0 +1,32 @@
+skill: retro
+
+should_trigger:
+  - prompt: "Haz una retrospectiva de esta sesión."
+    why: "Disparador directo de retro."
+  - prompt: "Revisa la conversación de ayer y dime qué falló en el entorno del agente."
+    why: "Disparador directo de retro: leer sesiones pasadas."
+  - prompt: "Run a retro on the last coding session."
+    why: "Disparador directo de retro."
+  - prompt: "¿Qué hooks o comprobaciones habrían evitado los errores de esta sesión?"
+    why: "Disparador directo de retro: comprobaciones automáticas."
+  - prompt: "Audita la sesión y propón mejoras para el CLAUDE.md y las herramientas."
+    why: "Disparador directo de retro."
+
+should_not_trigger:
+  - prompt: "Revisa el código de esta rama."
+    route_to: "code-review"
+    why: "Revisar código es el trabajo de code-review, no de retro."
+  - prompt: "Resume la conversación para que otro agente siga."
+    route_to: "handoff"
+    why: "El traspaso de la sesión es el trabajo de handoff, no de retro."
+  - prompt: "Escribe una skill nueva para esto."
+    route_to: "writing-for-agents"
+    why: "Escribir documentos para agentes es el trabajo de writing-for-agents, no de retro."
+  - prompt: "Escribe el cuerpo de la PR de esta rama."
+    route_to: "pr"
+    why: "El cuerpo de la PR es el trabajo de pr, no de retro."
+
+capability:
+  - scenario: "El usuario quiere saber qué cambiar en el entorno del agente tras una sesión."
+    must_include:
+      - "gravedad"

package/skills/suggest/SKILL.md

@@ -56,7 +56,7 @@ pairs with test-driven development and a verification pass before anything is ca
 
 Exact skill names and order: `grill-with-docs` or `wayfinder` -> `superpowers:brainstorming` or
 `to-spec` (and `write-adr` for decisions) -> `superpowers:writing-plans` ->
-`superpowers:executing-plans` (after `wayfinder`: `to-tickets` -> `implement`) -> `code-review`.
+`superpowers:executing-plans` (big spec: `to-tickets` -> `implement-spec`) -> `code-review` -> `pr`.
 On Claude Code this rule also arrives as a per-turn hook; the brevity here is deduplication,
 not relaxation.
 

package/skills/wait-what/SKILL.md

@@ -7,4 +7,4 @@ profiles: [core, ui, full]
 origin: damiangil
 ---
 
-Espera, no entiendo a dónde has llegado con esto. Vuelve a plantearlo: dame algo de contexto, habla en Inglés Técnico Simplificado ASD-STE100 (aplícalo igual en español: frases cortas, una idea por frase, vocabulario consistente), y usa el lenguaje ubicuo de `CONTEXT.md` (sigue `CONTEXT-MAP.md` hasta el correcto si el repo tiene más de uno).
+Espera, no entiendo a dónde has llegado con esto. Vuelve a plantearlo: dame algo de contexto, habla en Inglés Técnico Simplificado ASD-STE100 (aplícalo igual en español: frases cortas, una idea por frase, vocabulario consistente), y usa el lenguaje ubicuo de `GLOSSARY.md` (sigue `GLOSSARY-MAP.md` hasta el correcto si el repo tiene más de uno).

package/targets/_md-block.js

@@ -21,7 +21,7 @@ export function writeSkill(id, fromDir, toPath) {
 export function wireHook(paths, sourceMd, policy = {}) {
   const full = stripFrontmatter(readFileSync(sourceMd, 'utf8'));
   const body = policy.codeHooks === false
-    ? `# rsc-suggest — always-on operations layer\n\nRead \`docs/wiki/harness/user-profile.md\` before acting. If the user wants to build, add or change something, route it through \`grill-with-docs\` or \`wayfinder\`, then write the spec with \`superpowers:brainstorming\` or \`to-spec\` (decisions go to \`write-adr\`) before any code, then build it with \`superpowers:writing-plans\` (or \`to-tickets\` then \`implement\` when it came out of \`wayfinder\`), and review it with \`code-review\` before merging (si toca pantalla, \`flujo-interfaz\` dice que skill de diseno manda) — unless it is a one-line change, typo, or config bump, which skips the chain. Use \`orient\` to keep the user situated and \`suggest\` to offer a missing skill only when the current task needs it. Close with the configured orientation block.\n`
+    ? `# rsc-suggest — always-on operations layer\n\nRead \`docs/wiki/harness/user-profile.md\` before acting. If the user wants to build, add or change something, route it through \`grill-with-docs\` or \`wayfinder\`, then write the spec with \`superpowers:brainstorming\` or \`to-spec\` (decisions go to \`write-adr\`) before any code, then build it with \`superpowers:writing-plans\` (or \`to-tickets\` then \`implement-spec\` for a big spec or one that came out of \`wayfinder\`), and review it with \`code-review\` before merging, writing the PR body with \`pr\` (si toca pantalla, \`flujo-interfaz\` dice que skill de diseno manda) — unless it is a one-line change, typo, or config bump, which skips the chain. Use \`orient\` to keep the user situated and \`suggest\` to offer a missing skill only when the current task needs it. Close with the configured orientation block.\n`
     : full;
   const block = `${MARK_START}\n${body}\n${MARK_END}`;
   let doc = existsSync(paths.hookTarget) ? readFileSync(paths.hookTarget, 'utf8') : '';

package/targets/hook-once.mjs

@@ -101,10 +101,12 @@ el que esta claro y el usuario ha dado el visto bueno.
    Cada decision dificil de revertir se registra con \`write-adr\`, en docs/adr/.
 2. Escribir la spec: \`to-spec\`, o \`superpowers:brainstorming\` para cerrarla por secciones.
    Sin spec escrita no se programa.
-3. Construir: \`superpowers:writing-plans\` -> \`superpowers:executing-plans\`. Solo el trabajo que
-   salio de \`wayfinder\` va con \`to-tickets\` -> \`implement\`, ticket a ticket.
+3. Construir: \`superpowers:writing-plans\` -> \`superpowers:executing-plans\`. Spec grande o que
+   salio de \`wayfinder\` -> \`to-tickets\` -> \`implement-spec\` (subagentes en paralelo sobre el
+   grafo de tickets); un solo ticket suelto -> \`implement\`.
    Si la tarea toca pantalla, invoca ademas \`flujo-interfaz\`: dice que skill de diseno manda.
-4. Antes de fusionar: \`code-review\` (estandares del repo + lo que pedia la spec).
+4. Antes de fusionar: \`code-review\` (estandares del repo + lo que pedia la spec), y el cuerpo
+   de la PR con \`pr\` (resumen visual, evidencia antes/despues, peligro de fusion).
 Siempre: \`superpowers:test-driven-development\` y \`superpowers:verification-before-completion\`
 antes de dar nada por terminado. Los bugs entran por \`superpowers:systematic-debugging\`.
 Cambio de una linea, typo o ajuste de configuracion -> hazlo y di que te saltas la cadena.

package/targets/session-memory-core.mjs

@@ -46,9 +46,10 @@ function cleanId(value, prefix = 'session') {
   return `${prefix}-${hash}`;
 }
 
-function git(cwd, args) {
+function git(cwd, args, input) {
   try {
-    return { ok: true, out: execFileSync('git', args, { windowsHide: true, cwd, encoding: 'utf8', stdio: ['ignore', 'pipe', 'ignore'], maxBuffer: 2 * 1024 * 1024 }).trim() };
+    const stdin = input === undefined ? 'ignore' : 'pipe';
+    return { ok: true, out: execFileSync('git', args, { windowsHide: true, cwd, input, encoding: 'utf8', stdio: [stdin, 'pipe', 'ignore'], maxBuffer: 16 * 1024 * 1024 }).trim() };
   } catch {
     return { ok: false, out: '' };
   }
@@ -162,7 +163,15 @@ function parseStatus(output) {
   return files;
 }
 
+// One `git` for every file, not one per file. Spawning a process costs ~25 ms on Windows, and this
+// runs on every hook event: a few hundred dirty files were enough to blow the 5 s hook timeout.
+// `--stdin-paths` stops at the first path it cannot read (a deleted file), so on failure each file
+// is hashed on its own, which keeps the old per-file `null` for the unreadable ones.
 function fingerprintFiles(worktree, files) {
+  if (!files.length) return {};
+  const batch = git(worktree, ['hash-object', '--no-filters', '--stdin-paths'], `${files.join('\n')}\n`);
+  const hashes = batch.ok ? batch.out.split('\n') : [];
+  if (hashes.length === files.length) return Object.fromEntries(files.map((path, i) => [path, hashes[i]]));
   return Object.fromEntries(files.map((path) => {
     const result = git(worktree, ['hash-object', '--no-filters', '--', path]);
     return [path, result.ok ? result.out : null];
@@ -305,7 +314,8 @@ export function capture(input = {}) {
   const recordPath = join(store.root, 'sessions', `${storageId}.json`);
   let anchor = readJson(anchorPath);
   let existing = readJson(recordPath);
-  const firstSnapshot = snapshot(here, null);
+  // The first snapshot only seeds a new anchor; an existing one already has its baseline.
+  const firstSnapshot = anchor ? null : snapshot(here, null);
   if (!anchor) {
     anchor = {
       sessionId,
@@ -318,7 +328,11 @@ export function capture(input = {}) {
   }
   if (input.event === 'start' && !existing) return { record: null, path: null, notice: null, compactionHint: false };
 
-  const repo = snapshot(here, anchor.baselineHead);
+  // Against its own HEAD as baseline there is nothing committed to diff, so a fresh anchor's
+  // snapshot already is the repo state: reuse it instead of walking the tree a second time.
+  const repo = firstSnapshot && anchor.baselineHead === firstSnapshot.head
+    ? firstSnapshot
+    : snapshot(here, anchor.baselineHead);
   // Count what CHANGED, not which tool changed it. `editDelta` is +1 per Edit/Write tool event, and
   // on its own it was blind to everything done through the shell — a heredoc, `sed -i`, a script, a
   // formatter — which is how automated sessions work. The session that found this had touched dozens