flowchart LR
A[Input<br/>documento + parámetros] --> B[Skill<br/>metodología]
B --> C[Output<br/>resultado estructurado]
Qué es una skill
Anatomía de una capacidad reutilizable: alcance, metodología, instrucciones, criterios, ejemplos, controles, output y reglas de uso.
En la página anterior cambiamos la pregunta.
Ya no preguntamos solamente:
“¿Qué prompt funciona?”
Preguntamos:
“¿Qué capacidad necesita este proceso?”
Pero ponerle un nombre a una capacidad no basta.
Supongamos que creamos una carpeta denominada:
skill_revision_contractualy dentro escribimos:
Revisa bien el contrato.El nombre puede sonar organizado. La capacidad sigue estando casi completamente indefinida.
Para que una skill sea útil necesitamos poder explicar qué hace, cómo lo hace, bajo qué criterios, con qué límites y qué resultado debe producir.
Idea central
En el marco pedagógico de este handbook, una skill es una capacidad delimitada que encapsula una metodología reutilizable para realizar una tarea.
Puede incluir:
capacidad + metodología + instrucciones + criterios + ejemplos + controles + output + reglas de uso.
No todos los productos representan una skill de esta manera. Aquí utilizamos estos componentes porque permiten diseñar y evaluar mejor una capacidad profesional.
Una skill como contrato funcional
Una forma útil de pensar una skill es imaginar que estamos redactando el contrato funcional de una pequeña capacidad.
No un contrato jurídico.
Un contrato en el sentido de:
“Si recibes esta clase de entrada, debes realizar esta clase de trabajo, respetar estas reglas y producir esta clase de salida.”
Por ejemplo:
NOMBRE
Revisión de limitación de responsabilidad
CAPACIDAD
Evaluar una cláusula frente a un estándar proporcionado.
ENTRADA
Cláusula + posición contractual + estándar aplicable.
MÉTODO
Extraer → comparar → clasificar → justificar.
CONTROLES
No inventar criterios. No presentar inferencias como texto.
SALIDA
Matriz de hallazgos y desviaciones.Este esquema todavía es simplificado. Pero ya permite comprender por qué una skill es algo más que un nombre.
Capacidad delimitada
El primer elemento es definir qué problema resuelve.
Comparemos:
Skill: revisar asuntos jurídicoscon:
Skill: identificar obligaciones expresas del proveedor
en un contrato tecnológicoLa primera formulación es tan amplia que resulta difícil saber qué comportamiento esperar.
La segunda posee una frontera.
Podemos preguntar:
- ¿identificó todas las obligaciones relevantes?;
- ¿las localizó correctamente?;
- ¿incluyó algo que no estaba en el contrato?;
- ¿confundió una facultad con una obligación?
Eso permite evaluar la capacidad.
Delimitar también significa excluir
Una skill no sólo debe decir qué hace.
Puede necesitar decir qué no hace.
Por ejemplo:
Esta skill extrae obligaciones expresas.
No evalúa:
- validez;
- conveniencia;
- riesgo;
- cumplimiento;
- interpretación de derecho aplicable.La exclusión evita que una capacidad pequeña se expanda silenciosamente.
Esto será especialmente importante cuando combinemos distintas skills.
Metodología
La capacidad responde:
¿qué tarea resolvemos?
La metodología responde:
¿qué secuencia conceptual seguimos para resolverla?
Supongamos una skill de revisión de responsabilidad.
Una metodología podría ser:
1. Identificar la disposición principal.
2. Identificar definiciones relacionadas.
3. Identificar el cap general.
4. Identificar carve-outs.
5. Identificar límites especiales.
6. Revisar referencias cruzadas.
7. Comparar con el criterio aplicable.
8. Señalar desviaciones.
9. Verificar evidencia.La metodología no necesita describir cada detalle técnico de implementación.
Su función es capturar la lógica profesional de la tarea.
Metodología no es necesariamente una cadena rígida
Algunas tareas poseen un orden natural.
Otras permiten variaciones.
Una skill puede decir:
Antes de evaluar, debes haber identificado evidencia suficiente.sin exigir que todas las suboperaciones ocurran siempre en una secuencia idéntica.
La metodología representa dependencias relevantes, no burocracia.
Instrucciones
Las instrucciones convierten la metodología en comportamiento esperado.
Por ejemplo:
- Revisa el texto completo de la cláusula y sus remisiones.
- Extrae literalmente el cap.
- No completes lenguaje ausente.
- Identifica todas las excepciones expresas.
- Si una excepción depende de otra cláusula, indícalo.
- Compara cada elemento separadamente con el criterio proporcionado.Una buena instrucción intenta ser observable.
Comparemos:
Sé riguroso.con:
Para cada hallazgo indica la disposición que lo sustenta.
Si no existe una ubicación verificable, no lo presentes como hallazgo confirmado.La segunda permite revisar si la skill cumplió.
Criterios
Aquí aparece una distinción más delicada.
La skill puede necesitar reglas para decidir cómo clasificar.
Por ejemplo:
Compatible
La cláusula satisface el criterio proporcionado.
Desviación
La cláusula contradice o se aparta del criterio.
No determinado
La evidencia disponible no permite realizar la comparación.Estos son criterios de operación de la skill.
Sin embargo, el contenido sustantivo que varía —por ejemplo, que el cap mínimo sea doce meses— puede pertenecer al conocimiento externo.
Esta diferencia será el tema de una página completa.
Por ahora basta con separar:
criterio metodológico:
“compara el cap con el mínimo aplicable”de:
criterio sustantivo:
“el mínimo aplicable es 12 meses”La skill puede contener el primero y recibir el segundo como información.
Ejemplos
Los ejemplos ya aparecieron en prompting.
Dentro de una skill cumplen una función semejante: mostrar cómo se aplica la metodología.
Por ejemplo:
EJEMPLO POSITIVO
Cláusula:
“La responsabilidad agregada no excederá doce meses de fees.”
Criterio:
“Mínimo: doce meses.”
Resultado:
Compatible respecto del monto del cap.También podemos mostrar un caso de abstención:
EJEMPLO
Cláusula:
“La responsabilidad agregada no excederá seis meses.”
Criterio:
No disponible.
Resultado:
No determinado.
Razón:
No es posible evaluar compatibilidad sin conocer
el estándar aplicable.Este segundo ejemplo enseña una conducta particularmente valiosa: no convertir ausencia de información en una respuesta inventada.
Los ejemplos no sustituyen los criterios
Si una skill contiene cinco precedentes de contratos antiguos, no necesariamente debemos tratarlos como reglas.
Un ejemplo sirve para mostrar un patrón.
Un criterio define cómo debe evaluarse.
Esta diferencia es importante en Derecho, donde la autoridad de una fuente no depende simplemente de que aparezca dentro de la instrucción.
Controles
Una skill profesional necesita límites.
Podemos distinguir inicialmente dos clases.
Controles sobre contenido
No inventar cláusulas.
No atribuir al documento contenido que no aparece.
No tratar una inferencia como cita.
No completar un estándar ausente.Controles sobre conclusión
No emitir recomendación final cuando falte el estándar.
No considerar aprobado un riesgo que requiera escalamiento.
Marcar contradicciones entre fuentes.Pero debemos ser cuidadosos con la palabra control.
Una instrucción escrita dentro de una skill no garantiza técnicamente el comportamiento.
Podemos pedir:
No alucines.y el sistema seguir produciendo un error.
Por eso conviene distinguir:
REGLA ESPECIFICADA
↓
COMPORTAMIENTO OBSERVADO
↓
EVIDENCIA DE QUE EL CONTROL FUNCIONA
Una regla dentro de la skill no es una garantía
“Usa sólo evidencia disponible” puede ser una instrucción correcta.
Todavía necesitamos comprobar si la salida realmente está respaldada.
La especificación reduce ambigüedad.
La evaluación determina si la capacidad funciona.
Output
Una capacidad también se define por lo que produce.
Supongamos una skill de extracción.
Una salida narrativa como:
“El proveedor tiene varias obligaciones de confidencialidad y seguridad.”
puede ser útil para lectura rápida.
Pero si después queremos verificar o comparar, necesitamos algo más estructurado.
Por ejemplo:
| Campo | Función |
|---|---|
| obligación | Qué debe hacer la parte |
| sujeto | Quién debe cumplir |
| evidencia | Texto relevante |
| ubicación | Cláusula o sección |
| condición | Cuándo aplica |
| observación | Información faltante o remisión |
El output forma parte de la interfaz conceptual de la skill.
Input y output crean una frontera
Podemos describir una skill así:
La utilidad de esta frontera es que otras capacidades pueden reutilizar el resultado.
Una skill de comparación puede recibir la extracción.
Una skill de verificación puede revisar la matriz.
Todavía no necesitamos llamarlo workflow. Basta reconocer que los outputs pueden convertirse en inputs para otras operaciones.
Reglas de uso
Una skill debería especificar cuándo corresponde utilizarla.
Por ejemplo:
USAR CUANDO
- existe un contrato identificable;
- la tarea consiste en extraer obligaciones expresas;
- el texto relevante está disponible.
NO USAR PARA
- determinar validez jurídica;
- inferir obligaciones no escritas;
- sustituir una opinión legal final.
ABSTENERSE CUANDO
- el documento está incompleto;
- una remisión decisiva apunta a un anexo no disponible;
- la extracción del texto es ilegible.Esta sección puede parecer administrativa.
En realidad define la frontera de confianza.
Una capacidad bien diseñada no sólo sabe producir respuestas.
También sabe cuándo su resultado no debería tratarse como suficiente.
La anatomía completa
Podemos representar la skill como un conjunto de decisiones:
flowchart TB
A[Capacidad delimitada] --> B[Metodología]
B --> C[Instrucciones]
C --> D[Criterios]
D --> E[Ejemplos]
E --> F[Controles]
F --> G[Output]
G --> H[Reglas de uso]
El diagrama no significa que toda skill deba almacenarse literalmente en ocho archivos o bloques separados.
Sirve para revisar su diseño.
Podemos preguntar:
- ¿sé qué hace?;
- ¿sé qué no hace?;
- ¿sé cómo procede?;
- ¿sé qué reglas aplica?;
- ¿sé cómo se ve un resultado correcto?;
- ¿sé qué errores intenta evitar?;
- ¿sé qué salida debe producir?;
- ¿sé cuándo no debería utilizarse?
Si no podemos responder, la capacidad sigue estando poco especificada.
Ejemplo completo: skill de extracción de obligaciones
Veamos una skill pequeña.
NOMBRE
Extraer obligaciones del proveedor
OBJETIVO
Identificar todas las obligaciones expresas asumidas por
el proveedor en los documentos indicados.
ENTRADA
- contrato;
- anexos incluidos;
- parte identificada como proveedor.
METODOLOGÍA
1. revisar el documento completo;
2. localizar lenguaje obligatorio;
3. identificar el sujeto obligado;
4. identificar condiciones y excepciones;
5. registrar remisiones;
6. conservar evidencia.
INSTRUCCIONES
- incluir obligaciones principales y accesorias;
- no incluir meras facultades;
- no incluir obligaciones del cliente;
- no completar obligaciones implícitas.
CRITERIOS
Una obligación debe contener una conducta atribuible al
proveedor y una base textual identificable.
CONTROLES
Si no existe evidencia verificable, no confirmar el hallazgo.
OUTPUT
obligación | ubicación | evidencia | condición | observación
REGLAS DE USO
No utilizar esta skill para evaluar suficiencia jurídica,
riesgo o cumplimiento.Observe qué hemos conseguido.
La capacidad no “revisa el contrato”.
Realiza una transformación determinada.
Eso permite después construir otras capacidades sobre un resultado más estable.
¿Dónde vive una skill?
Hasta ahora hemos hablado de la skill como objeto conceptual.
En una implementación concreta puede representarse de distintas maneras:
- un archivo de instrucciones;
- una configuración;
- una función;
- un paquete de prompts;
- un componente de una aplicación;
- una capacidad definida por un producto.
No necesitamos escoger una única implementación para aprender el concepto.
Lo importante es evitar el error inverso:
asumir que porque un proveedor llama “skill” a una funcionalidad, su definición debe convertirse en nuestra taxonomía general.
En este handbook conservaremos la definición funcional:
skill = capacidad o metodología delimitada y reutilizable.
Por qué esto importa en trabajo jurídico
La explicitación de una skill produce beneficios que van más allá de comodidad.
Permite preguntar qué tarea fue delegada, qué criterio fue aplicado, qué información faltaba, qué parte necesita supervisión y qué versión de la metodología produjo un hallazgo.
No es lo mismo extraer que evaluar. Una clasificación sin criterio visible es difícil de revisar. Una capacidad de redacción puede requerir controles distintos de una capacidad de verificación. Y si se actualiza solamente la metodología de responsabilidad, no debería ser necesario modificar todas las demás capacidades del sistema.
La arquitectura empieza a producir trazabilidad.
Qué debes recordar
Una skill bien diseñada no es un texto largo con muchas instrucciones.
Es una capacidad delimitada cuya lógica puede comprenderse.
Sus componentes útiles incluyen:
capacidad
metodología
instrucciones
criterios
ejemplos
controles
output
reglas de usoNo todos son obligatorios en idéntica forma para todas las skills.
Funcionan como un mapa para detectar huecos.
La pregunta más importante es:
¿podemos explicar qué hace esta capacidad y cómo reconocer si realizó bien su trabajo?
El problema que todavía queda abierto
Podríamos intentar construir una única skill denominada:
revisar contrato completoe introducir dentro de ella extracción, comparación, clasificación, evaluación, redacción y verificación.
Pero eso volvería a mezclar operaciones muy diferentes.
La siguiente página introduce una regla de diseño: en vez de construir un “gran abogado artificial”, conviene pensar en skills pequeñas, delimitadas y combinables.