Prompt Engineering - AI

October 17, 2025  

Rol

Eres <rol técnico: p. ej. experto en ciberseguridad / analista de datos / asistente administrativo> con y especialidad en <área concreta="">.

Contexto

Contexto corto y verificable. Incluye:

• Objetivo general: .
• Entorno: <producción / laboratorio / autorizado / restricciones legales>.
• Datos iniciales: <lista, dominio, archivos, parámetros>.

Tareas (ordenadas y numeradas)

1. Tarea 1: <acción principal, resultado esperado y formato de salida>.
2. Tarea 2: .
3. Tarea 3: <análisis adicional: patrones, heurísticas, tecnologías>.

Cada tarea debe indicar prioridad (alta/mediana/baja).

Proceso paso a paso

1. Paso A: .
2. Paso B: <bucle/iteración y condiciones de parada>.
3. Paso C: <verificación después de cada iteración; criterio Success/Error>.

Incluir límites: <máx iteraciones por ejecución, tasa, timeout>.

Reglas firmes

• Nunca <acciones prohibidas>.
• Todos los resultados deben ser <forma, ej. únicos, distintos de entrada>.
• Formato: <JSON/CSV/markdown con esquema exacto>.
• No usar <negrita/asteriscos> si aplica.
• Autorización requerida: .

Herramientas permitidas y uso

• Herramienta A: <nombre> — propósito y condiciones de uso.
• Herramienta B: <nombre> — cuándo y cómo usar; criterios de success/error.
  Indicar que cada uso de herramienta debe registrarse en la salida.

Seguridad y cumplimiento

• Confirmar que toda acción está autorizada.
• No realizar pruebas intrusivas fuera del entorno autorizado.
• Registrar auditoría: <timestamp, comando, respuesta, decisión>.

Formato de salida obligatorio

• Ejemplo mínimo (JSON):

{
“meta”: {
“agent_role”: “<rol>”,
“run_id”: “<uuid>”,
“timestamp”: “<ISO8601>”
},
“results”: [
{
“item”: “<nombre>”,
“status”: “success|error”,
“evidence”: “<respuesta breve>”,
“notes”: “<heurística aplicada>”
}
],
“summary”: “<texto corto con métricas: succeed, failed, tiempo>”
}

Casos de prueba y validación

• Input ejemplo 1: <…> => Resultado esperado: <…>

• Criterios de aceptación: <exactitud, unicidad, porcentaje mínimo de verificación>.

Instrucciones de iteración y parada

• Repetir generación hasta o hasta .
• Guardar checkpoint cada <N> iteraciones.
• En caso de error persistente: documentar y continuar.

Indicadores de calidad y métricas

• Cobertura válida (%).
• Ratio success/error.
• Tiempo por ítem.
• Duplicados detectados.

Consejos rápidos para redactar el prompt

• Sé específico. Un objetivo claro produce acciones concretas.
• Define formatos de entrada y salida precisos.
• Añade límites operativos y políticas de seguridad.
• Incluye ejemplos mínimos y contraejemplos.
• Exige registro de decisiones y evidencias.
• Prefiere instrucciones imperativas y numeradas.

Plantilla para copiar y pegar

#Rol  
Eres <rol técnico: p. ej. experto en ciberseguridad / analista de datos / asistente administrativo> con <años de experiencia> y especialidad en <área concreta>.
## Contexto  
Contexto corto y verificable. Incluye:    
- Objetivo general: <qué debe lograr el agente>.
- Entorno: <producción / laboratorio / autorizado / restricciones legales>.    
- Datos iniciales: <lista, dominio, archivos, parámetros>.
#Tareas (ordenadas y numeradas)  
1. Tarea 1: <acción principal, resultado esperado y formato de salida>.  
2. Tarea 2: <verificación o validación obligatoria>.  
3. Tarea 3: <análisis adicional: patrones, heurísticas, tecnologías>.  
Cada tarea debe indicar prioridad (alta/mediana/baja).
#Proceso paso a paso  
4. Paso A: <cómo empezar>.  
5.  Paso B: <bucle/iteración y condiciones de parada>.  
6. Paso C: <verificación después de cada iteración; criterio Success/Error>.  
Incluir límites: <máx iteraciones por ejecución, tasa, timeout>.
#Reglas firmes
- Nunca <acciones prohibidas\>.
- Todos los resultados deben ser <forma, ej. únicos, distintos de entrada>.
- Formato: <JSON/CSV/markdown con esquema exacto>.    
- No usar <negrita/asteriscos> si aplica.
- Autorización requerida: <confirmación explícita si es ofensivo>.
#Herramientas permitidas y uso  
- Herramienta A: <nombre\> — propósito y condiciones de uso.  
- Herramienta B: <nombre\> — cuándo y cómo usar; criterios de success/error.  
    Indicar que cada uso de herramienta debe registrarse en la salida.
#Seguridad y cumplimiento
- Confirmar que toda acción está autorizada.
- No realizar pruebas intrusivas fuera del entorno autorizado.
- Registrar auditoría: <timestamp, comando, respuesta, decisión>.
#Formato de salida obligatorio  
- Ejemplo mínimo (JSON):  
{  
 "meta": {  
 "agent_role": "<rol\>",  
 "run_id": "<uuid\>",  
 "timestamp": "<ISO8601\>"  
 },  
 "results": [  
 {  
 "item": "<nombre\>",  
 "status": "success|error",  
 "evidence": "<respuesta breve\>",  
 "notes": "<heurística aplicada\>"  
 }  
 ],  
 "summary": "<texto corto con métricas: succeed, failed, tiempo>"  
}
#Casos de prueba y validación
- Input ejemplo 1:
<...> => Resultado esperado: <...>
- Criterios de aceptación: <exactitud, unicidad, porcentaje mínimo de verificación>.
#Instrucciones de iteración y parada
- Repetir generación hasta <condición> o hasta <límite>.
- Guardar checkpoint cada <N\> iteraciones.
- En caso de error persistente: documentar y continuar.
#Indicadores de calidad y métricas
- Cobertura válida (%).
- Ratio success/error.
- Tiempo por ítem.
- Duplicados detectados.