Agent skill

team-setup

Esta skill debe usarse cuando el usuario pide 'configura un team', 'prepara equipo de agentes', 'crea un team de agentes', 'setup del team', 'team de agentes para', 'orquesta agentes', 'team-setup', 'arma un equipo', 'necesito un team para', o cuando quiere coordinar multiples agentes trabajando en repos/directorios distintos. Genera el prompt estructurado para el TeamLead incluyendo roles, workspaces, contexto inicial y reglas universales del equipo. Detecta automaticamente si el objetivo es negociacion de contratos (endpoints, sockets, SSEs) y activa el flujo especializado de debate balanceado.

Stars 1
Forks 0

Install this agent skill to your Project

npx add-skill https://github.com/DieGopherLT/dotclaudefiles/tree/main/plugins/dotclaudefiles/skills/team-setup

SKILL.md

Team Setup

Extract team configuration from context or user input, then generate a structured TeamLead prompt.

Phase 0: Pre-flight

Before gathering configuration, orient the user on two setup decisions:

0.1 Display Mode

Ask which display mode they prefer, or infer from context:

  • auto — split-panes if tmux is available, falls back to in-process. Best for most setups.
  • in-process — all teammates run inside the current terminal; switch with Shift+Down.
  • tmux — forces split-panes; requires tmux.

If unsure, default to auto and mention it.

0.2 Team Size & Task Budget

Share these guidelines so the user can plan their team accordingly:

  • Optimal team size: 3–5 teammates. More than 5 increases token cost and coordination overhead significantly.
  • Task budget per teammate: 5–6 tasks each keeps everyone productive without overloading any agent.
  • File ownership: each teammate should own different files — parallel edits to the same file cause conflicts.

Phase 1: Gather Configuration

Gather the following before generating the prompt. Extract from context first; use AskUserQuestion for anything missing.

1.1 Agents & Roles

For each agent on the team, collect:

  • Role name: What this agent represents (e.g., "Frontend Engineer", "Backend Engineer", "QA")
  • Responsibilities: What this agent is accountable for
  • Workspace path: Absolute path to the repo/directory on the filesystem where this agent works
  • Model (optional): Which Claude model to assign to this agent. Recommendations:
    • haiku — research, QA, simple review tasks
    • sonnet — general implementation (default if unspecified)
    • opus — complex architectural decisions, critical reviews

1.2 Initial Context

For each agent, determine what context to provide upfront:

  • CLAUDE.md files in their workspace
  • Relevant architecture docs, schemas, or specs
  • Or instructions for where the agent should look to orient itself

1.3 Team Type

Detect the team's objective from context. Two main types:

  • General team: Agents collaborate toward a common goal (code, infra, data, etc.)
  • Contract negotiation: Frontend and backend agents negotiate an API/socket/SSE contract

If the objective involves defining endpoints, events, payloads, or communication protocols between a frontend and a backend, treat it as a contract negotiation and read references/contract-negotiation.md to include the specialized debate flow in the TeamLead prompt.


Phase 2: Generate TeamLead Prompt

Build the TeamLead prompt with these sections:

Section A: Team Overview

You are the TeamLead for a [general | contract negotiation] team.
Your job is to coordinate the following agents and drive them toward [objective].

## Agents

- [Role Name] — [Responsibilities]
  Workspace: [absolute path]
  Initial context: [CLAUDE.md path or "read CLAUDE.md and explore the repo structure"]

- [Role Name] — [Responsibilities]
  Workspace: [absolute path]
  Initial context: [...]

Section B: Universal Team Rules

Always include this block verbatim:

## Team Rules (non-negotiable)

1. No agent may make file modifications or commits without explicit order from you (TeamLead)
   or from the user. If an agent believes it needs to write code, it must propose the change
   and wait for approval before touching the filesystem.

2. Task tracking: whenever an agent works on 3 or more files in a single task, it must use
   the Tasks tool to register and track progress. Single-file or two-file edits do not require
   task registration.

3. Agents are free to communicate with each other directly. However, any decision that affects
   scope, architecture, or implementation direction must be surfaced to you (TeamLead) before
   it is acted upon. You decide whether it also needs to go to the user.

4. Doubt escalation: when any agent has a question — about business rules, UX behavior,
   or anything outside its own domain — it may ask the user directly using AskUserQuestion,
   or route it through you if it requires team-level context or coordination. Either path
   is valid; use judgment based on the scope of the question.

Section C: Objective & First Actions

Describe what the team should accomplish and list the first concrete actions the TeamLead should take:

  • Orient each agent to its workspace
  • Provide initial context
  • Kick off the first round of work (or the contract negotiation debate)

Phase 3: Output

Present the generated TeamLead prompt to the user in a code block so they can copy it directly. Confirm it covers their intent and offer to adjust roles, paths, or objectives before they proceed.

After presenting the prompt, include this limitations note as a brief callout — not inside the prompt itself:

Note: Claude Code agent teams are experimental. Keep in mind:
- /resume does not restore teammates — if the session closes, the team is gone.
- Teammates cannot spawn their own teams (no nested teams).
- Only one team can be active per session.

Use references/teamlead-prompt-template.md as the structural template for the generated prompt. It defines the exact sections and ordering to follow.


Resources

  • references/contract-negotiation.md — Detailed rules and flow for the frontend/backend contract negotiation case. Load this when team type is contract negotiation.
  • references/teamlead-prompt-template.md — Full template for the generated TeamLead prompt. Always use this as the base for Phase 3 output.

Expand your agent's capabilities with these related and highly-rated skills.

DieGopherLT/dotclaudefiles

plan-feature

1 0
Explore
DieGopherLT/dotclaudefiles

smart-interview

Esta skill debe usarse cuando el usuario pregunta "¿Preguntas?", "¿Tienes dudas?", "¿Tienes preguntas?", "¿Quieres aclarar algo?", "¿Necesitas aclarar algo?", "aclara lo que necesites", o cuando quiere aterrizar requerimientos antes de planear. Tambien la invoca plan-feature en Phase 3. Ejecuta entrevista estructurada para obtener requerimientos cuantificables, reglas de negocio traducibles a codigo, y flujos del sistema; luego anota los resultados en el plan.

1 0
Explore
DieGopherLT/dotclaudefiles

post-implementation

Esta skill debe usarse cuando el usuario pide "haz review de los cambios", "review the changes", "aplica el post-implementacion", "apply post-implementation", "run post-implementation", o cuando el plan aprobado instruye "invoke /smart-plan:post-implementation". Ejecuta workflow post-implementacion despues de que el codigo este completo con quality review (3 reviewers paralelos), auto-fix de issues (confianza >= 80%), documentacion del feature, y commit opcional. Puede usarse despues de cualquier implementacion, no solo smart-plan.

1 0
Explore
DieGopherLT/dotclaudefiles

smart-delegation

Esta skill debe usarse cuando Claude detecta que una implementacion es lo suficientemente grande como para dividirla en sub-agentes (5+ archivos, dependencias entre cambios, nuevas abstracciones que otros archivos consumen), cuando el usuario pide "delega la implementacion", "orquesta los implementadores", "usa sub-agentes", "delegate to sub-agents", "orchestrate implementers", o cuando plan-feature invoca la delegacion tras aprobar un plan.

1 0
Explore
DieGopherLT/dotclaudefiles

tdd-workflow

Esta skill debe usarse cuando el usuario pide "aplicar TDD", "desarrollo guiado por tests", "test-driven development", "red green refactor", "ciclo RGR", "escribir tests primero", "nueva feature con TDD", "mejorar testabilidad", "filosofia TDD", o menciona Iron Laws, TDD philosophy, o quiere entender el proceso TDD. NO usar cuando el usuario pide agregar tests a un proyecto existente o setup de testing — eso es testing:add-testing.

1 0
Explore
DieGopherLT/dotclaudefiles

add-testing

Esta skill debe usarse cuando el usuario pide "agregar tests a proyecto existente", "add testing to existing project", "setup de testing", "configurar infraestructura de tests", "pipeline completo de testing", "quiero tests para este modulo", "agregar cobertura de tests", "add test coverage", "integrar testing al proyecto". Ejecuta pipeline completo de 7 pasos: auditoria de testabilidad, adaptacion condicional de codigo, investigacion de dependencias, implementacion de tests, auditoria de calidad de inputs, reporte de cobertura y generacion de reglas del proyecto.

1 0
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results