Agent Skills
› mohitagw15856/pm-claude-skills
› prd-template
prd-template
GitHub生成专业产品需求文档(PRD)，涵盖问题定义、用户故事及成功指标。支持读取Brain上下文以增强事实依据，并自动同步更新实体与假设文件。
触发场景
撰写PRD
创建产品规格说明
定义功能需求
安装
npx skills add mohitagw15856/pm-claude-skills --skill prd-template -g -y
SKILL.md
Frontmatter
{
"name": "prd-template",
"language": "es",
"description": "Crea un Documento de Requerimientos de Producto (PRD) siguiendo una estructura de plantilla probada de gestión de producto. Úsalo cuando te pidan escribir un PRD, una especificación de producto, una especificación de funcionalidad o un documento de requerimientos para un producto o funcionalidad nueva. Produce un PRD completo con planteamiento del problema, historias de usuario, requerimientos funcionales, consideraciones técnicas y métricas de éxito."
}
Traducción al español de prd-template — la versión en inglés es la canónica.
Habilidad de Plantilla de PRD
Esta habilidad ayuda a crear Documentos de Requerimientos de Producto profesionales siguiendo las mejores prácticas de la industria.
Entradas requeridas
Pídele al usuario lo siguiente si no lo proporcionó:
- Nombre de la funcionalidad o del producto
- Problema que se resuelve (desde la perspectiva del usuario)
- Usuario objetivo (rol, contexto, qué intenta lograr)
- Métricas de éxito (¿cómo sabrás que funcionó?)
- Alcance (MVP vs. visión completa — qué entra y qué queda fuera del alcance)
- Actores clave (quién necesita revisar y aprobar)
Lee del Brain / Escribe en el Brain
Si existe un professional-brain (brain/), úsalo en lugar de pedir contexto que ya tienes:
- Lee primero:
context.md(producto, definiciones de métricas, voz),knowledge/strategy.md(hacia dónde va el producto), cualquierhypotheses/relacionada y el archivo de la funcionalidad correspondiente enentities/. Ejecutapython3 ../professional-brain/scripts/brain_query.py ./brain "<funcionalidad>"para extraer hechos fundamentados, y traslada sus etiquetas de procedencia al PRD (no presentes una[hunch](corazonada) como un requerimiento resuelto). - Escribe después: guarda la funcionalidad como/dentro de
entities/<funcionalidad>.md, registra cualquier decisión de alcance endecisions/y agrega los supuestos nuevos ahypotheses/. Etiqueta cada uno con su procedencia.
Materiales de apoyo
Esta habilidad incluye dos archivos de soporte — úsalos cuando estén disponibles:
templates/prd-skeleton.md— un esqueleto de PRD para completar, con una pista de "así se ve un buen resultado" por sección. Parte de él cuando el usuario quiera un documento para completar por su cuenta en lugar de un borrador generado.references/success-metrics-guide.md— calibración para la sección de Métricas de Éxito: la prueba de cuatro partes para una métrica, el conjunto estándar de adopción/resultado/negocio/salvaguarda, y las trampas más comunes. Consúltalo siempre que escribas o revises la tabla de métricas.
Estructura de la plantilla
Todo PRD debe incluir estas secciones, en este orden:
1. Resumen general
- Planteamiento del problema: ¿Qué problema estamos resolviendo? (2-3 oraciones)
- Solución propuesta: Descripción de alto nivel de lo que vamos a construir (2-3 oraciones)
- Métricas de éxito: Cómo mediremos el éxito (3-5 métricas clave)
2. Contexto y antecedentes
- Por qué ahora: ¿Por qué es este el momento adecuado?
- Alineación estratégica: ¿Cómo se alinea esto con los objetivos de la empresa?
- Resumen de investigación de usuarios: Hallazgos clave de la investigación (si aplica)
3. Historias de usuario y casos de uso
Formato: "Como [tipo de usuario], quiero [acción] para [beneficio]"
- Incluye de 3 a 7 historias de usuario principales
- Agrega criterios de aceptación para cada una
4. Requerimientos
Requerimientos funcionales:
- Funcionalidades imprescindibles (P0)
- Funcionalidades deseables (P1)
- Funcionalidades opcionales (P2)
Requerimientos no funcionales:
- Expectativas de rendimiento
- Consideraciones de seguridad
- Requerimientos de accesibilidad
5. Diseño y experiencia de usuario
- Enlace a maquetas de diseño o wireframes
- Flujos de usuario clave
- Casos límite y estados de error
6. Consideraciones técnicas
- Implicaciones de arquitectura
- Dependencias de otros sistemas
- Riesgos técnicos y mitigaciones
7. Plan de implementación
- Fase 1 (MVP): Qué entra en la primera versión
- Fase 2: Qué viene después
- Fase 3: Mejoras futuras
8. Preguntas abiertas
- Decisiones que todavía deben tomarse
- Actores a consultar
- Investigación pendiente
9. Apéndice
- Enlaces a investigación
- Documentos relacionados
- Análisis competitivo
Pautas de redacción
Tono: Claro, conciso, accionable Audiencia: Ingenieros, diseñadores, actores clave Extensión: Apunta a 3-6 páginas para funcionalidades, 8-12 para productos
Mejores prácticas:
- Usa ejemplos concretos en lugar de abstracciones
- Incluye el "por qué", no solo el "qué"
- Haz que los requerimientos sean verificables
- Enlaza a materiales de soporte
- Actualiza el documento a medida que se toman decisiones
Qué distingue a un buen PRD
✅ Sí:
- Escribe desde la perspectiva del usuario
- Incluye métricas de éxito específicas
- Aborda los casos límite
- Enlaza a investigación y datos
- Haz explícitos los compromisos y sacrificios
❌ No:
- Escribas detalles de implementación (eso es la especificación técnica)
- Asumas que todos tienen el contexto
- Dejes requerimientos ambiguos
- Omitas el "por qué"
- Olvides la accesibilidad
Rúbrica de puntuación (0–40)
Puntúa cualquier salida de esta habilidad antes de entregarla; 32+ es calidad lista para publicar.
| Dimensión | 0 | 5 | 10 |
|---|---|---|---|
| Fundamento del problema | El problema se plantea desde la perspectiva de la empresa, o se afirma sin evidencia | Problema enmarcado desde el usuario, pero los datos de soporte son vagos ("los usuarios están frustrados") y no se cita investigación | El problema es del usuario, cuantificado con datos del estado actual, y el "Por qué ahora" explica qué cambió; las afirmaciones se rastrean a investigación citada |
| Verificabilidad de los requerimientos | Los requerimientos son cualidades vagas ("rápido", "intuitivo") que un revisor no podría verificar | La mayoría de los requerimientos son concretos, pero los criterios de aceptación son escuetos y los requerimientos no funcionales son de relleno | Cada ítem P0/P1/P2 y cada RNF es verificable (umbrales, percentiles, estándares), y cada uno se rastrea a una historia de usuario o a un hallazgo de investigación |
| Rigor de las métricas | Faltan métricas de éxito, o son porcentajes sin línea base | Hay líneas base y objetivos, pero las métricas solo miden adopción — nada detectaría que la funcionalidad tenga éxito mientras el negocio pierde | Cada métrica tiene línea base → objetivo, el conjunto cubre resultado además de adopción, y al menos una salvaguarda protege contra ganar la métrica dañando al usuario |
| Honestidad de alcance y riesgo | El MVP y las fases futuras se mezclan; no se listan preguntas abiertas | Las fases están separadas, pero faltan las razones de los cortes y los desacuerdos se disimulan | Cada límite de fase tiene una razón explícita, lo excluido del alcance queda registrado con condiciones de reingreso, y las preguntas abiertas tienen responsable, fecha límite y el costo de cada respuesta |
Controles de calidad
- El planteamiento del problema está escrito desde la perspectiva del usuario (no de la empresa)
- Las métricas de éxito son específicas y medibles
- Las historias de usuario incluyen criterios de aceptación
- Los requerimientos son verificables (no vagos)
- Las preguntas abiertas se listan explícitamente
- El plan de implementación distingue el MVP de las fases futuras
Anti-patrones
- No escribas requerimientos desde la perspectiva de la empresa — cada requerimiento debe rastrearse a una necesidad del usuario
- No incluyas requerimientos vagos como "el sistema debe ser rápido" — cada requerimiento debe ser verificable
- No mezcles el MVP con las fases futuras — sé explícito sobre qué entra y qué no en la primera versión
- No dejes métricas de éxito como porcentajes sin línea base — especifica el estado actual y el objetivo
- No omitas las preguntas abiertas — los supuestos sin resolver son riesgos; visibilizarlos es el trabajo del PM
Ejemplo de apertura de un PRD
# PRD: Panel Multicanal de Atención al Cliente
## Resumen general
**Planteamiento del problema**: Los equipos de soporte gestionan actualmente las consultas de clientes por correo, chat y redes sociales con tres herramientas separadas, lo que genera respuestas tardías, trabajo duplicado y experiencias de cliente inconsistentes. En promedio, los agentes de soporte pierden 2.3 horas al día cambiando entre herramientas y rastreando manualmente el historial de conversaciones.
**Solución propuesta**: Construir un panel unificado que agregue las consultas de clientes de todos los canales en una sola interfaz, mantenga el historial de conversaciones entre canales y ofrezca enrutamiento inteligente según la experiencia y disponibilidad del agente.
**Métricas de éxito**:
- Reducir el tiempo promedio de respuesta de 4 horas a 1 hora
- Disminuir el tiempo de cambio entre herramientas en 80% (de 2.3 a <0.5 horas)
- Mejorar la puntuación de satisfacción del cliente de 3.8 a 4.5 (sobre 5)
- Aumentar la productividad de los agentes de soporte en 35%
## Contexto y antecedentes
**Por qué ahora**: La satisfacción del cliente cayó 15% en los últimos 6 meses, principalmente por tiempos de respuesta lentos. Nuestro principal competidor lanzó un panel de soporte unificado el trimestre pasado, y ya lo escuchamos en llamadas de ventas. La rotación del equipo de soporte es del 45% anual, con la "complejidad de las herramientas" citada como frustración principal.
**Alineación estratégica**: Esto se alinea con el objetivo de la empresa para el Q1 de "Mejorar la retención de clientes en 10%" y con el OKR del equipo de soporte de "Reducir el tiempo promedio de gestión en 25%".
**Resumen de investigación de usuarios**: Realizamos entrevistas con 12 agentes de soporte y observamos 20 horas de sesiones de soporte. Hallazgos clave:
- Los agentes dedican 35% de su tiempo a buscar contexto de interacciones previas
- El 65% de los escalamientos se debe a la falta de historial de conversaciones
- Los agentes calificaron el cambio entre herramientas como su frustración diaria #1 (dolor de 9.2/10)
- El NPS actual de la experiencia de soporte es -12
## Historias de usuario y casos de uso
**HU1: Bandeja de entrada unificada**
Como agente de soporte, quiero ver todas las consultas de clientes en un solo lugar para no perder solicitudes urgentes y poder priorizar con eficacia.
Criterios de aceptación:
- La bandeja muestra consultas de correo, chat y redes sociales
- Las consultas se ordenan por prioridad (urgente, alta, normal, baja)
- El agente puede filtrar por canal, cliente o estado
- Actualizaciones en tiempo real cuando llegan consultas nuevas
**HU2: Contexto entre canales**
Como agente de soporte, quiero ver el historial completo de la conversación sin importar el canal, para dar respuestas consistentes e informadas sin pedirle al cliente que se repita.
Criterios de aceptación:
- La vista de línea de tiempo muestra todas las interacciones en orden cronológico
- Cada interacción muestra canal, marca de tiempo y contenido
- El perfil del cliente muestra datos demográficos e información de la cuenta
- Los problemas y resoluciones anteriores son accesibles
[Continuar hasta 5-7 historias de usuario en total...]
版本历史
- 54fad50 当前 2026-07-19 13:15
