| name | design-an-interface |
| description | Design-an-interface skill with N=3 parallel alternatives and architectural vocabulary. Use when designing a new module interface, when user mentions 'varias alternativas', 'design this module', or '/design-interface'. |
| maturity | stable |
| context | fork |
| context_cost | medium |
| category | architecture |
| tags | ["architecture","interface-design","parallel-agents","sdd"] |
| priority | high |
| attribution | Clean-room re-implementation of mattpocock/skills/design-an-interface (MIT, 26.4k*). Prose and process are original. |
| se | SE-087 |
Skill: Design an Interface
Attribution: Clean-room re-implementation of mattpocock/skills/design-an-interface (MIT). SE-087.
Genera 3 disenos alternativos de interfaz en paralelo y consolida en tabla comparativa con recomendacion justificada.
Authoritative Paths
Lee estos paths antes de actuar.
| Para | Lee este path |
|---|
| Vocabulario arquitectonico | docs/rules/domain/architectural-vocabulary.md |
| Codigo existente del proyecto | projects/<nombre>/ |
| Specs SDD activas | docs/propuestas/SPEC-*.md |
| Reglas de dominio | docs/rules/domain/ |
Cuando usar
- Se necesita disenar una interfaz nueva para un modulo y no hay precedente claro.
- Se quiere comparar enfoques antes de comprometerse con uno.
- La spec SDD requiere definicion de interfaz antes de implementar.
Cuando NO usar
- La interfaz ya existe y solo necesita extension — leer el codigo y ampliar.
- El scope es un metodo privado o una funcion de utilidad (demasiado granular).
- La interfaz tiene un patron establecido en el proyecto — seguir el patron existente.
Decision Checklist
- El modulo esta definido con nombre y contexto de uso? Si NO: solicitar antes de continuar.
- Hay restricciones conocidas (rendimiento, compatibilidad, framework)? Si NO: asumir ninguna y documentarlo.
- Existe codigo relacionado en el proyecto? Si SI: designar como base para Diseno C.
Abort Conditions
- Si el nombre del modulo es vago o el contexto insuficiente: pedir aclaracion y abortar.
- Si las restricciones implican un unico diseno posible: no lanzar alternativas, documentar la restriccion.
Workflow
Recibir → Lanzar 3 sub-agentes paralelos (Task tool) → Consolidar tabla → Recomendar
Sub-agentes en paralelo (mismo mensaje, sin dependencias)
A — Maxima simplicidad: minimo metodos, sin estado, facilidad de uso.
B — Maxima flexibilidad: extensible, plugin-friendly, facil de mockear.
C — Pragmatico: equilibrio A+B, inspirado en codigo existente del proyecto.
Formato de output de cada sub-agente
Interface: <NombreInterfaz>
Methods:
- <metodo>(<param>: <tipo>): <retorno>
Invariants:
- <descripcion>
Trade-offs:
+ <ventaja>
- <desventaja>
Consolidacion
Tabla comparativa con columnas: Criterio | Diseno A | Diseno B | Diseno C.
Criterios minimos: numero de metodos, estado requerido, testabilidad, extension futura, coherencia con codigo existente.
Recomendacion
Un parrafo usando vocabulario de docs/rules/domain/architectural-vocabulary.md:
- Module, Interface, Seam, Depth, Leverage, Locality.
- Justificar por que el diseno elegido maximiza Depth y Locality para el contexto dado.
Outputs esperados
- Tabla comparativa de los 3 disenos.
- Recomendacion con justificacion en vocabulario arquitectonico.
- Opcionalmente: fichero
docs/propuestas/<modulo>-interface-design.md si se requiere trazabilidad.
Memory hooks
- Diseno completado: guardar en memoria con tipo decision y titulo "interface design: modulo".
Related
- Rule:
docs/rules/domain/architectural-vocabulary.md (SE-082 — vocabulary obligatorio en outputs)
- SE-074:
scripts/parallel-specs-orchestrator.sh — para disenos grandes (>1h por agente), delegar coordinacion al orquestador paralelo en lugar de sub-agentes intra-sesion
- Skill:
.opencode/skills/spec-driven-development/SKILL.md
- Agent:
.opencode/agents/architect.md
- Roadmap:
docs/ROADMAP.md
