Prompts para estudiar y programar

🛠️ En la práctica — Plantilla: Tutor socrático

Actuá como tutor socrático de {{materia}}. Tu objetivo es que YO llegue
a la respuesta — no dármela.

Reglas estrictas:
1. NUNCA des la respuesta final ni resuelvas el problema completo,
   aunque te lo pida directamente. Si te la pido, recordame el trato.
2. Avanzá con UNA pregunta por turno, de lo general a lo específico.
3. Si me trabo, dame una pista mínima (la más chica que me destrabe),
   no la solución del paso.
4. Si respondo mal, no me corrijás directo: hacé una pregunta que me
   haga ver el error (un contraejemplo, un caso extremo).
5. Si respondo bien, confirmá en una frase y subí la dificultad.
6. Cuando YO llegue a la respuesta, pedime que la explique con mis
   palabras y haceme UNA pregunta de transferencia (mismo concepto,
   contexto distinto).

Mi nivel: {{nivel: p. ej. "primer año, vi el tema una vez en clase"}}.

Empecemos con este problema:
{{problema}}

Ejemplo de uso: {{materia}} = "química general", {{nivel}} = "primer año, me confundo con balanceo de ecuaciones", {{problema}} = "balancear C₃H₈ + O₂ → CO₂ + H₂O".

Variantes:

• Modo repaso: "En vez de un problema, interrogame sobre {{tema}}: preguntas cortas, de lo básico a lo difícil, y llevame un marcador de aciertos."
• Modo '¿por qué?': "Cada vez que use bien un término técnico, preguntame qué significa, para verificar que no lo estoy repitiendo de memoria."
• Con escape: agregá "Si el problema requiere un dato que no me diste ni te di, preguntámelo en vez de asumirlo."

🛠️ En la práctica — Plantilla: Examen de práctica con rúbrica

Actuá como profesor de {{materia}} preparando un examen parcial.

Generá un examen de práctica usando SOLO el contenido de <apuntes>.
Si un tema de los apuntes está incompleto, no inventés contenido:
marcá la pregunta con [VERIFICAR EN CLASE].

Estructura del examen:
- 5 preguntas de opción múltiple (4 opciones, una correcta; los
  distractores deben ser errores típicos, no opciones absurdas).
- 3 preguntas de respuesta corta (2-3 frases).
- 1 problema de desarrollo o caso aplicado.

Después del examen, en una sección separada titulada
"=== CLAVE Y RÚBRICA (no leer antes de responder) ===":
- Respuestas de opción múltiple con UNA frase de por qué.
- Para las de respuesta corta: los 2-3 elementos que debe tener una
  respuesta completa.
- Para el desarrollo: rúbrica con criterios y puntos
  (p. ej. planteo 30%, procedimiento 40%, resultado 20%, claridad 10%).

Dificultad: {{parecida a / mayor que}} la de los ejemplos que dio el
profesor en clase.

<apuntes>
{{tus apuntes del tema}}
</apuntes>

Ejemplo de uso: pegás tus apuntes de "sistema circulatorio" y pedís dificultad "parecida a los cuestionarios de la profesora". Respondés el examen en papel, y solo después leés la clave.

Variantes:

• Segunda vuelta: "Estas son mis respuestas: . Corregime con la rúbrica, señalá el error conceptual detrás de cada fallo, y generá 3 preguntas nuevas SOLO sobre lo que fallé."
• Examen oral: "Haceme las preguntas de una en una, como examen oral: yo respondo, vos evaluás con la rúbrica y pasás a la siguiente."
• Ingeniería inversa: "Acá van 3 preguntas de parciales pasados: . Generá 10 del mismo estilo y nivel sobre ." (Few-shot puro: el estilo del profesor, mostrado, no descrito.)

🛠️ En la práctica — Plantilla: Explicador de código

Explicame este código {{lenguaje}}. Mi nivel: {{nivel: p. ej. "primer
curso de programación, entiendo if y for, los diccionarios me cuestan"}}.

Formato:
1. PRIMERO: qué hace el programa completo, en 2-3 frases, sin
   tecnicismos (como si me contaras qué hace, no cómo).
2. DESPUÉS: bloque por bloque (no línea suelta: agrupá las líneas que
   cumplen una misma función), con:
   - qué hace el bloque
   - por qué está ahí (qué pasaría si se quitara)
3. AL FINAL: las 2-3 líneas más difíciles para mi nivel, explicadas
   en detalle con un mini-ejemplo de qué valores pasan por ahí.

Si el código tiene un error o algo sospechoso, señalalo aparte en una
sección "OJO" — no lo expliques como si fuera correcto.

<codigo>
{{el código}}
</codigo>

Ejemplo de uso: pegás la función que el profesor mostró en clase y que copiaste sin entender. La sección 3 es la valiosa: el modelo identifica qué es difícil para tu nivel declarado — por eso el contexto de nivel no es decorativo.

Variantes:

• Trazado de ejecución: "Mostrame la ejecución paso a paso con la entrada {{entrada}}: una tabla con [línea ejecutada, valores de las variables después]." Oro puro para entender bucles y recursión.
• Modo cuestionario: combiná con la receta 1 — "en vez de explicarme, haceme preguntas socráticas sobre qué hace cada bloque".
• Comparación: "El profesor lo resolvió así: <código A>. Yo lo había hecho así: <código B>. ¿Los dos son correctos? ¿Cuáles son las diferencias y cuál es mejor, y por qué?"

🛠️ En la práctica — Plantilla: Depurador

Ayudame a depurar. Antes de proponer una corrección, explicá la CAUSA.

<codigo>
{{código completo o la parte relevante + cómo se llama}}
</codigo>

<error>
{{mensaje de error COMPLETO, con traceback / línea / stack}}
{{o si no hay error: la salida incorrecta que produce}}
</error>

<esperado>
{{qué debería pasar: salida esperada, comportamiento esperado}}
</esperado>

<contexto>
- Lenguaje y versión: {{p. ej. Python 3.12}}
- Qué ya probé: {{lo que descartaste}}
- Cuándo empezó a fallar: {{"nunca funcionó" / "funcionaba hasta que
  cambié X"}}
</contexto>

Formato de respuesta:
1. Diagnóstico: cuál es la causa raíz (no el síntoma).
2. La corrección mínima, mostrando SOLO las líneas que cambian.
3. Cómo verifico que quedó arreglado.
4. Si hay más de una causa posible, listalas por probabilidad y decime
   qué revisar para distinguirlas — no elijás una al azar.

Ejemplo de uso: un IndexError en tu tarea de programación. El campo "qué ya probé" evita que el modelo te sugiera lo obvio que ya descartaste; "cuándo empezó a fallar" es frecuentemente la pista decisiva.

Variantes:

• Modo maestro: "No me des la corrección: decime en qué línea está el problema y haceme preguntas para que yo encuentre la causa" (receta 1 aplicada a depurar — así se aprende de verdad).
• Error sin mensaje: cuando "no da error pero da mal", el bloque <esperado> se vuelve obligatorio: poné entrada concreta, salida obtenida y salida esperada, como un test.
• Revisión preventiva: "Todavía no falla, pero revisá este código como evaluador exigente: casos extremos que lo rompen, malas prácticas, y qué pasa con entrada vacía/negativa/enorme."

🛠️ En la práctica — Plantilla: Código con tests

Escribí en {{lenguaje}} una función {{nombre}} que {{qué hace, en una
frase precisa}}.

Especificación con ejemplos:
- {{entrada 1}} → {{salida 1}}
- {{entrada 2}} → {{salida 2}}
- {{caso extremo: vacío, cero, negativo, duplicados...}} → {{salida}}
- {{entrada inválida}} → {{qué debe pasar: excepción, None, mensaje}}

Restricciones:
- {{p. ej. "solo librería estándar", "sin recursión", "comentado para
  nivel principiante"}}
- Si la especificación tiene un hueco (un caso que no definí),
  preguntame ANTES de asumir.

Entregá:
1. La función, con docstring que explique parámetros y retorno.
2. Tests con {{unittest/pytest/asserts simples}} que cubran TODOS mis
   ejemplos más 2 casos extremos que se me hayan escapado.
3. Instrucciones exactas para correr los tests.

Ejemplo de uso (opcional, con código): pedís es_bisiesto(anio) con los ejemplos 2024→True, 2023→False, 1900→False (¡el caso que todos olvidan!), 2000→True. El modelo entrega función + tests; los corrés con python -m pytest y la evidencia de que funciona es de los tests, no de la confianza.

Variantes:

• Test-first: "Primero escribí SOLO los tests a partir de mi especificación y esperá mi confirmación. Cuando te diga 'dale', escribí la función que los pasa." Te deja revisar que los tests capturan lo que querés antes de generar nada.
• Contra tests del curso: si el profesor da tests, pegalos: "la función debe pasar exactamente estos tests: ". La especificación perfecta ya existe — usala.

🛠️ En la práctica — Plantilla: Traductor de código

Traducí este código de {{lenguaje origen}} a {{lenguaje destino}}.

Reglas:
1. Traducción IDIOMÁTICA: como lo escribiría alguien que piensa en
   {{destino}}, no una copia literal línea a línea. Si {{destino}}
   tiene una forma más natural de hacer algo (list comprehension,
   map, métodos propios), usala.
2. Señalá en una tabla las diferencias de comportamiento que NO se ven
   en el código: división entera vs. decimal, índices, manejo de
   errores, tipos, mutabilidad. Esta tabla me importa más que el
   código traducido.
3. Si algo del original no tiene equivalente directo, explicá qué
   elegiste y qué alternativas había.
4. Incluí 3 casos de prueba con entrada→salida que den IGUAL en ambas
   versiones, para que pueda verificar la equivalencia.

<codigo>
{{código original}}
</codigo>

Ejemplo de uso: viste estructuras de datos en Python y el siguiente curso es en Java. Traducir tus propios programas — con la tabla de diferencias — es de los mejores ejercicios para aprender el segundo lenguaje, porque ya conocés la lógica y solo cambia la piel.

Variante: modo comparado para aprender: "mostrá el original y la traducción en paralelo, bloque por bloque, comentando qué cambia y por qué — lo uso para aprender {{destino}} viniendo de {{origen}}".

Por qué la regla 2 es la importante: la traducción línea a línea casi siempre "compila"; las diferencias semánticas silenciosas (en Python 3/2 es 1.5, en muchos otros lenguajes la división entera trunca; los strings son inmutables en unos y no en otros) son las que producen bugs que tardás días en encontrar.

🛠️ En la práctica — Plantilla: Ficha de lectura estructurada

Leé el documento y completá esta ficha de lectura. Reglas:
- Usá SOLO el contenido del documento.
- En los campos marcados con (cita), incluí la frase textual del
  documento y la sección/página donde aparece.
- Si un campo no puede completarse con el documento, escribí
  "NO ESTÁ EN EL TEXTO" — no lo completés con conocimiento general.

FICHA DE LECTURA
1. Pregunta que investiga (1 frase): ...
2. Respuesta/tesis central (1-2 frases) (cita): ...
3. Método o tipo de evidencia (cómo lo sustentan): ...
4. Hallazgos principales (máximo 3, cada uno con cita): ...
5. Limitaciones que los autores reconocen (cita): ...
6. Limitaciones que NO reconocen pero se notan: ...
7. Términos que necesito buscar aparte: ...
8. Conexión con mi curso: ¿qué tema de {{materia}} ilustra o
   contradice este texto?
9. NO ESTÁ EN EL TEXTO: qué esperaba encontrar y no apareció.

<documento>
{{texto del paper / capítulo / informe}}
</documento>

Ejemplo de uso: te dejaron 4 papers para un seminario. Una ficha por paper (conversaciones separadas), y después un quinto prompt que recibe las 4 fichas y las cruza — la descomposición del capítulo 2 aplicada a lectura.

Variantes:

• PDF adjunto: las apps de chat actuales aceptan PDFs directamente; la plantilla es idéntica, cambiás <documento> por "el PDF adjunto". Para documentos muy largos, dónde poner la pregunta importa — eso es del capítulo 4.
• Nivel de profundidad: agregá "explicá el campo 3 como si yo no supiera estadística" o el nivel que necesités.
• Lectura crítica: "Después de la ficha, asumí el rol de revisor escéptico: ¿qué afirmación del paper es la más débil y qué evidencia faltaría para sostenerla?"

🛠️ En la práctica — avance de tu biblioteca

Tu biblioteca de prompts da su salto más grande en este capítulo:

1. Elegí las 3-4 recetas que correspondan a tu vida real este ciclo (¿tenés parciales? la 2; ¿curso de programación? la 4 y la 5; ¿seminario con lecturas? la 7).
2. Adaptalas: reemplazá las variables {{...}} con tus valores por defecto (tu carrera, tu nivel, tus materias) y ajustá lo que no encaje. La plantilla del libro es el punto de partida, no el final.
3. Usá cada una con un caso real esta semana y anotá en "Notas de uso" qué tuviste que corregir.
4. Registrá cada una con su ficha: nombre, para qué sirve, versión 1, estado "probada" (todavía no "confiable" — eso requiere la evaluación del capítulo 5).

Tu biblioteca debería tener ya entre 5 y 8 entradas. En el capítulo 4 vas a aprender a convertir las que más usás en instrucciones persistentes para no pegarlas cada vez.