| 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:
- Leer el plan completo en
NeoCorporateWeb.Web/infraestructura/md/plan-comercializacion.md para conocer los 8 bloques y su contenido.
- Leer el archivo de estado
.claude/skills/neo-sales/estado.md para saber qué items ya se completaron.
- 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:
- Lee el detalle del bloque en
plan-comercializacion.md.
- 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?
- 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.
- Actualiza
estado.md marcando los items completados.
- 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 <noreply@anthropic.com>
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
