claimcheck

claimcheck

Dos formas silenciosas en las que el trabajo de código abierto muere, detectadas antes de que te cuesten semanas:

1. Reclamaciones obsoletas. Alguien comenta "me encargo de esto" en un issue y luego desaparece. El issue sigue mostrando "sin asignar", así que el siguiente voluntario escribe código que choca con un fantasma.
2. Correcciones estacionadas. Trabajo terminado en una rama de un fork que nunca se convirtió en PR. Commits reales, diffs reales, visibilidad cero.

claimcheck escanea ambas. Es el complemento de greenlight: greenlight pregunta "¿se puede aterrizar este issue?", claimcheck pregunta "¿todos los que dijeron que sí realmente aparecieron, y su trabajo llegó a publicarse?"

Instalación

npm install -g claimcheck
# or
npx claimcheck claims owner/repo

Requiere Node 20+. Configura GITHUB_TOKEN (o GH_TOKEN) para el límite de 5000 req/h autenticado; sin ello obtienes 60 req/h. Las respuestas se cachean en ~/.cache/claimcheck.

CLI

Encontrar reclamaciones obsoletas en un repositorio

claimcheck claims modelcontextprotocol/python-sdk

Escanea issues abiertos sin asignar, detecta comentarios de reclamación (reclamaciones explícitas, intenciones de trabajo, solicitudes de asignación; bots, mantenedores y el autor del issue quedan excluidos), verifica si apareció algún PR vinculado y clasifica los resultados con las reclamaciones más antiguas primero:

Stale claims in modelcontextprotocol/python-sdk: 2 stale of 5 claimed issues (threshold 45d)

[STALE] modelcontextprotocol/python-sdk#3287
  Fix: handle empty result sets
  https://github.com/modelcontextprotocol/python-sdk/issues/3287
  claimant: helpfuldev, 63d ago (want-to-work)

[IN FLIGHT] modelcontextprotocol/python-sdk#3290
  ...
  claimant: shipitdev, 5d ago (explicit-claim)

Banderas: --days 45 cambia el umbral de obsoleto, --json imprime salida de máquina.

Cubos de antigüedad de reclamaciones

Cubo	Antigüedad	Significado
FRESH	<14 días	El reclamante probablemente sigue activo
WATCH	14 a 44 días	Verificar antes de duplicar trabajo
STALE	45 a 89 días	Discutible, probablemente abandonado
DEAD	90+ días	Casi con certeza abandonado
WORK_IN_FLIGHT	cualquier	Existe un PR vinculado, el trabajo es real

Encontrar correcciones estacionadas en un fork

claimcheck parked CloudCorpRecords/pdfcn

Lista ramas en un fork (excluyendo la rama predeterminada), compara cada una contra la rama predeterminada del upstream y verifica si hay PRs abiertos desde ese fork. Una rama adelantada por 1+ commits sin PR abierto es PARKED:

Parked branches on CloudCorpRecords/pdfcn (upstream shadcn-labs/pdfcn): 1 parked of 4 branches

[PARKED_STALE] fix-typos
  ahead by 5 commit(s), last commit 20d ago
  no open PR on upstream

Cubos de antigüedad de estacionadas (desde la fecha del commit de la punta de la rama)

Veredicto	Antigüedad	Significado
PARKED_RECENT	<7 días	Probablemente aún se está terminando
PARKED_STALE	7 a 30 días	Probablemente olvidada, fácil de revivir
PARKED_DEAD	30+ días	Puede necesitar rebase sobre upstream

Las ramas con un PR abierto se muestran como IN_PR, las ramas al nivel del upstream como EVEN. Ninguna está estacionada.

Estado de reclamación de un issue

claimcheck issue https://github.com/modelcontextprotocol/python-sdk/issues/3287

Cada reclamante encontrado en los comentarios, su cubo de antigüedad y si existe un PR vinculado.

Servidor MCP

Los mismos motores como herramientas, para agentes que deberían verificar antes de comentar o codificar:

{
  "mcpServers": {
    "claimcheck": {
      "command": "npx",
      "args": ["-y", "claimcheck", "mcp"],
      "env": { "GITHUB_TOKEN": "ghp_your_token_here" }
    }
  }
}

Herramienta	Entrada	Devuelve
stale_claims	repo (owner/repo), stale_days opcional	Reclamaciones obsoletas clasificadas, las más antiguas primero
parked_branches	fork (owner/repo)	Ramas estacionadas con datos de comparación, más todas las ramas
issue_claim_status	url (URL del issue)	Reclamantes, cubos de antigüedad, PRs vinculados, resumen

O ejecuta el servidor directamente: npx claimcheck mcp (stdio).

Cómo funciona la detección

Heurísticas de reclamación (reimplementación limpia de los patrones probados en el dogfooding de greenlight):

• Reclamaciones fuertes: "me gustaría encargarme de esto", "por favor asígnamelo", "estoy trabajando en esto", "he empezado a trabajar en esto", "PR en camino" y similares.
• Interés suave: "encantado de ayudar", "interesado en esto", "investigando esto". Se registra, nunca se trata como reclamación.
• Excluidos: cuentas de bots, mantenedores del repositorio (su "me encargo de esto" es triaje, no una reclamación discutible) y el autor del issue a menos que anuncie un PR real.

Una reclamación con cualquier PR vinculado es WORK_IN_FLIGHT a cualquier antigüedad: el reclamante hizo el trabajo, solo que aún no ha aterrizado. Solo las reclamaciones sin PR envejecen a STALE y DEAD.

Desarrollo

npm install
npm test        # 23 offline tests, node:test via tsx
npm run build   # tsc to dist/

Los motores (src/claims.ts, src/parked.ts) son funciones puras sobre datos obtenidos, totalmente probables sin conexión contra fixtures en test/fixtures/. src/github.ts contiene el cliente REST (issues, comentarios, búsqueda de PRs, ramas, comparación, información del fork) con caché de archivos.

Licencia

MIT, Rene Turcios 2026.