Project Templates
Los templates de proyecto del lab: el template de Next.js, el template de herramienta CLI Python, el template del research framework y el template de skill de agente. Cómo se estructura cada uno, qué contiene y cómo arrancar un proyecto nuevo desde cada uno.
Propósito
Esta página documenta los templates de proyecto del lab. El lab tiene cuatro templates:
- Next.js template — para aplicaciones web full-stack.
- CLI Python tool template — para herramientas de línea de comandos que invocan los agentes del lab.
- Research framework template — para añadir una herramienta nueva al research framework.
- Agent skill template — para añadir una capacidad nueva a los agentes del lab.
Cada template tiene una estructura estándar, un requisito de documentación estándar y un workflow estándar. Un proyecto nuevo debería escoger el template más cercano y seguirlo.
Selección de template
| Si estás construyendo... | Usa este template |
|---|---|
| Una aplicación web | Next.js template |
| Una herramienta CLI que invocan los agentes | CLI Python tool template |
| Una herramienta de research nueva | Research framework template |
| Una capacidad de agente nueva | Agent skill template |
| Otra cosa | Abre una discusión con el operator |
Next.js template
Ubicación
{workspace-root}/stack_inicial_proyectos/front-end/nextjs/
Stack
- Next.js 15
- React 19
- Tailwind CSS v4
- Zustand (state)
- shadcn/ui (components)
- TypeScript
Estructura
Skills
El .agents/skills/ del template incluye:
nextjs-best-practices/— las best practices de Next.js del framework.react-patterns/— patrones comunes de React.tailwind-utility/— clases utility de Tailwind.zustand-state/— gestión de estado con Zustand.shadcn-ui/— componentes de shadcn/ui.
Requisito de documentación
Cada proyecto creado desde este template debe tener un directorio docs/ con:
README.md— project overview.code-reference.md— interfaces, funciones, patrones.architecture.md— arquitectura técnica.
La documentación se actualiza con cada commit que cambie la arquitectura o las interfaces públicas.
Workflow
- Copia el template a un directorio nuevo.
- Actualiza
package.jsoncon el nombre del proyecto y las dependencias. - Actualiza
app/page.tsxcon la home page específica del proyecto. - Añade las rutas específicas del proyecto bajo
app/. - Añade los componentes específicos bajo
components/. - Añade los stores específicos bajo
stores/. - Escribe la documentación bajo
docs/. - Inicializa git y haz commit.
- Corre
npm installynpm run devpara verificar.
CLI Python tool template
Ubicación
{workspace-root}/devclaw-tools/stack-template/tool_name/ (estructura general)
Una instancia real está en {workspace-root}/movie-scraper-tools/tools/torrent-finder/.
Stack
- Python 3.10+
- Click (CLI)
- Pydantic (data validation)
- requests, beautifulsoup4, lxml (HTTP y parsing)
- pytest (testing)
- AutoSkills (contexto del proyecto para el coding sub-agent)
Estructura
Skills
El .agents/skills/ del template incluye el contenido AutoSkills. El package.json es un pequeño fichero JSON que el coding sub-agent usa para entender el proyecto.
Requisito de documentación
Cada herramienta debe tener:
README.md— qué hace la herramienta, cómo instalarla, cómo usarla.TOOL.md— la spec técnica (input schema, output schema, ejemplos, failure modes).SKILL.md— el fichero de activación que lee el Coordinator.AGENTS.md— instrucciones para el coding sub-agent.
El TOOL.md es el contrato entre la herramienta y el agente. Se actualiza cuando cambia la interfaz de la herramienta.
Workflow
- Copia el template a un directorio nuevo bajo
tools/. - Actualiza
tool_name,package.jsonypyproject.toml. - Implementa
lib.py(core logic) ymain.py(CLI entry point). - Escribe tests bajo
tests/. - Escribe
README.md,TOOL.md,SKILL.mdyAGENTS.md. - Registra la herramienta en el
tools.jsondel proyecto. - Corre los tests con
pytest. - Commit.
Research framework template
Ubicación
Una herramienta nueva se añade al research framework creando un nuevo paquete bajo {research-root}/docs/orchestrator/tools/tool-N-name/ o {research-root}/docs/domains/<domain>/tool-N-name/.
Una instancia real es docs/orchestrator/tools/tool-h-report-generator/.
Estructura
Skills
El skills/<skill-name>/SKILL.md de la herramienta describe cuándo usarla y el workflow.
Requisito de documentación
Cada herramienta de research debe tener:
README.md— qué hace la herramienta.docs/README.md— documentación más profunda.skills/<skill-name>/SKILL.md— el fichero de activación.tests/— tests unitarios para la lógica de la herramienta.
La API pública de la herramienta está documentada en docs/README.md con los esquemas de input y output.
Workflow
- Crea el paquete bajo
docs/orchestrator/tools/tool-N-name/(usa la siguiente letra disponible para el prefijo). - Implementa los módulos de la herramienta bajo
src/. - Escribe tests bajo
tests/. - Escribe el SKILL.md y la documentación.
- Registra la herramienta en el orquestador (si es necesario).
- Corre los tests con
pytest. - Verifica que la herramienta se puede invocar a través del CLI del orquestador.
Agent skill template
Ubicación
Los skills se añaden al directorio .agents/skills/ del agente. Un skill es un único fichero SKILL.md (y ficheros de soporte opcionales).
Estructura
Formato de SKILL.md
El SKILL.md tiene un YAML frontmatter y un body markdown:
Requisito de documentación
Cada skill debe tener un SKILL.md con el frontmatter (name, description) y el body (when to use, workflow, inputs, outputs, failure modes).
El skill lo carga el skill loader del Coordinator cuando las frases disparadoras matchean.
Workflow
- Crea un directorio bajo
.agents/skills/. - Escribe
SKILL.mdcon el frontmatter y el body. - Añade los ficheros de soporte (README, examples).
- Verifica que el Coordinator puede activar el skill.
Convenciones
Todos los templates comparten estas convenciones:
- La documentación es parte del deliverable. Un proyecto sin documentación está incompleto.
- Los skills son first-class. Cada proyecto tiene un directorio
.agents/skills/con los skills relevantes. - Los tests son first-class. Cada proyecto tiene un directorio
tests/con tests unitarios. - La configuración es explícita. La configuración está en ficheros, no en código.
- La sanitización es obligatoria. Sin usernames reales, sin nombres de agentes reales, sin rutas absolutas reales en la documentación. Usa placeholders.