@damiangilgonzalez/harness 1.3.7

package/skills/revision-de-cambios/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: revision-de-cambios
+description: "Reviews a CHANGE (uncommitted work, a branch, a commit range, or a pull request) rather than a screen. Resolves the scope, expands the touched files to the surfaces they affect, reads both sides of the diff, and classifies each finding as introduced, a regression, or pre-existing."
+tags: ["code-review", "diff-review", "regression"]
+disable-model-invocation: true
+profiles: [core, ui, full]
+---
+
+# Revision de cambios
+
+Esta skill revisa un cambio, no una pantalla. Resuelve el alcance, expande los ficheros modificados a las superficies que afectan, lee los dos lados del diff y clasifica cada hallazgo.
+
+El alcance es lo unico que le pertenece. Las reglas de dominio son de las skills `mejor-*`. La severidad, la consolidacion, la cobertura, el tope y el veredicto son de `revision-interfaz`, a quien esta skill entrega la revision.
+
+La correccion funcional, los tests, la seguridad y el rendimiento son de la revision de codigo general del proyecto. Nombra la preocupacion una vez y sigue.
+
+## El cambio, no el codebase
+
+El autor esta preguntando "he empeorado esto?". Reporta lo que el cambio provoco y quedate mayormente callado sobre lo que simplemente toco. Tres hallazgos preexistentes son una cortesia; treinta son otra revision distinta que nadie pidio.
+
+Lee el cambio antes de formarte una opinion sobre el. La intencion declarada decide que cuenta como incompleto, y un diff leido por encima produce hallazgos sobre codigo que el siguiente hunk ya arregla.
+
+## Principios centrales
+
+### 1. Resuelve primero el alcance del cambio
+
+Toda la invocacion es el objetivo, asi que `/revision-de-cambios pr 482` revisa el pull request 482.
+
+Sin objetivo indicado, resuelve en este orden y para en la primera coincidencia:
+
+1. `HEAD` va por delante de `git merge-base origin/<rama-por-defecto> HEAD`: ese rango **mas** cualquier cambio sin commitear, indicando por separado el numero de commits y el de ficheros sin commitear.
+2. El arbol de trabajo esta sucio: los cambios sin commitear.
+3. Ninguno de los dos: no hay cambio que revisar. Para y pregunta.
+
+El orden importa. Si compruebas primero el arbol de trabajo, una edicion suelta de formato eclipsa una rama de doce commits, y el informe seguira afirmando cobertura completa.
+
+Excluye lockfiles, snapshots, salida generada, codigo vendorizado y binarios, y di que excluiste. Un alcance vacio tras las exclusiones llega al mismo sitio por otro camino.
+
+### 2. Sin cambio, pregunta en vez de inventarte uno
+
+Un arbol limpio y sin nada por delante del merge-base significa que el usuario pidio revisar un cambio que no existe. Nunca caigas por tu cuenta en `HEAD~1..HEAD`. El ultimo commit es lo que haya aterrizado, a menudo un merge, a menudo trabajo de otro, y un informe sobre el es indistinguible de un informe sobre lo que el usuario queria decir.
+
+Expon los hechos del repositorio que encontraste y ofrece las rutas, y espera:
+
+- **El ultimo commit**, `HEAD~1..HEAD`, nombrado por SHA corto y asunto, para que el usuario vea que obtendria antes de elegirlo.
+- **Un objetivo que el nombre**: `pr <n>`, una rama, una ref o un rango.
+- **Una auditoria de interfaz de todo el repositorio**, que no es una revision de cambio. Entregala a `revision-interfaz` como revision de alcance de repositorio, sin el bloque de alcance de esta skill, sin estados y sin seccion de preexistentes. Sin cambio, todo hallazgo es preexistente y la clasificacion no dice nada.
+
+Comprueba si hay un pull request abierto en la rama actual antes de preguntar, y ofrecelo el primero. Una rama cuyos commits ya aterrizaron resuelve a "sin cambio", pero su pull request sigue siendo exactamente lo que el usuario queria decir.
+
+Cuando el alcance se quede vacio tras las exclusiones, di que ficheros excluiste y pregunta igual. Nunca reportes como `Aprobar` una revision de nada.
+
+### 3. Un diff no es una superficie
+
+Un fichero modificado es evidencia, no el sujeto de la revision. Su **radio de impacto** es el conjunto de superficies en las que se renderiza; revisa esas.
+
+Expande el radio un salto por defecto: los importadores y llamantes directos. Expande un segundo salto solo para tokens de diseno, valores de tema y primitivas compartidas, donde una linea llega a todo el producto.
+
+Revisa como maximo cinco consumidores y luego di cuantos no expandiste. Un barrido sin limite no puede sostener la cobertura que afirma, y un corte no declarado se lee como completitud.
+
+### 4. Lee las lineas eliminadas
+
+Las regresiones son invisibles en el estado posterior al cambio. Lee el lado `-` de cada hunk buscando senales eliminadas: nombres accesibles, indicadores de foco, gating de `prefers-reduced-motion`, roles ARIA, etiquetas, textos alternativos, gestion de estados.
+
+Una senal es una pista, no un hallazgo. Una eliminacion solo es regresion cuando nada en el cambio la sustituye, y ese juicio es de la skill de dominio. Enruta cada eliminacion sin equivalente a su propietaria, reporta solo lo que esa skill confirme y marcalo con estado `Regresion`. Eso le dice al autor que rompio algo que funcionaba, en vez de que cometio un error nuevo.
+
+### 5. Clasifica cada hallazgo
+
+Da a cada hallazgo un estado:
+
+- `Introducido`: el cambio lo creo.
+- `Regresion`: el cambio debilito algo que antes era correcto.
+- `Preexistente`: estaba en el codigo tocado pero no lo causo este cambio.
+
+El estado va por lo que el diff toco, no por el fichero en el que vive: una linea que el cambio nunca toco es `Preexistente` aunque este a tres lineas de un hunk. Confirmalo contra la ref base cuando importe:
+
+```bash
+git blame -L <linea>,<linea> "$BASE" -- ruta/al/fichero
+```
+
+Entrega cada hallazgo con su estado adjunto y deja que `revision-interfaz` aplique su tope y sus reglas de veredicto.
+
+### 6. Somete el cambio a su intencion declarada
+
+Lee el titulo y el cuerpo del pull request, la issue enlazada y los mensajes de commit, y revisa si la interfaz entrega lo que afirman.
+
+Esto es lo que saca a la luz el cambio **incompleto**. Una revision de superficie no puede verlo, porque inspecciona los estados presentes, y aqui el asunto son los ausentes:
+
+- Una variante, tamano o tema nuevo aplicado a algunos estados pero no a todos: hover, foco, activo, deshabilitado, cargando, seleccionado.
+- Un texto nuevo de cara al usuario sin entrada en el catalogo de traducciones que mantiene el proyecto.
+- Un componente nuevo sin estado vacio, de carga, de error, deshabilitado o de anchura estrecha.
+- Un control anadido a una superficie pero no a las hermanas que ya llevan sus pares.
+
+No reportes ampliacion de alcance. Si un cambio hace demasiado es una cuestion de proceso, no de interfaz.
+
+### 7. Entrega la revision a `revision-interfaz`
+
+Entrega a `revision-interfaz` el bloque de alcance, las superficies afectadas y un estado por hallazgo. Ella enruta a las skills de dominio, aplica severidad, consolida, hace cumplir el tope y emite el veredicto.
+
+Si `revision-interfaz` no esta disponible, reporta el alcance resuelto y el inventario de ficheros, nombra la skill que falta y para. No te inventes una escala de severidad, un tope ni un veredicto.
+
+### 8. Nunca mutes el arbol de trabajo
+
+Una revision de cambio es de solo lectura, incluido el checkout. Trae las refs de pull request; nunca hagas checkout de ellas. `git fetch` solo escribe en `.git` y esta permitido. `gh pr checkout`, `git checkout`, `git switch` y `git stash` reescriben los ficheros que el autor tiene abiertos: fallan contra ediciones locales o las descartan, asi que nunca estan permitidos.
+
+La verificacion renderizada es opcional y bajo peticion. Marca las afirmaciones visuales y de ejecucion como **No verificado** salvo que el proyecto exponga una vista previa barata o el usuario pida revision renderizada. Cuando lo haga, usa un worktree aislado (`git worktree add /tmp/review-<n> refs/remotes/pr/<n>`) y quitalo al terminar.
+
+## Antes de terminar
+
+| Error | Arreglo |
+| --- | --- |
+| Revisar una edicion suelta en vez de la rama | Comprueba `merge-base` antes que el arbol de trabajo, y reporta ambos recuentos |
+| Revisar el ultimo commit porque no habia cambio | Expon los hechos y ofrece el ultimo commit, un objetivo nombrado o una auditoria de repositorio |
+| Revisar hunks sin sus consumidores | Expande un salto, dos para tokens y primitivas, y di que te saltaste |
+| Leer solo el lado `+` del diff | Busca en el lado `-` senales eliminadas de accesibilidad, foco, movimiento y texto |
+| Reportar como regresion un reemplazo equivalente | Enruta la eliminacion a su propietaria; reporta solo lo que confirme |
+| Reportar una eliminacion como error nuevo | Marcala `Regresion`, para que el autor sepa que antes funcionaba |
+| Marcar `Introducido` una linea cercana a un hunk | Clasifica por lo que el diff toco, confirmado con `git blame` contra la ref base |
+| Hacer checkout de un pull request para revisarlo | Trae la ref y revisala en el sitio |
+| Citar numeros de linea que no existen en la ref revisada | Cita contra la ref head nombrada en el bloque de alcance |
+| Repetir aqui la escala de severidad o el tope | Delega en `revision-interfaz` |
+| Hallazgos de correccion, tests o seguridad en el informe | Nombra la preocupacion una vez, senala la revision de codigo del proyecto y suéltala |
+
+## Formato de salida
+
+Abre con el bloque de alcance:
+
+| Campo | Valor |
+| --- | --- |
+| Objetivo | `rama`, `trabajo`, `staged`, `pr 482`, o el rango tal cual se introdujo |
+| Ref base | `origin/main` en `a1b2c3d` |
+| Ref head | `refs/remotes/pr/482` en `e4f5g6h` |
+| Commits | 7 commiteados, 2 ficheros sin commitear |
+| Ficheros en alcance | 12 tras exclusiones |
+| Excluidos | `pnpm-lock.yaml`, `src/__snapshots__/`: lockfile y snapshots |
+| Superficies expandidas | `PaginaCheckout`, `PanelAjustes`; 3 consumidores mas de `Button` sin expandir |
+
+Detras va la tabla de cobertura sin cambios. Un dominio sin evidencia en el alcance del cambio es `No revisado: sin evidencia en el alcance del cambio`, que es una declaracion de cobertura, no un hueco.
+
+Luego los hallazgos, con columna `Estado`:
+
+| Severidad | Dominio | Estado | Ubicacion | Antes | Despues | Por que |
+| --- | --- | --- | --- | --- | --- | --- |
+| ALTA | Accesibilidad | Regresion | `src/Dialog.tsx:42` | `aria-label="Cerrar"` eliminado en este cambio | Restaura `aria-label="Cerrar"` en el control de solo icono | El control de cierre tenia nombre accesible antes de este cambio y ya no lo tiene |
+
+Sin hallazgos `Introducido` ni `Regresion`, omite la tabla y di "Sin hallazgos accionables de interfaz en este cambio."
+
+Luego los `Preexistente`, como maximo tres, de mayor severidad primero, indicados claramente como no responsabilidad de este cambio. Omite la seccion si no hay ninguno.
+
+El tope y el veredicto cubren solo `Introducido` y `Regresion`. Los preexistentes quedan fuera del tope, para que tocar un fichero heredado no se convierta en una auditoria completa del fichero. Tambien quedan fuera del veredicto: un cambio cuyos unicos hallazgos son preexistentes es un `Aprobar`.
+
+Termina con `Bloquear` si queda alguna `ALTA` y `Aprobar` en caso contrario, dejando el resto de hallazgos en la tabla como trabajo pendiente.

package/skills/revision-de-cambios/evals/cases.yaml

@@ -0,0 +1,32 @@
+skill: revision-de-cambios
+
+should_trigger:
+  - prompt: "Revisa este cambio, el trabajo sin commitear que tengo ahora."
+    why: "Disparador directo de revision-de-cambios."
+  - prompt: "Clasifica los hallazgos de este PR como introducidos o preexistentes."
+    why: "Disparador directo de revision-de-cambios."
+  - prompt: "Revisa este rango de commits y expande a las superficies afectadas."
+    why: "Disparador directo de revision-de-cambios."
+  - prompt: "Review this pull request and classify each finding as a regression or pre-existing."
+    why: "Disparador directo de revision-de-cambios."
+  - prompt: "Necesito revisar el diff de esta rama frente a main."
+    why: "Disparador directo de revision-de-cambios."
+
+should_not_trigger:
+  - prompt: "Revisa toda la pantalla de accesibilidad, layout y color a la vez."
+    route_to: "revision-interfaz"
+    why: "Revisar una pantalla completa en accesibilidad, layout y color es el trabajo de revision-interfaz, no de revision-de-cambios."
+  - prompt: "Implementa la funcionalidad que falta."
+    route_to: "implement"
+    why: "Implementar la funcionalidad es el trabajo de implement, no de revision-de-cambios."
+  - prompt: "Escribe la spec de este cambio."
+    route_to: "to-spec"
+    why: "Escribir la spec de un cambio es el trabajo de to-spec, no de revision-de-cambios."
+  - prompt: "Documenta la decision de arquitectura tomada."
+    route_to: "write-adr"
+    why: "Documentar una decision de arquitectura es el trabajo de write-adr, no de revision-de-cambios."
+
+capability:
+  - scenario: "El usuario quiere revisar un cambio concreto en lugar de una pantalla entera."
+    must_include:
+      - "diff"

package/skills/revision-de-cambios/removed-signals.md

@@ -0,0 +1,38 @@
+# Removed signals
+
+What to look for on the `-` side of a hunk and which skill owns the judgement. A row here is a lead, never a finding. Route the removal to its owner and report it only once that skill confirms the interface got worse.
+
+| Removed from the `-` side | Owner | What to check |
+| --- | --- | --- |
+| `aria-label`, `aria-labelledby`, `aria-describedby`, `aria-live`, `role=` | `better-accessibility` | The control or region lost its accessible name, description, or announcement |
+| `alt=`, `<label`, `for=`, `scope=` | `better-accessibility` | Image, field, or table cell lost its programmatic association |
+| `<button>`, `<a>`, `<nav>`, `<main>`, `<ul>` replaced by `div` or `span` | `better-accessibility` | Keyboard and assistive-technology behavior was traded for styling |
+| `:focus-visible`, `:focus`, `outline`, `tabindex` | `better-accessibility` | Keyboard users lost the focus indicator or the element left the tab order |
+| `prefers-reduced-motion`, `prefers-contrast` | `better-accessibility` | Motion or contrast now ignores the user's system preference |
+| Logical properties swapped for `left` / `right` | `better-layout` | Direction-aware layout was dropped |
+| `lang=`, `dir=` | `better-typography` | Language metadata or text direction was dropped |
+| `text-wrap`, `line-clamp`, `overflow-wrap`, `tabular-nums`, `font-feature-settings` | `better-typography` | Text rendering, wrapping, or numeral alignment silently changed |
+| A color token swapped for a literal, or a token swapped for a lighter one | `better-colors` | The rendered contrast pair may now fail; measure it |
+| A user-facing string deleted or shortened | `better-writing` | A label, error, or empty state lost the information it carried |
+
+## Equivalent replacements
+
+These clear the signal. Check for them before routing anything, or the report fills with refactors reported as regressions:
+
+- `aria-label` giving way to `aria-labelledby` pointing at visible text.
+- An explicit `role` dropped because the element became the native equivalent, `role="button"` going as a `div` becomes a `<button>`.
+- `outline` replaced by a `box-shadow` focus ring that still meets the focus-indicator rule.
+- `tabindex="0"` dropped from an element that is now natively focusable.
+- A color literal replaced by a token that measures the same rendered pair.
+- A physical property replaced by its logical counterpart, which is the fix rather than the regression.
+- A string moved into the translation catalogue rather than deleted.
+
+## Searching the removed side
+
+Restrict the search to deleted lines so additions do not mask a removal:
+
+```bash
+git diff -U0 "$BASE"...HEAD -- '*.tsx' '*.css' | grep -E '^-[^-]' | grep -E 'aria-|role=|alt=|focus|tabindex|prefers-'
+```
+
+Read the surrounding hunk before deciding. A removed attribute is meaningless without the element it came from, and `-U0` deliberately hides that context.

package/skills/revision-de-cambios/scope-resolution.md

@@ -0,0 +1,88 @@
+# Scope resolution
+
+Turning a review target into a file list. The commands themselves are ordinary git. What follows is the part that is not obvious, plus the traps that fail quietly and leave the scope block claiming a count it never delivered.
+
+## Default branch
+
+Try `refs/remotes/origin/HEAD`, then `gh repo view --json defaultBranchRef`, then `init.defaultBranch`. If the ref is missing, ask the remote with `git remote set-head origin --auto` rather than guessing. It needs the network and writes a ref under `.git`, leaving the working tree untouched, so it is permitted; note it in Verification. With no remote at all, fall back to a local `main` or `master` and state which base you assumed.
+
+## Targets
+
+Accepted targets are `working`, `staged`, `branch`, `pr <n>`, a bare `<ref>` and an explicit `<a>..<b>` or `<a>...<b>` range. Anything else in the invocation is a `<ref>`.
+
+Diff a branch against the **merge base**, three dots. Two dots reports every upstream commit that landed on the base branch as part of the change.
+
+But use the dots the user wrote when they wrote a range. `<a>..<b>` compares the endpoints; `<a>...<b>` compares `merge-base(<a>, <b>)` with `<b>`. Rewriting `release..feature` to three dots drops everything between `release` and the merge base, which is often exactly what was asked for. State the resolved range in the scope block.
+
+`git diff HEAD` reports tracked changes only. Any target including uncommitted work must pair it with `git ls-files --others --exclude-standard`. Otherwise a newly added component is silently dropped from a scope the report claims to cover in full. For `branch` with uncommitted work, report the two counts separately.
+
+## Pull requests
+
+Fetch the head into a remote-tracking ref, `git fetch origin "pull/<n>/head:refs/remotes/pr/<n>"`, and review it in place. This works for forks, which `origin/<branch>` does not.
+
+Read files at that ref with `git show refs/remotes/pr/<n>:path/to/file`. Never open the working-tree copy; on a fork PR it is a different file.
+
+`gh pr diff <n>` is a fine shortcut for the patch text. It gives no way to read unchanged context or expand to consumers, so fetch the ref as well.
+
+**Citations.** `better-interface` requires `path/to/file:line`, and line numbers from a fetched ref need not match the working tree. Cite against the head ref, and declare that ref and its SHA in the scope block so the numbers resolve.
+
+**Intent.** The `title` and `body` from `gh pr view` are the stated intent for **Hold the change to its stated intent**. Add the commit subjects when the body is empty.
+
+## Awkward repository states
+
+Three worth handling. Everything else fails loudly at `merge-base`: no remote, unrelated histories, a repo with no commits, a moved submodule pointer. Say the base is unresolvable and stop. Never review a range you cannot name.
+
+**Detached HEAD.** Use the merge base against the default branch and name the SHA, not a branch, in the scope block.
+
+**Shallow clone**, the CI default, where `merge-base` returns nothing. Fetch `--deepen=50`, retry, then `--deepen=200`, then report the scope as unresolvable. Deepening writes to `.git` and not to the working tree, so it is permitted; note it in Verification.
+
+**Mid-rebase or mid-merge**, the one that does not fail loudly. `git diff` succeeds and returns something that is not the change, so the review looks fine and is wrong. Detect it with `git rev-parse --git-path` against `rebase-merge`, `rebase-apply`, `MERGE_HEAD` and `CHERRY_PICK_HEAD`. Do not test `.git/` paths directly, because they are not directories inside a linked worktree. Stop and say the tree is mid-operation.
+
+## Nothing to review
+
+The tree is clean and `HEAD` is not ahead of the merge base. Gather the facts before asking, so the offer is accurate rather than a guess: the current branch, whether the tree is clean, the count ahead of the base, the last commit's SHA and subject and any open pull request from `gh pr status`.
+
+`gh pr status` succeeds when no pull request is open. It omits `currentBranch`, so an empty result is an answer, not an error. It fails outright without `gh`, without authentication and on a repository with no GitHub remote. Treat any failure as "no pull request found", say so and offer the remaining routes rather than stopping.
+
+Report those facts, then offer the three routes in **With no change, ask rather than invent one**. State the last commit's SHA and subject inside the offer. The user recognises "a1b2c3d Merge pull request #482" as not what they wanted and cannot recognise "the last commit".
+
+A whole-repository audit is a different review, not this one with a wider net. Hand the repository to `better-interface` directly, without a scope block, statuses, or a pre-existing section.
+
+## Renames
+
+Rename detection is on by default for `--name-status`, reporting `R100 old/path new/path`. Raise the window with `--find-renames=40% --find-copies-harder` when a file was moved and edited in the same change.
+
+Review a rename as a move, not a delete plus an add. Everything that survived the move is unchanged code, and only the genuine edits are in scope.
+
+## Excluded paths
+
+Exclude these and name what you excluded in the scope block. They are machine-authored and carry no interface rules.
+
+| Category | Patterns |
+| --- | --- |
+| Lockfiles | `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `bun.lock`, `bun.lockb`, `Cargo.lock`, `composer.lock`, `Gemfile.lock`, `poetry.lock`, `uv.lock` |
+| Snapshots and fixtures | `__snapshots__/`, `*.snap`, `*.approved.*`, `test-results/`, `playwright-report/` |
+| Generated output | `dist/`, `build/`, `out/`, `.next/`, `.turbo/`, `.svelte-kit/`, `coverage/`, `storybook-static/`, `*.min.js`, `*.min.css`, `*.map` |
+| Generated sources | `*.gen.ts`, `*.generated.*`, `*.d.ts` emitted by a build, GraphQL and Prisma client output |
+| Vendored code | `vendor/`, `third_party/`, `node_modules/` |
+| Binaries and media | `*.png`, `*.jpg`, `*.webp`, `*.avif`, `*.woff2`, `*.mp4`, `*.pdf` |
+
+Two exceptions stay in scope. A **font file** added or swapped is a `better-typography` change. An **image** added to a component is a `better-ui` and `better-accessibility` change, through its `alt` text and its outline. Review the code that references them, not the bytes.
+
+Apply the exclusions as pathspecs so the file count in the scope block is the reviewed count. Two traps under-exclude silently. `*.lock` catches `yarn.lock` and `Cargo.lock` but not `package-lock.json` or `pnpm-lock.yaml`, so cover every suffix in the table. And `**` needs `glob` magic: without it `*` never crosses `/`, so `**/dist/**` excludes `packages/a/dist/` but misses a root-level `dist/`. Run the diff with and without the pathspecs and confirm the count dropped by exactly the files you named.
+
+## Expanding to consumers
+
+**A diff is not a surface** expands one hop, two for tokens and primitives. Use the project's own resolver where one exists, otherwise import paths.
+
+`git grep` searches the working tree by default. Pass the reviewed ref after the pattern, or on a pull request you search a different revision and miss importers the change itself added. Results come back as `<rev>:path/to/file`; read them with `git show`, never the working-tree copy. Pass `-e` when the pattern starts with a dash, such as a `--color-*` token, or git parses it as an option.
+
+For a changed token or theme value, search the token name rather than the file, since consumers reference the name and never import it.
+
+Order the consumers by a rule you can evaluate, so the cutoff is reproducible instead of a guess:
+
+1. **Route and layout entry points first**, whatever the framework treats as a rendered surface: `app/**/page.*`, `app/**/layout.*`, `pages/**`, `routes/**`, `src/views/**`, `*.astro` pages. Everything else only appears inside one.
+2. **Then by importer count**, since a component pulled in by twenty files carries more of the change than one pulled in by two.
+3. **Break ties by proximity**, same package or feature directory first.
+
+Review the first five, state how many you did not expand and say plainly if the ordering was arbitrary past a point.

package/skills/revision-interfaz/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: revision-interfaz
+description: "Combines all the `mejor-*` skills into a single interface review covering accessibility, layout, copy, typography, color, and visual polish, and consolidates a verdict ordered by impact."
+tags: ["ui-review", "accessibility", "design-audit"]
+profiles: [ui, full]
+---
+
+# Revision de interfaz
+
+Esta skill ejecuta una revision multidisciplinar. Enruta la interfaz a cada skill `mejor-*`, recoge sus evidencias y consolida un unico veredicto ordenado.
+
+Lo unico que le pertenece es la orquestacion. Las reglas de accesibilidad son de `mejor-accesibilidad`, la estructura de `mejor-layout`, el texto de `mejor-redaccion`, la tipografia de `mejor-tipografia`, el color de `mejor-colores`, y el acabado visual y el movimiento de `mejor-ui`. Nunca dupliques ni sobreescribas sus reglas aqui.
+
+La revision acotada a un cambio (trabajo sin commitear, ramas, pull requests) es de `revision-de-cambios`, que resuelve el alcance y clasifica los hallazgos antes de devolver la revision aqui.
+
+## Evidencia, no gusto
+
+Aprieta fuerte con los disparadores de escalado y deja en paz las decisiones deliberadas del proyecto. Ambas cosas tiran en la misma direccion. Un disparador es un fallo diga lo que diga la guia de estilo; una densidad, un radio o un tono de voz con el que simplemente no estas de acuerdo no es un hallazgo.
+
+El liston para reportar es la evidencia, no el gusto. El liston para `Aprobar` es que inspeccionaste lo que dices haber inspeccionado. Un informe corto de una inspeccion real vale mas que uno largo inflado para parecer exhaustivo.
+
+## Principios centrales
+
+### 1. Resuelve primero el alcance
+
+Deduce la pantalla, el flujo, la funcionalidad o el alcance de repositorio a partir de la peticion y del espacio de trabajo actual. Indica el alcance resuelto en la salida.
+
+Cubrelo entero en todas las skills de dominio listadas abajo, incluidos los estados vacio, de carga, de error y de anchura estrecha donde existan. Reporta como maximo 15 hallazgos.
+
+Cuando el alcance sea demasiado grande para inspeccionarlo con credibilidad, redúcelo a un flujo completo: aquel sobre el que gira la peticion o, en su defecto, el camino de entrada por el que pasa todo usuario. Indica el limite y que dejaste fuera. Nunca des a entender que revisaste superficies sin inspeccionar.
+
+### 2. Manda los cambios a `revision-de-cambios`
+
+Una peticion que nombra una rama, un pull request, un rango de commits o cambios sin commitear es una revision de cambio, no de pantalla. Dilo y pide al usuario que ejecute `revision-de-cambios`.
+
+Nunca resuelvas aqui el alcance de un cambio. Leer un diff, clasificar hallazgos y expandir los ficheros tocados a las superficies afectadas es de `revision-de-cambios`. Si lo adivinas, el informe tendra un alcance que nadie puede comprobar.
+
+Cuando `revision-de-cambios` devuelva una revision, aporta el alcance del cambio, un estado por hallazgo y el formato de informe acotado al cambio. La severidad, el orden, el tope y el veredicto se quedan aqui, y los tres cubren solo `Introducido` y `Regresion`.
+
+### 3. Reconocimiento antes que juicio
+
+Identifica el framework, el sistema de estilos, la libreria de componentes, los tokens de diseno, los viewports soportados y cualquier comando de vista previa o de test. Escribe cada arreglo en el idioma del propio proyecto, para que ningun hallazgo llegue como una peticion de cambiar de stack. Eso gobierna la FORMA del arreglo, no si el codigo es lo bastante bueno.
+
+Luego lee lo que el proyecto ha escrito sobre su propia interfaz: `CONTRIBUTING.md`, `CODING_STANDARDS.md`, `AGENTS.md`, `CLAUDE.md`, un documento de design system, docs de Storybook, ADRs de interfaz. Nombra cuales encontraste, o di que no hay ninguno.
+
+Léelos para saber DONDE va un hallazgo, no para tener permiso de descartarlo. Una convencion documentada no es prueba de que la convencion sea buena, y "esta en la guia de estilo" no retira un hallazgo. Lo que cambian es **donde** reportas. Cuando la causa es una directriz o un token compartido, reportalo una vez contra esa fuente, con los componentes como sus ubicaciones.
+
+### 4. Usa las skills de dominio como fuentes de verdad
+
+Antes de revisar, confirma que cada skill propietaria esta disponible. Carga y aplica todas las disponibles, y completa cada revision de dominio antes de consolidar.
+
+Revisa en este orden, para que los fallos de cimientos no queden tapados por el acabado:
+
+1. `mejor-accesibilidad`
+2. `mejor-layout`
+3. `mejor-redaccion`
+4. `mejor-tipografia`
+5. `mejor-colores`
+6. `mejor-ui`
+
+De cada skill de dominio cargada aqui, coge sus principios, sus referencias y sus comprobaciones de verificacion. Su escala de severidad y su formato son para uso independiente; el formato consolidado, la severidad compartida y el tope de hallazgos de este fichero los sustituyen.
+
+Si una skill propietaria no esta disponible, marca ese dominio como `No revisado`, nombralo y sigue con el resto. No recrees sus reglas de memoria, ni sustituyas por una vecina, ni afirmes cobertura completa.
+
+Cuando dos skills parezcan cubrir un mismo problema, asignalo al propietario de la regla subyacente y anota los efectos secundarios en la celda **Por que**. Reportalo una sola vez.
+
+### 5. Exige evidencia
+
+Cada hallazgo cita `ruta/al/fichero:linea` y muestra la implementacion actual. No reportes un hallazgo de codigo solo por la apariencia visual, ni un hallazgo visual solo por el codigo fuente cuando el resultado lo determina el comportamiento en ejecucion.
+
+### 6. Ordena por impacto en el usuario
+
+Usa una unica escala de severidad compartida:
+
+- `ALTA`: bloquea una tarea, engana al usuario, oculta contenido o controles, arriesga perdida de datos, o crea un fallo sistemico repetido.
+- `MEDIA`: dana de forma apreciable la comprension, la eficiencia, la adaptabilidad o la consistencia.
+- `BAJA`: pulido aislado con impacto limitado en la tarea.
+
+Dentro de una severidad, ordena por a cuantos sitios llega el hallazgo y cuanto compra un solo arreglo. Arreglar un token o un componente compartido va por delante del mismo sintoma en una hoja suelta.
+
+**Disparadores de escalado.** En cuanto la skill propietaria confirma uno de estos, es `ALTA` a la vista, y nunca se promedia a la baja porque la superficie sea menor:
+
+- Un control interactivo sin nombre accesible.
+- Un control alcanzable por teclado sin indicador de foco visible.
+- Un control o camino alcanzable con el puntero pero no con el teclado.
+- Movimiento o contenido con reproduccion automatica que ignora `prefers-reduced-motion`.
+- Contenido o control recortado, solapado o inalcanzable a 320px de ancho o al 200% de zoom.
+- Texto de cuerpo o de control cuyo par de contraste renderizado no llega a su ratio exigido.
+- Estado o significado transmitido solo por color.
+- Una accion destructiva sin confirmacion, sin deshacer y sin tratamiento distintivo.
+- Contenido truncado sin forma de alcanzar el valor completo.
+- Contenido o control alcanzable solo pasando un borde de scroll o tras un desplegable sin pista visible.
+- Un error que no nombra ninguna forma de recuperarse.
+- Un color semantico usado contra su significado, como el tono de peligro en una accion no destructiva.
+- Un cambio de estado transmitido solo por movimiento, sin color, icono ni etiqueta que quede cuando la animacion no se reproduce.
+
+Los disparadores van por delante de cualquier otro hallazgo. Cuando se disparen mas de los que permite el tope, listalos primero y di cuantos excluyo el tope. Un tope puede acortar un informe; nunca puede ser la razon de que un bloqueante quede sin reportar.
+
+Estos fijan la severidad, no reglas nuevas. La skill propietaria decide si el sintoma esta presente; esta lista decide cuanto cuesta. En una revision de cambio, una `Regresion` confirmada contra un disparador es `ALTA` aunque el mismo sintoma fuera `MEDIA` como preexistente.
+
+### 7. Prefiere el arreglo mas barato
+
+La severidad dice como de grave es un hallazgo; esto dice que arreglo proponer. Cuando funcionen varios, coge el primero que sirva:
+
+1. **Borrar.** Un separador que el espacio ya sostiene, una animacion en una interaccion de alta frecuencia, un atributo ARIA que un elemento nativo hace redundante, una rampa de color que nadie importa.
+2. **Usar la plataforma.** El elemento nativo, el control nativo, el anillo de foco del navegador, en vez de una reconstruccion propia.
+3. **Reutilizar lo que el proyecto ya tiene.** Un token existente, un paso de espaciado, una curva de movimiento, antes que cualquier valor nuevo.
+4. **Corregir el valor.** El easing, el radio, el hueco o el par de contraste equivocado, con el valor exacto que da la skill propietaria.
+5. **Anadir.** Un token nuevo, un envoltorio, una media query, un atributo ARIA que la plataforma no puede aportar.
+
+Un arreglo escrito en el paso 5 donde el paso 1 estaba disponible es un hallazgo en si mismo. Reporta el borrado en su lugar.
+
+### 8. Consolida los hallazgos sistemicos
+
+Una causa raiz es un hallazgo. Lista todas las ubicaciones confirmadas en la misma fila, en vez de una fila por aparicion. Nunca rellenes para llegar al tope; una revision corta o sin hallazgos es un resultado valido.
+
+### 9. Verifica lo verificable
+
+Ejecuta las comprobaciones seguras y relevantes que ofrezca el proyecto. Inspecciona la interfaz renderizada cuando importe el comportamiento en ejecucion o el juicio visual, y reporta el comando o la interaccion exacta y su resultado. Una comprobacion que no puedes ejecutar es **No verificado**, nunca un hallazgo.
+
+### 10. Revisa sin mutar, por defecto
+
+Trata una peticion de revision como de solo lectura. No edites codigo salvo que el usuario tambien te pida implementar los hallazgos. Cuando lo haga, conserva el informe consolidado como alcance del cambio y vuelve a ejecutar la verificacion relevante despues.
+
+## Antes de terminar
+
+| Error | Arreglo |
+| --- | --- |
+| Seis informes de dominio inconexos | Una unica tabla de hallazgos ordenada |
+| Afirmacion visual deducida solo del codigo | Inspecciona el estado renderizado, o marcalo como no verificado |
+| Huecos silenciosos de cobertura | Muestra que dominios y estados se inspeccionaron de verdad |
+| Skill propietaria ausente tratada como cubierta | Marca el dominio `No revisado` y nombra la skill |
+| Reportar todo problema heredado de un fichero tocado | Tres hallazgos preexistentes, en su propia seccion |
+| Un problema preexistente bloqueando una revision de cambio | Deja los preexistentes fuera del tope y fuera del veredicto |
+| Dominio marcado `Limpio` cuando el cambio no lo toco | Marcalo `No revisado: sin evidencia en el alcance del cambio` |
+
+## Formato de salida
+
+Abre con el alcance resuelto y una tabla de cobertura por dominio (`Revisado` / `No revisado` con el motivo). Sigue la tabla de hallazgos:
+
+| Severidad | Dominio | Ubicacion | Antes | Despues | Por que |
+| --- | --- | --- | --- | --- | --- |
+
+Cierra con la verificacion ejecutada y el veredicto: `Bloquear` si queda alguna `ALTA`, `Aprobar` en caso contrario, dejando el resto en la tabla como trabajo pendiente.

package/skills/revision-interfaz/evals/cases.yaml

@@ -0,0 +1,32 @@
+skill: revision-interfaz
+
+should_trigger:
+  - prompt: "Haz una revision completa de esta interfaz: accesibilidad, layout, color y texto."
+    why: "Disparador directo de revision-interfaz."
+  - prompt: "Necesito un veredicto unico ordenado por impacto sobre esta pantalla."
+    why: "Disparador directo de revision-interfaz."
+  - prompt: "Revisa toda la UI de esta pagina con todas las skills mejor-*."
+    why: "Disparador directo de revision-interfaz."
+  - prompt: "Run a full interface review covering accessibility, layout, copy, typography and color."
+    why: "Disparador directo de revision-interfaz."
+  - prompt: "Consolida los hallazgos de diseno de esta pantalla en un solo informe."
+    why: "Disparador directo de revision-interfaz."
+
+should_not_trigger:
+  - prompt: "Revisa solo el diff de un PR concreto."
+    route_to: "revision-de-cambios"
+    why: "Revisar el diff de un PR concreto es el trabajo de revision-de-cambios, no de revision-interfaz."
+  - prompt: "Implementa la funcionalidad de esta pantalla."
+    route_to: "implement"
+    why: "Implementar la funcionalidad es el trabajo de implement, no de revision-interfaz."
+  - prompt: "Escribe el copy de un solo boton."
+    route_to: "mejor-redaccion"
+    why: "Escribir el copy de un boton es el trabajo de mejor-redaccion, no de revision-interfaz."
+  - prompt: "Genera la paleta de colores desde cero."
+    route_to: "mejor-colores"
+    why: "Generar la paleta de colores es el trabajo de mejor-colores, no de revision-interfaz."
+
+capability:
+  - scenario: "El usuario quiere una revision de interfaz completa y consolidada."
+    must_include:
+      - "veredicto"

package/skills/roast-me/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: roast-me
+description: "Use when someone wants an honest, comedic audit of their own prompting — reads their past agent transcripts, scores prompt quality and compute efficiency, names their worst habits, builds a model-selection cheat sheet. NOT reviewing code an agent produced (that is `code-review`), NOT prompting technique in general (that is `prompt-engineering`)."
+tags: [prompting, self-audit, compute-efficiency, ai-hygiene, learning]
+recommends: [prompt-engineering, code-review, context-budget]
+profiles: [full]
+origin: risco
+---
+
+# roast-me — audit your prompting, score yourself, stop burning money
+
+You are the **prompt auditor**. Your target is not the user's code — it is their *prompting behaviour*, read from their own recent agent transcripts.
+
+Every run follows five phases. Execute them in order.
+
+## Phase 1 — Extract
+
+Parse `$ARGUMENTS` for a day count. Accept `--days N`, `days=N`, or a bare number (e.g. `3` means three days). Default: 7. Also accept `--runtime auto|claude|codex|gemini` (default `auto`).
+
+Run the extractor:
+
+```
+python3 <skill_dir>/tools/extract_prompts.py --days <N> --runtime <runtime>
+```
+
+Where `<skill_dir>` is the directory containing this SKILL.md. Use your runtime's mechanism to resolve it (environment variable, `__file__` equivalent, or the skill's known install path).
+
+Wait for completion. Read the output JSON path that the script prints. Report to the user:
+
+```
+Scanned <sessions> sessions across <projects> projects
+Extracted <N> prompts (<errors> with errors, <recovered> auto-recovered, <unrecovered> impactful)
+```
+
+If `total_prompts` is 0: tell the user "No transcript data found for that window. Try a longer window (`--days 30`) or check that your assistant's transcript directory exists." Then stop.
+
+**Key distinction**: always report `effective_error_rate` (errors NOT auto-recovered), never the raw error rate. Auto-recovered errors are the agent doing its job — not your fault.
+
+## Phase 2 — Analyze Prompt Quality
+
+Read the extracted JSON. Batch the prompts into groups of ~30. For each batch, use your runtime's subagent/Task mechanism to run a parallel analysis pass with the prompt in `prompts/analyze.md`, passing the batch as JSON.
+
+Collect results. Group flagged issues by category and severity.
+
+**Filter rule**: keep only issues where the impact was real — agent went in the wrong direction, user had to correct, dangerous action attempted, or significant wasted work (>10 tool calls). Discard issues where `error_was_recovered` is true.
+
+Report category counts as a progress update.
+
+If zero issues are flagged, proceed to Phase 3 anyway — the roast should honour good prompting.
+
+## Phase 3 — Analyze Compute Efficiency
+
+Read the same JSON. Batch into ~30-prompt groups. Spawn parallel subagent passes with `prompts/compute.md`.
+
+Aggregate across batches:
+- All `overuse_cases` (deduplicate by index)
+- All `thinking_overuse_cases`
+- All `correctly_used_heavy_model` examples
+- Summed totals: `total_overuse_count`, `total_savings_usd`, `thinking_overuse_count`
+- `worst_category` = most frequent `task_type` in overuse_cases
+
+Keep only `high` and `medium` confidence overuse cases.
+
+Report:
+
+```
+Compute analysis: <X> confirmed overuse cases | $Y.YY potential savings | Z reasoning overuse
+```
+
+## Phase 4 — Generate Roast
+
+Spawn a single subagent with `prompts/roast.md`. Pass it:
+- Aggregated issue counts by category and severity
+- Top ~15 worst prompt examples (highest severity + real impact)
+- Stats metadata (especially `effective_error_rate`)
+- A sample of ~10 issue-free prompts for the "What You Do Well" section
+- `compute_stats` from the extraction metadata
+- Aggregated compute analysis (overuse cases, thinking overuse, correctly-used examples, totals)
+
+Collect the roast report. Extract the dual score (Prompt Quality 0–100, Compute Efficiency 0–100) and the grade letters.
+
+## Phase 5 — Score, Track, Present
+
+Save results to `~/.roast-me-history.json`. Read existing history (if any), append a new entry:
+
+```json
+{
+  "date": "YYYY-MM-DD",
+  "runtime": "auto",
+  "days_analyzed": 7,
+  "prompt_quality_score": 73,
+  "prompt_quality_grade": "C",
+  "compute_efficiency_score": 35,
+  "compute_efficiency_grade": "F",
+  "total_prompts": 200,
+  "issues_flagged": 30,
+  "effective_error_rate": 0.08,
+  "correction_rate": 0.06,
+  "focus_of_week": "The 3W Rule",
+  "compute_total_cost_usd": 22.50,
+  "compute_wasted_cost_usd": 8.10,
+  "compute_overuse_count": 30,
+  "model_distribution": {"heavy": 0.4, "balanced": 0.4, "light": 0.2}
+}
+```
+
+Write the updated history back to `~/.roast-me-history.json`.
+
+If previous entries exist, append a trend line after the main report:
+
+```
+Score History:
+  Date        Prompt Quality    Compute Efficiency    Focus
+  2026-06-01  68/100 (D+)       --/-- (new)           Context anchoring
+  2026-06-08  73/100 (C) +5↑   35/100 (F)            The 3W Rule
+```
+
+Output the roast report as formatted markdown.
+
+## Orientación (siempre)
+
+Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ✅ qué hiciste · 🧭 por qué · ➡️ siguiente, terminando en pregunta), calibrado al dial de `docs/wiki/harness/user-profile.md`. **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el "¿instalo la skill que falta?".)