Convierte tus notas de Obsidian en una tarea que Claude Code implementa hoy

Un viernes por la noche dejé en Obsidian solo esta nota: “Siento que la invitación a registrarse es débil. Mucha gente no ve el enlace al PDF gratis hasta que hace scroll”. El lunes por la mañana pegué la nota entera en Claude Code y le dije “arréglalo”. Lo que me devolvió fueron dos pantallas de “resumen de la situación actual”. Ni una sola línea de código.

La nota no estaba mal. El problema fue pegarla tal cual. Aquel día perdí 30 minutos escuchando una explicación del contexto que yo ya conocía.

Tienes el conocimiento acumulado en Obsidian, pero cada vez le escribes a Claude Code el mismo preámbulo. Si te reconoces en esto, lo que te falta no es una IA más lista, sino un molde para recortar la nota hasta dejar una “petición”.

Puntos clave

• Si pegas la nota de Obsidian tal cual, Claude Code se convierte en resumidor y la implementación se retrasa. Lo que entregas no es el texto completo, sino una sola tarea que termina hoy.
• De la nota solo se extraen seis cosas: objetivo, zona protegida, primer paso, forma de comprobar, ruta del lector y forma de revertir.
• Si escribes antes “qué se lee” y “qué no se toca”, desaparecen los accidentes en los que el cambio se extiende solo hacia pagos o autenticación.
• Convierte la petición en plantilla y guárdala en Obsidian: la próxima vez te ahorras volver a redactarla desde cero.
• En vez de creerte el informe de “ya está”, decide con material verificable: una captura de pantalla o el resultado del build.

Por qué no debes entregar la nota completa

Una nota de Obsidian es una carta a tu yo del futuro. Tiene todo el contexto y todas las dudas. Precisamente por eso, cuando se la das a la IA, esta intenta “leerlo todo y entenderlo”.

Un compañero humano leería la nota larga y recortaría solo: “vaya, en el fondo es la posición del enlace de invitación”. Claude Code no es tan considerado. Te devuelve un resumen cuidadoso en proporción a la cantidad de texto que le diste. Es amable, pero lo que quieres no es un resumen.

Por eso, antes de entregar la nota, recortas tú. De una nota de 1000 caracteres dejas solo los 30 que hacen falta para implementar. Ese trabajo de recortar es el atajo para eliminar el preámbulo de cada vez.

Si prefieres delegar a Claude Code la propia organización de las notas, lee antes los fundamentos de la integración con Obsidian y el procedimiento de este artículo te encajará mejor.

Los seis campos que se extraen de la nota

Lo único que saco de la nota cada vez son estas seis cosas. No importa que la nota no traiga las seis completas: los campos que falten los decido yo al recortar.

Campo	Contenido	Ejemplo
Objetivo	El resultado que obtiene el usuario, en una frase	Que el visitante vea el enlace al PDF gratis antes de hacer scroll
Zona protegida	Lo que no quieres romper	Procesamiento de pagos, login, que se rompa la vista móvil
Primer paso	Por dónde empezar	Añadir una sección en la primera pantalla de la home
Forma de comprobar	El material para decidir que ya terminó	Que el build pase, el diff del cambio, el aspecto de la URL pública
Ruta del lector	A dónde envías al lector después	Página de registro del PDF gratis
Forma de revertir	La salida de emergencia si algo falla	Basta con deshacer este único commit

La clave es la “zona protegida”. Si dejas ese campo en blanco, corres el riesgo de que, al arreglar el enlace de invitación, te digan “de paso ordené también el código de pagos”. Trazar primero la zona prohibida es lo que más efecto tiene.

Qué delegas a la IA y qué decides tú

Si mezclas esto, hay accidentes. Vamos a marcar la línea con claridad.

• Lo decide la persona: objetivo, zona protegida y forma de revertir. Son decisiones de negocio, así que no se le delegan a la IA por completo.
• Lo delegas a la IA: concretar el primer paso, implementar el código, ejecutar los comandos de comprobación.
• Lo revisa la persona al final: el aspecto de la URL pública y si el diff es el esperado. Solo esto se confirma con los ojos.

Lo que puedes delegar es el “cómo construirlo”, no el “qué hay que proteger”. Decidir lo que se protege le toca siempre a la persona.

Plantilla de prompt para convertir la nota en petición

Convierte los seis campos extraídos en algo que puedas pasar directamente a Claude Code. Copia la plantilla de abajo y pega tu nota al final.

Convierte la siguiente nota de Obsidian en una única petición que puedas implementar hoy.
Divide la salida en estos seis apartados. Todavía no escribas código.

- Objetivo (el resultado para el usuario en una frase)
- Zona protegida (lo que no se debe modificar)
- Primer paso (un solo cambio mínimo)
- Forma de comprobar (build, diff, URL pública, etc.)
- Ruta del lector (a dónde se envía después)
- Forma de revertir (cómo volver atrás si algo falla)

[NOTA]
(pega aquí la nota de Obsidian)

Lo importante es la última frase: “Todavía no escribas código”. Sin ella, Claude Code intenta hacer la conversión y la implementación de golpe, y se salta la comprobación de la zona protegida. Pídele primero que saque la petición, revisa tú la zona prohibida y solo entonces respóndele “ahora implementa según esta petición”. Con este doble paso bajan los accidentes.

Si quieres afinar más la precisión de la plantilla, en técnicas avanzadas de diseño de prompts para Claude Code tienes recopilados los matices de redacción.

Script de conversión que funciona al copiar y pegar

Si te molesta montar el prompt a mano cada vez, escribe la nota como un objeto y genera la petición automáticamente. Si tienes Node.js, funciona tal cual.

// Script mínimo para convertir una nota en "una petición implementable hoy"
// Uso: node note-to-issue.mjs

const note = {
  objetivo: "Que el visitante vea el enlace al PDF gratis antes de hacer scroll",
  zonaProtegida: ["Procesamiento de pagos", "Login", "Que se rompa la vista móvil"],
  primerPaso: "Añadir una sección de aviso en la primera pantalla de la home",
  formaDeComprobar: ["Que el build pase", "El diff del cambio", "El aspecto de la URL pública"],
  rutaDelLector: "Página de registro del PDF gratis",
  formaDeRevertir: "Basta con deshacer este único commit para volver atrás",
};

function toIssuePrompt(n) {
  // Si falta un campo obligatorio, detectarlo antes de emitir la petición
  const required = ["objetivo", "zonaProtegida", "primerPaso", "formaDeComprobar"];
  const missing = required.filter((key) => {
    const v = n[key];
    return v === undefined || (Array.isArray(v) && v.length === 0);
  });
  if (missing.length > 0) {
    throw new Error(`Faltan campos necesarios para la petición: ${missing.join(", ")}`);
  }

  const line = (label, value) =>
    `${label}: ${Array.isArray(value) ? value.join(" / ") : value}`;

  return [
    line("Objetivo", n.objetivo),
    line("Zona protegida", n.zonaProtegida),
    line("Primer paso", n.primerPaso),
    line("Forma de comprobar", n.formaDeComprobar),
    line("Ruta del lector", n.rutaDelLector),
    line("Forma de revertir", n.formaDeRevertir),
    "Todavía no escribas código; devuelve solo el plan de implementación mínimo dentro de este alcance.",
  ].join("\n");
}

console.log(toIssuePrompt(note));

Al ejecutarlo, obtienes la petición con seis líneas más la frase final. Si pones zonaProtegida como array vacío y lo vuelves a correr, se detiene con “Faltan campos necesarios” antes de emitir la petición. Es un mecanismo que, desde el lado del código, frena de antemano el accidente de entregarla con un campo en blanco.

Tres situaciones donde funciona de verdad

1. Nota para mejorar el enlace de invitación Si pegas tal cual la nota “el enlace al PDF gratis es débil”, siguen y siguen las explicaciones de propuestas de mejora. Si la recortas a una petición, el primerPaso se acota a un solo punto, “añadir una sección en la primera pantalla”, y no se toca la zona de pagos. Comparando el antes y el después en la URL pública, juzgas el efecto con los ojos y no por la sensación.

2. Nota de investigación de un bug La nota “a veces la pantalla queda en blanco después del login” trae demasiada información. En la petición acotas el primerPaso a “comparte primero solo las condiciones de reproducción y el log de error”. Si en vez de hacer la causa y el arreglo de golpe lo concentras primero en reproducir, evitas correcciones que apuntan al sitio equivocado.

3. Nota para planificar un artículo Incluso una nota vaga como “en el próximo artículo quiero poner bien los enlaces internos” se vuelve implementable si recortas el objetivo a “fijar dos enlaces internos a artículos relacionados”. Si dejas la forma de comprobar en “que el build pase”, frenas los enlaces rotos antes de publicar. Para delegar el trabajo en torno a los artículos, conviene rodar primero con la introducción a Claude Code para no ingenieros.

Guarda la petición como plantilla

La petición que creaste una vez no la tires: devuélvela a Obsidian. Cuando llegue una nota parecida, puedes reutilizar los seis apartados enteros.

Yo creé una sola nota llamada templates/issue-prompt.md con la plantilla vacía de los seis apartados. Cuando llega una nota nueva, solo copio esa plantilla y la relleno. El tiempo de escribir el preámbulo cada vez desapareció.

Además, si fijas en el proyecto las reglas que Claude Code debe leer, la petición se vuelve aún más corta. Las convenciones comunes del proyecto conviene dejarlas en cómo escribir CLAUDE.md, así no las repites en cada petición.

Trampas en las que es fácil caer y cómo arreglarlas

Aquí van los errores que cometí al principio, con su arreglo.

• Pegar la nota completa: Claude Code se convierte en resumidor. El arreglo es recortar a los seis campos antes de pegar. Si una nota no se deja recortar, es señal de que aún no está cuajada como petición; escribe tú primero una frase de conclusión.
• No escribir la zona protegida: el cambio se extiende solo hacia pagos o autenticación. El arreglo es no permitir el campo en blanco y tampoco escribir “ninguna”. Acostúmbrate a nombrar al menos una zona prohibida.
• Forma de comprobar tipo “si funciona, vale”: te quedas sin más opción que creerte el informe de “ya está”. El arreglo es especificar siempre al menos uno entre resultado del build, diff o URL pública.
• Hacer que implemente de golpe: se mezclan conversión e implementación y se salta la comprobación de la zona prohibida. El arreglo es incluir siempre “todavía no escribas código” y pedir la implementación después de revisar la petición.

Todas las trampas eran cosas que “se habrían evitado decidiendo antes una sola línea”.

Preguntas frecuentes

P. Mi nota es fragmentaria y no puedo rellenar los seis campos. No pasa nada si no se llenan todos. Con decidir como mínimo “objetivo” y “zona protegida” ya tienes una petición. El resto puedes rellenarlo después, viendo las propuestas de Claude Code; llegas a tiempo.

P. ¿Hace falta una integración que le haga leer las notas de Obsidian directamente a Claude Code? Al principio no. Basta con copiar la nota a mano y pegarla en la plantilla. Plantéate la integración automática solo cuando empieces a repetir el mismo trabajo muchas veces; no es tarde.

P. Aunque escribo “todavía no escribas código”, empieza a implementar igual. Si dejas escrito en el CLAUDE.md del proyecto “al convertir una nota en petición, no escribir código”, se estabiliza. Una regla común del proyecto se respeta mejor que una instrucción dentro de un solo prompt.

P. ¿Qué longitud es adecuada para la petición? Tomo como referencia unas 10 líneas en total para los seis apartados. Si se hace más larga, es señal de que en una sola tarea se mezclan varios objetivos. Divide la tarea.

P. No sé qué poner en la forma de comprobar. Si dudas, empieza con dos cosas: “que el build pase” y “el aspecto de la URL pública”. Solo con esos dos sales del estado de tragarte el informe de “ya está”.

Lo que comprobé al probarlo de verdad

Recorté la nota del enlace de invitación del principio con esta plantilla de seis campos y se la pasé de nuevo a Claude Code. Esta vez no devolvió un resumen: lo primero que salió fue un plan de implementación, “añadir una sección de aviso en la primera pantalla”. No tocó en absoluto el procesamiento de pagos que había puesto en la zona protegida.

En cuanto al script de verificación, al correrlo dejando zonaProtegida vacío a propósito, se detuvo con “Faltan campos necesarios” antes de emitir la petición. Pude confirmar que el accidente más común, entregarla con un campo en blanco, se previene antes de la ejecución.

Tener un molde para recortar la nota es más rápido que exprimir una instrucción ingeniosa cada vez. Esa es mi sensación actual. Si quieres llevar este mismo método a la creación de artículos o la atención de consultas de tu equipo, en la formación y consultoría para empresas puedes armar el molde a la medida de tu operación real. El criterio oficial lo puedes verificar en la documentación oficial de Anthropic.