opencode-wait-a-minute

Files (200)

• ci.yml · .github/workflows/
• dist-tag.yml · .github/workflows/
• rc1-validation.yml · .github/workflows/
• release.yml · .github/workflows/
• .gitignore
• opsx-apply.md · .opencode/commands/
• opsx-archive.md · .opencode/commands/
• opsx-explore.md · .opencode/commands/
• opsx-propose.md · .opencode/commands/
• opsx-sync.md · .opencode/commands/
• CHANGELOG.md
• LICENSE
• README.md
• README_es.md
• SKILL.md
• active-task · active-task-x/.wam/
• logo-dark.svg · assets/
• logo.svg · assets/
• DELIVERABLE_SUMMARY.md · benchmarks/
• README.md · benchmarks/
• analyzer.mjs · benchmarks/analyzers/
• baseline.mjs · benchmarks/artifact-outcome/
• episodes.mjs · benchmarks/artifact-outcome/
• fixtures.mjs · benchmarks/artifact-outcome/
• index.mjs · benchmarks/artifact-outcome/
• run-benchmark.mjs · benchmarks/artifact-outcome/
• runner.mjs · benchmarks/artifact-outcome/
• verifier.mjs · benchmarks/artifact-outcome/
• wam-runner.mjs · benchmarks/artifact-outcome/
• bench-context.mjs · benchmarks/
• charts.mjs · benchmarks/charts/
• cli.mjs · benchmarks/
• cli.test.mjs · benchmarks/
• context-ablation-study.mjs · benchmarks/
• context-benchmark.mjs · benchmarks/
• quality-harness.mjs · benchmarks/cqe/
• run-benchmark.mjs · benchmarks/cqe/
• ablation.mjs · benchmarks/evaluation/
• ablation.test.mjs · benchmarks/evaluation/
• causal-metrics.mjs · benchmarks/evaluation/
• compare-runs.mjs · benchmarks/evaluation/
• compare-runs.test.mjs · benchmarks/evaluation/
• equivalence.mjs · benchmarks/evaluation/
• evaluation.test.mjs · benchmarks/evaluation/
• metrics.mjs · benchmarks/evaluation/
• state-equivalence.mjs · benchmarks/evaluation/
• state-equivalence.test.mjs · benchmarks/evaluation/
• statistics.mjs · benchmarks/evaluation/
• statistics.test.mjs · benchmarks/evaluation/
• success.mjs · benchmarks/evaluation/
• success.test.mjs · benchmarks/evaluation/
• README.md · benchmarks/evidence/
• evidence.test.mjs · benchmarks/evidence/
• index.mjs · benchmarks/evidence/
• methodology.md · benchmarks/evidence/
• sources.json · benchmarks/evidence/
• traces.mjs · benchmarks/fixtures/
• conditions.mjs · benchmarks/frontend-ux/
• corpus.mjs · benchmarks/frontend-ux/
• rubric.mjs · benchmarks/frontend-ux/
• …and 140 more

SKILL.md (first lines)

# Wait a Minute

## Philosophy

«Wait a Minute: antes de responder, no asumas. Entiende primero.»

El sistema debe analizar la petición del usuario, inspeccionar el proyecto cuando corresponda, identificar qué sabe y qué no sabe, detectar supuestos, determinar el tipo de tarea, descubrir las skills relevantes y decidir si necesita hacer preguntas antes de continuar.

**El trabajo real comienza después del pre-flight.**

## Prompt Hook Behavior

El hook de sesión `prompt` intercepta el prompt **antes** de:
1. Resolución de skills
2. Selección de modelo/tier
3. Invocación de agente
4. Procesamiento del request

El hook puede:
- Modificar el prompt
- Ejecutar análisis de pre-flight
- Decidir si continuar, preguntar o delegar
- Inyectar contexto al agente

## Four Categories Framework

### KNOWN
Hechos confirmados por:
- Usuario (declaración explícita)
- Archivos (código, configuración)
- Herramientas (results de grep/read/glob)
- Configuración del proyecto
- Documentación del proyecto
- OpenSpec specs/changes cuando existan

### INFERRED
Conclusiones razonables derivadas de evidencia:
- Patrones observados en el código
- Convenciones del proyecto
- Dependencias inferidas
- Estructura de directorios

### ASSUMED
Supuestos que podrían ser incorrectos:
- "Usa JWT porque es el estándar"
- "El frontend es Angular porque así suele ser"
- "Redis es para caching porque sí"

### UNKNOWN
Información que todavía no conocemos:
- Si el proyecto ya usa autenticación
- Quién toma decisiones de arquitectura
- Qué restricciones ocultas existen

**Regla:** «Si un UNKNOWN o ASSUMED puede cambiar materialmente la solución, no continuar silenciosamente: hacer una pregunta.»

## Project-Aware Analysis

Antes de formular preguntas, el sistema debe analizar el repositorio cuando sea posible. Priorizar (en orden):

1. `AGENTS.md` — contexto persistente del proyecto
2. `README` — descripción y setup
3. `package.json` / equivalente — dependencias y scripts
4. Estructura de directorios relevante
5. Archivos relacionados con la petición
6. Tests existentes — patrón de implementation
7. Configuración de build/lint
8. Dependencias relevantes
9. Documentación técnica existente
10. OpenSpec specs/changes cuando existan
11. Skills del proyecto

**El análisis debe ser proporcional a la tarea.**
- Modificación trivial → inspección ligera
- Decisión arquitectónica → análisis profundo

## Request Classification

Determinar una o más categorías:

- `question` — pregunta directa, factual
- `research` — investigar un tema, comparar opciones
- `debugging` — encontrar y corregir un bug
- `bug-fix` — corregir un error conocido
- `implementation` — nuevo código o funcionalidad
- `refactoring` — mejorar estructura existente
- `architecture` — decisiones de alto nivel
- `security` — vulnerabilidades o hardening
- `performance` — optimización de rendimiento
- `testing` — tests unitarios/integración
- `migration` — migrar a otra tecnología
- `infrastructure` — setup, despliegue, configuración
- `documentation` — docs, README, comentarios
- `investigation` — investigación de código existente
- `planning` — planear un cambio
- `destructive-operation` — cambios que pueden destruir datos/estado

**También determinar:**
- `complexity`: trivial | normal | complex
- `risk`: bajo | medio | alto
- `ambiguity`: baja | media | alta
- `confidence`: 0-100%

## Assumption Audit

Antes de continuar debe realizar una auditoría explícita:

```
What do I know?
What am I inferring?
What am I assuming?
What do I still need to know?
```

**No debe preguntar cosas que pueda determinar inspeccionando el proyecto.**

**Ejemplo incorrecto:**
> "¿Qué framework usas?"
> (si package.json ya permite determinarlo)

From khnker/opencode-wait-a-minute, MIT.

More from khnker/opencode-wait-a-minute