De los hallazgos
a capacidades reutilizables.

---
name: feature-intake-spec-checklist
description: Estandariza la definición de funcionalidades antes de la implementación generando un paquete mínimo trazable que cubra alcance, decisiones, riesgos, criterios de aceptación y planes de validación.
---

# Skill: Feature Intake -> Spec Checklist

## 1) Metadata
- **Skill ID:** feature-intake-spec-checklist
- **Version:** 0.1.0
- **Purpose:** Estandarizar la definición de funcionalidades antes de la implementación generando un paquete mínimo trazable que cubra alcance, decisiones, riesgos, aceptación y validación.
- **Audience (roles):** Chapter/PO, Tech Lead, Backend, Frontend, QA, Cyber
- **When to use:** Antes de crear tareas de implementación o abrir un PR significativo.
- **When NOT to use:** Incidentes P1 de producción, cambios triviales como typos o tareas sin impacto funcional.
- **Sensitive inputs:** No incluyas datos reales de clientes, credenciales, secretos, tokens ni URLs internas no autorizadas.
- **Expected output:** Markdown estructurado mediante la sección Output a continuación.

## 2) Inputs
Proporciona la información en este formato:

- **Business context (brief):**
- **Feature request / user story:**
- **Expected impact (metric or outcome):**
- **Scope (in/out):**
- **Known technical constraints:** (stack, standards, performance, availability)
- **Known risks:** (security, compliance, stability)
- **Dependencies:** (services, teams, data)
- **Team Definition of Done (DoD):** (if available)

## 3) Output
Devuelve **solo** un documento Markdown con estas secciones y bullets:

1. **Summary**
2. **Scope**
    - Dentro del alcance
    - Fuera del alcance
3. **Supuestos**
4. **Decisiones técnicas por tomar (pendientes o resueltas)**
5. **Riesgos y mitigaciones**
6. **Criterios de aceptación (medibles)**
7. **Plan de validación**
    - Pruebas unitarias
    - Pruebas funcionales
    - Seguridad (comprobaciones mínimas)
    - Evidencia requerida (qué adjuntar)
8. **Tareas sugeridas por rol**
    - Chapter/PO
    - Tech Lead
    - Backend
    - Frontend
    - QA
    - Cyber
9. **Preguntas abiertas**

## 4) Constraints
- No inventes requisitos: si falta información, inclúyela bajo **Preguntas abiertas**.
- No propongas herramientas fuera del stack permitido.
- No incluyas datos sensibles ni secretos.
- Los criterios de aceptación deben ser verificables; no escribas “mejorar el rendimiento” sin una métrica.
- El plan de validación debe incluir al menos un elemento de evidencia concreto, como salida de pruebas, un checklist o un archivo actualizado.
- Mantén la salida en un máximo de 1-2 páginas para que siga siendo usable.

## 5) Validation Rules
La salida es válida si:
- Incluye todas las secciones definidas en Output.
- Tiene al menos 3 criterios de aceptación medibles.
- Tiene al menos 3 tareas para cada rol central: Tech Lead, Backend y QA, o explica por qué un rol no aplica.
- Incluye al menos 2 riesgos con mitigaciones.
- No contiene datos sensibles ni secretos.
- No contiene supuestos no declarados.

## 6) Evidence
Adjunta o referencia estos elementos en el PR o entrega:
- `SKILL.md` versionado.
- `examples/input.sample.md`.
- `examples/output.sample.md`.
- Tag de versión para el Skill, como `skill-feature-intake-v0.1.0`.

## Business context (brief)
Reduce complaints caused by duplicate transfers.

## Feature request / user story
As a user, I want to confirm a transfer before sending it
so that I can avoid duplicates.

## Expected impact
Reduce duplicate-transfer complaints by 20% in one month.

## Scope (in/out)
In: pre-send confirmation, summary message, data validation.
Out: infrastructure changes and a complete UI redesign.

## Known technical constraints
Existing REST API, web frontend, standardized logging.

## Known risks
Sensitive data exposure in logs; amount-validation errors.

## Dependencies
Accounts service and transfers service.

## Team Definition of Done (DoD)
Unit tests, brief documentation, and reviewed PR.

# Feature Intake -> Spec Checklist

## 1. Summary
Add a pre-send transfer confirmation with a concise summary
and validation of transfer data. Target: 20% reduction in
duplicate-transfer complaints in one month.

## 6. Acceptance criteria (measurable)
- 95%+ of valid attempts show confirmation before submission.
- Invalid data blocks submission with a validation message.
- Duplicate complaints drop 20% within one month.
- No sensitive values appear in confirmation event logs.

## 9. Open questions
- What baseline measures the 20% reduction?
- Which API version owns the confirmation contract?

Actua como el Skill feature-intake-spec-checklist
(.github/skills/feature-intake-spec-checklist/SKILL.md).
Usa como entrada el contenido de examples/input.sample.md y genera
UNICAMENTE el documento Output definido en el contrato del Skill.

CONTEXTO
workshop-auth-backend/HALLAZGOS.md es la matriz de hallazgos del Dia 1.

OBJETIVO
Generar workshop-auth-backend/HU-01.md a partir de las filas "Pendiente"
de HALLAZGOS.md relacionadas con el token de autenticacion.

RESTRICCIONES
No inventes hallazgos que no esten en HALLAZGOS.md. No incluyas valores de
tokens, secretos ni credenciales.

CRITERIOS DE ACEPTACION
HU-01.md tiene las secciones Origen, Contexto, Ajustes necesarios, Criterios de
aceptacion y Evidencia esperada. Origen lista los Id (H-xx) y la evidencia
archivo:linea de cada hallazgo usado. Cada criterio de aceptacion es
verificable con una prueba.

FORMATO DE RESPUESTA
Solo el archivo HU-01.md.

# HU-01 - Token firmado con expiracion y claims minimos

## Veredicto
**Usable con ajustes.** La historia conecta seguridad, configuracion, testing y evidencia.

## Contexto
El servicio de autenticacion expone `POST /auth/login` y devuelve `token`, `expiresIn` y `user`. La implementacion usa firma HMAC y lee `AUTH_TOKEN_SECRET`.

## Ajustes necesarios
- Exigir los claims `sub`, `client`, `iat` y `exp`.
- Obtener `client` desde la solicitud, validarlo y reflejarlo en el token.
- Comprobar que `expiresIn` coincide con `exp - now` usando una tolerancia documentada.
- Eliminar el secreto por defecto fuera del sandbox o documentarlo como exclusivo de laboratorio.
- Evitar logs del token y del secreto.
- Mantener como decision tecnica si se conserva HMAC o se adopta una libreria JWT.

## Criterios de aceptacion
- Un token valido contiene `sub`, `client`, `iat` y `exp`.
- `expiresIn` es coherente con `exp - now` dentro de la tolerancia definida.
- Login valido, credenciales invalidas y token expirado tienen pruebas.
- No se registran tokens, secretos ni valores sensibles.
- La decision sobre HMAC frente a una libreria JWT queda documentada.

## Evidencia esperada
- Documento generado por los Skills a partir de este archivo.
- Pruebas de claims, expiracion y errores de autenticacion.
- Configuracion documentada de `AUTH_TOKEN_SECRET`.
- Evidencia de logs redactados.

Actua como el Skill feature-intake-spec-checklist
(.github/skills/feature-intake-spec-checklist/SKILL.md).

Lee workshop-auth-backend/HU-01.md y usa el archivo como unica entrada.
Genera UNICAMENTE el documento Output definido en el contrato del Skill,
con sus nueve secciones: Summary, Scope (in/out), Assumptions,
Technical decisions to make, Risks and mitigations, Acceptance criteria,
Validation plan, Suggested tasks by role y Open questions.

No inventes requisitos. Marca como pregunta abierta toda decision que la HU
no confirme. No incluyas valores de tokens, secretos ni credenciales.

Actua como el Skill discovery-analysis
(.github/skills/discovery-analysis/SKILL.md).

Contexto: estas en reqflow-workspace/ con los tres repos:
- workshop-auth-backend
- workshop-login-frontend
- workshop-requirements-api

Objetivo: produce 3-5 hallazgos con evidencia concreta (archivo:linea o comando),
impacto, prioridad propuesta, contrato potencialmente afectado y como validarlo.

Restricciones:
- no modificar codigo;
- no crear issues automaticamente;
- marca todo como CANDIDATO y detente para revision humana.

Actua como el Skill spec-writing
(.github/skills/spec-writing/SKILL.md).

Fuente: usa como entrada el hallazgo/Issue aprobado (titulo + evidencia + impacto).
Incluye contratos protegidos de ReqFlow cuando aplique.

Entrega solo la spec en el formato sugerido por el Skill y detente para
revision humana.

Actua como el Skill architecture-decision
(.github/skills/architecture-decision/SKILL.md).

Entrada: spec aprobada.
Salida: impacto, componentes, contratos protegidos, estrategia incremental,
pruebas necesarias, riesgos/trade-offs y decisiones abiertas.

Detente para revision humana antes de implementar.

Actua como el Skill issue-implementation
(.github/skills/issue-implementation/SKILL.md).

Precondiciones:
- issue aprobado
- spec aprobada
- impacto/arquitectura aprobada

Implementa el cambio minimo necesario, ejecuta pruebas relevantes y prepara
un PR con evidencia real.

Actua como el Skill reqflow-definition-of-done
(.github/skills/reqflow-definition-of-done/SKILL.md).

Evalua el cambio propuesto/implementado para el Issue trabajado en S2.

Para cada criterio responde solo con:
- CUMPLIDO (citar evidencia)
- FALTA EVIDENCIA (decir que falta)
- BLOQUEADO (explicar causa)
- NO APLICA AL ALCANCE (justificar)
- PENDIENTE DE OTRO GATE (indicar cual)

No inventes ejecuciones de CI ni cobertura.