refacil-sdd-ai 4.2.4 → 4.4.0

package/skills/verify/SKILL.md

@@ -1,132 +1,159 @@
----
-name: refacil:verify
-description: Validar que la implementacion cumple con las specs — construye un briefing con testCommand y criterios CA/CR, delega al sub-agente refacil-validator para el reporte y maneja correcciones con aprobacion del usuario
-user-invocable: true
----
-
-# refacil:verify — Entrypoint de Verificacion
-
-Este skill es un **wrapper** que construye un **briefing estructurado** con el comando de test y los criterios ya extraidos, delega el analisis al sub-agente `refacil-validator`, y maneja la interaccion con el usuario para aplicar correcciones.
-
-**Prerequisitos**: perfil `openspec` de `refacil-prereqs/SKILL.md` + reglas de `METHODOLOGY-CONTRACT.md`.
-
-## Flujo
-
-### Paso 0: Resolver scope
-
-Determina el scope antes de invocar al sub-agente. Prioriza este orden:
-1. Argumento del usuario (`$ARGUMENTS`).
-2. Cambio activo en `openspec/changes/`.
-3. Si hay multiples cambios activos y no hay `$ARGUMENTS`, **detente** y pide al usuario seleccionar explicitamente cual cambio validar.
-
-No invoques al sub-agente con scope ambiguo.
-
-### Paso 0.5: Archivos ocultos bajo `openspec/changes/` (evitar falsos negativos)
-
-Si **esta sesion** inspecciona el directorio del cambio antes o despues de delegar, aplica **`refacil-prereqs/METHODOLOGY-CONTRACT.md` §8**.
-
-### Paso 0.6: Construir briefing para el sub-agente (reduce tool calls del validator)
-
-Antes de invocar al sub-agente, extrae el contexto que de otro modo el validator calcularía por su cuenta:
-
-1. **Comando de test** — lee `refacil-prereqs/METHODOLOGY-CONTRACT.md` §3. Extrae el comando exacto.
-
-2. **Criterios CA/CR** — si hay cambio activo, lee la especificacion en `openspec/changes/<changeName>/`:
-   - `specs.md` si existe, y/o archivos bajo `specs/` (recursivo).
-   - Extrae la lista de CA-XX (criterios de aceptacion) y CR-XX (criterios de rechazo) con su descripcion.
-   - Si no hay specs o el scope es `git-diff`, omite este campo.
-
-3. **Archivos del scope** — ejecuta `git diff --name-only HEAD` para obtener los archivos modificados en este cambio.
-
-Construye el bloque BRIEFING:
-
-```
-BRIEFING:
-changeName: <nombre o null si scope=git-diff>
-testCommand: <comando exacto>
-criteria:
-  acceptance:
-    - CA-01: <descripcion>
-    - CA-02: <descripcion>
-  rejection:
-    - CR-01: <descripcion>
-changedFiles: [ruta/archivo-1.ts, ...]
-mode: conciso | detailed
-```
-
-### Paso 1: Delegar al sub-agente refacil-validator
-
-Invoca a `refacil-validator` pasandole el BRIEFING del paso anterior.
-
-El sub-agente:
-- Usa `testCommand` del briefing directamente (sin buscarlo en METHODOLOGY-CONTRACT.md).
-- Usa `criteria` del briefing para la verificacion (sin re-leer specs desde cero).
-- Usa `changedFiles` para enfocar el scope de verificacion OpenSpec.
-- Delega a OpenSpec verify para issues contra la spec.
-- Corre los tests y verifica coverage.
-- Opcionalmente consulta el bus cross-repo ante ambigüedades.
-- Retorna reporte combinado + bloque JSON fenced como ` ```refacil-verify-result `.
-
-### Paso 2: Presentar el reporte
-
-Muestra el **reporte combinado** (todo lo anterior al bloque `refacil-verify-result`) al usuario. No muestres el bloque JSON — es metadata interna.
-
-**Si el sub-agente retorno un error de scope** (sin bloque JSON): propaga al usuario y pide clarificacion.
-
-### Paso 3: Procesar el resultado
-
-Parsea el bloque ` ```refacil-verify-result ` del sub-agente.
-
-#### Si `result` es APROBADO:
-
-```
-RESULTADO: APROBADO
-
-El siguiente paso es el review de calidad con checklist del equipo.
-Quieres que continue con `/refacil:review`?
-```
-
-#### Si `result` es REQUIERE CORRECCIONES:
-
-Presenta los issues y pregunta:
-
-```
-RESULTADO: REQUIERE CORRECCIONES
-
-Correcciones necesarias:
-1. [CRITICAL/WARNING] [descripcion] — [fix sugerido]
-2. ...
-
-Quieres que aplique estas correcciones? (si/no)
-- Si: aplicare los fixes y re-verificare automaticamente
-- No: puedes corregirlos manualmente y luego continuo con /refacil:verify
-```
-
-### Paso 4: Aplicar correcciones (si el usuario acepta)
-
-**Solo aplica fixes despues de aprobacion explicita del usuario.**
-
-1. Aplica SOLO las correcciones listadas — no agregar funcionalidad nueva, no refactorizar codigo no relacionado.
-2. Si hay tests que necesitan ajuste, ajustarlos tambien.
-3. Muestra resumen de archivos modificados.
-4. **Re-ejecuta automaticamente desde el Paso 1** (re-invoca al sub-agente con el mismo briefing) para confirmar que las correcciones resolvieron los issues.
-5. Maximo **2 rondas** de correccion automatica. Si persisten issues, listarlos para correccion manual.
-
-**Si el usuario no acepta:** lista los issues para correccion manual. Sugiere `/refacil:verify` de nuevo.
-
-## Reglas
-
-- **Siempre construye el briefing (Paso 0.6) antes de delegar** — reduce los tool calls del sub-agente.
-- **Siempre delega al sub-agente** para el analisis. No repliques aqui la logica de lectura de specs ni de ejecucion de tests.
-- **Dotfiles en `openspec/changes/`**: nunca afirmes ausencia de `.review-passed` sin `-a`; ver §8.
-- **Las correcciones SOLO las aplica este wrapper** (Paso 4), despues de aprobacion explicita.
-- **No muestres el bloque JSON al usuario**.
-- **Las correcciones deben ser quirurgicas**: solo lo necesario para resolver los issues reportados.
-- Maximo 2 rondas de correccion automatica antes de escalar a manual.
-- Si el sub-agente retorno algo fuera de formato, informa: "El validator retorno un reporte no estructurado — continua manualmente."
-- **Continuidad del flujo**: si el resultado es APROBADO y el usuario confirma afirmativamente, invocar inmediatamente el **Skill tool** con `skill: "refacil:review"`. (Ver `METHODOLOGY-CONTRACT.md §5`.)
-
-## Ver tambien
-
-- Sub-agente: `.claude/agents/refacil-validator.md` (fuente: `refacil-sdd-ai/agents/validator.md`)
-- Bus cross-repo: `refacil-prereqs/BUS-CROSS-REPO.md`
+---
+name: refacil:verify
+description: Validate that the implementation meets the specs — builds a briefing with testCommand and CA/CR criteria, delegates to the refacil-validator sub-agent for the report, and handles corrections with user approval
+user-invocable: true
+---
+
+# refacil:verify — Verification Entrypoint
+
+This skill is a **wrapper** that builds a **structured briefing** with the test command and criteria already extracted, delegates the analysis to the `refacil-validator` sub-agent, and handles the interaction with the user to apply corrections.
+
+**Prerequisites**: `sdd` profile from `refacil-prereqs/SKILL.md` + rules from `METHODOLOGY-CONTRACT.md`.
+
+## Flow
+
+### Step 0: Resolve scope
+
+Determine the scope before invoking the sub-agent. Prioritize in this order:
+1. User argument (`$ARGUMENTS`).
+2. Active change in `refacil-sdd/changes/`.
+3. If there are multiple active changes and no `$ARGUMENTS`, **stop** and ask the user to explicitly select which change to validate.
+
+Do not invoke the sub-agent with ambiguous scope.
+
+If you already have a `changeName`, run `refacil-sdd-ai sdd status <changeName> --json` to verify that the artifacts exist (`artifacts.proposal`, `artifacts.tasks`, `artifacts.specs` = true). If critical artifacts are missing, inform the user before continuing.
+
+### Step 0.5: Hidden files under `refacil-sdd/changes/` (avoid false negatives)
+
+If **this session** inspects the change directory before or after delegating, apply **`refacil-prereqs/METHODOLOGY-CONTRACT.md` §8**.
+
+### Step 0.6: Verify validator agent is installed (blocking — CA-12)
+
+Before doing anything else, check that `.claude/agents/refacil-validator.md` exists (read by explicit path or `ls -la .claude/agents/refacil-validator.md`).
+
+**If the file does NOT exist**, stop immediately:
+```
+El agente `refacil-validator` no está instalado. Ejecuta `/refacil:update` y reinicia la sesión antes de volver a correr `/refacil:verify`.
+```
+Do not continue and do not escalate to any other agent.
+
+### Step 1: Build briefing for the sub-agent (reduces validator tool calls)
+
+Before invoking the sub-agent, extract the context that the validator would otherwise calculate on its own:
+
+1. **Test command** — read `refacil-prereqs/METHODOLOGY-CONTRACT.md` §3. Extract the exact command.
+
+2. **CA/CR criteria** — if there is an active change, read the specification in `refacil-sdd/changes/<changeName>/`:
+   - `specs.md` if it exists, and/or files under `specs/` (recursively).
+   - Extract the list of CA-XX (acceptance criteria) and CR-XX (rejection criteria) with their descriptions.
+   - If there are no specs or the scope is `git-diff`, omit this field.
+
+3. **Scope files** — run `git diff --name-only HEAD` to get the files modified in this change.
+
+4. **Cross-skill memory** — if `changeName` is not null and `refacil-sdd/changes/<changeName>/memory.yaml` exists, read it and extract:
+   - `commandsRun` — the test command(s) already executed by the tester. Include in the briefing so the validator uses the same command without re-discovering it.
+   - `criteriaRun` — the CA-XX/CR-XX already tested. Include in the briefing so the validator can skip re-reading specs for those criteria.
+   If the file does not exist, omit these fields — do not block (CR-04).
+
+Build the BRIEFING block:
+
+```
+BRIEFING:
+changeName: <name or null if scope=git-diff>
+testCommand: <exact command>
+criteria:
+  acceptance:
+    - CA-01: <description>
+    - CA-02: <description>
+  rejection:
+    - CR-01: <description>
+changedFiles: [path/file-1.ts, ...]
+mode: concise | detailed
+commandsRun: [<command>, ...]          # from memory.yaml — omit if not present
+criteriaRun: [CA-01, CR-01, ...]       # from memory.yaml — omit if not present
+```
+
+### Step 2: Delegate to the refacil-validator sub-agent
+
+Invoke `refacil-validator` passing it the BRIEFING from the previous step.
+
+The sub-agent:
+- Uses `testCommand` from the briefing directly (without looking it up in METHODOLOGY-CONTRACT.md).
+- Uses `criteria` from the briefing for verification (without re-reading specs from scratch).
+- Uses `changedFiles` to focus the 3D verification on those files.
+- Applies the 3D framework (Completeness/Correctness/Coherence) directly.
+- Runs the tests and verifies coverage.
+- Optionally consults the bus cross-repo for ambiguities.
+- Returns combined report + JSON block fenced as ` ```refacil-verify-result `.
+
+### Step 3: Present the report
+
+Show the user the **combined report** (everything before the `refacil-verify-result` block). Do not show the JSON block — it is internal metadata.
+
+**If the sub-agent failed to load** (tool error, agent type not found, or no response at all): stop immediately and do NOT escalate to any other agent:
+```
+The validator sub-agent could not be loaded — retry or run `/refacil:verify` again.
+```
+
+**If the sub-agent responded but without a `refacil-verify-result` block** (unstructured output): show the raw report and stop:
+```
+The validator returned an unstructured report — continue manually.
+```
+Do not re-invoke a different agent.
+
+**If the sub-agent returned a scope error** (`SCOPE_ERROR: <reason>`, without JSON block): propagate to the user and ask for clarification. This is NOT the CA-01 failsafe — the agent loaded correctly but found an ambiguous scope.
+
+### Step 4: Process the result
+
+Parse the ` ```refacil-verify-result ` block from the sub-agent.
+
+#### If `result` is APPROVED:
+
+```
+RESULT: APPROVED
+
+The next step is the quality review with the team checklist.
+Do you want me to continue with `/refacil:review`?
+```
+
+#### If `result` is REQUIRES_CORRECTIONS:
+
+Present the issues and ask:
+
+```
+RESULT: REQUIRES_CORRECTIONS
+
+Required corrections:
+1. [CRITICAL/WARNING] [description] — [suggested fix]
+2. ...
+
+Do you want me to apply these corrections? (yes/no)
+- Yes: I will apply the fixes and automatically re-verify
+- No: you can fix them manually and then continue with /refacil:verify
+```
+
+### Step 5: Apply corrections (if the user accepts)
+
+**Only apply fixes after explicit user approval.**
+
+1. Apply ONLY the listed corrections — do not add new functionality, do not refactor unrelated code.
+2. If there are tests that need adjustment, adjust them as well.
+3. Show summary of modified files.
+4. **Automatically re-run from Step 2** (re-invoke the sub-agent with the same briefing) to confirm the corrections resolved the issues.
+5. Maximum **2 rounds** of automatic correction. If issues persist, list them for manual correction.
+
+**If the user does not accept:** list the issues for manual correction. Suggest `/refacil:verify` again.
+
+## Rules
+
+- **Always build the briefing (Step 1) before delegating** — reduces the sub-agent tool calls.
+- **Always delegate to the sub-agent** for the analysis. Do not replicate spec reading or test execution logic here.
+- **Dotfiles in `refacil-sdd/changes/`**: never assert absence of `.review-passed` without `-a`; see §8.
+- **Corrections are ONLY applied by this wrapper** (Step 5), after explicit approval.
+- **Corrections must be surgical**: only what is necessary to resolve the reported issues.
+- Maximum 2 rounds of automatic correction before escalating to manual.
+- **Sub-agent failsafe (CA-01)**: if the validator fails to load (tool error) or returns no response — stop and inform the user. Do NOT escalate to any other agent.
+- **Unstructured output (CA-02)**: if the validator responds but without a `refacil-verify-result` block — show the raw report and stop. Do NOT re-invoke another agent.
+- **SCOPE_ERROR (CR-03)**: if the validator returns `SCOPE_ERROR: <reason>` — propagate and ask for clarification. CA-01 does NOT apply here.
+- **Agent missing (CA-12)**: checked in Step 0.6 — stop before delegating if `.claude/agents/refacil-validator.md` is absent.
+- **Flow continuity**: if the result is APPROVED and the user confirms affirmatively, immediately invoke the **Skill tool** with `skill: "refacil:review"`. (See `METHODOLOGY-CONTRACT.md §5`.)

package/templates/compact-guidance.md

@@ -1,45 +1,45 @@
-<!-- AUTO-GENERADO por refacil-sdd-ai. No edites entre los marcadores; el contenido se refresca en cada sesion. -->
-
-## Eficiencia de tokens
-
-Reglas para minimizar el consumo de contexto al trabajar en este repositorio.
-
-**Lectura de archivos**
-- Usa `Read` con `offset` y `limit` cuando conozcas la zona relevante del archivo.
-- No leas archivos de mas de 500 lineas completos; segmenta por rango.
-- Para descubrir estructura del repo: usa `Glob` en lugar de `ls -R` o `find`.
-- No releas el archivo completo si ya leiste el bloque relevante; continua desde ese contexto.
-- Antes de leer un archivo largo, ubica simbolos con busqueda y luego lee solo rangos candidatos.
-
-**Busqueda**
-- Usa `Grep` con `head_limit` en vez de dump crudo.
-- Cuando solo necesites ubicaciones, usa `output_mode: "files_with_matches"`.
-- Acota siempre con `glob` o `type` para no escanear de mas.
-
-**Git (via Bash)**
-- Historial: `git log --oneline -20` por defecto; amplia solo si es insuficiente.
-- Diffs: empieza con `git diff --stat`; pide el diff completo solo del archivo que vas a tocar.
-- Status: `git status -s` (short format).
-- Show: `git show --stat` antes del full.
-
-**Tests**
-- Reporta solo failures; no enumeres los passes en el output visible.
-- Si el runner tiene modo silencioso o summary (`jest --silent --reporters=summary`, `pytest -q`), usalo.
-- Si el runner es verboso por defecto, redirige: `2>&1 | tail -80`.
-
-**Logs y errores**
-- No pegues stack traces enteros; extrae solo el frame relevante con el mensaje.
-- Resume logs repetidos: "(N ocurrencias de <mensaje>)".
-- Para archivos de log: `tail -100` o filtra por nivel ERROR/WARN.
-
-**Build y lint**
-- `tsc`, `eslint`, `biome`: agrupa errores por archivo o por regla; no enumeres linea por linea.
-- Construccion exitosa: confirma con una sola linea, no pegues el output completo.
-- Si hay muchos errores similares: muestra un ejemplo y el conteo.
-
-**Docker y contenedores**
-- `docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Image}}"`.
-- `docker logs --tail 100` siempre; nunca logs completos.
-
-**Regla general**
-Cuando dudes entre verbosidad y concision, elige concision. El usuario puede pedir detalle bajo demanda.
+<!-- AUTO-GENERATED by refacil-sdd-ai. Do not edit between markers; content is refreshed every session. -->
+
+## Token efficiency
+
+Rules to minimize context consumption when working in this repository.
+
+**File reading**
+- Use `Read` with `offset` and `limit` when you know the relevant area of the file.
+- Do not read files longer than 500 lines in full; segment by range.
+- To discover repo structure: use `Glob` instead of `ls -R` or `find`.
+- Do not re-read the entire file if you already read the relevant block; continue from that context.
+- Before reading a long file, locate symbols with search and then read only candidate ranges.
+
+**Search**
+- Use `Grep` with `head_limit` instead of raw dumps.
+- When you only need locations, use `output_mode: "files_with_matches"`.
+- Always narrow with `glob` or `type` to avoid over-scanning.
+
+**Git (via Bash)**
+- History: `git log --oneline -20` by default; expand only if insufficient.
+- Diffs: start with `git diff --stat`; request the full diff only for the file you are about to touch.
+- Status: `git status -s` (short format).
+- Show: `git show --stat` before the full show.
+
+**Tests**
+- Report only failures; do not enumerate passes in visible output.
+- If the runner has a silent or summary mode (`jest --silent --reporters=summary`, `pytest -q`), use it.
+- If the runner is verbose by default, redirect: `2>&1 | tail -80`.
+
+**Logs and errors**
+- Do not paste full stack traces; extract only the relevant frame with the message.
+- Summarize repeated logs: "(N occurrences of <message>)".
+- For log files: `tail -100` or filter by ERROR/WARN level.
+
+**Build and lint**
+- `tsc`, `eslint`, `biome`: group errors by file or by rule; do not enumerate line by line.
+- Successful build: confirm with a single line, do not paste the full output.
+- If there are many similar errors: show one example and the count.
+
+**Docker and containers**
+- `docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Image}}"`.
+- `docker logs --tail 100` always; never full logs.
+
+**General rule**
+When in doubt between verbosity and conciseness, choose conciseness. The user can request detail on demand.

package/templates/methodology-guide.md

@@ -1,54 +1,58 @@
-Instrucciones completas del proyecto: ver `AGENTS.md`. Si falta, ejecuta `/refacil:setup`.
+Full project instructions: see `AGENTS.md`. If missing, run `/refacil:setup`.
 
-## Metodologia SDD-AI (Refacil)
+## SDD-AI Methodology
 
-Skills identicas en `.claude/skills/refacil-*/` (Claude Code) y `.cursor/skills/refacil-*/` (Cursor). Instaladas por `refacil-sdd-ai init`.
+Skills are identical in `.claude/skills/refacil-*/` (Claude Code) and `.cursor/skills/refacil-*/` (Cursor). Installed by `refacil-sdd-ai init`.
 
-| Comando | Descripcion |
+| Command | Description |
 |---------|-------------|
-| `/refacil:setup` | Instalar OpenSpec y generar AGENTS.md |
-| `/refacil:guide` | Guia interactiva — que comando usar |
-| `/refacil:explore` | Explorar el codebase sin cambios |
-| `/refacil:propose` | Crear propuesta de cambio |
-| `/refacil:apply` | Implementar tasks del cambio |
-| `/refacil:test` | Generar tests unitarios |
-| `/refacil:verify` | Validar implementacion vs specs |
-| `/refacil:review` | Review con checklist de calidad |
-| `/refacil:archive` | Archivar cambio completado |
-| `/refacil:up-code` | Subir codigo y crear PR |
-| `/refacil:bug` | Flujo guiado de bugfix |
-| `/refacil:update` | Migrar documentacion al patron actual (.agents/) |
-
-Flujo: `setup` → `propose` → `apply` → `test` → `verify` → `review` → `archive` → `up-code`
-
-## Bus entre agentes (refacil-bus)
-
-Canal local de texto plano entre sesiones de Claude Code / Cursor corriendo en distintos repos. Evita que el dev haga de transcriptor manual entre sus propios agentes.
-
-| Comando | Descripcion |
+| `/refacil:setup` | Generate `AGENTS.md`, `.agents/`, `refacil-sdd/changes/`, and IDE index files for the project |
+| `/refacil:guide` | Interactive guide — which command to use |
+| `/refacil:explore` | Explore the codebase without changes |
+| `/refacil:propose` | Create a change proposal |
+| `/refacil:apply` | Implement change tasks |
+| `/refacil:test` | Generate unit tests |
+| `/refacil:verify` | Validate implementation vs specs |
+| `/refacil:review` | Quality checklist review |
+| `/refacil:archive` | Archive a completed change |
+| `/refacil:up-code` | Push code and create PR |
+| `/refacil:bug` | Guided bugfix flow |
+| `/refacil:update` | Apply pending **methodology** migrations (same engine as `notify-update`; e.g. `AGENTS.md` → `.agents/` index pattern) |
+
+**Typical feature flow:** `setup` → `explore` (optional) → `propose` → `apply` → `test` → `verify` → `review` → `archive` → `up-code`.
+
+**Bug flow:** `bug` replaces `propose`/`apply` for the fix path; then `test` / `review` / `archive` / `up-code` as appropriate (see skill `refacil:bug`).
+
+**Legacy layout:** if the repo still has **`openspec/changes/`**, run any **`refacil-sdd-ai sdd …`** command or open a session ( **`check-update`** ) to migrate into **`refacil-sdd/`**; then remove **`openspec/`** when no longer referenced. Optional OpenSpec CLI (**`opsx:*`**) may coexist; SDD-AI uses **`refacil-sdd/`** and **`/refacil:*`** as the primary interface.
+
+## Inter-agent bus (refacil-bus)
+
+Local plain-text channel between Claude Code / Cursor sessions running in different repos. Prevents the developer from manually transcribing context between their own agents.
+
+| Command | Description |
 |---------|-------------|
-| `/refacil:join <sala>` | Crear o unirse a una sala. La primera vez genera un bloque de presentacion en `AGENTS.md`. |
-| `/refacil:say "..."` | Anuncio a toda la sala. |
-| `/refacil:ask @nombre "..." [--wait N]` | Pregunta dirigida; `@all` (o `*`) pregunta a todos en la sala. `--wait N` bloquea hasta la primera respuesta o N seg. |
-| `/refacil:reply "..."` | Responde la ultima pregunta dirigida (autocompleta `correlationId`). |
-| `/refacil:attend` | Modo escucha activa: recibe preguntas y el LLM las responde, luego re-invoca para seguir escuchando. |
-| `/refacil:inbox` | Ver mensajes nuevos desde la ultima lectura. |
+| `/refacil:join <room>` | Create or join a room. First time generates an introduction block in `AGENTS.md`. |
+| `/refacil:say "..."` | Broadcast to the entire room. |
+| `/refacil:ask @name "..." [--wait N]` | Directed question; `@all` (or `*`) asks everyone in the room. `--wait N` blocks until the first response or N sec. |
+| `/refacil:reply "..."` | Reply to the last directed question (auto-fills `correlationId`). |
+| `/refacil:attend` | Active listen mode: receives questions and the LLM answers them, then re-invokes to keep listening. |
+| `/refacil:inbox` | View new messages since the last read. |
 
-Uso tipico: antes de arrancar una tarea que puede requerir contexto de otros repos, el dev pone al agente de cada otro repo en `/refacil:attend`. Despues, en su repo de trabajo, el LLM puede pedir contexto con `/refacil:ask @<repo> "..." --wait` y recibir la respuesta automaticamente sin que el dev salte entre ventanas.
+Typical usage: before starting a task that may require context from other repos, the developer puts the agent in each other repo into `/refacil:attend`. Then, in their working repo, the LLM can request context with `/refacil:ask @<repo> "..." --wait` and receive the response automatically without the developer switching between windows.
 
-Si en la sala se acuerdan cambios que afectan un repo, en ese repo se sigue el flujo SDD-AI (`/refacil:propose`, etc.) y quien implementa **avisa por el bus** al que pidio el cambio al terminar (detalle en `refacil-prereqs/BUS-CROSS-REPO.md` en el paquete). Los **`ask` que piden trabajo** en otro repo deben ir con **alcance claro**; el destino usa **`/refacil:propose`** por convención (no hace falta pegar la guía en el mensaje). Skill `/refacil:ask`.
+If changes affecting a repo are agreed upon in the room, the SDD-AI flow (`/refacil:propose`, etc.) is followed in that repo and the implementer **notifies via the bus** when done (details in `refacil-prereqs/BUS-CROSS-REPO.md` in the package). **`ask` requests that involve work** in another repo must include **clear scope**; the destination uses **`/refacil:propose`** by convention. See skill `/refacil:ask`.
 
-CLI util para el dev: `refacil-sdd-ai bus view` (abre UI web en el navegador), `bus watch <session>` (panel en terminal), `bus status`, `bus rooms`. No consumen tokens.
+Useful CLI for the developer: `refacil-sdd-ai bus view` (opens web UI in browser), `bus watch <session>` (terminal panel), `bus status`, `bus rooms`. These do not consume tokens.
 
-## Estructura de documentacion del proyecto
+## Project documentation structure
 
-El detalle del proyecto vive en `.agents/` — un archivo `.md` por area (summary, architecture, stack, testing, commands...).
-`AGENTS.md` es el indice: una linea por archivo indicando que contiene y cuando leerlo.
-`CLAUDE.md` y `.cursorrules` son indices minimos que solo apuntan a `AGENTS.md` — no contienen detalle de proyecto.
+Project detail lives in `.agents/` — one `.md` file per area (summary, architecture, stack, testing, commands...).
+`AGENTS.md` is the index: one line per file indicating what it contains and when to read it.
+`CLAUDE.md` and `.cursorrules` are minimal indices that only point to `AGENTS.md` — they contain no project detail.
 
-## Eficiencia de tokens (automatica)
+## Token efficiency (automatic)
 
-- El hook `check-update` en `SessionStart` sincroniza el bloque `compact-guidance` en `AGENTS.md`.
-- El bloque define reglas de salida compacta (lectura por rango, busqueda acotada, tests/logs resumidos).
-- Si `AGENTS.md` aun no existe, la sincronizacion se omite sin error.
-- No editar manualmente el contenido entre marcadores `compact-guidance`; se sobreescribe automaticamente.
+- The `check-update` hook at `SessionStart` syncs the `compact-guidance` block in `AGENTS.md`.
+- The block defines compact output rules (range reads, bounded searches, summarized test/log output).
+- If `AGENTS.md` does not exist yet, the sync is skipped without error.
+- Do not manually edit content between the `compact-guidance` markers; it is overwritten automatically.

package/config/openspec-config.yaml

@@ -1,8 +0,0 @@
-# OpenSpec Configuration Template — Equipo Refacil
-# Copiar a openspec/config.yaml despues de ejecutar openspec init
-
-# Idioma: español para artefactos, terminos tecnicos en ingles
-language: spanish
-
-# Las skills refacil:* usan la estructura de OpenSpec por debajo
-# No es necesario modificar el schema default (spec-driven)

package/skills/prereqs/OPENSPEC-DELTAS.md

@@ -1,51 +0,0 @@
-# Deltas Refacil sobre OpenSpec
-
-Lee este archivo **ademas** de la skill `openspec-*` que indique el comando `refacil:*`. No sustituye a OpenSpec; solo fija convenciones del equipo.
-
-**Ubicacion en el repo:** mismo directorio que `SKILL.md` de `refacil-prereqs` (`.claude/skills/refacil-prereqs/` o `.cursor/skills/refacil-prereqs/`).
-
-## Idioma (todas las delegaciones)
-
-- Respuestas al usuario y artefactos bajo `openspec/`: **español**; terminos tecnicos (API, REST, nombres de tipos, etc.) en **ingles**.
-
-## propose — `openspec-propose`
-
-- **Nombre de carpeta del cambio** (`openspec/changes/<nombre>/`): cumplir **`METHODOLOGY-CONTRACT.md` §9** — el primer caracter **debe** ser letra ASCII; **prohibido** crear el cambio con nombre que empiece por digito (incluye prefijos tipo `YYYY-MM-DD-...`). El CLI OpenSpec falla con esos nombres (`openspec status --change`, etc.). Fijar o validar el slug **antes** de generar artefactos.
-- Criterios de aceptacion: formato **Dado / Cuando / Entonces**.
-- Incluir **criterios de rechazo** (edge cases) en specs.
-- Tasks con estimacion de esfuerzo **S / M / L**.
-- Design alineado a **patrones existentes** del repo (desde `AGENTS.md` o exploracion acotada).
-
-### Specs: archivo unico vs arbol `specs/` (compatibilidad Refacil)
-
-OpenSpec puede indicar `specs/**/*.md` y crear **un archivo por capability** (ej. `specs/product-amount-percentile/spec.md`). Los comandos **refacil:*** deben soportar **ambas** formas:
-
-| Forma | Validacion |
-|-------|------------|
-| **A** | `specs.md` en la raiz del cambio (`openspec/changes/<id>/specs.md`) |
-| **B** | Sin `specs.md`, pero existe al menos un `.md` bajo `openspec/changes/<id>/specs/` (recursivo) |
-
-- **Si OpenSpec solo genera B:** no es error. **No hace falta** duplicar obligatoriamente en `specs.md` salvo que el equipo quiera un indice unico para humanos.
-- **Si coexisten A y B:** lee **ambos**; si hay contradiccion clara entre `specs.md` y los fragmentos, **pregunta al usuario** cual manda antes de `apply`.
-- Al cerrar **propose**, en el resumen de revision lista **todas** las rutas de spec (archivo raiz y/o cada `specs/**.md`).
-
-## apply — `openspec-apply-change`
-
-- Respetar **estrictamente** `AGENTS.md`.
-- No agregar funcionalidad fuera del alcance de las specs aprobadas.
-- No refactorizar codigo no relacionado con el cambio.
-- Si una task es ambigua, **preguntar** antes de implementar.
-- **Especificacion**: aplica la tabla del Paso 0 de `refacil:apply` (`specs.md` y/o `specs/**/*.md`); no asumas que solo existe `specs.md` en la raiz.
-
-## archive — `openspec-archive-change`
-
-- Si OpenSpec pregunta si sincronizar specs delta a `openspec/specs/`: responder **SI**. La sincronizacion es **obligatoria** en esta metodologia.
-
-## explore — `openspec-explore`
-
-- Solo lectura; no modificar archivos ni generar codigo.
-- Enriquecer el informe con puntos de `AGENTS.md` relevantes al tema explorado (ya indicado en la skill `refacil:explore`).
-
-## verify — `openspec-verify-change`
-
-- Sin reglas extra sobre OpenSpec: aplica solo el bloque **Idioma** de arriba a informes y mensajes al usuario.