MCP HubMCP Hub
Retour aux compétences

submit-to-cran

pjt222
Mis à jour 2 days ago
4 vues
17
2
17
Voir sur GitHub
Métadesign

À propos

Cette compétence offre un flux de travail complet pour soumettre des packages R au CRAN, gérant à la fois les soumissions initiales et les mises à jour. Elle automatise les vérifications préalables (localement, win-builder, R-hub), prépare le fichier requis `cran-comments.md` et gère le processus de soumission final. Utilisez-la lorsque votre package R est prêt pour sa première publication sur le CRAN, pour soumettre des versions mises à jour, ou pour resoumettre suite aux retours des relecteurs.

Installation rapide

Claude Code

Recommandé
Principal
npx skills add pjt222/agent-almanac -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternatif
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/submit-to-cran

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation


name: submit-to-cran description: > Procedimiento completo para enviar un paquete R a CRAN, incluyendo verificaciones previas al envío (local, win-builder, R-hub), preparación de cran-comments.md, comprobación de URLs y ortografía, y el envío en sí. Cubre primeros envíos y actualizaciones. Usar cuando un paquete está listo para su publicación inicial en CRAN, al enviar una versión actualizada de un paquete ya en CRAN, o al reenviar tras recibir comentarios del revisor de CRAN. locale: es source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: r-packages complexity: advanced language: R tags: r, cran, submission, release, publishing

Enviar a CRAN

Ejecutar el flujo completo de envío a CRAN desde las verificaciones previas hasta la presentación.

Cuándo Usar

  • El paquete está listo para su publicación inicial en CRAN
  • Se envía una versión actualizada de un paquete ya publicado en CRAN
  • Se reenvía tras recibir comentarios del revisor de CRAN

Entradas

  • Obligatorio: Paquete R que pasa R CMD check local con 0 errores y 0 advertencias
  • Obligatorio: Número de versión actualizado en DESCRIPTION
  • Obligatorio: NEWS.md actualizado con los cambios de esta versión
  • Opcional: Comentarios previos del revisor de CRAN (para reenvíos)

Procedimiento

Paso 1: Verificación de Versión y NEWS

Verificar que DESCRIPTION tiene la versión correcta:

desc::desc_get_version()

Verificar que NEWS.md tiene una entrada para esta versión. La entrada debe resumir los cambios visibles para el usuario.

Esperado: La versión sigue el versionado semántico. NEWS.md tiene una entrada correspondiente para esta versión.

En caso de fallo: Actualizar la versión con usethis::use_version() (elegir "major", "minor" o "patch"). Añadir una entrada en NEWS.md resumiendo los cambios visibles para el usuario.

Paso 2: Verificación Local de R CMD Check

devtools::check()

Esperado: 0 errores, 0 advertencias, 0 notas (1 nota aceptable en primeros envíos: "New submission").

En caso de fallo: Corregir todos los errores y advertencias antes de continuar. Leer el registro en <pkg>.Rcheck/00check.log para más detalles. Las notas deben explicarse en cran-comments.md.

Paso 3: Verificación Ortográfica

devtools::spell_check()

Añadir palabras legítimas a inst/WORDLIST (una palabra por línea, ordenadas alfabéticamente).

Esperado: Sin errores ortográficos inesperados. Todas las palabras marcadas se corrigen o se añaden a inst/WORDLIST.

En caso de fallo: Corregir los errores ortográficos genuinos. Para términos técnicos legítimos, añadirlos a inst/WORDLIST (una palabra por línea, ordenadas alfabéticamente).

Paso 4: Verificación de URLs

urlchecker::url_check()

Esperado: Todas las URLs devuelven HTTP 200. Sin enlaces rotos ni redirigidos.

En caso de fallo: Reemplazar las URLs rotas. Usar \doi{} para enlaces DOI en lugar de URLs directas. Eliminar enlaces a recursos que ya no existen.

Paso 5: Verificaciones en Win-Builder

devtools::check_win_devel()
devtools::check_win_release()

Esperar los resultados por correo electrónico (generalmente 15-30 minutos).

Esperado: 0 errores, 0 advertencias en Win-builder release y devel. Los resultados llegan por correo en 15-30 minutos.

En caso de fallo: Resolver los problemas específicos de la plataforma. Causas frecuentes: advertencias de compilador distintas, dependencias de sistema faltantes, diferencias en separadores de ruta. Corregir localmente y reenviar a Win-builder.

Paso 6: Verificación en R-hub

rhub::rhub_check()

Esto verifica en múltiples plataformas (Ubuntu, Windows, macOS).

Esperado: Todas las plataformas pasan con 0 errores y 0 advertencias.

En caso de fallo: Si una plataforma específica falla, revisar el registro de compilación de R-hub para errores específicos de esa plataforma. Usar testthat::skip_on_os() o código condicional para comportamientos dependientes de la plataforma.

Paso 7: Preparar cran-comments.md

Crear o actualizar cran-comments.md en la raíz del paquete:

## R CMD check results
0 errors | 0 warnings | 1 note

* This is a new release.

## Test environments
* local: Windows 11, R 4.5.0
* win-builder: R-release, R-devel
* R-hub: ubuntu-latest (R-release), windows-latest (R-release), macos-latest (R-release)

## Downstream dependencies
There are currently no downstream dependencies for this package.

Para actualizaciones, incluir:

  • Qué cambió (brevemente)
  • Respuesta a comentarios previos del revisor
  • Resultados de la verificación de dependencias inversas si corresponde

Esperado: cran-comments.md resume con precisión los resultados de verificación en todos los entornos de prueba y explica cualquier nota.

En caso de fallo: Si los resultados difieren entre plataformas, documentar todas las variaciones. Los revisores de CRAN cotejarán estas declaraciones con sus propias pruebas.

Paso 8: Verificación Final Previa al Envío

# Una última verificación
devtools::check()

# Verificar el tarball compilado
devtools::build()

Esperado: El devtools::check() final pasa sin problemas. Se genera un tarball .tar.gz en el directorio padre.

En caso de fallo: Si aparece un problema de última hora, corregirlo y repetir todas las verificaciones desde el Paso 2. No enviar con fallos conocidos.

Paso 9: Envío

devtools::release()

Esto ejecuta verificaciones interactivas y envía. Responder todas las preguntas con honestidad.

Alternativamente, enviar manualmente en https://cran.r-project.org/submit.html subiendo el tarball.

Esperado: El correo de confirmación de CRAN llega en minutos. Hacer clic en el enlace de confirmación para finalizar el envío.

En caso de fallo: Revisar el correo para los motivos del rechazo. Problemas comunes: ejemplos demasiado lentos, etiquetas \value faltantes, código no portable. Corregir los problemas y reenviar, indicando en cran-comments.md qué cambió.

Paso 10: Acciones Posteriores al Envío

Tras la aceptación:

# Etiquetar la versión
usethis::use_github_release()

# Incrementar a versión de desarrollo
usethis::use_dev_version()

Esperado: Se crea la versión de GitHub con la etiqueta de la versión aceptada. DESCRIPTION se incrementa a la versión de desarrollo (x.y.z.9000).

En caso de fallo: Si la versión de GitHub falla, crearla manualmente con gh release create. Si la aceptación de CRAN se retrasa, esperar el correo de confirmación antes de etiquetar.

Validación

  • R CMD check devuelve 0 errores, 0 advertencias en la máquina local
  • Win-builder pasa (release + devel)
  • R-hub pasa en todas las plataformas probadas
  • cran-comments.md describe con precisión los resultados de verificación
  • Todas las URLs son válidas
  • Sin errores ortográficos
  • El número de versión es correcto e incrementado
  • NEWS.md está actualizado
  • Los metadatos de DESCRIPTION están completos y son precisos

Errores Comunes

  • Ejemplos demasiado lentos: Envolver los ejemplos costosos en \donttest{}. CRAN impone límites de tiempo.
  • Nombres de archivos/directorios no estándar: Evitar archivos que generen notas de CRAN (revisar .Rbuildignore)
  • Falta \value en la documentación: Todas las funciones exportadas necesitan una etiqueta @return
  • Fallos en la compilación de viñetas: Asegurarse de que las viñetas compilan en un entorno limpio sin tu .Renviron
  • Formato del título en DESCRIPTION: Debe ser en Mayúsculas de Título, sin punto al final, sin "A Package for..."
  • Olvidar las verificaciones de dependencias inversas: Para actualizaciones, ejecutar revdepcheck::revdep_check()

Ejemplos

# Flujo completo previo al envío
devtools::spell_check()
urlchecker::url_check()
devtools::check()
devtools::check_win_devel()
rhub::rhub_check()
# Esperar resultados...
devtools::release()

Habilidades Relacionadas

  • release-package-version - incremento de versión y etiquetado git
  • write-roxygen-docs - asegurar que la documentación cumple los estándares de CRAN
  • setup-github-actions-ci - verificaciones de CI que reflejan las expectativas de CRAN
  • build-pkgdown-site - sitio de documentación para paquetes aceptados

Dépôt GitHub

pjt222/agent-almanac
Chemin: i18n/es/skills/submit-to-cran
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

Compétences associées

content-collections

Méta

Cette compétence propose une configuration éprouvée en production pour Content Collections, un outil axé sur TypeScript qui transforme des fichiers Markdown/MDX en collections de données typées de manière sûre avec une validation Zod. Utilisez-la lors de la création de blogs, de sites de documentation ou d'applications Vite + React riches en contenu pour garantir la sécurité de typage et la validation automatique du contenu. Elle couvre tout, de la configuration du plugin Vite et de la compilation MDX à l'optimisation des déploiements et la validation des schémas.

Voir la compétence

polymarket

Méta

Cette compétence permet aux développeurs de créer des applications avec la plateforme de marchés prédictifs Polymarket, incluant l'intégration d'API pour le trading et les données de marché. Elle fournit également une diffusion de données en temps réel via WebSocket pour surveiller les transactions en direct et l'activité du marché. Utilisez-la pour mettre en œuvre des stratégies de trading ou pour créer des outils traitant les mises à jour de marché en direct.

Voir la compétence

creating-opencode-plugins

Méta

Cette compétence aide les développeurs à créer des plugins OpenCode qui s'interconnectent avec plus de 25 types d'événements tels que les commandes, les fichiers et les opérations LSP. Elle fournit la structure du plugin, les spécifications de l'API événementielle et les modèles d'implémentation pour les modules JavaScript/TypeScript. Utilisez-la lorsque vous avez besoin d'intercepter, de surveiller ou d'étendre le cycle de vie de l'assistant IA OpenCode avec une logique personnalisée pilotée par les événements.

Voir la compétence

sglang

Méta

SGLang est un framework de service LLM haute performance spécialisé dans la génération rapide et structurée pour les workflows JSON, regex et agentiques grâce à son cache de préfixe RadixAttention. Il offre une inférence nettement plus rapide, particulièrement pour les tâches avec des préfixes répétés, ce qui le rend idéal pour les sorties complexes et structurées ainsi que les conversations multi-tours. Choisissez SGLang plutôt que des alternatives comme vLLM lorsque vous avez besoin d'un décodage contraint ou que vous construisez des applications avec un partage étendu de préfixes.

Voir la compétence