CommunityRedacción y edicióngithub.com

AI PRD: escribir requisitos que un sistema modelo pueda realmen…

Ejecuta un producto desde el descubrimiento hasta el retiro: plantillas con compuertas, tarjetas PM canon y habilidades de IA que funcionan sin IA.

¿Qué es AI PRD: escribir requisitos que un sistema modelo pueda realmen…?

Este skill transforma la redacción de un PRD (Documento de Requisitos de Producto) para sistemas basados en IA, reconociendo que sus requisitos no son instrucciones para un ingeniero, sino restricciones para un sistema que improvisa. Reestructura el documento tradicional en cinco secciones clave: criterios de aceptación como conjuntos de evaluación (con ejemplos etiquetados y umbrales numéricos), especificación de casos extremos (tablas obligatorias para rechazo, escalado a humano y prohibición de invención), manejo explícito de la no determinismo (variaciones aceptables vs. defectos), guardarraíles como características con dueños y una página de operaciones (costo, latencia, versionado de modelos y telemetría). Soporta tanto contextos no regulados como regulados (financiero o de datos), ofreciendo una ruta especial con plantillas byte-exactas y condiciones previas de licencia. El output final incluye una tabla de brechas (GAPS) que prioriza los riesgos y exige condiciones numéricas de aprobación, dueños y pruebas para cada requisito.

Compatible con✓Claude Code~Codex CLI~Cursor✓Antigravity
npx skills add RizwanZafaris/product-manager-OS

Installed? Explore more Redacción y edición skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

AI PRD: escribir requisitos que un sistema modelo pueda realmente cumplir

Un PRD para un sistema de IA es un documento diferente. Tus requisitos no son instrucciones para un ingeniero; son restricciones sobre un sistema que improvisará. Esta habilidad reestructura el documento en torno a ese hecho.

Archivos que impulsa esta habilidad

Cuándo usar

  • Especificar cualquier funcionalidad donde un LLM, agente o modelo tome o redacte una decisión
  • Revisar un PRD existente que diga "la IA debería..." en alguna parte
  • Convertir un demo en algo por lo que un equipo de ingeniería pueda rendir cuentas

Las cinco secciones que esta habilidad exige

1. Los criterios de aceptación son conjuntos de evaluación, no oraciones

"El agente debería extraer el nombre del comerciante" es un deseo. Un requisito es:

  • Un conjunto de ejemplos etiquetados (mínimo 30 a 50 casos para un primer lanzamiento)
  • Un umbral de aprobación expresado como número (precisión, recall en k, o puntuación del juez)
  • La regla para lo que sucede por debajo del umbral (bloquear lanzamiento, no "revisar")

Por cada "debería" en el borrador, pregúntate: ¿dónde está el conjunto de ejemplos, cuál es el número, quién posee la tarea de agregar casos fallidos de vuelta al conjunto? Captura las respuestas en ../../templates/ai/eval-spec.md.

2. Los casos extremos son la especificación, no el apéndice

El camino feliz es lo que el modelo hace gratis. El documento demuestra su valor en los límites. Exige tablas explícitas para:

  • DEBE RECHAZAR: entradas que el sistema declina (fuera de alcance, inseguras, ambiguas sin posibilidad de reparación)
  • DEBE ESCALAR: condiciones que derivan a un humano, con el destino de derivación nombrado; captura los disparadores y el comportamiento de tiempo de espera en ../../templates/ai/human-approval-gates.md
  • NUNCA DEBE INVENTAR: campos donde la fabricación es peor que la ausencia (números, nombres, declaraciones legales o regulatorias, montos monetarios); la política de abstención vive en ../../templates/ai/hallucination-controls.md

3. El no determinismo se escribe

La misma entrada puede producir una salida diferente mañana. El PRD debe declarar:

  • Qué variaciones de salida son aceptables (redacción, orden, formato)
  • Cuáles son defectos (decisión diferente, número diferente, comportamiento de rechazo diferente)
  • Postura de reproducibilidad: política de temperatura y semilla, y si los registros capturan lo suficiente para repetir cualquier decisión

Si el PRD no lo dice, QA lo decidirá más tarde, en un rastreador de errores, con enojo.

4. Los guardarraíles son funcionalidades con dueños

Cada guardarraíl obtiene una fila en ../../templates/ai/guardrails.md: nombre, disparador, comportamiento, dueño, prueba. Conjunto mínimo a considerar para cualquier característica agentiva:

  • Fallo cerrado en salida no verificable (no se puede comprobar = no enviarlo al usuario)
  • Aprobación humana antes de cualquier cosa irreversible (envíos, pagos, eliminaciones, publicaciones)
  • Límites de gasto y tasa con un techo declarado y un comportamiento declarado en el techo
  • Aislamiento de entrada: el contenido que el sistema lee son datos, nunca instrucciones
  • Rastro de auditoría: quién o qué decidió, basado en qué entradas, en qué versión del modelo

5. La página de operaciones

  • Costo por llamada objetivo y el umbral de alerta
  • Presupuesto de latencia por paso
  • Fijación de versión del modelo y el proceso de decisión de actualización
  • Telemetría: qué se registra por decisión, dónde se ejecutan las evaluaciones (CI, pre-lanzamiento, muestreo en producción) y el disparador de reversión

La ruta regulada

Las herramientas genéricas de PRD escriben las cinco secciones anteriores y se detienen. Cuando el producto está bajo un regulador financiero o de datos, no ejecutes la superposición de esta habilidad de memoria. Comienza en su lugar desde la plantilla byte-exacta en ../../modules/regulated/templates/regulated-ai-prd-template.md, sigue ../../modules/regulated/SKILL.md, y completa su sección 0 (precondiciones de licencia, reglas del esquema, residencia de datos y términos del proveedor, puntos de contacto con delitos financieros, conducta, la métrica de prueba de auditoría) antes de escribir cualquier requisito. Un campo de superposición en blanco es una decisión diferida a quien lo encuentre en blanco. Nombres de reguladores, números de sección y texto citado provienen solo de ese módulo o del texto primario que el usuario proporcione; nunca los inventes.

Flujo de trabajo

  1. Clasifica el contexto. Regulado: toma la ruta regulada anterior, luego regresa aquí para secciones que el módulo no cubra. No regulado: comienza desde ../../templates/definition/prd.md.
  2. Lee el borrador del PRD, o entrevista al PM si comienza en blanco.
  3. Reescribe cada declaración con "debería" en la forma de la sección 1. Enumera aquellas que no se puedan convertir en evaluaciones; esos no son requisitos aún, márcalos.
  4. Construye las tres tablas de casos extremos. Presiona por al menos 5 filas cada una; tablas vacías significan que el descubrimiento no está completo.
  5. Escribe la cláusula de no determinismo y la tabla de guardarraíles.
  6. Produce una lista de BRECHAS (GAPS) de una página: cada lugar donde el documento original asumió un implementador determinista, clasificado por radio de explosión.

Formato de salida

Devuelve el PRD reestructurado con las cinco secciones, luego la tabla de BRECHAS:

#BrechaDónde en el originalRadio de explosión si se entrega tal cualArreglo más pequeño

Puerta de salida

El output de esta habilidad alimenta la Puerta 2 en ../../os/STAGE-GATES.md. No reportes el PRD como terminado mientras algún requisito carezca de una condición numérica de aprobación, algún guardarraíl carezca de dueño y prueba, o alguna fila de BRECHAS carezca de dueño y fecha.

Skills relacionados