メニュー
Vigilante de las 14 fases + gate 10.5. Delega la evaluación de outcomes al skill `grader` (Sprint 8.1) y enforces la regla absoluta de cross-project retrieval. NO usa checklist binario — el grader decide should_block según outcomes verificables.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | flow-guardian |
| description | Vigilante de las 14 fases + gate 10.5. Delega la evaluación de outcomes al skill `grader` (Sprint 8.1) y enforces la regla absoluta de cross-project retrieval. NO usa checklist binario — el grader decide should_block según outcomes verificables. |
La v1 era checklist binario: cada fase tenía sus [ ] X completed,
[ ] Y verified, y se podía marcar completed con cáscara/mock. Eso fue
la raíz que permitió incidentes tipo FocusNow#3.
La v2 delega outcomes al grader (skills/grader/SKILL.md) y se queda
como capa de orquestación + invariantes cross-project.
SIEMPRE que se ejecute una acción dentro de un proyecto APEX. El hook
SessionStart ya prima esta skill al inicio. Antes de:
apex_set_phase)Antes de apex_set_phase(N, status="completed" | "in_progress"):
1. Ejecutar apex_grader_evaluate(phase=fase_a_cerrar, mode="deterministic")
2. Si verdict.should_block:
a. Mostrar al usuario los issues + razón
b. NO llamar apex_set_phase. Atacar issues primero.
c. Si el usuario insiste por motivo justificado:
apex_set_phase(..., force=True, force_reason="...")
(esto registra apex_add_error severity=high automáticamente)
3. Si verdict pasa: apex_set_phase normalmente.
El handler MCP y el hook PreToolUse phase-gate.py ya enforcen
esto técnicamente — esta skill describe el flujo para que el agente lo
entienda y lo respete.
ANTES de proponer una decisión de stack, arquitectura, diseño visual, UX, scraping, auth, deploy o cualquier elección estructural, ejecutar:
apex_search_cross_project(query="<términos relevantes>")
Procesar el resultado:
Si la tool devuelve "hub.db no disponible":
apex_add_error(source="claude", description="hub.db offline en sesión", severity="medium").apex-hub para habilitar segundo cerebro.Antes de cualquier apex_set_phase(11, ...):
1. apex_grader_evaluate(phase=10) — fase 10 debe estar PASS
2. apex_security_gate(...) — 8 capas L1-L8 deben estar 'passed'
3. Si alguna no es 'passed' → bloquear con diagnóstico
El handler MCP de apex_set_phase consulta grader_verdicts. Si la fase
10 tiene verdict should_block=true, la transición a 11 falla. Esto
cierra el GAP CRIT-C del audit pre-Sprint 8.
| Origen del bloqueo | Cómo enforce |
|---|---|
| Checks deterministas (git, tests, emojis, schema, e2e) | Grader → handler apex_set_phase → hook phase-gate.py (doble red) |
| Juicio LLM (mock_data, hallucination, ambiguous_outcome) | Grader modo full → handler |
| Gate AgentArmor 10.5 | apex_security_gate + grader verdict de fase 10 |
| Cross-project retrieval omitido | Esta skill (orquestación) — el agente debe llamar apex_search_cross_project antes de decisiones estructurales |
completed sin haber llamado apex_grader_evaluate.force=true sin force_reason documentado.apex_search_cross_project previa.skills/grader/SKILL.md — evaluador outcome-based (delegación principal)skills/apex-goal/SKILL.md — bucle persistente con turn-budgetskills/security-audit/SKILL.md — AgentArmor 8 capasskills/iterate/SKILL.md — fase 12 (in_progress perpetuo)skills/code-review/SKILL.md — review estilo staff engineerforce=true se
promueven a issues en hub.db automáticamente.Prototipa lógica de negocio compleja como máquina de estados ejecutable (TUI Python con Textual). Mejor que prosa para validar transiciones, edge cases y reglas de negocio. Genera un .py corriendo + diagrama Mermaid commiteado a wiki/concepts/. Triggers ES/EN — prototipo, prototype, máquina de estados, state machine, valida transiciones, business logic complejo, "más de 5 reglas".
Bucle persistente con turn-budget. Mantiene un goal activo entre turnos, juez Sonnet 4.6 decide done|continue|degenerate tras cada turno. Adaptación de Hermes /goal con detección de degeneración.
Bucle de diagnóstico disciplinado para bugs difíciles y regresiones de rendimiento. Reproduce → minimiza → hipotetiza → instrumenta → corrige → test de regresión. Usar cuando el usuario dice "diagnose this" / "debug this", reporta un bug, dice que algo está roto/throwing/failing, o describe una regresión de rendimiento. Triggers ES/EN — diagnose, diagnostica, debug, "está roto", regresión, "no funciona".
Sesión de interrogatorio que confronta tu plan contra el modelo de dominio existente, afila la terminología y actualiza la documentación (CONTEXT.md, ADRs / wiki/decisions/) inline conforme las decisiones cristalizan. Usar cuando el usuario quiere estresar un plan contra el lenguaje del proyecto y las decisiones documentadas. Triggers ES/EN — grill, parrilla, interrogar, "afina mi plan", stress-test plan, challenge plan.
Encuentra oportunidades de profundización (deepening) en un codebase, informado por el lenguaje del dominio en CONTEXT.md y las decisiones en wiki/decisions/ o docs/adr/. Usar cuando el usuario quiere mejorar arquitectura, encontrar oportunidades de refactor, consolidar módulos fuertemente acoplados, o hacer un codebase más testeable y AI-navegable. Triggers ES/EN — improve architecture, "mejorar arquitectura", deepening, refactor, "demasiados módulos pequeños", "es difícil de testear".
Desarrollo guiado por tests con bucle red-green-refactor. Usar cuando el usuario quiere construir features o arreglar bugs usando TDD, menciona "red-green-refactor", quiere tests de integración, o pide desarrollo test-first. Triggers ES/EN — tdd, test-driven, "primero test", red-green-refactor, "tests integración".