desglose-del-objetivo-del-curso

¿Qué hace desglose-del-objetivo-del-curso?

Convierte el inputs.json de un cliente en tree.json: un árbol con raíz en el objetivo del curso, donde cada arista significa "el hijo es algo que el participante debe ser capaz de HACER, con Claude, para que su padre ocurra."

Decisión de diseño de esta habilidad: desde la evidencia hacia arriba. El método no descompone el objetivo desde la cima. Comienza desde los criterios y los objetivos semanales, pregunta qué debe ser observablemente cierto cuando se cumple cada uno y qué debe hacer el participante para producir esa evidencia, y retrocede desde esas acciones hacia el objetivo. El objetivo es lo último que se une, no lo primero que se divide. El significado de la arista es el mismo en ambos sentidos; solo difiere el orden de construcción.

Entradas y salidas

• Carpeta de ejecución: proporcionada por el usuario. Todo se lee y escribe desde y hacia ella.
• Lee: <run>/inputs.json (esquema h0-inputs/1). Los datos del cliente provienen únicamente de este archivo. No lea nada más sobre el cliente.
• Escribe: tree-A.json, tree-B.json, tree-C.json, tree-pitches.md; después de la selección, tree.json, skills-list.md y una línea en decisions.md.
• Validación: desde la carpeta que contiene schemas/, ejecute python schemas/validate.py h1 <run>/tree-X.json --inputs <run>/inputs.json Debe imprimir PASS. Corrija y vuelva a ejecutar hasta que lo haga. Si no puede alcanzar PASS, deténgase e informe los errores restantes; nunca entregue un archivo fallido.
• Scripts (en scripts/ de esta habilidad, todos escriben UTF-8):
  • order_leaves.py <tree.json>: calcula leaf_order a partir de los nodos y lo escribe en el archivo. Nunca escriba leaf_order manualmente.
  • render_leaves.py <tree.json> [<out.md>]: renderiza leaf_order como la lista numerada de hojas skills-list.md. Nunca escriba la lista manualmente.
  • pick.py <run> <A|B|C> ["razón"]: copia la selección a tree.json y añade una línea a decisions.md.

Método (versión A: desde la evidencia hacia arriba)

Trabaje en este orden. Mantenga una lista de borradores mientras avanza; solo el árbol se escribe.

Paso 0. Clasificar las entradas

1. Copie goal exactamente en el goal del árbol.
2. Clasifique cada entrada de constraints en uno de dos montones:
   • Vincula el árbol: sobre datos (de dónde vienen, lectura/escritura) o alcance (qué está incluido o excluido). Úselo en los Pasos 2–4.
   • Entrega: sobre tiempo, duración, número de sesiones, formato, programación. Colóquelo en set_aside con la restricción copiada exactamente y una razón de una línea ("restricción de entrega; el árbol trata solo de capacidad"). Nunca da forma, dimensiona, divide o fusiona un nodo.
3. Lea presenter_owned (si existe) como contexto. Estos nunca son nodos, y ningún nodo puede requerir que el participante los realice.
4. Liste los problemas del glosario ahora, antes de construir:
   • cada valor del glosario que comience con UNRESOLVED o PROVISIONAL → una brecha undefined_term, incluso si el objetivo no usa el término;
   • cada término en el objetivo, objetivos semanales, criterios o restricciones que el glosario no defina y del que dependa el árbol (qué cuenta como unidad a verificar, qué forma tiene un archivo de datos) → una brecha undefined_term. No defina ninguno de ellos usted mismo. Cuando un nodo dependa de uno, redacte el nodo para que funcione sin la definición y nombre la brecha.

Paso 1. Escribir la evidencia

Para cada criterio: la evidencia es su pass_if, léalo literalmente. Escriba una línea: "Observable: <pass_if>, producido por <quién>, a partir de <qué>." Para cada objetivo semanal: escriba qué podría ver otra persona si se cumpliera (un producto, un registro, un cambio visible). Si el objetivo trata sobre comodidad o confianza y no tiene producto, nombre el comportamiento visible más pequeño que lo demuestre (por ejemplo, "existe una versión revisada después de la solicitud de seguimiento del propio participante").

Paso 2. Nombrar la acción que produce cada evidencia

Para cada línea de evidencia, pregunte: "¿Qué hace el participante, con Claude, que deja esta evidencia atrás?" Escríbala como una acción imperativa con un objeto ("Producir…", "Marcar…", "Pedir a Claude que…"), nunca un tema ("Fundamentos de prompt", "Alfabetización en datos").

• Si dos líneas de evidencia son producidas por la misma acción, comparten una acción.
• Cada acción distinta se convierte en un nodo de nivel superior (un hijo de la raíz) y recibe serves enumerando cada objetivo semanal y criterio cuya evidencia produce.
• Verificación de cobertura: cada id W y C en las entradas aparece en al menos un serves de nivel superior. Si la evidencia de un objetivo semanal se produce realmente dentro de otra acción (una versión más pequeña de ella), esa acción de nivel superior también la sirve y la acción más pequeña se convierte en descendiente.
• Si dos acciones de nivel superior dependen entre sí (una necesita el producto de la otra), enlácelas con prereqs, no anidándolas.

Paso 3. Retroceder desde cada acción

Para cada nodo, pregunte: "¿Qué deben ser capaces de hacer, con Claude, antes de que esto pueda ocurrir?" Cada nueva respuesta se convierte en un hijo.

• Solo las acciones realizadas con Claude son hijos. Pedir a Claude cuenta, y también juzgar, verificar o actuar sobre la salida de Claude (esa es la mitad del trabajo del participante). Un paso que no toca ni a Claude ni a su salida (operar otra herramienta, enviar algo) no es un nodo: o está cubierto por el perfil o el conocimiento del dominio, o es una brecha ("las entradas no dicen quién/cómo…").
• Si la respuesta ya es un nodo en otra parte, enlácelo con prereqs en lugar de duplicarlo.
• Un prerrequisito que varios hermanos necesitan se sitúa bajo su padre común más bajo, no dentro de la rama de un hermano; de lo contrario, los prereqs de un hermano pueden apuntar a una rama que lo necesita, lo que order_leaves.py reporta como un ciclo.
• Divida solo por esta pregunta. Nunca divida, fusione o dimensione un nodo para ajustarlo a sesiones, laboratorios, tiempo o cualquier forma de enseñarlo.

Paso 4. Detenerse en el piso, y registrarlo

Deje de dividir un nodo cuando la pregunta del Paso 3 no dé una nueva respuesta. El nodo es entonces una hoja y recibe floor:

• profile: el perfil del participante ya cubre lo que viene antes (cite o parafrasee qué campo del perfil).
• domain_knowledge: es conocimiento ordinario del propio trabajo del participante, indicado en las entradas (diga dónde).
• inputs_stop: las entradas no dicen nada que le permita ir más allá (diga qué falta, y añada una brecha si es importante). Cuando los únicos prerrequisitos restantes son nodos existentes, están en prereqs; elija la razón que explica por qué no queda nada nuevo, y diga "los prerrequisitos restantes ya son nodos: …" en detail.

Paso 5. Datos y afirmaciones sobre Claude

• Datos. Cualquier nodo que necesite datos recibe una entrada data: what, y source tomado de las entradas: live, read-only (datos reales que se leen y nunca se escriben; nunca inventados), sample, o own (del propio participante). Ponga la frase de las entradas que establece la fuente en quote, copiada exactamente. Si las entradas no dicen de dónde vienen los datos, use UNRESOLVED, omita quote y añada una brecha data_provenance nombrando el nodo.
• Afirmaciones. Cualquier nodo que asuma algo que un producto de Claude puede hacer (leer un archivo adjunto, revisar a petición, señalar una fila de origen) recibe una entrada claims con verify: true, a menos que cite una URL de documentación actual que lo indique (entonces cite en lugar de verify). Nunca ambos.

Paso 6. Unir el objetivo

Cree la raíz al final: parent: null, skill = el objetivo reformulado como la acción del participante, sin serves, sin floor. Apunte cada nodo de nivel superior hacia ella. Numere los nodos N1 (raíz) hacia arriba. Verifique:

• cada nodo excepto la raíz tiene un padre; las hojas tienen floor, los no hojas no; solo los hijos de la raíz tienen serves;
• ninguna palabra de tiempo, formato o programación en ningún skill.

Paso 7. Ordenar, validar, renderizar

1. python <skill>/scripts/order_leaves.py <run>/tree-A.json (establece leaf_order; falla en un ciclo, lo que significa un bucle de prereqs a corregir).
2. Valide tree-A.json hasta que PASS.
3. Complete gaps con todo lo de los Pasos 0, 3, 4 y 5. Las brechas se informan, nunca se llenan.

Tres versiones

Cada ejecución escribe tres árboles que pasan la validación desde el mismo inputs.json y el mismo esquema. B y C provienen de subagentes frescos separados (nunca bifurcaciones), cada uno recibe solo su breve instrucción a continuación, la ruta de la carpeta de ejecución, la ruta de scripts/ de esta habilidad y el comando de validación. Si la plataforma no tiene subagentes, escriba B y C usted mismo y ponga esta frase al principio de tree-pitches.md: "B y C son interpretados por el mismo modelo, no ejecuciones independientes."

Instrucción para B (decisión de diseño alternativa: descomposición desde el objetivo hacia abajo). "Lea solo <run>/inputs.json. Construya <run>/tree-B.json (esquema h1-tree/1) descomponiendo el objetivo desde la cima: divida el objetivo raíz en las acciones que lo componen, luego divida cada una hasta que preguntar '¿qué deben hacer, con Claude, antes de esto?' no dé una nueva respuesta (entonces registre floor). Significado de la arista: el hijo es algo que el participante debe ser capaz de HACER, con Claude, para que su padre ocurra. Cada hijo de la raíz declara serves; cada id W y C debe ser servido. Las habilidades son acciones, no temas. Las restricciones de entrega (tiempo, duración, formato) van en set_aside con una razón; las restricciones de datos vinculan el árbol; los elementos propiedad del presentador nunca son nodos. Las fuentes de datos provienen solo de las entradas, con la frase de las entradas citada exactamente, o UNRESOLVED más una brecha. Informe cada término del glosario UNRESOLVED/PROVISIONAL y cada término indefinido como una brecha; nunca defina uno. Las afirmaciones sobre productos de Claude llevan verify: true. Ejecute scripts/order_leaves.py para establecer leaf_order, luego la validación, hasta que imprima PASS. Devuelva una oración argumentando a favor de su versión, nombrando la decisión de diseño."

Instrucción para C (contradictor / verificador de hechos). "Lea solo <run>/inputs.json y <run>/tree-A.json. Ataque las premisas de A: para cada nodo pregunte si es realmente algo hecho con Claude, si es necesario para su padre, y si su evidencia podría ser verificada por alguien que no sea su autor. Verifique cada afirmación sobre productos de Claude con la documentación actual (docs.claude.com, support.claude.com); mantenga verify: true en todo lo que no pueda confirmar, y cite la URL en todo lo que pueda. Elimine lo que no pueda verificarse o medirse, fusione duplicados en prereqs, y proponga el árbol más esbelto o seguro. Mantenga el mismo esquema, significado de arista y reglas: cada id W y C servido, acciones no temas, pisos en las hojas, restricciones de entrega en set_aside, fuentes de datos citadas de las entradas o UNRESOLVED con una brecha, términos indefinidos informados no definidos. Escriba <run>/tree-C.json, ejecute scripts/order_leaves.py, luego la validación, hasta PASS. Devuelva una oración argumentando a favor de su versión."

Presentaciones, selección, registro

1. Escriba <run>/tree-pitches.md: una línea por versión, A — <una oración>, B — …, C — …, cada una nombrando su decisión de diseño. Ninguna versión se marca como recomendada. Puede señalar un error fáctico en cualquier versión; no vota.
2. El presentador selecciona. Ejecute python <skill>/scripts/pick.py <run> <A|B|C> "<razón dada, si la hay>". Antes de proponer, lea decisions.md si existe para no proponer algo ya rechazado.
3. Valide tree.json una vez más, luego python <skill>/scripts/render_leaves.py <run>/tree.json → <run>/skills-list.md.

Informe (al usuario, al final de una ejecución)

• los archivos escritos;
• la salida de validación para cada versión;
• cada brecha (términos indefinidos, procedencia de datos, otros), según se listan en el árbol;
• cada restricción pospuesta, con su razón;
• si B y C fueron subagentes independientes o interpretados.

Ejemplo inventado (genérico, no de ningún cliente)

Objetivo: "Cada organizador voluntario usa Claude para convertir la hoja de inscripción en un rota de turnos y verifica cada espacio contra la hoja." Criterio: "pass_if: un espacio corregido por organizador, con la fila de la hoja de inscripción contra la que se verificó."

• Paso 1 evidencia: "existe un espacio corregido más la fila contra la que se verificó para cada organizador."
• Paso 2 acción (nivel superior, sirve ese criterio): "Verificar cada espacio del rota contra la hoja de inscripción y corregir cualquier espacio que la hoja no respalde, registrando la fila."
• Paso 3 retroceso: "Pedir a Claude que muestre, para cada espacio, la fila de la hoja de la que proviene" (con Claude) → hijo. "Abrir la hoja de inscripción" (sin Claude) → no es un nodo; perfil o brecha.
• Paso 4 piso en "Juzgar si una fila respalda un espacio": domain_knowledge, porque los organizadores ya gestionan las inscripciones.