Menú
Use when the user runs /skill-creator or asks to "set up project skills", "create
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Project and feature planning with 4 adaptive phases - Specify, Design, Tasks, Execute. Auto-sizes depth by complexity. Creates atomic tasks with verification criteria, atomic git commits, requirement traceability, and persistent memory across sessions. Stack-agnostic. Use when (1) Starting new projects (initialize vision, goals, roadmap), (2) Working with existing codebases (map stack, architecture, conventions), (3) Planning features (requirements, design, task breakdown), (4) Implementing with verification and atomic commits, (5) Quick ad-hoc tasks (bug fixes, config changes), (6) Tracking decisions/blockers/deferred ideas across sessions, (7) Pausing/resuming work. Triggers on "initialize project", "map codebase", "specify feature", "discuss feature", "design", "tasks", "implement", "validate", "verify work", "UAT", "quick fix", "quick task", "pause work", "resume work". Do NOT use for architecture decomposition analysis (use architecture skills) or technical design docs (use create-technical-design-doc).
Use after finishing a non-trivial feature or change (not a trivial tweak like a rename, version bump, or typo), or whenever the user asks to "explain what you did", "how does this work", "walk me through it", "explain like I'm five", "under the hood", "why did you do it that way", "me explica", "como funciona", or "por que". Also use when the user wants a written or visual (HTML) walkthrough of a change, saved to study later. Produces a deep, beginner-friendly explanation file with diagrams, analogies, and references in a gitignored explanations/ folder.
Use at the START of any feature, fix, refactor, or change in a project. Checks for the project's skill tree (skills/project-context and skills/spec-driven-development), loads project context, and routes the task into the project's spec-driven workflow. If no project skills exist, offers once to create them with /skill-creator. Triggers on "add a feature", "implement", "fix", "refactor", "build", "change", "new endpoint", "new module", or starting any development task.
| name | creating-project-skills |
| description | Use when the user runs /skill-creator or asks to "set up project skills", "create |
Generates a structured, per-project skill tree. Four phases. Copy this checklist:
Bootstrap progress:
- [ ] Phase 1: DETECT (read codebase)
- [ ] Phase 2: INTERVIEW (ask only what code can't answer)
- [ ] Phase 3: GENERATE (write the tree)
- [ ] Phase 4: REPORT (summary + next step)
package.json .name or root folder), framework (@nestjs/core, express,
next, fastify, etc.), test tool (jest, vitest, mocha), language (TS if tsconfig.json).find . -name "*.module.ts" -not -path "*/node_modules/*" → base name = module.
b. Monorepo: packages/*/package.json or apps/*/package.json → each is a module.
c. Flat: src/*/ dirs with ≥5 source files → each is a module.
d. Fallback: ask the user to list the main modules.*.entity.ts, *.model.ts, *.schema.ts, schema.prisma.EventEmitter, @nestjs/event-emitter, Bull, RabbitMQ, Kafka, HTTP
clients (HttpModule, axios, fetch) between modules.{name} at {path} — what is its
main responsibility?" (skip obvious ones like auth, users).Read the templates with the Read tool (not auto-loaded):
references/sdd-clone/references/project-context-template.mdreferences/sdd-clone/references/module-template.mdreferences/sdd-clone/references/sdd-skill-template.mdreferences/sdd-clone/references/tdd-immutable.mdGenerate in this order:
skills/project-context/SKILL.mdFill project-context-template.md: project name, domain, core entities, tech stack, code
conventions, a module-map table linking each <module>/SKILL.md, communication patterns, global
business rules.
skills/spec-driven-development/ (full clone + project overlay)cp -r references/sdd-clone/* skills/spec-driven-development/
This brings SKILL.md + all references/*.md from tlc-spec-driven (stack-agnostic).skills/spec-driven-development/SKILL.md header using sdd-skill-template.md, filled
with the project name + framework, and the instruction to load project-context then the affected
<module>/SKILL.md before any code.skills/spec-driven-development/references/project-conventions.md from DETECT data
(framework, module structure, file/class/service naming, test pattern, one representative module
folder tree).references/tdd-immutable.md into
skills/spec-driven-development/references/tdd-immutable.md, and ensure the SKILL.md prominently
links it: tests are written first in phase 1 as the frozen contract; implementation conforms to
the tests; tests are never edited to make code pass.<module>/SKILL.md per moduleFill module-template.md: responsibility, business rules, internal structure + naming, key
abstractions, and relationships — Emits / Consumes / Depends-on — plus known gotchas.
<module>/<submodule>/SKILL.mdFor submodules with ≥3 significant files (services, controllers, guards, strategies), generate a deeper skill with the same template.
Skills generated:
✓ skills/project-context/SKILL.md
✓ skills/spec-driven-development/SKILL.md (+ references/)
✓ {module}/SKILL.md ...
New module → copy an existing {module}/SKILL.md and adapt.
New submodule → {module}/{submodule}/SKILL.md, same template.
Next: start any feature — using-project-skills will route you through spec-driven-development.