Curso – Claude
EN

Contribuir a Claude Cómo

¡Gracias por su interés en contribuir a este proyecto! Esta guía le ayudará a entender cómo contribuir eficazmente.

Acerca de este proyecto

Claude How To es una guía visual, basada en el ejemplo de Claude Code. Proporcionamos: - Diagramas Mermaid explicar cómo funcionan las características - Plantillas preparadas para la producción puede utilizar inmediatamente - Ejemplos del mundo real con contexto y mejores prácticas - Vías de aprendizaje progresivo de principiante a avanzado

Tipos de contribuciones

1. Nuevos ejemplos o plantillas

Añada ejemplos para las características existentes (comandos de barra, skills, hooks, etc.): - Copiar-pegar código listo - Explicaciones claras de cómo funciona - Usar casos y beneficios - Consejos para solucionar problemas

2. Mejoras de la documentación

  • Aclarar las secciones confusas
  • Fijar errores tipográficos y gramática
  • Añadir información que falta
  • Mejorar los ejemplos de código

3. Guías de características

Crear guías para las nuevas características de Claude Code: - Tutoriales paso a paso - Diagramas de arquitectura - Patrones comunes y antipatrones - Flujos de trabajo en el mundo real

4. Informes de fallos

Informe de problemas que usted encuentra: - Describa lo que usted esperaba - Describa lo que realmente sucedió - Incluya pasos para reproducir - Añada la versión relevante de Claude Code y OS

5. Comentarios y sugerencias

Ayudar a mejorar la guía: - Sugerir mejores explicaciones - Señalar las lagunas en la cobertura - Recomendar nuevas secciones o reorganización

Primeros pasos

1. tenedor y clon

git clone https://github.com/tobalseverin/claude-curso.git
cd claude-howto

2. Crear una Subdivisión

Use un nombre descriptivo de la rama:

git checkout -b add/feature-name
git checkout -b fix/issue-description
git checkout -b docs/improvement-area

3. Establezca su entorno

Los hooks pre-commit ejecutan los mismos cheques que CI localmente antes de cada confirmación. Los cinco cheques deben pasar antes de que se acepte una PR.

Dependencias necesarias:

# Python tooling (uv is the package manager for this project)
pip install uv
uv venv
source .venv/bin/activate
uv pip install -r scripts/requirements-dev.txt

# Markdown linter (Node.js)
npm install -g markdownlint-cli

# Mermaid diagrams render with Pele, which needs Node.js >= 20 (nothing to
# install globally). Check your version:
node --version

# Install pre-commit and activate hooks
uv pip install pre-commit
pre-commit install

Verifique su configuración:

pre-commit run --all-files

La primera ejecución descarga Node.js 22 para los hooks de Sirena (precommit provisiones, por lo que funcionan incluso sin un sistema Node.js) y el paquete de Pele en scripts/.vendor-cache/pele/; más tarde se ejecuta el trabajo fuera de línea. Los hooks de Sirena se ejecutan en modo estricto y fallan si Pele no puede ejecutar. SKIP=mermaid,vietnamese-mermaid,japanese-mermaid.

Los hooks que corren en cada comisión son:

Hook Lo que comprueba
markdown-lint Formato y estructura de marcado
cross-references Enlaces relativos, anclajes, vallas de código
mermaid-syntax Todos ```mermaid bloques de análisis correctamente
link-check URLs externas son accesibles
build-epub EPUB genera sin errores (on .md cambios)

Estructura del directorio

├── 01-slash-commands/      # User-invoked shortcuts
├── 02-memory/              # Persistent context examples
├── 03-skills/              # Reusable capabilities
├── 04-subagents/           # Specialized AI assistants
├── 05-mcp/                 # Model Context Protocol examples
├── 06-hooks/               # Event-driven automation
├── 07-plugins/             # Bundled features
├── 08-checkpoints/         # Session snapshots
├── 09-advanced-features/   # Planning, thinking, backgrounds
├── 10-cli/                 # CLI reference
├── scripts/                # Build and utility scripts
└── README.md               # Main guide

Cómo contribuir a ejemplos

Añadiendo una orden de barra

  1. Crear una .md archivo en 01-slash-commands/
  2. Incluir:
  3. Descripción clara de lo que hace
  4. Casos de uso
  5. Instrucciones de instalación
  6. Ejemplos de uso
  7. Consejos de personalización
  8. Actualizar 01-slash-commands/README.md

Añadir una habilidad

  1. Crear un directorio en 03-skills/
  2. Incluir:
  3. SKILL.md - Documentación principal
  4. scripts/ - scripts de ayuda si es necesario
  5. templates/ - Plantillas rápidas
  6. Ejemplo de uso en README
  7. Actualizar 03-skills/README.md

Añadiendo un subagente

  1. Crear una .md archivo en 04-subagents/
  2. Incluir:
  3. Propósito y capacidades del agente
  4. Estructura del sistema rápida
  5. Ejemplo de casos de uso
  6. Ejemplos de integración
  7. Actualizar 04-subagents/README.md

Añadiendo configuración de MCP

  1. Crear una .json archivo en 05-mcp/
  2. Incluir:
  3. Explicación de configuración
  4. Variables de entorno necesarias
  5. Instrucciones de configuración
  6. Ejemplos de uso
  7. Actualizar 05-mcp/README.md

Añadir un hook

  1. Crear una .sh archivo en 06-hooks/
  2. Incluir:
  3. Shebang y descripción
  4. Comentarios claros que explican la lógica
  5. Manipulación de errores
  6. Consideraciones relativas a la seguridad
  7. Actualizar 06-hooks/README.md

Directrices para la redacción

Estilo Markdown

  • Usar encabezamientos claros (H2 para las secciones, H3 para las subsecciones)
  • Mantener los párrafos cortos y centrados
  • Usar puntos de viñeta para las listas
  • Incluir bloques de código con especificación de idioma
  • Añadir líneas en blanco entre secciones

Ejemplos de código

  • Haga que los ejemplos de copiar-pegar estén listos
  • Comentar lógica no obvia
  • Incluir versiones simples y avanzadas
  • Mostrar casos de uso en el mundo real
  • Destacar las cuestiones potenciales

Documentación

  • Explicar el "por qué" no sólo el "qué"
  • Incluir requisitos previos
  • Añadir secciones de resolución de problemas
  • Enlace a temas relacionados
  • Mantenlo amigable con los principiantes.

JSON/YAML

  • Usar una sangría adecuada (2 o 4 espacios consistentemente)
  • Añadir comentarios para explicar la configuración
  • Incluir ejemplos de validación

Diagramas

  • Usar Sirena cuando sea posible
  • Mantener diagramas simples y legibles
  • Incluir descripciones debajo de diagramas
  • Enlace a las secciones pertinentes

Directrices para el envío de documentos

Siga el formato de confirmación convencional:

type(scope): description

[optional body]

Tipos: - feat: Nueva característica o ejemplo - fix: Corrección o corrección de errores - docs: Cambios en la documentación refactor: Reestructuración del código - style: Cambios de formato - test: Adiciones o cambios de prueba - chore: Construir, dependencias, etc.

Ejemplos:

feat(slash-commands): Add API documentation generator
docs(memory): Improve personal preferences example
fix(README): Correct table of contents link
docs(skills): Add comprehensive code review skill

Antes de presentar

Lista de verificación

  • [ ] Código sigue el estilo del proyecto y convenciones
  • [ ] Nuevos ejemplos incluyen documentación clara
  • [ ] Los archivos README se actualizan (tanto locales como root)
  • [ ] No hay información sensible (claves de la API, credenciales)
  • [ ] Ejemplos son probados y funcionan
  • [ ] Enlaces verificados y correctos
  • [ ] Los archivos tienen permisos adecuados (los guiones son ejecutables)
  • [ ] Mensaje de comisión es claro y descriptivo

Pruebas locales

# Run all pre-commit checks (same checks as CI)
pre-commit run --all-files

# Review your changes
git diff

Proceso de solicitud de pull

  1. Crear PR con una descripción clara:
  2. ¿Qué hace este add/fix?
  3. ¿ Por qué es necesario?

  4. Cuestiones conexas (en su caso)

  5. Incluya los detalles pertinentes:

  6. ¿Nueva característica? Incluya casos de uso
  7. Documentación? Explicar mejoras

  8. Ejemplos? Mostrar antes/después

  9. Vínculo con las cuestiones:

  10. Uso Closes #123 para cerrar automáticamente los problemas relacionados

  11. Tenga paciencia con las revisiones:

  12. Los responsables pueden sugerir mejoras
  13. Iterar sobre la base de la retroalimentación
  14. La decisión final corresponde a los encargados del mantenimiento

Proceso de revisión del código

Los evaluadores comprobarán: - Exactitud¿Funciona como se describe? Calidad¿Está listo para la producción? Coherencia: ¿Sigue los patrones del proyecto? - Documentación¿Está claro y completo? Seguridad: ¿Hay alguna vulnerabilidad?

Cuestiones relativas a la presentación de informes

Informes de fallos

Incluye: - Versión de Claude Code - Sistema operativo - Pasos para reproducir - Comportamiento esperado - Comportamiento real - Capturas de pantalla si procede

Solicitudes de características

Incluye: - Usar caso o problema que se está resolviendo - Solución propuesta - Alternativas que ha considerado - Contexto adicional

Cuestiones relativas a la documentación

Incluye: - Lo que es confuso o falta - Sugerencias de mejoras - Ejemplos o referencias

Políticas de proyectos

Información sensible

  • Nunca envíe claves, fichas o credenciales de API
  • Usar valores de marcadores de posición en ejemplos
  • Incluir .env.example para los archivos de configuración
  • Documentar las variables de entorno requeridas

Calidad del código

  • Mantenga los ejemplos enfocados y legibles
  • Evitar soluciones de ingeniería excesiva
  • Incluir comentarios para lógica no obvia
  • Prueba a fondo antes de enviar

Propiedad intelectual

  • Contenido original propiedad del autor
  • Proyecto utiliza licencia educativa
  • Respetar los derechos de autor existentes
  • Proporcionar atribución cuando sea necesario

Obtener ayuda

  • Preguntas: Abrir una discusión en temas de GitHub
  • Ayuda general: Comprobar la documentación existente
  • Ayuda para el Desarrollo: Revise ejemplos similares
  • Revisión de código: Mantenedores de etiquetas en relaciones públicas

Reconocimiento

Los colaboradores son reconocidos en: - Sección de colaboradores README.md - Página de colaboradores GitHub - Comprometer historia

Seguridad

Al aportar ejemplos y documentación, siga prácticas de codificación seguras:

  • Nunca secretos de código duro o claves de API - Usar variables de entorno
  • Avisar sobre las implicaciones de seguridad - Destacar los riesgos potenciales
  • Usar valores predeterminados seguros - Habilitar las características de seguridad por defecto
  • Validar entradas - Mostrar validación de entrada y desinfección adecuada
  • Incluir notas de seguridad - Consideraciones relativas a la seguridad de los documentos

Para las cuestiones de seguridad, véase SECURITY.md para nuestro proceso de reporte de vulnerabilidad.

Código de conducta

Estamos comprometidos a proporcionar una comunidad acogedora e inclusiva. CODE_OF_CONDUCT.md para nuestros estándares comunitarios completos.

En resumen: - Ser respetuoso e inclusivo - Bienvenido comentarios con gracia - Ayudar a otros a aprender y crecer - Evitar el acoso o la discriminación - Informar a los mantenedores

Se espera que todos los contribuyentes mantengan este código y se traten con amabilidad y respeto.

Licencia

Al contribuir a este proyecto, usted acepta que sus contribuciones serán licenciadas bajo la Licencia MIT. LICENCIA para más detalles.

¿Preguntas?

¡Gracias por contribuir!

Última actualización: 4 de agosto de 2026 Versión de Claude Code: 2.1.220 Fuentes: - https://code.claude.com/docs/en/overview Modelos compatibles: Claude Fable 5, Claude Opus 5, Claude Sonnet 5, Claude Sonnet 4.6, Claude Opus 4.8, Claude Haiku 4.5

← Anterior
Código de conducta de los colaboradores
Siguiente →
Política de seguridad

Versión en español de Cris Severin. Basado en Claude How To de luongnv89, bajo licencia MIT. Proyecto original