@damiangilgonzalez/harness 1.3.16 → 1.3.17

package/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.3.16",
+  "version": "1.3.17",
   "counts": {
     "skills": 294,
     "agents": 34,
@@ -3805,7 +3805,7 @@
     },
     {
       "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).",
+      "description": "Use when writing a PR body or opening a PR: a visual summary, before/after evidence, the merge danger (one-way or two-way door, blast radius), and a title checked against the repo's CI title rule before `gh pr create`.",
       "tags": [
         "pull-request",
         "review",

package/package.json

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

package/skills/code-review/SKILL.md

@@ -38,6 +38,8 @@ Busca el spec de origen, en este orden:
 
 Cualquier cosa en el repo que documente cómo debe escribirse el código, como `CODING_STANDARDS.md` o `CONTRIBUTING.md`. (En este proyecto: `CLAUDE.md` y `docs/CARTA-MAGNA.md`.)
 
+Si no encuentras ninguna, **no lo calles**: el eje de Estándares solo tendrá el smell baseline, y el reporte final debe decirlo en su primera línea ("Estándares: el repo no documenta estándares; solo se revisó el smell baseline"). Ofrece generar un `CODING_STANDARDS.md` inicial a partir de las convenciones que se observan en el repo (nombres, estructura, manejo de errores, tests). No lo escribas sin un sí del usuario.
+
 Además de lo que el repo documente, el eje de Estándares siempre lleva el **smell baseline** de abajo — un conjunto fijo de code smells de Fowler (_Refactoring_, cap. 3) que aplica incluso cuando el repo no documenta nada. Dos reglas lo condicionan:
 
 - **El repo manda.** Un estándar documentado del repo siempre gana; donde el repo avale algo que el baseline marcaría, suprime el smell.
@@ -74,7 +76,7 @@ Envía un único mensaje con dos llamadas a la herramienta `Agent`. Usa el subag
 - La ruta o el contenido recuperado del spec.
 - El encargo: "Reporta: (a) requisitos que el spec pedía y que faltan o están parciales; (b) comportamiento en el diff que no se pidió (scope creep); (c) requisitos que parecen implementados pero cuya implementación parece incorrecta. Cita la línea del spec por cada hallazgo. Menos de 400 palabras."
 
-Si falta el spec, sáltate el sub-agente de Spec y anótalo en el reporte final.
+Si falta el spec, sáltate el sub-agente de Spec y anótalo en el reporte final. Si faltan las fuentes de estándares, lanza igual el de Estándares con el baseline, y anótalo también junto con la oferta del `CODING_STANDARDS.md`.
 
 ### 5. Verificar los graves antes de presentarlos
 

package/skills/flujo-interfaz/SKILL.md

@@ -80,6 +80,13 @@ de las skills de diseno. Las mecanicas del framework son de `angular`, `react` o
 | Un flujo pierde usuarios a mitad | `leyes-de-retencion` -> `mejor-redaccion` -> `mejor-accesibilidad` |
 | Solo pulir lo que ya hay | `revision-interfaz` |
 
+## Cuando cuenta como hecho
+
+Un cambio visual no esta hecho sin una **captura del entorno donde el usuario lo va a probar**
+(su navegador, su URL, su viewport; no un test ni un render aislado si el usuario no prueba ahi).
+Que compile y pasen los tests no dice nada de como se ve. Si no puedes abrirlo, dilo y no lo
+declares terminado: "no lo he mirado en un navegador" es un trabajo sin acabar, no un matiz.
+
 ## Donde encaja en la metodologia
 
 Esta cadena vive **dentro** del paso de construir, no lo sustituye. El trabajo sigue llegando con

package/skills/implement/SKILL.md

@@ -14,6 +14,8 @@ Usa TDD (superpowers:test-driven-development) donde sea posible, en las costuras
 
 Ejecuta el typechecking con regularidad, archivos de test sueltos con regularidad, y la suite de tests completa una vez al final.
 
+Si el trabajo cambia algo visible, no está hecho hasta que lo hayas mirado: adjunta una captura del entorno donde el usuario lo va a probar. Si no puedes abrirlo, dilo y no lo des por terminado.
+
 Al terminar, usa /code-review para revisar el trabajo.
 
 Commitea tu trabajo en la rama actual.

package/skills/implement-spec/SKILL.md

@@ -30,9 +30,11 @@ Lanza los **subagentes implementadores** en segundo plano siempre que se pueda,
 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.
+   - fusiona la punta de la rama de integración en su propia rama antes de decir que ha terminado;
+   - si el ticket cambia algo visible, adjunta una captura del entorno donde el usuario lo va a probar;
+   - entrega un informe final de **150 palabras como máximo**: qué cambió, ficheros, resultado de los tests y bloqueos. El detalle va al commit o al ticket, no a la respuesta. Pon este tope literal en el prompt de cada subagente: cada entrega entra entera en tu contexto, y decenas de entregas largas te hacen olvidar lo que acaba de decir el usuario.
 
-5. Cuando un **subagente implementador** termina, fusiona su trabajo en la rama de integración con un **subagente fusionador**.
+5. Cuando un **subagente implementador** termina, revisa su entrega antes de fusionar. Si toca algo visible y no trae captura, o dice que no lo ha mirado en un navegador, **no está hecho**: devuélvesela para que lo mire. Si la entrega es buena, 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.
 

package/skills/orient/SKILL.md

@@ -63,6 +63,9 @@ The dial is spoken, not configured: when the user says "explícame más / menos"
 tanto" or "enséñame", update `accompaniment_level` in the profile, confirm in one line, and apply
 the new depth from this turn on.
 
+When a front closes (PR merged or opened, ticket done), `➡️` offers `handoff` and a fresh session
+before more work in this one; see the contract.
+
 At a real fork, ask. Deciding alone is faster and wrong — the fork is the moment the person's
 judgment is worth more than yours.
 

package/skills/orient/references/orientation-contract.md

@@ -28,6 +28,15 @@ Read `docs/wiki/harness/user-profile.md`. Two fields combine: `accompaniment_lev
 
 `technical_level` is orthogonal (plain language for `non-technical` even at L0; skip 101s for `technical` even at L3). Missing profile → assume `non-technical` + **L3** and offer to set the dial.
 
+## When a front closes
+
+A front ("frente") closes when its PR is merged or opened, or its ticket is done. That turn's `➡️`
+proposes `handoff` and a new session as the first option, instead of starting the next front here.
+A session that runs for days through several `/compact` loses what the user just said: each
+compaction and each subagent hand-back pushes the latest instructions further out. A handoff
+document carries what matters; the new session starts with room for it. If the user prefers to
+continue, continue — offer once per front, not every turn.
+
 ## Division of labor
 
 - `orient` guides the **person** (this contract).

package/skills/pr/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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)."
+description: "Use when writing a PR body or opening a PR: a visual summary, before/after evidence, the merge danger (one-way or two-way door, blast radius), and a title checked against the repo's CI title rule before `gh pr create`."
 tags: ["pull-request", "review", "evidence", "risk"]
 profiles: [core, ui, full]
 origin: damiangil
@@ -171,3 +171,17 @@ La evidencia basada en ejecución va justo detrás: resultados de tests, salida
 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.
+
+## Título
+
+Antes de `gh pr create`, comprueba que el título pasa el check de CI del repo. Un título mal formado tumba la PR aunque el código esté bien.
+
+1. Busca la regla: `grep -rnE "semantic-pull-request|pull_request\.title|commitlint" .github/workflows/` y, si aparece commitlint, su configuración (`commitlint.config.*`, `.commitlintrc*`, `package.json`). En `amannn/action-semantic-pull-request` mira `types`, `scopes`, `requireScope` y `subjectPattern`.
+2. Saca la regex o los tipos permitidos y prueba el título:
+
+   ```bash
+   node -e 'const re=/^(feat|fix|docs|refactor|test|chore)(\([\w-]+\))?!?: .+/u; const t=process.argv[1]; console.log(re.test(t)?"OK":"FALLA: "+t)' "fix(pr): valida el título"
+   ```
+
+   Si el repo antepone un gitmoji u otro prefijo, inclúyelo en la regex tal como lo pida la regla.
+3. Si falla, corrige el título antes de crear la PR. Si no hay ningún check de título, sigue la convención de los commits recientes (`git log --oneline -10`).

package/skills/pr/evals/cases.yaml

@@ -11,6 +11,8 @@ should_trigger:
     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."
+  - prompt: "Abre la PR, pero que el título no vuelva a tumbar el CI."
+    why: "Disparador directo de pr: el título se valida contra el check del repo."
 
 should_not_trigger:
   - prompt: "Revisa el código de esta PR."
@@ -31,3 +33,7 @@ capability:
     must_include:
       - "Peligro de fusión"
       - "Radio de impacto"
+  - scenario: "El repo tiene un check de título de PR en sus workflows."
+    must_include:
+      - ".github/workflows"
+      - "gh pr create"

package/targets/claude.js

@@ -9,6 +9,15 @@ const HERE = dirname(fileURLToPath(import.meta.url));
 // so a `Bash`-only matcher let `git push --force` or a commit without gitmoji through unasked.
 const SHELL_TOOLS = 'Bash|PowerShell';
 
+// Mods de la terminal de Claude Code que el harness deja activados en cada proyecto.
+// `cache-tax` mantiene caliente la caché del prompt en las pausas, y eso gasta tokens.
+export const CLAUDE_CODE_MODS = Object.freeze([
+  { id: 'skins@hellosverre-mods', marketplace: 'hellosverre-mods', repo: 'hellosverre/claude-skins' },
+  { id: 'savvy-progress@claude-kit', marketplace: 'claude-kit', repo: 'johnnyvizz/claude-kit' },
+  { id: 'filetree@claude-code-filetree', marketplace: 'claude-code-filetree', repo: 'data-goblin/claude-code-filetree' },
+  { id: 'cache-tax@claude-code-mods', marketplace: 'claude-code-mods', repo: 'karanb192/claude-code-mods' },
+]);
+
 export function writeSkill(id, fromDir, toPath) {
   // Migrate away from the legacy nested layout (.claude/skills/rsc/<id>) that
   // Claude Code never discovered — it only reads .claude/skills/<name>/SKILL.md.
@@ -235,6 +244,16 @@ export function wireHook(paths, sourceMd, policy = {}) {
     for (const id of policy.plugins) settings.enabledPlugins[id] = true;
   }
 
+  // Los mods de Claude Code van en cada install y update, se use el flujo o no. Con el marketplace
+  // en `extraKnownMarketplaces`, Claude Code ofrece instalarlos al abrir el proyecto. Un `false`
+  // que alguien puso a mano es una decisión suya y se respeta.
+  settings.extraKnownMarketplaces ||= {};
+  settings.enabledPlugins ||= {};
+  for (const { id, marketplace, repo } of CLAUDE_CODE_MODS) {
+    settings.extraKnownMarketplaces[marketplace] ||= { source: { source: 'github', repo } };
+    if (settings.enabledPlugins[id] !== false) 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,