neo-sales

name	neo-sales
description	Ejecuta el plan de comercialización de NeoCorporateWeb por bloques. Úsalo cuando el usuario escriba "/neo-sales", o cuando pida avanzar/continuar el "plan de comercialización", "roadmap comercial", "plan de ventas", "bloque comercial X", o trabajar en los gaps de `SALES-READINESS.md`. Lee `NeoCorporateWeb.Web/infraestructura/md/plan-comercializacion.md` como fuente de verdad del plan.

Skill: neo-sales

Esta skill orquesta la ejecución del plan de comercialización documentado en NeoCorporateWeb.Web/infraestructura/md/plan-comercializacion.md, derivado del análisis comercial en SALES-READINESS.md. Cada vez que el usuario te invoca, debes:

1. Leer el plan completo en NeoCorporateWeb.Web/infraestructura/md/plan-comercializacion.md para conocer los 8 bloques y su contenido.
2. Leer el archivo de estado .claude/skills/neo-sales/estado.md para saber qué items ya se completaron.
3. Determinar la acción según el argumento del usuario.

Importante: este plan no es código del core. Mucho de lo que hay aquí son documentos legales, integración con servicios externos (Stripe, MercadoPago, CRMs) y assets de marketing. No todo se resuelve con dotnet build. Cuando un item requiera contenido legal, decisiones de pricing, o credenciales de servicios externos, PREGUNTA al usuario en vez de inventar.

Argumentos soportados

Argumento	Acción
(vacío)	Mostrar estado actual + sugerir próximo bloque/item a ejecutar
estado	Tabla detallada de los 8 bloques con % completado
bloque N	Ejecutar el bloque número N (1–8) con confirmación previa
bloque N.M	Ejecutar solo el item M del bloque N (ej. bloque 4.3)
siguiente	Avanzar al siguiente item pendiente del bloque en curso
marcar N.M completado	Marcar manualmente un item (útil si se hizo fuera del flujo)
marcar N.M bloqueado <razón>	Marcar item como bloqueado con razón (ej. "esperando contrato con Stripe")
desbloquear N.M	Volver un item a pendiente
reset	(pide confirmación) Borra estado.md y empieza desde cero

Flujo por bloque

Cuando ejecutes un bloque:

1. Lee el detalle del bloque en plan-comercializacion.md.
2. Muestra al usuario la lista de items del bloque y pregúntale (con AskUserQuestion si hay >1 opción):
   • ¿Ejecutar todos los items del bloque, o seleccionar específicos?
   • ¿Confirmar antes de cada item, o avanzar automáticamente?
   • ¿Crear commit por item, por bloque, o no commitear?
3. Para cada item aprobado:
   • Si es código (signup, checkout, provisioning, etc.): investiga lo existente, planea el cambio, lo implementa, ejecuta dotnet build y dotnet test cuando aplique.
   • Si es documento legal (T&C, privacidad, DPA, SLA): genera un draft basado en plantillas estándar, deja marcado [REVISAR CON ABOGADO LOCAL] en las secciones que requieran ajuste por jurisdicción.
   • Si es contenido de marketing (landing copy, casos de estudio): pregunta al usuario por inputs específicos (cliente real, métricas, value prop) antes de inventar.
   • Si requiere integración externa (Stripe, MercadoPago, HubSpot): implementa la infraestructura, deja placeholders appsettings.json con claves dummy, documenta los pasos de configuración para que el usuario añada las credenciales reales.
4. Actualiza estado.md marcando los items completados.
5. Reporta al usuario qué se hizo, qué falló y qué queda pendiente del bloque, incluyendo los [REVISAR CON ABOGADO] y [REQUIERE CREDENCIALES] que dejaste.

Reglas obligatorias

• No inventes contenido legal. Marca claramente las plantillas con [REVISAR CON ABOGADO LOCAL — JURISDICCIÓN: XX].
• No inventes credenciales ni claves de prod. Usa <your_stripe_secret> o variables en appsettings.Production.json.example.
• No inventes precios definitivos sin confirmar con el usuario. El plan sugiere $29/$79/$199 pero eso es orientativo.
• No inventes casos de estudio reales. Si el usuario no tiene un cliente real para mostrar, ofrece template y dejarlo vacío hasta tener uno.
• Respeta la arquitectura existente del Bloque 1–9 de mejoras:
  • Multi-tenant con CompanyId y query filters globales.
  • Controllers ligeros; reglas de negocio en Services/.
  • AuditService para acciones administrativas relevantes.
  • HtmlSanitizerService antes de persistir HTML.
  • Migraciones SQL en infraestructura/sql/ Y database/Scripts/ con nombre YYYYMMDD_NN_descripcion.sql.
  • Textos UI en los 3 archivos .resx (es, en, pt).
  • No skipear hooks ni firmas (--no-verify, --no-gpg-sign).
• Confirma antes de comandos destructivos (drop tables, force push, delete branches, rm -rf).
• Build verificable: tras cambios de código, ejecuta dotnet build NeoCorporateWeb.Web.slnx y reporta el resultado.
• Tests verificables: tras tocar Services, Controllers, Middlewares o Data, ejecuta dotnet test NeoCorporateWeb.Web.slnx.
• Una migración → ambas carpetas: SQL nuevos en infraestructura/sql/ Y database/Scripts/.
• Documentación viva: al cerrar un bloque, actualiza plan-comercializacion.md cambiando el estado de items a ✅.
• SALES-READINESS.md también vive: al avanzar bloques significativos, actualiza la sección "Lo que NO está listo" reflejando lo que ya se cerró.

Archivo de estado (estado.md)

Si no existe, créalo con la plantilla inicial siguiente. Cuando completes un item, cambia [ ] por [x] y agrega — completado YYYY-MM-DD.

# Estado del plan de comercialización NeoCorporateWeb

Última actualización: <fecha>

## Bloque 1 — Documentos legales
- [ ] 1.1 Términos y Condiciones
- [ ] 1.2 Política de Privacidad
- [ ] 1.3 DPA (Data Processing Agreement)
- [ ] 1.4 SLA documentado
- [ ] 1.5 Contrato de reseller / partner

## Bloque 2 — Marketing site & demo pública
- [ ] 2.1 Landing del producto (single page)
- [ ] 2.2 Página pública de pricing
- [ ] 2.3 Tenant de demo público
- [ ] 2.4 1 caso de estudio inicial
- [ ] 2.5 Screenshots y video de 60s
- [ ] 2.6 Blog del producto con 3-5 posts iniciales
- [ ] 2.7 Suscripción a newsletter del producto

## Bloque 3 — Self-service signup
- [ ] 3.1 Página pública de registro /register
- [ ] 3.2 Verificación de email obligatoria
- [ ] 3.3 Provisioning automatizado de tenant nuevo
- [ ] 3.4 Selección de subdominio (slug.tudominio.com)
- [ ] 3.5 Onboarding wizard in-app (primer login)
- [ ] 3.6 Welcome drip emails
- [ ] 3.7 Página "Bienvenido, tu sitio está listo"

## Bloque 4 — Checkout y suscripciones
- [ ] 4.1 Integración Stripe Billing
- [ ] 4.2 Integración MercadoPago (LATAM)
- [ ] 4.3 Webhooks de pago
- [ ] 4.4 Flujo trial → paid automático
- [ ] 4.5 Página de upgrade/downgrade
- [ ] 4.6 Portal de billing (Stripe Customer Portal)
- [ ] 4.7 Trial 14 días sin tarjeta
- [ ] 4.8 Emails transaccionales (factura, pago fallido)

## Bloque 5 — Compliance GDPR/LGPD
- [ ] 5.1 Workflow "Borrar mi cuenta"
- [ ] 5.2 Export de datos por usuario
- [ ] 5.3 Política de retención configurable
- [ ] 5.4 Cookie consent granular
- [ ] 5.5 Audit log de eventos de compliance
- [ ] 5.6 DPA aceptado al registrarse

## Bloque 6 — Hardening pre-producción
- [ ] 6.1 Pen-test externo
- [ ] 6.2 Benchmarks de carga (k6/JMeter)
- [ ] 6.3 Backup off-site automático (S3/Azure Blob)
- [ ] 6.4 OWASP ZAP scheduled en CI
- [ ] 6.5 Fix 2 smoke tests pre-existentes
- [ ] 6.6 Quotas API por plan
- [ ] 6.7 Monitoring de read-replica
- [ ] 6.8 Property-based tests para query filters
- [ ] 6.9 Disaster recovery plan documentado

## Bloque 7 — Operación comercial
- [ ] 7.1 Integración CRM
- [ ] 7.2 Helpdesk / ticketing
- [ ] 7.3 Knowledge base público
- [ ] 7.4 Sistema de referidos
- [ ] 7.5 Email transaccional dedicado
- [ ] 7.6 Onboarding call automatizado (Cal.com)
- [ ] 7.7 NPS automático
- [ ] 7.8 Dashboard de churn risk

## Bloque 8 — Polish técnico opcional
- [ ] 8.1 Reemplazar Summernote por TipTap/Quill
- [ ] 8.2 Push notifications PWA
- [ ] 8.3 SSO / SAML
- [ ] 8.4 SOC 2 Type I
- [ ] 8.5 ISO 27001
- [ ] 8.6 Mobile app nativa
- [ ] 8.7 Marketplace de plantillas
- [ ] 8.8 API GraphQL

## Bloqueados / esperando
(vacío)

## Notas de sesión
(vacío)

Cuándo NO ejecutar

• Si el usuario solo pregunta "¿qué hay en el plan?": muéstralo, no ejecutes.
• Si un item requiere decisiones de producto/pricing/legal sin información: pregunta, no inventes.
• Si detectas que algo ya se hizo (por código o git log), márcalo en estado.md y continúa.
• Si el item requiere credenciales reales (Stripe, AWS, SendGrid…) que el usuario no te dio: deja placeholders, documenta cómo añadirlas, y marca como "[REQUIERE CREDENCIALES]" en estado.md bajo la sección "Bloqueados".

Convención de commits

<tipo>(neo-sales): bloque N.M <descripción corta>

<descripción extendida si aplica>

Co-Authored-By: Claude Sonnet 4.6 <[e-mail]>

Tipos: feat, fix, docs, chore, refactor. Para bloques 1 (legales) y 2 (marketing/contenido) suele ser docs(neo-sales): .... Para bloques 3/4/5/6/7 con código, suele ser feat(neo-sales): ....

Ejemplo: feat(neo-sales): bloque 3.3 provisioning automatizado de tenants nuevos Ejemplo: docs(neo-sales): bloque 1.2 política de privacidad — draft para revisión legal