メニュー
Verificación adversarial. Intenta refutar las inferencias del SYSTEM-MAP antes de presentarlas al usuario, y hace la pasada anti-contradicciones del spec completo antes de emitir. Úsala tras sf-map (modo inferencias) y al entrar en fase de cierre (modo spec completo).
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | sf-verify |
| description | Verificación adversarial. Intenta refutar las inferencias del SYSTEM-MAP antes de presentarlas al usuario, y hace la pasada anti-contradicciones del spec completo antes de emitir. Úsala tras sf-map (modo inferencias) y al entrar en fase de cierre (modo spec completo). |
Ejecuta el sub-agente Verificador (../../agents/verifier.md). Su postura es adversarial: busca el contraejemplo, no la confirmación. Una inferencia errónea que el usuario confirme por descuido queda cementada en el spec y envenena todo lo que se genere después.
[inferido] del SYSTEM-MAP.md.archivo:línea y la afirmación corregida) · indecidible ⚠️ (→ pregunta de entrevista).SYSTEM-MAP.md con los veredictos y registra el resultado en el journal.Con SPEC.draft.md + CONTEXT.draft.md + adr/ completos, busca en este orden:
Salida: hallazgos con severidad (bloquea-emisión | advertencia) y corrección propuesta. Los bloqueantes se resuelven con el usuario ANTES de sf-emit. Registra la pasada en el journal.
Intake de material aportado en proyectos nuevos (modo nuevo-con-material). Recibe el contexto del usuario (docs de APIs, flujos, lógica, resultado esperado), lo normaliza en un SYSTEM-MAP.md con referencias al material, deriva la Visión y siembra la sesión para que la entrevista solo cubra los huecos. Úsala cuando el usuario ya tiene información escrita de lo que quiere construir.
Persiste el estado de la sesión SpecFounder tras cada respuesta. Úsala SIEMPRE antes de formular la siguiente pregunta, para que la sesión sobreviva a caídas. Append al journal + reescritura del session.md mínimo.
Selecciona el dominio/propósito del spec al inicio (software o creativo) y carga el perfil que renombra las 6 secciones. Úsala como primer paso, antes de elegir metodología y modo.
Detecta drift entre el spec emitido y el código actual. Usa git diff desde la última emisión para re-explorar solo lo tocado y propone actualizaciones puntuales al spec. Úsala periódicamente o antes de una nueva feature, para que el spec siga siendo un contrato vivo.
Emite los artefactos finales del spec en la metodología elegida (OpenSpec, GitHub Spec-Kit, SDD genérico o Biblia creativa) con el formato literal del destino, los valida y genera el handoff. Úsala al cierre, tras la pasada de sf-verify.
Alias de compatibilidad: la exploración de proyectos existentes ahora la orquesta sf-map (inventario + exploradores paralelos + SYSTEM-MAP con evidencia). Úsala igual que antes en modo proyecto-existente; delega en sf-map.