Skill de proyecto nuevo para Claude Code

Revisada el 2026-10-12

Skill de Claude Code que monta el andamiaje mínimo de un proyecto nuevo: unas pocas preguntas, una estructura de carpetas, un CLAUDE.md breve y una decisión razonada sobre git.

Se activa con «nuevo proyecto» o equivalente. No pregunta por reglas, agentes, hooks ni MCP: esa configuración se diseña más adelante, cuando haga falta. Para proyectos con datos personales o confidenciales recomienda no inicializar git.

Datos clave
Formato	Skill de Claude Code (`SKILL.md`)¹
Idioma	Español
Instalación	Global: `~/.claude/skills/new-project/SKILL.md`. Solo un proyecto: `.claude/skills/new-project/SKILL.md`¹

Prompt

Copia el bloque completo en un archivo SKILL.md. La cabecera inicial (name y description) es la que usa Claude Code para decidir cuándo ofrecer la skill.¹

---
name: new-project
description: Crea la estructura de un proyecto nuevo (contexto/, referencias/, plantillas/, inputs/, credentials/, output/, docs/, .claude/) con pocas preguntas básicas, y decide con el usuario el nivel de git según el tipo de proyecto (sin git, git local o git con GitHub privado), sin git si maneja datos personales o confidenciales. La configuración avanzada de Claude Code (rules, agentes, hooks, MCP) no se pregunta por adelantado: se añade más tarde, cuando haga falta de verdad. Actívala cuando el usuario diga "nuevo proyecto", "crea un proyecto nuevo", "empezamos un proyecto" o equivalente.
---
 
Esta skill monta el andamiaje mínimo y suficiente de un proyecto nuevo: unas pocas preguntas básicas, la estructura de carpetas que de verdad se usa desde el primer día, y nada más.
 
Principio rector: no hay scaffolding para necesidades hipotéticas. Reglas, agentes, hooks o MCP se diseñan en una sesión dedicada el día que hagan falta de verdad — no se interroga sobre ellos al crear el proyecto, porque la respuesta casi siempre es "no aplica" y, aunque no lo sea, el diseño real no cabe en una respuesta de entrevista.
 
## 0. Aviso antes de preguntar
 
El usuario puede responder por voz. Antes de la primera pregunta, muestra este aviso (puedes adaptar la redacción, no el contenido):
 
> Vamos a crear el proyecto. Son 5-6 preguntas cortas, 1-2 frases cada una. Si en algún momento mencionamos una credencial, contraseña o token, dime solo el nombre del servicio — nunca el valor, ni por voz ni pegado en el chat. Ese valor lo escribes tú después directamente en el archivo.
 
Si una respuesta se alarga (más de 4-5 frases o varios temas), resúmela tú antes de seguir ("esa respuesta ha sido larga, la guardo así: ..."). No le pidas que la repita más corta.
 
Si el mensaje que activó la skill ya contesta alguna de estas preguntas, no la repitas.
 
## 1. Nombre y destino
 
1. Si `$ARGUMENTS` trae nombre, úsalo; si no, pregunta: "¿Cómo se llama el proyecto?"
2. Convierte a kebab-case (minúsculas, sin acentos, espacios/símbolos → guiones) para el nombre de carpeta.
3. Destino por defecto: `<carpeta-de-proyectos>/<slug>`, donde `<carpeta-de-proyectos>` es la carpeta en la que el usuario guarda sus proyectos (por ejemplo, `~/proyectos`). Solo usa otra ruta si el usuario lo pide explícitamente al invocar la skill.
4. Si la carpeta ya existe, **detente y avisa** — nunca sobrescribas un proyecto existente. Pregunta cómo quiere llamarlo si hay colisión.
 
### Dónde va cada cosa
 
Todo el proyecto va en una sola carpeta: `CLAUDE.md`, `contexto/`, `output/`, `.claude/` y también los documentos que lo alimentan. La copia de seguridad la da el sistema del equipo (por ejemplo, Time Machine en macOS o un servicio equivalente), no el repositorio.
 
**Excepción, solo esta: lo pesado y frío** —cursos, vídeo, escaneos de varios gigas que nunca se editan— puede ir a un almacenamiento externo, y el `CLAUDE.md` apunta ahí. Pregúntate si se va a tocar: si no, y pesa, fuera; si no pesa o se va a tocar, con el proyecto.
 
**El material de trabajo no es el documento definitivo.** Lo que se firma, se presenta o vale por sí mismo se queda en el archivo personal que corresponda y el proyecto solo lo lee: esa ruta no entra en `additionalDirectories` (la fricción de pedir permiso cada vez es correcta para un archivo de años).
 
## 2. Entrevista (un solo bloque, 5-6 preguntas)
 
Una por turno, cortas:
 
1. **Objetivo y destinatario**: "¿Qué resultado busca este proyecto y para quién es — cliente, uso interno, público general?"
2. **Qué lo da por terminado**: "¿Cómo sabremos que algo está bien hecho — hay tests, build, revisión de alguien, u otro criterio?" (si no aplica, anótalo y sigue).
3. **Archivos de origen**: "¿Este proyecto parte de documentos ya existentes? ¿Dónde están?" Por defecto van a `inputs/` dentro del proyecto. Solo si son varios gigas de material que no se va a editar, va a almacenamiento externo (ver paso 1).
   - Si hay documentos: "¿alguno es definitivo —firmado, presentado— y debería quedarse en tu archivo personal en vez de copiarse aquí?" Si los hay, no los muevas: anota la ruta en el `CLAUDE.md` como consulta, fuera de `additionalDirectories`.
4. **Datos confidenciales**: "¿Este proyecto va a manejar datos personales o confidenciales —documentos de identidad, cuentas, salud—?" Si la respuesta es sí, el proyecto va sin git (paso 9) y no se hace la pregunta de abajo.
   - Si no hay datos confidenciales, pregunta el **tipo de proyecto** con tres opciones y recomienda una según el caso (ver paso 9): «¿Es código o una web que se publica, o algo que quieres abrir desde otro equipo o compartir (git con GitHub privado, nivel 2), o son documentos y trabajo personal (git local, nivel 1)?» Dale al usuario la recomendación ya razonada en una frase; si duda, aplica la recomendada.
5. **Credenciales externas**: "¿Necesita ya credenciales de algún servicio externo —API, base de datos, un sitio web—? Dime solo el nombre del servicio, nunca el valor." Si no se sabe aún, se añade cuando haga falta.
6. *(Opcional, solo si el proyecto no es evidentemente personal/informal)* **Restricciones**: "¿Alguna normativa o tecnología obligatoria que deba respetar desde ya?"
 
Idioma de trabajo: español de España por defecto, sin preguntarlo salvo que el contexto lo haga dudoso.
 
No preguntes por reglas, agentes, skills propias, hooks, estilos de salida, MCP compartido o `CLAUDE.local.md`. Si en algún momento de la entrevista el usuario menciona una de estas necesidades por su cuenta (p.ej. "esto necesita que valides siempre el Excel de esta forma"), anótalo tal cual en el resumen de cierre (paso 10) como pendiente de sesión dedicada — no lo diseñes ahora ni lo preguntes activamente.
 
## 3. Crear la estructura de carpetas
 
```bash
DEST=<carpeta-de-proyectos>/<slug>
mkdir -p "$DEST"/{contexto,referencias/documentos,referencias/ejemplos,plantillas,inputs,credentials,output/borradores,output/revisiones,output/finales,output/archivo,docs/sesiones,docs/registro-cambios,.claude/rules}
```
 
Notas:
 
- `credentials/`: si el paso 2.5 nombró servicios, crea aquí un archivo por servicio, `<servicio>.env` (líneas `CLAVE="valor"`, nunca `.md` ni prosa), con el valor como placeholder para que el usuario lo rellene él mismo:
  ```bash
  cat > "$DEST/credentials/<servicio>.env" <<'EOF'
  <SERVICIO>_USERNAME="pendiente"
  <SERVICIO>_APP_PASSWORD="pendiente"
  EOF
  ```
- Solo se crea `.claude/rules/` (para `credenciales.md`, paso 6) y nada más dentro de `.claude/` salvo `settings.json` (paso 8). `.claude/agents/`, `.claude/skills/`, `.claude/commands/`, `.claude/output-styles/`, `.claude/workflows/` no se crean vacías: `mkdir -p` cuando de verdad se necesite algo ahí es un comando, no una carga.
- **No se crea** `.claude/agent-memory/`: la genera Claude Code solo, la primera vez que haga falta.
- **No se crea** `.claude/settings.local.json`: la genera Claude Code la primera vez que apruebas un permiso; el `.gitignore` del paso 9 ya la excluye.
 
## 4. Rellenar `contexto/`
 
- `contexto/objetivo.md`: objetivo + destinatario (fecha incluida).
- `contexto/restricciones.md`: lo contestado en 2.6, o "sin restricciones conocidas por ahora" si no aplica.
- `contexto/decisiones.md`: tabla vacía (fecha | decisión | motivo) para ir añadiendo con el tiempo.
 
Sé conciso: refleja lo dicho, no rellenes con generalidades.
 
## 5. Generar `CLAUDE.md`
 
Menos de 150 líneas siempre. Si algo pesa más o solo aplica a ciertas tareas, va a `.claude/rules/` cuando se cree esa regla más adelante — no aquí:
 
```markdown
# Proyecto: [nombre]
 
## Objetivo
 
[objetivo + destinatario, 2-3 párrafos]
 
## Antes de empezar cualquier tarea
 
1. Lee `contexto/objetivo.md`.
2. Revisa `contexto/decisiones.md` si existe.
3. No modifiques archivos hasta comprender el encargo.
4. Si la tarea es amplia, presenta primero un plan.
 
## Estructura
 
- `contexto/`: información permanente del proyecto.
- `referencias/`: materiales de consulta.
- `inputs/`: archivos de entrada.
- `plantillas/`: formatos reutilizables.
- `credentials/`: claves y credenciales sensibles (no se sube a git).
- `output/`: entregables (borradores/, revisiones/, finales/, archivo/).
- `docs/`: planes, decisiones y documentación (sesiones/, registro-cambios/).
 
[Solo si aplica, si no, omite el bloque:]
 
## Material fuera de esta carpeta
 
- Pesado y frío: `[ruta]`. Comprobar que la unidad está montada antes de usarlo.
- Archivo personal de consulta: `[ruta]`. Solo lectura, fuera de `additionalDirectories` a propósito.
 
## Convenciones
 
- Idioma de trabajo: [idioma].
- Usa nombres de archivo descriptivos; no sobrescribas originales.
- Borradores en `output/borradores/`; entregables aprobados en `output/finales/`.
- Incluye fecha en documentos que puedan quedar desactualizados.
 
## Forma de trabajar
 
1. Analiza. 2. Planifica. 3. Ejecuta. 4. Verifica. 5. Resume los cambios. 6. Guarda el resultado donde corresponda.
 
## Verificación
 
[lo contestado en 2.2; si no aplica, dilo]
 
## Criterio de finalización
 
El resultado está guardado, las verificaciones aplicables se han ejecutado, no quedan errores conocidos, y se ha indicado qué archivos se crearon o modificaron.
```
 
## 6. `.claude/rules/credenciales.md`
 
Créala siempre, haya o no un servicio ya identificado:
 
```markdown
---
paths:
  - "credentials/**"
  - ".mcp.json"
---
 
# Manejo de credenciales
 
- Cada servicio externo tiene su propio `credentials/<servicio>.env` (líneas `CLAVE="valor"`, nunca `.md` ni prosa).
- Nunca pidas al usuario el valor de una credencial en el chat, y nunca leas tú `credentials/*` (ya bloqueado en `settings.json`). El usuario escribe el valor directamente en el archivo.
- Si una credencial aparece pegada en el chat por error, dilo y recomienda revocarla y generar una nueva.
```
 
## 7. `README.md`
 
Breve: nombre del proyecto, una frase de objetivo, fecha de creación. No dupliques `CLAUDE.md`.
 
## 8. `.claude/settings.json`
 
Base prudente, siempre:
 
```json
{
  "permissions": {
    "allow": ["Read", "Write", "Edit"],
    "deny": [
      "Bash(rm -rf *)",
      "Read(./.env)",
      "Read(./secrets/*)",
      "Read(./credentials/*)"
    ]
  }
}
```
 
Si el paso 2.2 mencionó comandos concretos de build/test/lint, añádelos a `allow` (p. ej. `"Bash(npm test *)"`).
 
Si el proyecto tiene material pesado en almacenamiento externo (paso 1), añade `permissions.additionalDirectories` con esa ruta. No añadas ahí rutas de archivos personales de solo consulta.
 
No actives un modo de permisos total. Si el proyecto maneja datos sensibles (paso 2.4), dilo explícitamente en el resumen final aunque no bloquee git.
 
También crea `.worktreeinclude` en la raíz con:
 
```text
credentials/**
.env
.env.local
```
 
(para que si algún día se usa `--worktree`, las credenciales viajen con la copia aislada).
 
## 9. Git: tres niveles según el tipo de proyecto
 
Qué es cada cosa, por si el usuario lo pregunta:
 
- **git** es el historial de versiones del proyecto, en tu disco. Permite ver qué cambió y deshacer. No sube nada a internet.
- **GitHub** es una copia remota de ese historial. Sirve para (1) desplegar webs automáticamente (Cloudflare Pages o Vercel lo leen de ahí), (2) abrir el proyecto desde otro equipo, (3) compartirlo o colaborar. **No es tu copia de seguridad**: eso lo hace el sistema de copias del equipo.
 
Decisión por tipo de proyecto:
 
| Tipo | Nivel | Qué se hace |
|---|---|---|
| Con datos personales o confidenciales (documentos de identidad, cuentas, salud) | **0. Sin git** | No se inicializa. Se anota en el `CLAUDE.md` para que nadie lo «arregle» luego. |
| Documentos, investigación, organización personal | **1. Git local** | `git init` y commit inicial. Sin GitHub: no aporta nada y es una superficie más donde pueden acabar tus datos. |
| Código o web que se publica, proyecto que quieres abrir desde otro equipo o compartir | **2. Git + GitHub privado** | Lo anterior, más repositorio privado en GitHub y primer push (ver abajo). |
 
Motivo del nivel 0: un proyecto con datos confidenciales que acaba con ellos en el historial de git ya no se puede subir a ningún sitio, porque editar hoy no limpia el historial. `git init` se añade fácil más tarde; deshacerlo, no. Por el mismo motivo, **el paso a GitHub se decide al principio o se hace después revisando antes el historial entero**, no a ciegas.
 
Nivel 1 y 2, pasos comunes, sin preguntar:
 
1. `$DEST/.gitignore`:
   ```
   credentials/
   CLAUDE.local.md
   .claude/settings.local.json
   .claude/worktrees/
   .env*
   .DS_Store
   ```
   (añade algo más si el paso 2.6 lo reveló).
2. `git init -b main`
3. `git add -A`
4. Commit inicial: `Andamiaje inicial del proyecto`.
 
Solo nivel 2, después del commit inicial:
 
5. Muestra al usuario nombre y visibilidad que vas a usar (siempre **privado**, nombre = el slug) y espera su confirmación. Crear un repositorio remoto es una acción hacia fuera.
6. `gh repo create <slug> --private --source=. --remote=origin --push`
7. Comprueba con `git status -sb` que `main` sigue a `origin/main`.
8. Si `gh` no está autenticado, dilo y deja el nivel 1; no pidas ni pegues tokens.
 
Un repositorio público es una decisión aparte y explícita, nunca la opción por defecto.
 
Cuando un proyecto ya existente cambie de nivel (p. ej. de 1 a 2), no empujes sin antes revisar el historial completo buscando claves, tokens, IPs internas y copias de configuración (`git log --all -p | grep`), y reescribirlo si hace falta, con copia previa.
 
## 10. Cierre
 
Resume en pocas líneas:
 
1. carpeta creada (ruta completa);
2. archivos generados: `CLAUDE.md`, `contexto/*.md`, `README.md`, `.claude/settings.json`, `.claude/rules/credenciales.md`, `.gitignore`, `.worktreeinclude`, y cualquiera condicional (`credentials/<servicio>.env` pendiente de rellenar, `CLAUDE.md` con bloque de material externo);
3. nivel de git elegido y por qué (0 sin git, 1 local, 2 con GitHub privado, con la URL del repo si lo hay);
4. respuestas de la entrevista tal como quedaron guardadas, para que las confirme;
5. si durante la entrevista surgió una necesidad de regla/agente/skill/hook/MCP propia, recuérdalo aquí como pendiente de una sesión dedicada — no antes;
6. próximo paso sugerido: abrir la carpeta como raíz en el editor.
 
No declares el proyecto "terminado" en sentido amplio: esto crea el andamiaje, no ejecuta el trabajo del proyecto.

Cómo adaptarla

Sustituye <carpeta-de-proyectos> por la carpeta donde guardes tus proyectos.
Los nombres de carpeta (contexto/, output/, docs/…) son un convenio: cámbialos en todo el texto si usas otros.
Los tres niveles de git son una recomendación de partida. Ajusta la tabla a la sensibilidad de tus datos.
Si trabajas con almacenamiento externo para material pesado, mantén la excepción del paso 1; si no, elimínala.
Revisa el aviso inicial: está pensado para quien responde por voz y puede sobrar.

Véase también

Referencias

Extend Claude with skills. Anthropic, documentación de Claude Code. Consultado el 2026-10-10. ↩ ↩² ↩³

Índice

Skill de proyecto nuevo para Claude Code

Prompt

Cómo adaptarla

Véase también

Referencias

Backlinks

enciclia.comEnciclopedia sobre inteligencia artificial

Índice

Skill de proyecto nuevo para Claude Code

Prompt

Cómo adaptarla

Véase también

Referencias

Footnotes

Backlinks