236 lines
5.9 KiB
Markdown
236 lines
5.9 KiB
Markdown
---
|
|
version: 2.0.0
|
|
updated: 2026-03-11
|
|
tags: [commands, meta, automation, workflow]
|
|
---
|
|
|
|
# Command: create-command
|
|
|
|
Crea un nuevo comando en `.claude/commands/` siguiendo la estructura estándar del proyecto. Usa el template en `.claude/templates/command.md` y incluye flujo completo de git.
|
|
|
|
**Flujo completo:**
|
|
1. Solicita inputs del comando
|
|
2. Crea el archivo `.md` del comando
|
|
3. Muestra el contenido al usuario
|
|
4. Pregunta si está bien
|
|
5. Si el usuario confirma → ejecuta `/git:push` automáticamente
|
|
|
|
## Inputs
|
|
|
|
Se necesitan los datos del comando. Si no se proporcionan, preguntar.
|
|
|
|
- `nombre`: nombre del comando sin extensión (ej: `deploy`, `test-all`)
|
|
- `descripcion`: breve descripción de qué hace el comando (1 frase)
|
|
- `inputs`: lista de parámetros que recibe el comando (opcional)
|
|
- `flujo`: pasos principales que ejecuta el comando
|
|
|
|
## Flujo obligatorio
|
|
|
|
### 1. Validar nombre del comando
|
|
|
|
- Solo minúsculas y guiones (no underscores ni espacios)
|
|
- No usar nombres reservados del sistema (help, clear, exit)
|
|
- Verificar que no exista ya en `.claude/commands/`
|
|
|
|
```bash
|
|
ls -1 .claude/commands/ | grep -E "^${nombre}\.md$"
|
|
```
|
|
|
|
Si existe, **STOP** e informar al usuario.
|
|
|
|
### 2. Determinar tipo de comando
|
|
|
|
Analizar la descripción y flujo para clasificar:
|
|
|
|
- **Comando de git** (git-*): manipula ramas, commits, merges
|
|
- **Comando de issue** (create-issue, fix-issue, etc.): crea/modifica issues
|
|
- **Comando de proyecto** (build, deploy, test): ejecuta operaciones del proyecto
|
|
- **Comando genérico**: cualquier otro tipo
|
|
|
|
### 3. Cargar template base
|
|
|
|
Leer el template desde `.claude/templates/command.md`:
|
|
|
|
```bash
|
|
cat .claude/templates/command.md
|
|
```
|
|
|
|
### 4. Generar estructura del comando
|
|
|
|
Reemplazar los placeholders del template con los valores proporcionados:
|
|
|
|
```markdown
|
|
# Command: <nombre>
|
|
|
|
<Descripción breve en 1-2 líneas. Indicar qué hace el comando.>
|
|
|
|
**Flujo completo:** [si aplica]
|
|
<Lista numerada de pasos de alto nivel>
|
|
|
|
## Inputs
|
|
|
|
<Describir parámetros que recibe el comando>
|
|
|
|
- `param1`: descripción del parámetro
|
|
- `param2` (opcional): descripción del parámetro opcional
|
|
|
|
## Flujo obligatorio
|
|
|
|
### 1. <Paso principal 1>
|
|
|
|
<Descripción detallada del paso>
|
|
|
|
```bash
|
|
# Comandos ejemplo si aplica
|
|
comando1
|
|
comando2
|
|
```
|
|
|
|
<Notas adicionales, casos especiales, validaciones>
|
|
|
|
### 2. <Paso principal 2>
|
|
|
|
...
|
|
|
|
### N. Confirmar al usuario [si es comando interactivo]
|
|
|
|
Mostrar resumen de lo realizado:
|
|
|
|
```
|
|
<Mensaje de confirmación>
|
|
```
|
|
|
|
## Convenciones [si aplica]
|
|
|
|
- Regla 1
|
|
- Regla 2
|
|
|
|
## Reglas críticas [si aplica]
|
|
|
|
- Regla crítica 1
|
|
- Regla crítica 2
|
|
```
|
|
|
|
### 4. Rellenar secciones específicas por tipo
|
|
|
|
#### Para comandos de git:
|
|
- Incluir verificaciones de branch y estado
|
|
- Documentar convenciones de nombres de rama
|
|
- Explicar flujo de merge y push
|
|
|
|
#### Para comandos de issue:
|
|
- Referencia a `dev/issues/` y estructura
|
|
- Manejo de numeración consecutiva
|
|
- Actualización de `dev/issues/README.md`
|
|
|
|
#### Para comandos de proyecto:
|
|
- Documentar dependencias (Go, herramientas, etc.)
|
|
- Flags y opciones de ejecución
|
|
- Manejo de errores
|
|
|
|
### 5. Agregar ejemplos concretos
|
|
|
|
Incluir al menos 1 ejemplo de uso típico:
|
|
|
|
```markdown
|
|
## Ejemplo
|
|
|
|
**Input:**
|
|
```bash
|
|
/project:create-command build-all
|
|
```
|
|
|
|
**Output:**
|
|
```
|
|
Comando build-all creado en .claude/commands/build-all.md
|
|
Listo para usar: /build-all
|
|
```
|
|
```
|
|
|
|
### 6. Validar completitud
|
|
|
|
Verificar que el comando tiene:
|
|
|
|
- [ ] Título con formato `# Command: <nombre>`
|
|
- [ ] Descripción breve al inicio
|
|
- [ ] Sección de inputs (aunque esté vacía si no tiene)
|
|
- [ ] Flujo obligatorio con pasos numerados
|
|
- [ ] Ejemplos de bash si aplica
|
|
- [ ] Sección de convenciones si tiene reglas especiales
|
|
- [ ] Reglas críticas si hay validaciones obligatorias
|
|
|
|
### 7. Crear el archivo
|
|
|
|
```bash
|
|
cat > .claude/commands/<nombre>.md << 'EOF'
|
|
<contenido-generado>
|
|
EOF
|
|
```
|
|
|
|
### 8. Mostrar el comando creado y confirmar
|
|
|
|
**Mostrar al usuario el contenido completo del comando:**
|
|
|
|
```bash
|
|
cat .claude/commands/<nombre>.md
|
|
```
|
|
|
|
**Pausar y preguntar:**
|
|
|
|
```
|
|
Comando creado: <nombre>
|
|
|
|
¿Te parece bien el comando?
|
|
- Si es correcto: se hará commit y push automáticamente
|
|
- Si necesitas ajustes: puedes editarlo manualmente antes
|
|
```
|
|
|
|
**Esperar respuesta del usuario:**
|
|
|
|
- Si responde **SI** / afirmativo → continuar al paso 9
|
|
- Si responde **NO** / necesita cambios → **STOP** y decir: "Edita el archivo y cuando estés listo ejecuta `/git:push`"
|
|
|
|
### 9. Ejecutar git-push automáticamente
|
|
|
|
Una vez confirmado por el usuario, ejecutar el comando `/git:push` para:
|
|
|
|
1. Crear rama `quick/project:create-command-<nombre>` automáticamente
|
|
2. Commitear el archivo `.claude/commands/<nombre>.md`
|
|
3. Mergear a master con `--no-ff`
|
|
4. Push a remoto
|
|
5. Limpiar rama local
|
|
|
|
El comando `/git:push` maneja todo el flujo de git automáticamente.
|
|
|
|
### 10. Verificar disponibilidad
|
|
|
|
Informar al usuario:
|
|
|
|
```
|
|
✓ Comando /<nombre> creado e integrado a master
|
|
|
|
Para usar:
|
|
/<nombre> [argumentos]
|
|
|
|
Para ver ayuda:
|
|
/<nombre> --help
|
|
```
|
|
|
|
## Convenciones
|
|
|
|
- **Nombres descriptivos**: usar verbos de acción (create, fix, deploy, test)
|
|
- **Guiones para separar**: `git-branch`, `fix-issue`, no `git_branch`
|
|
- **Sin prefijo slash**: el archivo se llama `comando.md`, no `/comando.md`
|
|
- **Extensión obligatoria**: siempre `.md`
|
|
- **Estructura consistente**: seguir el template para mantener uniformidad
|
|
|
|
## Reglas críticas
|
|
|
|
- **Validar nombre antes de crear**: evitar sobrescribir comandos existentes
|
|
- **Documentar exhaustivamente**: cada paso debe ser claro y reproducible
|
|
- **Incluir ejemplos**: facilitar comprensión del uso
|
|
- **Confirmación obligatoria**: siempre mostrar el comando completo al usuario y esperar su aprobación antes de hacer commit/push
|
|
- **Flujo automático**: una vez aprobado por el usuario, ejecutar `/git:push` para integrar los cambios automáticamente
|
|
- **No crear comandos redundantes**: verificar si funcionalidad ya existe en otro comando
|
|
- **Respetar convenciones del proyecto**: seguir patrones de trunk-based development, pure core / impure shell, etc.
|