{{PROJECT_DESCRIPTION}}
🔥 Build · Break · Harden
Build boldly, test responsibly, and harden with evidence.
Construye con audacia, prueba con responsabilidad y refuerza con evidencias.
This is the HellCode Collective starting point for turning an idea into a well-defined project. It carries the HC² engineering rhythm—Build · Break · Harden—while remaining neutral about language and framework. The structure helps you describe the problem, constrain the first version, record decisions, organize work, and invite useful contributions.
Use it for prototypes, research projects, command-line tools, libraries, applications, experiments, or internal initiatives. Remove anything that does not help your project. If the generated repository is not affiliated with HellCode Collective, replace the HC² identity with the project's own identity.
- A project brief, roadmap, and decision log.
- Bilingual contribution, support, security, and reporting guidance.
- Structured issue forms and a pull request checklist.
- A portable Codespaces configuration with no project-specific runtime.
- A dependency-free quality check for documentation and template portability.
- A setup guide for repository features that GitHub templates do not copy.
- A clear writing style and a practical ASCII banner standard for CLI projects.
- Select Use this template, then Create a new repository.
- Choose any personal account or organization as the destination.
- Open the setup guide and complete the essential checklist.
- Replace the three template values listed under Customize.
- Define the first small outcome in the project brief.
Open the repository's Code menu, select Codespaces, and create a codespace. The neutral development container opens the core planning documents without selecting a project language or installing project dependencies.
Clone the generated repository with your preferred Git client, then open it in any editor. No bootstrap command is required.
- Write one sentence that explains the problem in
docs/PROJECT_BRIEF.md. - Name the people affected and the outcome they need.
- Choose one measurable success signal.
- Add the smallest useful milestone to
docs/ROADMAP.md. - Create the first issue from the task form that best matches the work.
If you cannot describe the first useful outcome yet, keep refining the brief before adding implementation detail.
| You want to… | Open… | Bring… |
|---|---|---|
| Report a reproducible problem | Issues → Bug report | Steps, expected result, and observed result |
| Propose a scoped improvement | Issues → Feature request | The problem, who benefits, and a success check |
| Explore an unfinished idea | Discussions | Context, boundaries, and the open question |
| Learn the project method | Wiki | Ten quiet minutes and a rough idea |
Issues turn known work into action. Discussions turn uncertainty into shared understanding. The Wiki preserves the route so the next person starts further ahead.
| Path | Purpose |
|---|---|
docs/PROJECT_BRIEF.md |
Problem, users, goals, constraints, and success signals |
docs/ROADMAP.md |
Outcomes organized by Now, Next, and Later |
docs/DECISION_LOG.md |
Short, durable records of important decisions |
docs/WRITING_STYLE.md |
HC² voice, bilingual writing, emoji, and accessibility rules |
docs/CLI_STYLE.md |
Required ASCII banner behavior for command-line tools |
src/ |
Product or library source when implementation starts |
tests/ |
Automated and manual verification assets |
examples/ |
Small, safe examples of intended use |
.github/ |
Issue forms, pull request guidance, labels, and automation |
.devcontainer/ |
Portable Codespaces and dev container configuration |
- Build — frame the problem. Define the smallest useful outcome before committing to an implementation.
- Break — challenge assumptions. Turn uncertainty into safe, authorized experiments and explicit failure cases.
- Harden — act on evidence. Improve reliability, security, accessibility, and maintainability based on what you learned.
- Record — preserve context. Log decisions that will matter to the next contributor or to your future self.
- Repeat — keep the scope honest. Update the brief and roadmap when reality changes the plan.
Every command-line tool created from this template must ship with a memorable ASCII banner. Personality is welcome; broken automation is not. The banner must remain optional in non-interactive use, must not corrupt machine-readable output, and must have a plain-text fallback. See the CLI style guide for examples and implementation rules.
Search the repository for these values and replace each one:
| Value | Replace with |
|---|---|
{{PROJECT_NAME}} |
The human-readable project name |
{{PROJECT_DESCRIPTION}} |
A concise statement of purpose and value |
{{CONTACT_CHANNEL}} |
A maintained support channel or neutral contact route |
Then choose a license, review the code of conduct, and configure the repository features in the setup guide. Avoid adding owner-specific links to reusable files unless the project is no longer intended to serve as a template.
Read CONTRIBUTING.md before proposing a change. Small, focused pull requests with a clear reason and verification notes are easiest to review. Follow the writing style for human-facing text and the CLI style guide for command-line tools. Participation is governed by CODE_OF_CONDUCT.md.
- Bug: open Issues, select Bug report / Reporte de error, and include a minimal reproduction.
- Feature: open Issues and select Feature request / Solicitud de función. Explain the problem before the proposed solution.
- Documentation: use Documentation improvement / Mejora de documentación.
- Question or idea: start a conversation in the repository's Discussions tab.
- Security vulnerability: do not open a public issue. Follow SECURITY.md and use the repository's private vulnerability reporting flow.
- Other support: see SUPPORT.md or use
{{CONTACT_CHANNEL}}.
- Keep the brief, roadmap, and decision log aligned with current reality.
- Keep examples small, safe, and verified.
- Update
CHANGELOG.mdfor user-visible changes. - Run the quality workflow before merging.
- Review permissions, dependencies, security reports, and stale guidance.
- For CLI projects, verify the ASCII banner,
--no-banner,NO_COLOR, pipes, and machine-readable modes. - Select and add an appropriate license before public distribution.
No project license is selected by this template. Without a license, copyright
law reserves the default rights to the copyright holder. Choose and add a
LICENSE file before others are expected to use, modify, or distribute the
project.
Este es el punto de partida de HellCode Collective para convertir una idea en un proyecto bien definido. Incorpora el ritmo de ingeniería HC² —Build · Break · Harden— sin imponer un lenguaje ni un framework. La estructura ayuda a describir el problema, limitar la primera versión, registrar decisiones, organizar el trabajo e invitar a contribuciones útiles.
Puede utilizarse para prototipos, investigación, herramientas de línea de comandos, librerías, aplicaciones, experimentos o iniciativas internas. Elimina todo aquello que no ayude a tu proyecto. Si el repositorio generado no está afiliado a HellCode Collective, sustituye la identidad HC² por la del proyecto.
- Un resumen de proyecto, roadmap y registro de decisiones.
- Guías bilingües de contribución, soporte, seguridad y reporte.
- Formularios estructurados para issues y una lista de comprobación para pull requests.
- Una configuración portable de Codespaces sin runtime específico del proyecto.
- Una comprobación de calidad sin dependencias para documentación y portabilidad.
- Una guía para configurar las funciones que GitHub no copia desde un template.
- Un estilo de redacción claro y un estándar práctico de banners ASCII para proyectos CLI.
- Selecciona Use this template y después Create a new repository.
- Elige cualquier cuenta personal u organización como destino.
- Abre la guía de configuración y completa la lista esencial.
- Sustituye los tres valores indicados en Personalización.
- Define el primer resultado pequeño en el resumen de proyecto.
Abre el menú Code del repositorio, selecciona Codespaces y crea un codespace. El contenedor de desarrollo neutral abre los documentos principales de planificación sin seleccionar un lenguaje ni instalar dependencias del proyecto.
Clona el repositorio generado con el cliente Git que prefieras y ábrelo en cualquier editor. No es necesario ejecutar ningún comando de preparación.
- Escribe una frase que explique el problema en
docs/PROJECT_BRIEF.md. - Identifica a las personas afectadas y el resultado que necesitan.
- Elige una señal de éxito medible.
- Añade el hito útil más pequeño a
docs/ROADMAP.md. - Crea el primer issue con el formulario que mejor corresponda al trabajo.
Si todavía no puedes describir el primer resultado útil, sigue refinando el resumen antes de añadir detalles de implementación.
| Quieres… | Abre… | Aporta… |
|---|---|---|
| Reportar un problema reproducible | Issues → Bug report | Pasos, resultado esperado y resultado observado |
| Proponer una mejora acotada | Issues → Feature request | El problema, quién se beneficia y una comprobación de éxito |
| Explorar una idea todavía abierta | Discussions | Contexto, límites y la pregunta pendiente |
| Aprender el método del proyecto | Wiki | Diez minutos tranquilos y una idea aproximada |
Issues convierte trabajo conocido en acción. Discussions convierte incertidumbre en comprensión compartida. La Wiki conserva la ruta para que la siguiente persona empiece más adelante.
| Ruta | Propósito |
|---|---|
docs/PROJECT_BRIEF.md |
Problema, usuarios, objetivos, restricciones y señales de éxito |
docs/ROADMAP.md |
Resultados organizados en Ahora, Después y Más adelante |
docs/DECISION_LOG.md |
Registros breves y duraderos de decisiones importantes |
docs/WRITING_STYLE.md |
Voz HC², redacción bilingüe, emojis y accesibilidad |
docs/CLI_STYLE.md |
Comportamiento obligatorio del banner ASCII para herramientas CLI |
src/ |
Código del producto o librería cuando comience la implementación |
tests/ |
Recursos de verificación automática y manual |
examples/ |
Ejemplos pequeños y seguros del uso previsto |
.github/ |
Formularios, guía de pull requests, labels y automatización |
.devcontainer/ |
Configuración portable de Codespaces y dev containers |
- Build — delimita el problema. Define el resultado útil más pequeño antes de comprometerte con una implementación.
- Break — cuestiona las suposiciones. Convierte la incertidumbre en experimentos seguros, autorizados y con fallos explícitos.
- Harden — aplica las evidencias. Mejora fiabilidad, seguridad, accesibilidad y mantenimiento a partir de lo aprendido.
- Registra — conserva el contexto. Documenta las decisiones que importarán a quien contribuya después o a tu yo del futuro.
- Repite — mantén honesto el alcance. Actualiza el resumen y el roadmap cuando la realidad cambie el plan.
Toda herramienta de línea de comandos creada con este template debe incluir un banner ASCII memorable. La personalidad es bienvenida; romper automatizaciones, no. El banner debe poder desactivarse en usos no interactivos, no debe contaminar salidas procesables por máquinas y debe tener una alternativa en texto plano. Consulta la guía de estilo CLI para ver ejemplos y reglas de implementación.
Busca estos valores en el repositorio y sustituye cada uno:
| Valor | Sustituir por |
|---|---|
{{PROJECT_NAME}} |
El nombre legible del proyecto |
{{PROJECT_DESCRIPTION}} |
Una descripción breve de su propósito y valor |
{{CONTACT_CHANNEL}} |
Un canal de soporte mantenido o una vía neutral de contacto |
Después elige una licencia, revisa el código de conducta y configura las funciones del repositorio mediante la guía de configuración. Evita añadir enlaces ligados al propietario en archivos reutilizables salvo que el proyecto deje de funcionar como template.
Lee CONTRIBUTING.md antes de proponer un cambio. Los pull requests pequeños, centrados y con una justificación clara y notas de verificación son los más fáciles de revisar. Sigue el estilo de redacción para contenido dirigido a personas y la guía de estilo CLI para herramientas de terminal. La participación se rige por CODE_OF_CONDUCT.md.
- Error: abre Issues, selecciona Bug report / Reporte de error e incluye una reproducción mínima.
- Funcionalidad: abre Issues y selecciona Feature request / Solicitud de función. Explica el problema antes que la solución propuesta.
- Documentación: usa Documentation improvement / Mejora de documentación.
- Pregunta o idea: inicia una conversación en la pestaña Discussions del repositorio.
- Vulnerabilidad de seguridad: no abras un issue público. Sigue SECURITY.md y utiliza el reporte privado de vulnerabilidades.
- Otro soporte: consulta SUPPORT.md o utiliza
{{CONTACT_CHANNEL}}.
- Mantén el resumen, roadmap y registro de decisiones alineados con la realidad.
- Conserva ejemplos pequeños, seguros y verificados.
- Actualiza
CHANGELOG.mdpara cambios visibles para las personas usuarias. - Ejecuta el workflow de calidad antes de fusionar cambios.
- Revisa permisos, dependencias, reportes de seguridad y documentación obsoleta.
- En proyectos CLI, comprueba el banner ASCII,
--no-banner,NO_COLOR, pipes y modos procesables por máquinas. - Elige y añade una licencia apropiada antes de la distribución pública.
Este template no selecciona una licencia para el proyecto. Sin una licencia, la
legislación de copyright reserva los derechos predeterminados a su titular.
Elige y añade un archivo LICENSE antes de esperar que otras personas usen,
modifiquen o distribuyan el proyecto.