PM Copilot
Triangula tickets de soporte al cliente y solicitudes de funciones para generar planes de producto priorizados con puntuación de convergencia y limpieza de PII.
Documentación
PM Copilot
Un servidor MCP que triangula tickets de soporte al cliente, solicitudes de funciones y conversaciones de agentes de soporte con IA para ayudar a los PMs a decidir qué construir a continuación.
Resultados reales: Analizó 3,353 señales en una ventana de 30 días: 1,678 tickets de soporte, 276 solicitudes de funciones y 1,399 conversaciones de agentes de soporte con IA en 4 productos. Prioridad principal: Reservas y Programación — 285 tickets + 74 solicitudes de funciones + 347 chats apuntando al mismo problema, con el agente de IA respondiendo con baja confianza en el 48% de esos chats.
Los 1,399 chats son el punto clave. Ninguno de ellos era visible para el análisis antes de v1.4.0, y representan el 83% del volumen del canal de tickets.
Lea la historia completa: Construí un servidor MCP que cambió cómo priorizo productos — por qué lo construí, cómo funcionan las señales convergentes en la práctica y lo que aprendí construyendo con Claude Code.
Qué Hace Esto Diferente
- Triangulación de señales. Compara tickets de soporte con solicitudes de funciones para encontrar temas convergentes, y luego los puntúa con una fórmula ponderada que da a las señales convergentes un impulso de prioridad 2x.
- El punto ciego de la desviación. Un agente de soporte con IA responde preguntas que nunca se convierten en tickets, por lo que la priorización basada en tickets subestima cada tema que el bot maneja — y la brecha se amplía a medida que el bot mejora. Las conversaciones de Chatbase se integran como una tercera clase de señal, con un
self_serve_failure_ratepor tema que muestra dónde falla la autoservicio. - Componibilidad. Funciona junto a otros servidores MCP. Pase datos de churn de Metabase o tendencias de tráfico de Google Analytics a
generate_product_planmediantekpi_context, y la metodología ajusta las prioridades en consecuencia. - Metodología PM integrada. Puntuación basada en opinión, construida sobre 7 años de gestión de productos en 9 productos y más de 1M de usuarios. Es un proceso real de toma de decisiones expuesto como recurso MCP, no un marco genérico.
- Eliminación de PII. Los datos del cliente nunca llegan al LLM sin filtrar. Los números de seguro social, tarjetas de crédito (validadas por Luhn), correos electrónicos y números de teléfono se redactan antes del análisis. Las respuestas del agente se filtran de las citas.
Arquitectura
graph TD
A[Claude Desktop / Code] -->|stdio| B[pm-copilot]
A -->|stdio| C[Metabase MCP]
A -->|stdio| D[Google Analytics MCP]
B -->|Reactive| E[HelpScout: tickets]
B -->|Proactive| F[ProductLift: feature requests]
B -->|Deflected| I[Chatbase: AI agent chats]
C -->|Quantitative| G[Conversion, Churn, Revenue]
D -->|Acquisition| H[Traffic, Channels, Trends]
B -.->|kpi_context| A
Claude orquesta múltiples servidores MCP. PM Copilot maneja las señales cualitativas del cliente. Otros servidores proporcionan métricas comerciales cuantitativas. El parámetro kpi_context es el punto de integración — no se requieren integraciones punto a punto.
Inicio Rápido
git clone https://github.com/dkships/pm-copilot.git
cd pm-copilot
npm install
cp .env.example .env # Edit with your credentials
npm run build
Credenciales
HelpScout es obligatorio. ProductLift y Chatbase son opcionales — configure uno, ambos o ninguno, y el análisis se adapta.
| Variable | Obligatorio | Descripción |
|---|---|---|
HELPSCOUT_APP_ID | Sí | ID de aplicación OAuth de https://secure.helpscout.net/apps/custom/ |
HELPSCOUT_APP_SECRET | Sí | Secreto de aplicación OAuth |
PRODUCTLIFT_PORTALS | No | Multi-portal: name|url|key,name2|url2|key2 |
PRODUCTLIFT_PORTAL_URL | No | URL de portal único |
PRODUCTLIFT_API_KEY | No | Token Bearer de portal único |
PRODUCTLIFT_PORTAL_NAME | No | Nombre mostrado del portal (predeterminado: default) |
CHATBASE_API_KEY | No | Clave secreta a nivel de cuenta de Chatbase → Configuración → Claves API |
CHATBASE_AGENTS | No | Multi-agente: name|agentId,name2|agentId2 |
CHATBASE_AGENT_ID | No | ID de agente único |
CHATBASE_AGENT_NAME | No | Nombre mostrado del agente único (predeterminado: default) |
El acceso a la API de Chatbase requiere un plan Chatbase Standard o superior. En un plan inferior, la API devuelve 403 y la señal de desviación se reporta como una advertencia en lugar de fallar todo el análisis. Un agente por producto es la forma útil — los agentes le dan atribución a nivel de producto que un buzón de soporte compartido no tiene.
Claude Desktop
Agregue a ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"pm-copilot": {
"command": "node",
"args": ["/absolute/path/to/pm-copilot/dist/index.js"]
}
}
}
Claude Code
claude mcp add pm-copilot -- node /absolute/path/to/pm-copilot/dist/index.js
O use el .mcp.json ya en la raíz del proyecto — Claude Code lo recoge automáticamente.
Herramientas
synthesize_feedback
Cruza referencias de tickets de HelpScout, solicitudes de funciones de ProductLift y conversaciones de Chatbase, y devuelve análisis con temas coincidentes y puntuaciones de prioridad.
| Parámetro | Tipo | Predeterminado | Descripción |
|---|---|---|---|
timeframe_days | número | 30 | Días a mirar hacia atrás (1-90) |
top_voted_limit | número | 50 | Solicitudes más votadas por portal; las solicitudes recientes en el período de tiempo siempre se incluyen al inicio |
mailbox_id | string | — | Filtro de buzón de HelpScout (ID crudo) |
mailbox_name | string | — | Nombre del buzón de HelpScout (insensible a mayúsculas); se resuelve automáticamente a un ID. Ejecute list_sources para ver nombres |
portal_name | string | — | Filtro de portal de ProductLift |
agent_name | string | — | Filtro de agente de Chatbase. Ejecute list_sources para ver nombres |
source_filter | string | — | Filtro de fuente de conversación de Chatbase, separado por comas para múltiples, ej. Widget or Iframe o WhatsApp,API. Insensible a mayúsculas. Ejecute list_sources para los valores válidos |
detail_level | string | "summary" | "summary", "standard", o "full". El tamaño de salida escala con el volumen de datos — aproximadamente 20KB / 100KB / 600KB |
Devuelve temas ordenados por puntuación de prioridad, cada uno con recuentos reactivo/proactivo, indicador de convergencia, resúmenes de evidencia y citas representativas de clientes.
generate_product_plan
Construye un plan de producto priorizado con evidencia y citas de clientes. Acepta métricas comerciales externas mediante kpi_context.
| Parámetro | Tipo | Predeterminado | Descripción |
|---|---|---|---|
timeframe_days | número | 30 | Días a mirar hacia atrás (1-90) |
top_voted_limit | número | 50 | Solicitudes más votadas por portal; las solicitudes recientes en el período de tiempo siempre se incluyen al inicio |
mailbox_id | string | — | Filtro de buzón de HelpScout (ID crudo) |
mailbox_name | string | — | Nombre del buzón de HelpScout (insensible a mayúsculas); se resuelve automáticamente a un ID. Ejecute list_sources para ver nombres |
portal_name | string | — | Filtro de portal de ProductLift |
agent_name | string | — | Filtro de agente de Chatbase. Ejecute list_sources para ver nombres |
source_filter | string | — | Filtro de fuente de conversación de Chatbase, separado por comas para múltiples, ej. Widget or Iframe o WhatsApp,API. Insensible a mayúsculas. Ejecute list_sources para los valores válidos |
kpi_context | string | — | Métricas comerciales de otros servidores MCP |
max_priorities | número | 5 | Número de prioridades a devolver (1-10) |
preview_only | boolean | false | Modo auditoría: mostrar qué datos se enviarían |
detail_level | string | "summary" | "summary", "standard", o "full". El tamaño de salida escala con el volumen de datos — para un buzón de 30 días, aproximadamente 5KB / 21KB / 375KB |
format | string | "json" | "json" (estructurado, componible) o "markdown" (informe de producto listo para leer) |
get_feature_requests
Acceso a datos crudos de ProductLift para explorar solicitudes de funciones directamente. Cada solicitud incluye su url público.
| Parámetro | Tipo | Predeterminado | Descripción |
|---|---|---|---|
portal_name | string | — | Filtrar a un portal específico |
include_comments | boolean | true | Incluir comentarios en cada solicitud |
status | string | — | Filtrar a solicitudes con este estado (insensible a mayúsculas), ej. open, planned, completed |
list_sources
Lista las fuentes de datos a las que el servidor está conectado — buzones de HelpScout (id + nombre),
portales de ProductLift (nombre + url) y agentes de Chatbase (nombre + id) — para que pueda descubrir los
nombres para pasar a mailbox_name / portal_name / agent_name. Cuando Chatbase está configurado,
también devuelve chatbase_conversation_sources, los valores que source_filter acepta (una lista fija
de la documentación de Chatbase, no consultada por cuenta). Solo lectura; nunca devuelve claves API o datos
de clientes. No toma parámetros.
Clases de señales
Tres fuentes, tres cosas diferentes que le dicen. Solo las primeras dos alimentan la regla de convergencia.
| Clase | Fuente | Qué significa | Alimenta |
|---|---|---|---|
| Reactiva | Tickets de HelpScout | Algo está roto | Frecuencia, severidad, convergencia |
| Proactiva | Solicitudes de ProductLift | Algo se desea | Frecuencia, impulso de votos, convergencia |
| Desviada | Conversaciones de Chatbase | Algo fue preguntado, y el autoservicio lo manejó o no | Solo frecuencia |
Las señales desviadas cuentan para la frecuencia y llevan dos campos de evidencia por tema, pero no entran en los términos de severidad o impulso de votos y no cambian el impulso de convergencia 2x. La fórmula no cambia desde v2.1:
deflected_count— conversaciones que coinciden con el temaself_serve_failure_rate— proporción de esas conversaciones donde la confianza más baja de respuesta del agente estuvo por debajo de 0.5mean_answer_confidence— media de esa misma puntuación
Un tema con alto deflected_count y un alto self_serve_failure_rate es uno que los clientes siguen
preguntando y que el autoservicio no resuelve. Chatbase no documenta qué mide su campo min_score,
por lo que se reporta como evidencia para que el LLM la pese en lugar de integrarse en la
puntuación de prioridad.
Las conversaciones llegan de varios canales (widget, WhatsApp, Messenger, API, …). El análisis
informa un recuento chatbase_sources por canal, y el parámetro source_filter limita una ejecución
a uno o más canales (separados por comas) — el filtro se aplica en el lado del servidor por Chatbase. Una
advertencia: los recuentos pueden incluir canales que el filtro no cubre, como Playground o
unknown (Chatbase omitió la fuente). Un valor de filtro fuera de la lista conocida se pasa
con una advertencia en lugar de rechazarse, ya que cero coincidencias usualmente significa que el valor es
incorrecto, no que el canal se silenció.
Chatbase es opcional. Sin CHATBASE_API_KEY configurado, los campos de desviación simplemente están ausentes
y el análisis se comporta exactamente como antes.
Salida de ejemplo
Una respuesta synthesize_feedback recortada en el nivel de detalle summary predeterminado. Los valores son ilustrativos; note la eliminación de PII aplicada a la cita del cliente.
{
"timeframe_days": 30,
"detail_level": "summary",
"portal_name": "all",
"fetched_at": "2026-06-01T16:00:00.000Z",
"pii_scrubbing_applied": true,
"pii_categories_redacted": ["email", "phone", "credit_card"],
"analysis": {
"total_data_points": 612,
"reactive_count": 548,
"proactive_count": 64,
"deflected_count": 312,
"chatbase_sources": {
"Widget or Iframe": 284,
"WhatsApp": 23,
"API": 5
},
"themes": [
{
"theme_id": "booking-scheduling",
"label": "Booking & Scheduling",
"category": "core",
"priority_score": 87.1,
"convergent": true,
"signal_type": "convergent",
"reactive_count": 211,
"proactive_count": 19,
"deflected_count": 96,
"self_serve_failure_rate": 0.48,
"mean_answer_confidence": 0.53,
"evidence_summary": "326 signals (211 support tickets, 19 feature requests, 96 AI chat conversations). Convergent — appears in both support and feature requests (2x priority boost). The AI agent answered with low confidence in 48% of those chats — customers ask about this and self-serve often does not resolve it.",
"representative_quotes": [
"[Support ticket] \"Double-booked slots again after the timezone change — reach me at [EMAIL REDACTED]\"",
"[Feature request, 47 votes] \"Let me block buffer time between meetings\"",
"[AI chat, answer confidence 0.31] \"how do i stop people booking on weekends\""
]
},
{
"theme_id": "list-management",
"label": "List & Contact Management",
"category": "audience",
"priority_score": 41.7,
"convergent": false,
"signal_type": "deflected",
"reactive_count": 0,
"proactive_count": 0,
"deflected_count": 58,
"self_serve_failure_rate": 0.58,
"mean_answer_confidence": 0.5,
"evidence_summary": "58 signals (58 AI chat conversations). The AI agent answered with low confidence in 58% of those chats — customers ask about this and self-serve often does not resolve it.",
"representative_quotes": [
"[AI chat, answer confidence 0.22] \"how many contacts does pro allow\""
]
}
],
"emerging_themes": [
{ "pattern": "csv export", "frequency": 12 }
],
"unmatched_count": 38
}
}
Componibilidad en Acción
PM Copilot está diseñado para trabajar junto a otros servidores MCP. Aquí hay un ejemplo práctico que muestra cómo una anulación kpi_context cambia la clasificación. Los números son ilustrativos.
Paso 1: El PM hace una sola pregunta
Extraiga nuestros datos de churn y finalización de reservas, luego use pm-copilot para crear un plan de producto usando todo ese contexto.
Paso 2: pm-copilot analiza las señales y devuelve las prioridades principales
| # | Tema | Puntuación | Tickets | Solicitudes de funciones | Chats | Falla de autoservicio | Señal |
|---|---|---|---|---|---|---|---|
| 1 | Facturación y Pagos | 91.1 | 2,336 | 20 | 240 | 55% | Convergente |
| 2 | Reservas y Programación | 87.1 | 682 | 74 | 310 | 45% | Convergente |
| 3 | Cuenta y Licencias | 69.7 | 1,955 | 8 | 180 | 38% | Convergente |
| 4 | Equipo y Colaboración | 64.4 | 1,875 | 19 | 60 | 50% | Convergente |
| 5 | Marca Blanca y Marca | 50.2 | 92 | 30 | 95 | 42% | Convergente |
Paso 3: Métricas comerciales de paneles llegan como kpi_context
Product A: booking completion rate dropped from 74% to 66% over last
30 days. Monthly churn increased from 3.1% to 4.2%. Organic traffic
up 22% MoM. Product B: document completion rate steady at 81%.
Churn flat at 2.8%.
Paso 4: Claude sintetiza ambos y anula la fórmula
Las puntuaciones dicen que Facturación y Pagos es #1. Pero la metodología dice que los datos de churn anulan la fórmula. Con la finalización de reservas del Producto A cayendo 8 puntos y el churn disparándose un 35%, Reservas y Programación se convierte en el verdadero #1 — es el producto principal rompiéndose.
El Producto B se desprioriza (métricas estables, sin fuego). El crecimiento orgánico del 22% del tráfico del Producto A eleva Marca Blanca y Marca como una jugada de crecimiento.
El servidor proporciona la clasificación de señales. El contexto de KPI proporciona el juicio de anulación. Claude sintetiza ambos.
Metodología
PM Copilot expone un recurso pm-copilot://methodology — el marco de planificación de productos de David Kelly, construido a lo largo de 7 años lanzando 9 productos a más de 1M de usuarios.
Principios clave:
- La regla del 5%. Completas alrededor del 5% de lo que los clientes piden cada mes. El marco identifica qué 5% importa más.
- Las señales convergentes siempre ganan. El mismo tema en tickets de soporte y solicitudes de funciones es la señal de mayor confianza.
- Reactivo > proactivo. Lo que está roto impulsa la deserción. Puedes sobrevivir sin tener una función; no puedes sobrevivir a errores.
- Las métricas de negocio anulan la fórmula. El aumento de la deserción, la caída de la conversión o el impacto en los ingresos pueden cambiarlo todo.
La metodología está versionada (v2.1) y se sirve como contenido markdown a través del protocolo de recursos MCP. Cada respuesta de generate_product_plan enlaza a ella (methodology_resource) y, cuando se proporciona kpi_context, instruye a Claude para aplicarla — si realmente se lee depende de que el cliente MCP exponga los recursos.
Evaluación
La fórmula de puntuación solo importa si la coincidencia de temas subyacente es correcta. npm run eval mide eso.
Por qué coincidencia por palabras clave
Los temas se emparejan con listas de palabras clave — palabras clave de varias palabras como subcadenas, palabras individuales en un límite de palabra con un sufijo plural regular opcional — no con embeddings ni un clasificador LLM. Es una compensación deliberada:
- El texto del cliente nunca sale del servidor hacia una API de embeddings o clasificación de terceros. Las garantías de PII a continuación solo se mantienen porque nada en la ruta de coincidencia hace una llamada de red.
- La misma entrada siempre produce los mismos temas, por lo que una clasificación de prioridad puede auditarse y explicarse. Un clasificador LLM reorganizaría las clasificaciones entre ejecuciones.
- Sin costo de tokens ni latencia por punto de datos, lo que permite que un análisis de 2,000 señales termine en menos de un minuto.
El costo es el recuerdo. Las listas de palabras clave pierden paráfrasis, y las pierden de manera desigual entre productos. En datos de chat en vivo retenidos, un tercio de las conversaciones aún no coincide con ningún tema. Eso es lo que la evaluación existe para cuantificar, y por qué el número se publica en lugar de ocultarse.
Ejecutarlo
npm run build && npm run eval
npm run eval -- --failures # every miss and false positive
npm run eval -- --json # machine-readable report
npm run eval -- --min-f1 0.90 # non-zero exit below threshold, for CI
La coincidencia es de múltiples etiquetas — una señal puede pertenecer a varios temas — por lo que el informe da precisión, recuerdo y F1 por tema, más dos tasas que importan más que los promedios: miss rate (se esperaba un tema, no coincidió con nada) y false alarm rate (no se esperaba nada, coincidió con algo).
Qué encontró la primera ejecución
El primer trabajo de la evaluación fue auditar la configuración v2, y encontró cinco defectos reales:
- La cobertura de plurales era inconsistente.
tierse listaba sintiers, y las palabras clave individuales coincidían en un límite de palabra simple, por lo que "los niveles" no coincidía con nada. En datos de chat en vivo, este era el costoso — un aviso recurrente de widget, "¿cuáles son sus planes y precios?", no coincidía con ningún tema, porqueplanpierde "planes" ypricingpierde "precios". teamse activaba con "equipo fundador" y "equipo de TI" — la mitad de los falsos positivos en el fixture.planetiquetaba "planeo lanzar la próxima semana" como Cuenta y Licencias.upgradeestaba tanto en Facturación y Pago como en Cuenta y Licencias, por lo que un ticket de API que mencionaba una actualización aterrizaba en ambos.- Las palabras clave de varias palabras son subcadenas exactas, por lo que
cant loginperdía "no puedo iniciar sesión" youtlook calendarperdía "¿esto funciona con outlook?".
Los cinco están corregidos en v3: las palabras clave individuales ahora coinciden con un sufijo plural regular opcional, las palabras clave demasiado genéricas se acotaron (team → my team / team member / teams), las palabras clave duplicadas se asignaron a un solo tema, y se agregaron las variantes faltantes. Dos nuevos temas surgieron de conversaciones reales sin coincidencia — Sorteos y Concursos y Gestión de Listas y Contactos — para los cuales la configuración no tenía vocabulario en absoluto.
Línea base
Dos números, porque miden cosas diferentes.
Contra el fixture confirmado (82 ejemplos etiquetados a mano):
| config | precisión | recuerdo | F1 | tasa de fallos |
|---|---|---|---|---|
| v2 | 88.7% | 68.8% | 77.5% | 25.0% |
| v3 | 95.8% | 96.8% | 96.3% | 2.6% |
Trátalo con sospecha. La configuración se iteró contra este fixture, por lo que la cifra de v3 es dentro de la muestra y se halaga a sí misma. Es una puerta de regresión — te dice que un cambio rompió algo, no qué tan bien funciona la coincidencia.
El número que significa algo son datos reales retenidos. 1,100 conversaciones de chat en cuatro productos, de una ventana de 30 días antes de la de la que se derivaron los nuevos temas:
| producto | conversaciones | v2 sin coincidencia | v3 sin coincidencia | cambio |
|---|---|---|---|---|
| Producto A | 435 | 20.5% | 19.3% | −1.1pp |
| Producto B | 464 | 58.4% | 48.5% | −9.9pp |
| Producto C | 135 | 25.9% | 23.7% | −2.2pp |
| Producto D | 66 | 66.7% | 34.8% | −31.8pp |
| todos | 1,100 | 39.9% | 33.1% | −6.8pp |
Las ganancias llegan donde la teoría decía: los productos cuyo vocabulario la configuración nunca cubrió. Un tercio de las conversaciones aún no coincide con nada, así que queda mucho por hacer.
El registro resultó importar menos que la cobertura del producto. El chat del Producto A está mejor emparejado que los tickets, por lo que la redacción del chat por sí sola no es el problema — el vocabulario faltante del producto lo es, y los agentes de chat por producto exponen eso donde un buzón de soporte compartido lo promedia.
Limitaciones conocidas
- Los avisos de widget predefinidos inflan los conteos. Botones preestablecidos como "Entré en un sorteo — ¿cómo sé si gané?" se repiten textualmente docenas de veces. No se deduplican, y eso es deliberado: veinte personas haciendo clic en un preestablecido son veinte personas con esa pregunta. Significa que el volumen de un tema con un preestablecido popular no es comparable al de uno sin él.
- La coincidencia es solo en inglés. Los datos en vivo incluyen conversaciones en alemán, español e italiano, y todas aterrizan en
unmatched. - Los plurales irregulares aún necesitan listarse. La regla de sufijos cubre
plan/plans, noentry/entries.
Para un número de tus propios datos, exporta señales a un JSONL local con la forma del fixture y pasa --fixture ./local/real.jsonl. Los fixtures reales contienen texto de clientes — mantenlos fuera de git.
Seguridad
Los datos de los clientes fluyen a través de PM Copilot en su camino hacia Claude. Todo el texto se limpia antes de entrar en el pipeline de análisis o salir del servidor.
Limpieza de PII
| Categoría | Método | Reemplazo |
|---|---|---|
| SSN | Coincidencia de patrón (XXX-XX-XXXX) | [SSN REDACTED] |
| Tarjetas de crédito | Secuencias de 13-19 dígitos + validación Luhn | [CC REDACTED] |
| Direcciones de correo electrónico | Patrón de correo estándar | [EMAIL REDACTED] |
| Números de teléfono | Formatos de EE. UU. (+1, paréntesis, guiones, puntos) | [PHONE REDACTED] |
| Campo de correo del cliente | Siempre redactado | [REDACTED] |
Lo que excluimos por completo
| Datos | Por qué |
|---|---|
| Respuestas de agentes/administradores | Solo importa la voz del cliente; las respuestas de agentes podrían filtrar procesos internos |
| Notas internas de HelpScout | Pueden contener credenciales, soluciones alternativas, discusiones internas |
| Adjuntos | Podrían contener capturas de pantalla con PII, facturas, documentos médicos |
| Identidades de votantes | Los conteos de votos son suficientes; la identidad individual no agrega valor de PM |
| Nombres de comentaristas | El rol (admin vs cliente) es todo lo que el análisis necesita |
| Turnos de asistente de Chatbase | Solo se analizan las propias palabras del cliente |
| Envíos de formularios de leads de Chatbase | Capturan nombres, correos y números de teléfono, y no tienen valor de PM |
| Identificadores de usuario final de Chatbase | userId reduce la identidad entre conversaciones |
| País por conversación de Chatbase | La geografía no agrega nada al análisis de temas y reduce la identidad |
Nota sobre el chat como fuente de datos
Un widget de chat acepta texto libre ilimitado, por lo que es la superficie de PII más amplia de las tres fuentes — las personas pegan números de pedido, direcciones y claves de licencia en una caja de chat de una manera que no hacen en una publicación de hoja de ruta. Esto no es hipotético: en una ejecución en vivo de 30 días, agregar la fuente de Chatbase fue lo que primero hizo que credit_card apareciera en pii_categories_redacted. Los tickets y publicaciones de hoja de ruta en la misma ventana produjeron solo correos y números de teléfono.
Dos cosas lo mantienen contenido: solo se leen los turnos de role: "user", y cada turno pasa por el mismo limpiador que las otras fuentes antes de entrar en el análisis.
La atribución de mensajes de Chatbase es estructurada, lo que la convierte en la fuente de voz del cliente más limpia de las tres. La ruta de HelpScout tiene que adivinar el texto del agente con heurísticas de frases porque una vista previa de conversación puede ser de cualquier lado del intercambio; aquí role lo dice directamente, por lo que se omiten las heurísticas.
Controles de auditoría
preview_only: trueengenerate_product_planmuestra qué datos se enviarían sin obtenerlos- Cada respuesta incluye metadatos de
pii_scrubbing_appliedypii_categories_redacted - Las categorías de datos se registran en stderr en cada llamada (solo categorías, nunca contenido)
Desarrollo
npm install # Install dependencies
npm run build # Compile TypeScript
npm run dev # Watch mode
npm start # Run the server
npm test # Run the test suite
npm run eval # Theme-matching eval (see Evaluation)
Pruebas locales
Llama a una herramienta de forma aislada sin reiniciar tu cliente MCP — útil para iterar sobre cambios y para verificar tamaños de respuesta:
npm run build
npm run tool -- --list
npm run tool -- list_sources '{}'
npm run tool -- get_feature_requests '{"portal_name":"<your-portal>","status":"open"}'
El ejecutor imprime el tamaño en bytes de cada respuesta. La salida puede incluir tus nombres/URLs de fuentes configuradas (y texto de cliente con PII limpiada) — redacta antes de compartir.
Configuración de temas
themes.config.json en la raíz del proyecto define qué temas buscar. Edita sin reconstruir — se carga en tiempo de ejecución.
Incluye 18 temas basados en datos en 12 categorías. Agrega los tuyos añadiendo al array de themes. Los puntos de datos sin coincidencia se analizan para patrones emergentes usando detección de frecuencia de bigramas/trigramas.
Después de editar, ejecuta npm run eval — informa precisión y recuerdo por tema y marca palabras clave que se activan en ejemplos de otro tema, que es como se detectan las demasiado genéricas.
Fórmula de puntuación
priority = (frequency × 0.35 + severity × 0.35 + vote_momentum × 0.30) × convergence_boost
- Frecuencia (0.35): Conteo de puntos de datos, normalizado entre temas — incluye señales desviadas
- Severidad (0.35): Solo señales reactivas — conteo de hilos (total, incluyendo respuestas de agentes), recencia (decaimiento de vida media de 7 días), aumentos de etiquetas
- Impulso de votos (0.30): Solo señales proactivas — 80% votos + 20% comentarios
- Convergencia (2x): Se aplica cuando un tema tiene tanto señales reactivas como proactivas. Las señales desviadas no lo activan
La frecuencia y el impulso de votos se normalizan contra el tema principal en la misma llamada, por lo que las puntuaciones son relativas a una ventana de análisis. Compara clasificaciones entre llamadas, no puntuaciones brutas.
Solución de problemas
- Los cambios no surten efecto. El cliente MCP ejecuta el
dist/compilado. Después de editar el código fuente, ejecutanpm run buildy reinicia el cliente (o la conexión del servidor MCP) para recoger el nuevo código. No HelpScout mailbox named "…". Ejecutalist_sourcespara ver los nombres exactos de los buzones, o pasa elmailbox_idnumérico directamente.No portal found with name "…"/ portal faltante. El portal debe configurarse enPRODUCTLIFT_PORTALS(o las variables de entorno de portal único). Ejecutalist_sourcespara ver los portales configurados.- Advertencia de Chatbase:
A Standard plan or higher is required. El acceso a la API comienza en el plan Standard de Chatbase. El resto del análisis aún se ejecuta; solo faltan los campos de desviación. chatbase_agentsestá vacío enlist_sources. TantoCHATBASE_API_KEYcomo una deCHATBASE_AGENTS/CHATBASE_AGENT_IDdeben estar configurados — una clave por sí sola no configura nada.
Contribuir
- Haz un fork del repositorio
- Crea una rama de características (
git checkout -b feature/your-feature) - Asegúrate de que
npm run buildse ejecute sin errores - Sigue los patrones existentes: las herramientas usan
registerTool, los clientes de API obtienen su propio módulo, la limpieza de PII ocurre en la capa de formato - Abre una solicitud de extracción