메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.
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.
Reconcilia el glosario CONTEXT con el resto del spec. Úsala cuando un término aparezca con dos significados, o periódicamente para detectar términos del SPEC que no estén canonizados en CONTEXT.
| name | sf-drift |
| description | 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. |
"El spec es un contrato vivo: cuando el producto cambie, actualiza el spec primero" es fácil de decir y caro de hacer si implica re-mapear todo. Esta skill lo hace barato: diff dirigido desde la última emisión.
Existe una emisión previa registrada en el journal (línea EMIT, con fecha y rutas). Si no la hay, esto es un re-spec-parcial normal → usa sf-map.
journal.md la última línea EMIT (o la última pasada de sf-drift, línea NOTA drift). Si el repo tiene git, identifica el commit más cercano a esa fecha (git log --until=<fecha>).git diff --stat <ancla>..HEAD → lista de archivos tocados. Sin git: compara fechas de modificación contra el ancla.SYSTEM-MAP.md (cada afirmación cita archivo:línea). Un archivo tocado invalida potencialmente las afirmaciones que lo citan → esas secciones son sospechosas. Archivos nuevos sin afirmación asociada → posible funcionalidad no especificada (Sección 3).sf-map fase 1) SOLO sobre los archivos tocados de las secciones sospechosas. Compara sus afirmaciones nuevas contra el spec emitido.S{n}.Qa{m}).NOTA drift en el journal con el nuevo ancla.