菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | sf-checkpoint |
| description | 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. |
Ejecuta el protocolo de checkpoint definido en ../../persistence/STATE-SCHEMA.md. Invócala tras CADA respuesta del usuario y ANTES de formular la siguiente pregunta.
Por qué así (ver ../../RENDIMIENTO.md): el checkpoint es la operación más repetida de la sesión (~1 por turno × decenas de turnos). El diseño lo hace barato estructuralmente: añadir una línea al final de
journal.mdes una operación fiable y mínima, ysession.mdes tan pequeño (~25-35 líneas) que reescribirlo entero cuesta menos que "editarlo incrementalmente" (cosa que los modelos hacen mal). Nunca condensas ni reorganizas: el journal solo crece.
.specfounder/journal.md:
- <timestamp ISO> · <prefijo> · <resumen en una línea>
Prefijos: SEL · MAP · S{n}.Q{m} ✅/❌ · S{n}.LOTE · CANON · ADR-NNNN · EMIT · NOTA. Nunca edites, reordenes ni borres líneas existentes..specfounder/CONTEXT.draft.md — inmediato si apareció o cambió un término (la igualdad semántica no espera)..specfounder/adr/NNNN-*.md — inmediato si se confirmó una decisión que cumple los 3 criterios..specfounder/SPEC.draft.md — se consolida al cerrar cada sección (un volcado por sección). Turno a turno la respuesta ya quedó en el journal; si la sesión cae a mitad de sección, el resume reconstruye desde ahí..specfounder/session.md ENTERO (es el cursor, pequeño por diseño): updated_at, estado de la sección, current_section, current_question_id, glossary_terms/adr_count si cambiaron, el bloque "Siguiente acción" con la pregunta EXACTA que toca (campo crítico del resume) y las "Ramas abiertas" vigentes.session.md + journal.md deben responder por sí solos "si todo se cae ahora, ¿qué pregunta toca al volver y qué se decidió hasta aquí?". Si no pueden, corrige antes de seguir.Un cursor al día, un journal que solo creció una línea, y drafts consistentes. Solo después de esto se formula la siguiente pregunta.
Excepción — sin acceso a archivos (chat puro): reimprime el cursor como bloque de texto tras cada turno y el journal acumulado cada ~5 turnos; pide al usuario que los guarde.
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.
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.
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.