@damiangilgonzalez/harness 1.3.13 → 1.3.15

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/agents.js

@@ -68,7 +68,15 @@ ${REFUTER_FOUR_INPUTS}
 3. Did you inspect the relevant **caller, import, and relevant test**?
 4. Can the severity survive the **existing guards** you verified?
 
-If an answer is no, lower the severity or omit the finding. Every **HIGH or CRITICAL** needs the line and failure mode in the report. **Zero findings with an attack list is valid.**
+If an answer is no, lower the severity or omit the finding. Every **blocker or should-fix** needs the line and failure mode in the report. **Zero findings with an attack list is valid.**
+
+**Report findings in one shape, so the panel can be consolidated** — a fenced ${'`json findings`'} block holding an array (empty when you found nothing):
+
+${'```'}json findings
+[{ "lens": "<your lens>", "severity": "blocker|should-fix|nit|question", "file": "path/from/repo/root", "line": 42, "claim": "one sentence: what is wrong", "failure_scenario": "concrete input + state -> wrong result", "evidence": "the exact changed line, quoted" }]
+${'```'}
+
+${'`rsc review consolidate`'} merges what several lenses reported about the same place and sends each unique blocker or should-fix to ${'`finding-verifier`'}, whose job is to prove it false. A blocker or should-fix with no ${'`file`'}, ${'`line`'} or ${'`failure_scenario`'} is downgraded to a question there, mechanically.
 
 **Common false positives to reject:** an equivalent mutant with no diverging input; a documented dummy value that never reaches a sink; a deliberate boundary already enforced by a caller; generated/vendor code outside the change; style preference presented as correctness; and a theoretical race with no shared state or overlapping lifetime.
 
@@ -126,8 +134,36 @@ ${REFUTER_CONTRACT}
 
 **Check the mapping both ways:** every acceptance criterion needs a falsification procedure that can be made to fail, and every test should trace to something someone asked for.`,
   },
+  // The second half of ECC's orch-review, adapted: after `rsc review consolidate` collapses the panel's
+  // duplicates, every unique blocker/should-fix gets ONE more fresh context whose default is that the
+  // finding is false. A refuter attacks the diff; the verifier attacks the finding. Same asymmetry,
+  // pointed the other way — which is what stops an exaggerated lens from reaching the author as a blocker.
+  {
+    name: 'finding-verifier',
+    desc: 'Adversarial verifier of review findings: takes ONE consolidated finding and tries to prove it false against the code. Default stance: the finding is false; only a reproduced or traced failure is CONFIRMED. Fresh context, edits nothing.',
+    body: `You are the **finding verifier** for this project. ${'`code-review`'} hands you **one** finding that survived ${'`rsc review consolidate`'} — a blocker or should-fix some refuter lens reported against a diff. Your job is to **prove it false**. Your starting position is that it is false; the finding has to beat you.
+
+**Your inputs:** the finding (location, claim, failure scenario, evidence) plus the same four the lenses had —
+
+${REFUTER_FOUR_INPUTS}
+
+**You do NOT get** the refuter's reasoning or the builder's defence. Judge the claim against the code, not against either story.
+
+**How to try to kill it:**
+1. Read the cited line **and** its callers, guards and tests — the check that makes it impossible often lives two functions up, or in a caller that never passes that input.
+2. Try the failure scenario for real when you can: run the test, execute the command, or write a throwaway check in a temp directory outside the repo. An observed failure outranks any argument.
+3. Ask whether the change **caused** it. A defect that was already there is real but does not block this delivery.
+
+**Verdict — exactly one, with its proof:**
+- **CONFIRMED** — you reproduced it, or traced a reachable path from a concrete input to the wrong result. Quote the output or the path. Only this verdict may block.
+- **REFUTED** — you found what makes it impossible (the guard, the caller, the type, the test). Cite it with file and line.
+- **UNPROVEN** — neither: it becomes a question for the human, and questions never block.
+
+Also state whether the severity holds. A CONFIRMED finding whose blast radius is narrow is a should-fix, not a blocker — say so. You fix nothing and edit no file: your output is the verdict, the proof, and the commands you ran.`,
+  },
 ];
 
+
 export const BASE_AGENT_NAMES = Object.freeze(AGENTS.map((agent) => agent.name));
 export { stackAgents, stackAgentNames, validateAgentCatalog };
 export const allAgentNames = () => [...BASE_AGENT_NAMES, ...stackAgentNames()];

package/targets/claude.js

@@ -182,19 +182,6 @@ export function wireHook(paths, sourceMd, policy = {}) {
   );
   settings.hooks.PreToolUse.push({ matcher: SHELL_TOOLS, hooks: [{ type: 'command', command: sgCmd }] });
 
-  // Danger guard: a PreToolUse(Bash) hook that DENIES irreversible foot-gun commands
-  // (rm -rf, git push --force, DROP/TRUNCATE, DELETE/UPDATE without WHERE, dd to /dev,
-  // curl|bash, …) when the user-profile says the user is NON-technical (default-safe
-  // when no profile exists yet; never guards a fully `technical` user). Materialized +
-  // node-run (Windows-safe), idempotent, fail-open, opt-out via .rsc/.no-danger-guard.
-  const dgDest = join(paths.projectRoot, '.rsc', 'danger-guard.mjs');
-  copyFileSync(join(HERE, 'danger-guard.mjs'), dgDest);
-  const dgCmd = viaBootstrap('guard', at('.rsc', 'danger-guard.mjs'), `"${P}"`);
-  settings.hooks.PreToolUse = settings.hooks.PreToolUse.filter(
-    (e) => !hookWiringOf(e).includes('.rsc/danger-guard.'),
-  );
-  settings.hooks.PreToolUse.push({ matcher: SHELL_TOOLS, hooks: [{ type: 'command', command: dgCmd }] });
-
   // Gitmoji guard: a PreToolUse(Bash) hook that DENIES a `git commit` whose message
   // carries no gitmoji (gitmoji.dev) in front of the Conventional Commits header. The
   // convention lives in `git-workflow`; prose asks, this hook decides — at the one
@@ -226,18 +213,18 @@ export function wireHook(paths, sourceMd, policy = {}) {
     (e) => !hookWiringOf(e).includes('.rsc/userprompt-gate.'),
   );
   settings.hooks.UserPromptSubmit.push({ hooks: [{ type: 'command', command: fgCmd }] });
-  written.push(sgDest, dgDest, gmDest, fgDest, join(paths.projectRoot, '.rsc', 'sello.mjs'));
+  written.push(sgDest, gmDest, fgDest, join(paths.projectRoot, '.rsc', 'sello.mjs'));
   } else {
     for (const event of ['PreToolUse', 'UserPromptSubmit']) {
       if (!settings.hooks[event]) continue;
       settings.hooks[event] = settings.hooks[event].filter((entry) => {
         const body = hookWiringOf(entry);
-        return !body.includes('.rsc/ship-guard.') && !body.includes('.rsc/danger-guard.') &&
+        return !body.includes('.rsc/ship-guard.') &&
           !body.includes('.rsc/gitmoji-guard.') && !body.includes('.rsc/userprompt-gate.');
       });
       if (!settings.hooks[event].length) delete settings.hooks[event];
     }
-    for (const name of ['ship-guard.mjs', 'danger-guard.mjs', 'gitmoji-guard.mjs', 'userprompt-gate.mjs', 'sello.mjs']) {
+    for (const name of ['ship-guard.mjs', 'gitmoji-guard.mjs', 'userprompt-gate.mjs', 'sello.mjs']) {
       rmSync(join(paths.projectRoot, '.rsc', name), { force: true });
     }
     written.push(operationsSuggest);
@@ -248,6 +235,28 @@ export function wireHook(paths, sourceMd, policy = {}) {
     for (const id of policy.plugins) settings.enabledPlugins[id] = true;
   }
 
+  // Danger guard: its own decision, not part of the code-hook block above (#273). `init` promises it
+  // to non-technical and mixed users whatever the project is, and a plan that predates the field is
+  // read as "yes": a non-technical operations install gets the guard it was missing on its next sync,
+  // and a technical user gets a guard that stands down at runtime.
+  settings.hooks.PreToolUse ||= [];
+  settings.hooks.PreToolUse = settings.hooks.PreToolUse.filter((e) => !hookWiringOf(e).includes('.rsc/danger-guard.'));
+  if (policy.dangerGuard !== false) {
+    // Danger guard: a PreToolUse(Bash) hook that DENIES irreversible foot-gun commands
+    // (rm -rf, git push --force, DROP/TRUNCATE, DELETE/UPDATE without WHERE, dd to /dev,
+    // curl|bash, …) when the user-profile says the user is NON-technical (default-safe
+    // when no profile exists yet; never guards a fully `technical` user). Materialized +
+    // node-run (Windows-safe), idempotent, fail-open, opt-out via .rsc/.no-danger-guard.
+    const dgDest = join(paths.projectRoot, '.rsc', 'danger-guard.mjs');
+    copyFileSync(join(HERE, 'danger-guard.mjs'), dgDest);
+    const dgCmd = viaBootstrap('guard', at('.rsc', 'danger-guard.mjs'), `"${P}"`);
+    settings.hooks.PreToolUse.push({ matcher: SHELL_TOOLS, hooks: [{ type: 'command', command: dgCmd }] });
+    written.push(dgDest);
+  } else {
+    rmSync(join(paths.projectRoot, '.rsc', 'danger-guard.mjs'), { force: true });
+  }
+  if (!settings.hooks.PreToolUse.length) delete settings.hooks.PreToolUse;
+
   mkdirSync(dirname(file), { recursive: true });
   writeFileSync(file, JSON.stringify(settings, null, 2) + '\n');
 

package/targets/hook-once.mjs

@@ -90,6 +90,7 @@ export function claimOnce(key, { dir = markerDir(), windowMs = 30_000, now = Dat
 // definition: the hook emits it and `rsc doctor` measures it from the same constant. Anything
 // that reports a byte count for text it does not own drifts the moment the text changes.
 export const WORKFLOW_GATE_TEXT = `===== workflow gate · metodologia (maxima prioridad) =====
+Responde en el idioma en que escribe la persona, no en el de este texto.
 Si el usuario pide construir, anadir o cambiar algo (en cualquier idioma, se juzga la intencion),
 sigue esta cadena ANTES de escribir codigo. Ninguna skill escribe codigo de una feature hasta que
 el que esta claro y el usuario ha dado el visto bueno.
@@ -100,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/memory.js

@@ -35,7 +35,7 @@ export function memoryEnabledForProject(cwd = process.cwd()) {
 }
 
 function git(cwd, args) {
-  try { return execFileSync('git', args, { cwd, encoding: 'utf8', stdio: ['ignore', 'pipe', 'ignore'] }).trim(); } catch { return null; }
+  try { return execFileSync('git', args, { windowsHide: true, cwd, encoding: 'utf8', stdio: ['ignore', 'pipe', 'ignore'] }).trim(); } catch { return null; }
 }
 
 function rel(cwd, path) {

package/targets/sello.mjs

@@ -103,7 +103,7 @@ export function isEnabled(root) {
 // The CLI can run from any subdirectory; the guard always runs from the project
 // root. Both must compute the same candidate, so both resolve to the git toplevel.
 export function resolveRoot(root) {
-  const r = spawnSync('git', ['-C', root, 'rev-parse', '--show-toplevel'], { encoding: 'utf8' });
+  const r = spawnSync('git', ['-C', root, 'rev-parse', '--show-toplevel'], { windowsHide: true, encoding: 'utf8' });
   return r.status === 0 ? (r.stdout || '').trim() || root : root;
 }
 
@@ -211,7 +211,7 @@ export function lensesRequired(tier, cfg = null) {
 // name matches no file on disk, so the file would hash as deleted and any later
 // mutation of it would sail through the gate. -z gives raw NUL-separated paths.
 function git(root, ...args) {
-  const r = spawnSync('git', ['-C', root, '-c', 'core.quotePath=false', ...args], {
+  const r = spawnSync('git', ['-C', root, '-c', 'core.quotePath=false', ...args], { windowsHide: true,
     encoding: 'utf8', maxBuffer: 64 * 1024 * 1024,
   });
   return r.status === 0 ? (r.stdout || '') : null;

package/targets/session-memory-core.mjs

@@ -48,7 +48,7 @@ function cleanId(value, prefix = 'session') {
 
 function git(cwd, args) {
   try {
-    return { ok: true, out: execFileSync('git', args, { cwd, encoding: 'utf8', stdio: ['ignore', 'pipe', 'ignore'], maxBuffer: 2 * 1024 * 1024 }).trim() };
+    return { ok: true, out: execFileSync('git', args, { windowsHide: true, cwd, encoding: 'utf8', stdio: ['ignore', 'pipe', 'ignore'], maxBuffer: 2 * 1024 * 1024 }).trim() };
   } catch {
     return { ok: false, out: '' };
   }

package/targets/session-start.mjs

@@ -255,8 +255,8 @@ if (has('.git')) {
     // those make the fingerprint and an unchanged one reuses the last notice. Safe because `reap`
     // re-classifies before it removes anything.
     const trunk = W.resolveTrunk(root);
-    const tip = trunk ? spawnSync('git', ['-C', root, 'rev-parse', trunk], { encoding: 'utf8' }).stdout : '';
-    const list = spawnSync('git', ['-C', root, 'worktree', 'list', '--porcelain'], { encoding: 'utf8' }).stdout;
+    const tip = trunk ? spawnSync('git', ['-C', root, 'rev-parse', trunk], { encoding: 'utf8', windowsHide: true }).stdout : '';
+    const list = spawnSync('git', ['-C', root, 'worktree', 'list', '--porcelain'], { encoding: 'utf8', windowsHide: true }).stdout;
     const fingerprint = `${W.isCleanupEnabled(root)}\n${trunk}\n${tip}\n${list}`;
     const cacheFile = join(root, '.rsc', 'worktree-sweep.json');
     let cached = null;

package/targets/ship-guard.mjs

@@ -67,7 +67,7 @@ const MERGE = /\bgit\s+merge\b/;
 if (!TRUNK.test(command) && !MERGE.test(command)) allow();
 
 const git = (...args) => {
-  const r = spawnSync('git', ['-C', root, ...args], { encoding: 'utf8' });
+  const r = spawnSync('git', ['-C', root, ...args], { windowsHide: true, encoding: 'utf8' });
   return r.status === 0 ? (r.stdout || '').trim() : null;
 };
 

package/targets/worktree-reaper.mjs

@@ -73,7 +73,7 @@ function git(cwd, args) {
   // 64 MiB, because node's 1 MiB default kills git mid-write on any worktree with a few thousand
   // stray files and hands back a truncated-but-successful-looking result. Measured: in the 1.0-1.15 MB
   // band the same unchanged worktree flipped between verdicts across runs.
-  const r = spawnSync('git', ['-C', cwd, ...args], { encoding: 'utf8', maxBuffer: 64 * 1024 * 1024 });
+  const r = spawnSync('git', ['-C', cwd, ...args], { windowsHide: true, encoding: 'utf8', maxBuffer: 64 * 1024 * 1024 });
   // `raw` matters for porcelain output: its leading space is a status code, not padding, and
   // trimming it shifted every path by one character — so the message naming the file about to be
   // lost named a file that does not exist. A refusal has to be true to be actionable (P6).