Saltar al contenido principal

Ejecucion de Skill Individual

La ejecucion de skill individual es la via rapida — un agente, un dominio, una tarea enfocada. Sin sobrecarga de orquestacion, sin coordinacion multiagente. La habilidad se activa automaticamente desde tu prompt en lenguaje natural.

Cuando Usar Skill Individual​

Usa esto cuando tu tarea cumpla TODOS estos criterios:

  • Pertenece a un dominio — la tarea completa pertenece a frontend, backend, mobile, base de datos, diseno, infraestructura u otro dominio individual
  • Autocontenida — sin cambios de contrato API entre dominios, sin cambios de backend necesarios para una tarea de frontend
  • Alcance claro — sabes cual deberia ser el resultado (un componente, un endpoint, un esquema, una correccion)
  • Sin coordinacion — otros agentes no necesitan ejecutarse antes ni despues

Ejemplos de tareas de skill individual:

  • Construir un componente de UI
  • Agregar un endpoint de API
  • Corregir un bug en una capa
  • Disenar una tabla de base de datos
  • Escribir un modulo de Terraform
  • Traducir un conjunto de cadenas i18n
  • Crear una seccion del sistema de diseno

Cambiar a multiagente (/work u /orchestrate) cuando:

  • El trabajo de UI necesita un nuevo contrato API (frontend + backend)
  • Una correccion se propaga entre capas (agentes de debug + implementacion)
  • La funcionalidad abarca frontend, backend y base de datos
  • El alcance crece mas alla de un dominio despues de la primera iteracion

Lista de Verificacion Previa​

Antes de escribir el prompt, responde estas cuatro preguntas (se mapean a los cuatro elementos de la Estructura de Prompt):

ElementoPreguntaPor Que Importa
ObjetivoQue artefacto especifico debe crearse o modificarse?Previene ambiguedad — "agregar un boton" vs "agregar un formulario con validacion"
ContextoQue stack, framework y convenciones aplican?El agente detecta desde archivos del proyecto, pero ser explicito es mejor
RestriccionesQue reglas deben seguirse? (estilo, seguridad, rendimiento, compatibilidad)Sin restricciones, los agentes usan valores por defecto que pueden no coincidir con tu proyecto
Completado CuandoQue criterios de aceptacion verificaras?Da al agente un objetivo y a ti una lista de verificacion

Si falta algun elemento en tu prompt, el agente:

  • Incertidumbre LOW: Aplica valores por defecto y lista suposiciones
  • Incertidumbre MEDIUM: Presenta 2-3 opciones y procede con la mas probable
  • Incertidumbre HIGH: Se bloquea y hace preguntas (no escribira codigo)

Plantilla de Prompt​

Build <specific artifact> using <stack/framework>.
Constraints: <style, performance, security, or compatibility constraints>.
Acceptance criteria:
1) <testable criterion>
2) <testable criterion>
3) <testable criterion>
Add tests for: <critical test cases>.

Desglose de la Plantilla​

PartePropositoEjemplo
Build <specific artifact>El Objetivo — que crear"Build a user registration form component"
using <stack/framework>El Contexto — stack tecnologico"using React + TypeScript + Tailwind CSS"
Constraints:Reglas que el agente debe seguir"accessible labels, no external form libraries, client-side validation only"
Acceptance criteria:Completado Cuando — resultados verificables"1) email format validation 2) password strength indicator 3) submit disabled while invalid"
Add tests for:Requisitos de pruebas"valid/invalid submit paths, edge cases for email validation"

Ejemplos Reales​

Frontend: Formulario de Login​

Create a login form component in React + TypeScript + Tailwind CSS.
Constraints: accessible labels, client-side validation with Zod, no external form library beyond @tanstack/react-form, shadcn/ui Button and Input components.
Acceptance criteria:
1) Email validation with meaningful error messages
2) Password minimum 8 characters with feedback
3) Disabled submit button while form is invalid
4) Keyboard and screen-reader friendly (ARIA labels, focus management)
5) Loading state while submitting
Add unit tests for: valid submission path, invalid email, short password, loading state.

Flujo de ejecucion esperado:

  1. Skill activation: oma-frontend activates (keywords: "form", "component", "Tailwind CSS", "React")
  2. Difficulty assessment: Medium (2-3 files, some design decisions around validation UX)
  3. Resources loaded:
    • execution-protocol.md (always)
    • snippets.md (form + Zod patterns)
    • component-template.tsx (React structure)
  4. CHARTER_CHECK output: 
    CHARTER_CHECK:
    - Clarification level: LOW
    - Task domain: frontend
    - Must NOT do: backend API, database, mobile screens
    - Success criteria: form validation, accessibility, loading state, tests
    - Assumptions: Next.js App Router, @tanstack/react-form + Zod, shadcn/ui, FSD-lite architecture
  5. Implementation:
    • Creates src/features/auth/components/login-form.tsx (Client Component with "use client")
    • Creates src/features/auth/utils/login-schema.ts (Zod schema)
    • Creates src/features/auth/components/skeleton/login-form-skeleton.tsx
    • Uses shadcn/ui <Button>, <Input>, <Label> (read-only, no modifications)
    • Form handled by @tanstack/react-form with Zod validation
    • Absolute imports with @/
    • One component per file
  6. Verification:
    • Checklist: ARIA labels present, semantic headings, keyboard navigation works
    • Mobile: renders correctly at 320px viewport
    • Performance: no CLS
    • Tests: Vitest test file at src/features/auth/utils/__tests__/login-schema.test.ts

Backend: Endpoint REST API​

Add a paginated GET /api/tasks endpoint that returns tasks for the authenticated user.
Constraints: Repository-Service-Router pattern, parameterized queries, JWT auth required, cursor-based pagination.
Acceptance criteria:
1) Returns only tasks owned by the authenticated user
2) Cursor-based pagination with next/prev cursors
3) Filterable by status (todo, in_progress, done)
4) Response includes total count
Add tests for: auth required, pagination, status filter, empty results.

Flujo de ejecucion esperado:

  1. Skill activation: oma-backend activates (keywords: "API", "endpoint", "REST")
  2. Stack detection: Reads pyproject.toml or package.json to determine language/framework. If stack/ exists, loads conventions from there.
  3. Difficulty assessment: Medium (2-3 files: route, service, repository, plus test)
  4. Resources loaded:
    • execution-protocol.md (always)
    • stack/snippets.md if available (route, paginated query patterns)
    • stack/tech-stack.md if available (framework-specific API)
  5. CHARTER_CHECK: 
    CHARTER_CHECK:
    - Clarification level: LOW
    - Task domain: backend
    - Must NOT do: frontend UI, mobile screens, database schema changes
    - Success criteria: authenticated endpoint, cursor pagination, status filter, tests
    - Assumptions: existing JWT auth middleware, PostgreSQL, existing Task model
  6. Implementation:
    • Repository: TaskRepository.find_by_user(user_id, cursor, status, limit) with parameterized query
    • Service: TaskService.get_user_tasks(user_id, cursor, status, limit) — business logic wrapper
    • Router: GET /api/tasks with JWT auth middleware, input validation, response formatting
    • Tests: auth required returns 401, pagination returns correct cursor, filter works, empty returns 200 with empty array

Mobile: Pantalla de Configuracion​

Build a settings screen in Flutter with profile editing (name, email, avatar), notification preferences (toggle switches), and a logout button.
Constraints: Riverpod for state management, GoRouter for navigation, Material Design 3, handle offline gracefully.
Acceptance criteria:
1) Profile fields pre-populated from user data
2) Changes saved on submit with loading indicator
3) Notification toggles persist locally (SharedPreferences)
4) Logout clears token storage and navigates to login
5) Offline: show cached data with "offline" banner
Add tests for: profile save, logout flow, offline state.

Flujo de ejecucion esperado:

  1. Skill activation: oma-mobile activates (keywords: "Flutter", "screen", "mobile")
  2. Difficulty assessment: Medium (settings screen + state management + offline handling)
  3. Resources loaded:
    • execution-protocol.md
    • snippets.md (screen template, Riverpod provider pattern)
    • screen-template.dart
  4. CHARTER_CHECK: 
    CHARTER_CHECK:
    - Clarification level: LOW
    - Task domain: mobile
    - Must NOT do: backend API changes, web frontend, database schema
    - Success criteria: profile editing, notification toggles, logout, offline
    - Assumptions: existing auth service, Dio interceptors, Riverpod, GoRouter
  5. Implementation:
    • Screen: lib/features/settings/presentation/settings_screen.dart (Stateless Widget with Riverpod)
    • Providers: lib/features/settings/providers/settings_provider.dart
    • Repository: lib/features/settings/data/settings_repository.dart
    • Offline handling: Dio interceptor catches SocketException, falls back to cached data
    • All controllers disposed in dispose() method

Base de Datos: Diseno de Esquema​

Design a database schema for a multi-tenant SaaS project management tool. Entities: Organization, Project, Task, User, TeamMembership.
Constraints: PostgreSQL, 3NF, soft delete with deleted_at, audit fields (created_at, updated_at, created_by), row-level security for tenant isolation.
Acceptance criteria:
1) ERD with all relationships documented
2) External, conceptual, and internal schema layers documented
3) Index strategy for common query patterns (tasks by project, tasks by assignee)
4) Capacity estimation for 10K orgs, 100K users, 1M tasks
5) Backup strategy with full + incremental cadence
Add deliverables: data standards table, glossary, migration script.

Flujo de ejecucion esperado:

  1. Skill activation: oma-db activates (keywords: "database", "schema", "ERD", "migration")
  2. Difficulty assessment: Complex (architecture decisions, multiple entities, capacity planning)
  3. Resources loaded:
    • execution-protocol.md
    • document-templates.md (deliverable structure)
    • examples.md
    • anti-patterns.md (review during optimization)
  4. CHARTER_CHECK: 
    CHARTER_CHECK:
    - Clarification level: LOW
    - Task domain: database
    - Must NOT do: API implementation, frontend UI, infrastructure
    - Success criteria: schema, ERD, indexes, capacity estimate, backup strategy
    - Assumptions: PostgreSQL, 3NF, soft delete, multi-tenant with RLS
  5. Workflow: Explore (entities, relationships, access patterns, volume estimates) -> Design (external/conceptual/internal schemas, constraints, lifecycle fields) -> Optimize (indexes for query patterns, partitioning strategy, backup plan, anti-pattern review)
  6. Deliverables:
    • External schema summary (views per role: admin, project manager, team member)
    • Conceptual schema with ERD (Organization 1:N Project, Project 1:N Task, Organization 1:N TeamMembership, etc.)
    • Internal schema with physical DDL, indexes, partitioning
    • Data standards table (field naming rules, type conventions)
    • Glossary (tenant, workspace, assignee, etc.)
    • Capacity estimation sheet
    • Backup strategy (daily full + hourly incremental, 30-day retention)
    • Migration script

Lista de Verificacion de Puerta de Calidad​

Despues de que el agente entregue su salida, verifica estos elementos antes de aceptar:

Verificaciones Universales (Todos los Agentes)​

  • El comportamiento coincide con los criterios de aceptacion — cada criterio de tu prompt esta satisfecho
  • Las pruebas cubren el camino feliz y casos limite clave — no solo el camino feliz
  • Sin cambios de archivos no relacionados — solo se modificaron archivos relevantes para la tarea
  • Modulos compartidos no rotos — importaciones, tipos e interfaces usadas por otro codigo siguen funcionando
  • Se siguio el charter — las restricciones "Must NOT do" fueron respetadas
  • Lint, typecheck, build pasan — ejecuta las verificaciones estandar de tu proyecto

Especificos de Frontend​

  • Accesibilidad: elementos interactivos tienen aria-label, encabezados semanticos, la navegacion por teclado funciona
  • Movil: renderiza correctamente en breakpoints 320px, 768px, 1024px, 1440px
  • Rendimiento: sin CLS, objetivo FCP cumplido
  • Error boundaries y loading skeletons implementados
  • Componentes shadcn/ui no modificados directamente (se usan wrappers)
  • Importaciones absolutas con @/ (sin ../../ relativo)

Especificos de Backend​

  • Arquitectura limpia mantenida: sin logica de negocio en manejadores de ruta
  • Todas las entradas validadas (sin confiar en entrada del usuario)
  • Solo consultas parametrizadas (sin interpolacion de strings en SQL)
  • Excepciones personalizadas via modulo centralizado de errores (sin excepciones HTTP directas)
  • Endpoints de autenticacion con limite de tasa

Especificos de Mobile​

  • Todos los controladores liberados en el metodo dispose()
  • Offline manejado con gracia
  • Objetivo 60fps mantenido (sin jank)
  • Probado en iOS y Android

Especificos de Base de Datos​

  • Al menos 3NF (o justificacion documentada para desnormalizacion)
  • Las tres capas de esquema documentadas (externa, conceptual, interna)
  • Restricciones de integridad explicitas (entidad, dominio, referencial, regla de negocio)
  • Revision de anti-patrones completada

Senales de Escalamiento​

Observa estas senales que indican que deberias cambiar de skill individual a ejecucion multiagente:

SenalQue SignificaAccion
El agente dice "esto requiere un cambio de backend"La tarea tiene dependencias entre dominiosCambiar a /work — agregar agente backend
El CHARTER_CHECK del agente muestra elementos "Must NOT do" que realmente se necesitanEl alcance excede un dominioPlanificar la funcionalidad completa con /plan primero
La correccion se propaga a 3+ archivos en diferentes capasUna correccion afecta multiples dominiosUsar /debug con alcance mas amplio, o /work
El agente descubre un desajuste en el contrato APIDesacuerdo frontend/backendEjecutar /plan para definir contratos, luego regenerar ambos agentes
La puerta de calidad falla en puntos de integracionLos componentes no se conectan correctamenteAgregar paso de revision QA: oma agent:spawn qa "Review integration"
La tarea crece de "un componente" a "tres componentes + nueva ruta + API"Ampliacion del alcance durante la ejecucionDetener, ejecutar /plan para descomponer, luego /orchestrate
El agente se bloquea con clarificacion HIGHRequisitos fundamentalmente ambiguosResponder las preguntas del agente o ejecutar /brainstorm para clarificar el enfoque

La Regla General​

Si te encuentras regenerando el mismo agente mas de dos veces con refinamientos, la tarea probablemente es multidominio y necesita /work o como minimo un paso /plan para descomponerla correctamente.