flowchart LR
A[Prompt<br/>instrucción puntual] --> B[Template<br/>instrucción parametrizable]
B --> C[Skill<br/>metodología reutilizable]
De una instrucción a una capacidad
En la última página de la sección anterior llegamos a un punto importante. Ya no necesitábamos escribir una instrucción completamente nueva cada vez que aparecía una tarea semejante. Podíamos construir una template: mantener fija una estructura y sustituir solamente aquello que cambiaba de un asunto a otro.
Por ejemplo:
Compara [CLAUSULA] con [ESTANDAR]
desde la posición de [PARTE].
Identifica las diferencias materiales y entrégalas en [FORMATO].
La plantilla resuelve un problema real. Reduce repetición, disminuye variaciones accidentales y permite que una instrucción que funciona vuelva a utilizarse.
Pero imaginemos ahora que la revisión de una cláusula no consiste simplemente en completar tres variables.
El abogado debe saber qué disposiciones relacionadas buscar, qué excepciones revisar, cuándo un precedente es comparable, qué debe tratarse como evidencia, cómo separar una desviación de una preferencia negociadora, cuándo falta información y qué condiciones obligan a escalar el asunto.
En ese momento aparece un límite.
La organización no quiere reutilizar solamente la redacción de un encargo.
Quiere reutilizar una manera de hacer el trabajo.
Ese es el salto que abre esta sección.
Un prompt formula una instrucción para una ejecución.
Una template hace reutilizable esa instrucción mediante partes variables.
Una skill, en el marco pedagógico de este handbook, hace reutilizable una capacidad o metodología delimitada.
La pregunta cambia de:
“¿Qué prompt debo escribir?”
A:
“¿Qué capacidad necesita este proceso?”
La palabra skill se utiliza de formas distintas en productos y arquitecturas concretas. Aquí no intentaremos imponer una definición universal. La utilizaremos como una categoría funcional para comprender el paso desde instrucciones reutilizables hacia capacidades profesionales más estables.
El límite de una plantilla
Consideremos una tarea recurrente: revisar cláusulas de limitación de responsabilidad en contratos tecnológicos.
Una template podría decir:
Analiza la cláusula de [MATERIA]
desde la posición de [PARTE]
aplicando [ESTANDAR].
Para cada hallazgo indica:
- texto relevante;
- diferencia;
- riesgo;
- recomendación.
La plantilla contiene una estructura razonable. Pero todavía deja ocultas preguntas metodológicas importantes.
¿Qué debe buscar exactamente el sistema cuando la materia es responsabilidad?
¿Debe revisar solamente la cláusula titulada “Limitación de responsabilidad”?
¿Debe mirar indemnidades?
¿Debe buscar excepciones en otras secciones?
¿Debe comprobar si un anexo modifica el cap?
¿Debe tratar un contrato anterior como estándar o solamente como precedente?
¿Qué hace si no encuentra la política vigente?
¿Puede concluir que la cláusula es aceptable?
Una template puede contener todas esas instrucciones. Podríamos seguir agregándolas hasta construir un documento enorme.
Pero entonces aparece una señal de diseño: quizás aquello que estamos intentando conservar ya no es simplemente una plantilla lingüística.
Estamos intentando conservar una metodología.
Tres niveles, tres preguntas
Conviene observar la progresión sin pensar todavía en detalles técnicos.
| Nivel | Pregunta principal | Ejemplo |
|---|---|---|
| Prompt | ¿Qué quiero que hagas ahora? | “Compara esta cláusula con el estándar.” |
| Template | ¿Cómo reutilizo esta instrucción? | “Compara [CLÁUSULA] con [ESTÁNDAR].” |
| Skill | ¿Cómo se realiza correctamente esta clase de tarea? | Metodología de revisión de responsabilidad contractual |
No se trata de que cada nivel elimine al anterior.
Una skill puede contener prompts.
Puede utilizar templates.
Puede recibir parámetros.
La progresión es acumulativa.
La diferencia importante es qué intentamos estabilizar.
Con el prompt estabilizamos poco: una instrucción concreta.
Con la template estabilizamos una estructura de instrucción.
Con la skill intentamos estabilizar una forma de ejecutar una tarea.
Del texto de la instrucción al método profesional
Veamos la misma revisión en tres versiones.
Prompt
Revisa esta cláusula de responsabilidad.
El sistema debe completar una gran cantidad de decisiones.
Template
Revisa [CLAUSULA] desde la posición de [PARTE]
y compárala con [ESTANDAR].
Ahora algunas decisiones se convierten en parámetros.
Skill
La capacidad podría describirse así:
CAPACIDAD
Evaluar una cláusula de limitación de responsabilidad
desde la posición del cliente.
MÉTODO
1. Identificar el cap general.
2. Identificar la base de cálculo.
3. Identificar excepciones y carve-outs.
4. Revisar indemnidades y disposiciones relacionadas.
5. Revisar anexos que puedan modificar el régimen.
6. Obtener el estándar vigente.
7. Comparar cada componente por separado.
8. Identificar precedentes comparables cuando exista desviación.
9. Distinguir política, estándar, precedente y excepción.
10. Señalar información faltante.
11. Mantener evidencia para cada hallazgo.
12. Producir una salida uniforme para revisión humana.
Aquí la diferencia se vuelve visible.
La organización ya no conserva solamente una frase.
Conserva una secuencia de operaciones y controles que representa una manera de trabajar.
Una capacidad no es “conocimiento jurídico general”
La palabra capacidad podría producir otra confusión.
Podría parecer que estamos intentando construir una especie de “abogado digital” que contenga todo el conocimiento y realice cualquier tarea.
El curso adopta la dirección contraria.
Una skill debería ser delimitada.
Por ejemplo:
extraer obligaciones del proveedor
es una capacidad.
comparar dos versiones de una cláusula
es otra.
verificar si un hallazgo está respaldado por un documento
es otra.
En cambio:
hacer Derecho
no constituye una capacidad útil para diseño.
Tampoco:
revisar cualquier asunto jurídico
La utilidad aparece cuando podemos identificar:
- qué entra;
- qué transformación se espera;
- qué reglas gobiernan la tarea;
- qué resultado debería producir;
- cómo reconocer si falló.
Eso permite convertir una práctica profesional en algo más observable.
La skill como explicitación de conocimiento práctico
Mucho trabajo jurídico funciona mediante conocimiento práctico que no siempre está formalizado.
Un abogado experimentado puede saber que, al revisar una cláusula de responsabilidad, debe mirar inmediatamente la definición de daños, las indemnidades, las excepciones, el SLA, el régimen de seguridad, las disposiciones de confidencialidad y ciertos anexos.
Puede hacerlo sin recitar conscientemente un checklist.
Pero si queremos reutilizar esa capacidad en una aplicación, compartirla entre equipos o evaluarla sistemáticamente, necesitamos hacer explícitas al menos las partes relevantes del método.
La skill funciona entonces como una unidad de conocimiento procedimental: no contiene solamente una posible respuesta; contiene instrucciones sobre cómo llegar a una clase de resultado.
Esta distinción será crucial más adelante.
Cuándo vale la pena convertir una tarea en skill
No toda interacción necesita transformarse en una capacidad formalizada.
Si una persona pide una única vez:
Corrige la redacción de este párrafo.
puede ser innecesario construir algo más.
En cambio, vale la pena pensar en una skill cuando aparecen varias señales: la tarea se repite, varias personas necesitan realizarla de forma semejante, existe una metodología reconocible, hay errores recurrentes que conviene controlar, la salida debe mantener cierta consistencia, queremos evaluar la capacidad separadamente o necesitamos saber qué reglas produjo cada resultado.
La lógica es parecida a crear una buena plantilla, pero el objeto de reutilización es más rico.
Un ejemplo: comparación de versiones contractuales
Supongamos que todos los días recibimos nuevas versiones de contratos.
Podríamos conservar esta template:
Compara [VERSION_A] y [VERSION_B].
Indica los cambios importantes.
Sin embargo, distintos usuarios pueden entender “importante” de manera diferente.
Una skill de comparación contractual podría establecer:
1. Alinear cláusulas equivalentes aunque cambie su numeración.
2. Detectar adiciones, eliminaciones y modificaciones.
3. Separar cambios puramente formales de cambios sustantivos.
4. Identificar si cambia:
- una obligación;
- un derecho;
- un plazo;
- un monto;
- una condición;
- una excepción;
- un remedio.
5. Mantener referencia a ambas versiones.
6. No inferir impacto jurídico cuando falten antecedentes.
7. Entregar una matriz de diferencias.
La template decía qué encargo formular.
La skill describe cómo ejecutar la comparación.
De la improvisación a una capacidad nombrable
Una ventaja práctica de esta separación es que podemos empezar a hablar de capacidades con nombres estables:
skill: extraer obligaciones
skill: comparar cláusulas
skill: revisar responsabilidad
skill: verificar evidencia
Eso permite que una organización discuta su sistema de manera diferente.
En vez de preguntar:
“¿Cuál era el prompt que usábamos?”
puede preguntar:
“¿Qué versión de la skill de responsabilidad utilizamos?”
O:
“¿La skill de verificación comprobó esta afirmación?”
La conversación cambia desde frases hacia componentes funcionales.
Skill no significa tool
Todavía debemos proteger una frontera importante.
Una skill puede decir:
Busca el estándar interno vigente.
Pero esa instrucción no significa que el sistema posea automáticamente acceso al repositorio donde se encuentra.
La skill expresa cómo debería realizarse la tarea.
Una tool, que estudiaremos en la sección siguiente, aporta un medio para consultar, calcular o actuar sobre sistemas externos.
Por ahora:
Skill = capacidad metodológica
Tool = medio operacional
No adelantaremos la arquitectura de tools. Basta comprender que saber qué debería hacerse y tener medios para hacerlo son problemas distintos.
Skill tampoco significa workflow
Podemos representar dentro de una skill una secuencia metodológica.
Eso no convierte automáticamente la skill en un workflow.
Más adelante utilizaremos workflow para tratar explícitamente estados, secuencias, condiciones de avance, transiciones y responsables.
En esta sección nos interesa algo previo: identificar qué capacidades existen antes de organizarlas en un proceso mayor.
El caso conductor
Retomemos la pregunta que acompaña el handbook:
Llegó un contrato de proveedor de IA. ¿Puede aprobarse?
En la sección anterior aprendimos a especificar la tarea.
Podíamos utilizar una template como:
Revisa [TIPO_DE_CONTRATO]
desde la posición de [PARTE]
priorizando [MATERIAS].
Distingue texto, inferencia e información faltante.
Ahora damos un paso adicional.
En vez de depender de que el usuario describa cada vez toda la metodología, queremos disponer de capacidades reutilizables:
extraer cláusulas relevantes
↓
comparar con estándar
↓
clasificar desviaciones
↓
verificar evidencia
Todavía no estamos organizando automáticamente el proceso completo.
Tampoco hemos conectado repositorios.
Ni hemos introducido agentes.
Estamos construyendo los bloques de saber hacer.
Qué debes recordar
Un prompt y una skill no son sinónimos.
El prompt formula una instrucción.
La template hace esa instrucción reutilizable mediante variables y parámetros.
La skill intenta encapsular una capacidad profesional delimitada.
El cambio importante no es de longitud.
Una skill no es simplemente un prompt más largo.
El cambio es de función:
instrucción
↓
instrucción reutilizable
↓
metodología reutilizable
Una skill puede contener prompts y templates, pero su unidad conceptual es la capacidad.
Tampoco debemos confundir capacidad metodológica con capacidad operacional. Saber que hay que consultar una política no significa todavía poder acceder al repositorio que la contiene.
El problema que todavía queda abierto
Ya podemos decir que necesitamos una skill para revisar una cláusula.
Pero todavía no sabemos qué significa diseñarla bien.
¿Qué elementos debe contener?
¿Cómo se define su alcance?
¿Dónde se ubican instrucciones, criterios, ejemplos y controles?
¿Cómo especificamos el output?
¿Y cómo indicamos cuándo una skill debe o no debe utilizarse?
La siguiente página abre esa caja y estudia la anatomía de una skill.