ARQAWA/cursor-pi

Definir Goal

Resumen

Da forma a la intención del usuario para convertirla en un resultado concreto, con alcance acotado y criterios de finalización derivados de la solicitud. La verificación ordinaria utiliza lectura y evaluación lógica bajo las reglas del prompt principal; usa números solo cuando expresen un requisito real.

Esta habilidad cubre únicamente la definición del goal y la creación de la herramienta goal. No crees artefactos de planificación intermedios, instantáneas duraderas, registros, logs de decisión ni archivos de reanudación a partir de esta habilidad.

Solo el Main raíz gestiona el Goal nativo. Su selección no añade pruebas, revisiones, delegación, permisos ni otros flujos de trabajo. El Gold Standard evalúa de forma independiente el estado de trabajo útil, con o sin Goal. Notebook puede unirse automáticamente a un Goal seleccionado bajo sus propias condiciones, sin otra solicitud manual; Goal por sí solo no lo requiere. Mantén notas operativas útiles bajo esa política, fuera de este procedimiento de definición; el objetivo y estado nativos siguen siendo autoritarios.

La definición por sí sola no autoriza la ejecución de la tarea propuesta. Goal nunca reemplaza la aprobación o confirmación de ejecución requerida: la preparación de ToSpec no inicia el Goal de ejecución futuro, mientras que un Goal de preparación seleccionado explícitamente se refiere únicamente al resultado de preparación solicitado. La selección automática no anula una pausa del usuario ni convierte un bloqueador, espera de aprobación, final de turno o cancelación sin descarte en finalización. Sigue las reglas de estado nativas reales; la finalización requiere el resultado real y todas las acciones ya obligatorias.

Flujo de trabajo

1. Evalúa si Goal es útil para la orden actual real.

   • Selecciónalo automáticamente cuando un resultado solicitado de forma independiente necesite continuidad a través de etapas dependientes, investigación sustancial o incertidumbre, o ejecución prolongada, sujeto a la verificación de autoridad del paso 6.
   • Las preguntas cortas, las ediciones breves y directas y la discusión sobre posibles trabajos futuros no requieren Goal. El descubrimiento solicitado puede tener en sí mismo un resultado concreto; discutirlo no autoriza a ejecutarlo.
   • Un /goal directo, una solicitud para crear un goal o una petición de definición de goal selecciona esta habilidad independientemente de la complejidad. Una instrucción de trabajar sin Goal tiene prioridad sobre la selección automática para la tarea afectada.
   • Reevalúa después de un cambio material en la tarea, no en cada llamada de herramienta; no uses umbrales para comandos, minutos o archivos.

2. Reformula el goal probable en términos concretos. Un goal utilizable nombra:

   • el resultado específico que será verdadero
   • el artefacto, sistema, repositorio, entorno o comportamiento visible para el usuario involucrado
   • cómo se establecerá el resultado real mediante lectura y evaluación lógica, más cualquier evidencia explícitamente requerida
   • qué está dentro del alcance
   • qué está fuera del alcance cuando la ambigüedad importaría
   • la condición de parada para preguntar al usuario en lugar de insistir

3. Usa criterios que representen el resultado solicitado.

   • Deriva el resultado, las rutas de los artefactos, el alcance, el formato, los valores y las condiciones binarias de finalización a partir de la solicitud.
   • No inventes métricas, umbrales, validadores ni recuentos de ejecución para una mensurabilidad formal.
   • Las pruebas, comandos, CI, mediciones y recuentos de evidencia son opciones solo para evidencia empírica explícitamente solicitada o un procedimiento adoptado específicamente o una obligación de mayor prioridad.
   • Para correcciones ordinarias, análisis o trabajo de rendimiento basado en arquitectura, define la finalización a través del resultado real y la evaluación lógica.

4. Repara los goals débiles antes de establecerlos.

   • Reescribe los goals vagos en criterios de resultado concretos cuando la solicitud y el contexto local hagan segura esa interpretación.
   • Haz una pregunta de aclaración concisa cuando el detalle faltante cambie el resultado previsto o la validación.
   • Rechaza los goals de actividad pura como "avanzar", "seguir investigando", "mejorar cosas" o "trabajar en X" a menos que se afinen en un resultado verificable.

5. Verifica el estado del goal activo antes de crear un goal.

   • Lee la instantánea actual del Goal nativo raíz desde scope_focus_native_context. Valida conversationId, goalId, objetivo y estado nativo (0 no especificado, 1 activo, 2 pausado, 3 completado, 4 borrado). Un estado raíz válido ausente significa que no hay goal; identidad/estado desconocido es desconocido, no ausencia. Los hijos no gestionan el Goal raíz. Usa solo los campos de presupuesto nativos reales cuando se proporcionen; no los inventes.
   • Usa las herramientas nativas disponibles create_goal/update_goal y sus esquemas actuales. Cursor create_goal toma objective; no pases un campo de presupuesto solo de Codex. Una capacidad nativa requerida faltante detiene su transición dependiente; no simules Goal ni afirmes preparación completa.
   • Si no hay un goal sin finalizar, el objetivo cumple con el estándar de calidad y el paso 6 permite la creación, llama a create_goal.
   • Reutiliza un goal sin finalizar que coincida según las instrucciones actuales del usuario y el estado nativo; la selección repetida no crea un duplicado ni repite operaciones completadas.
   • Conserva un goal sin finalizar en conflicto. No lo reinicies, reemplaces ni marques como completado solo para hacer espacio. Resuelve solo el conflicto material a través de una ruta nativa permitida o una pregunta de usuario enfocada; no requieras un nuevo hilo.

6. Crea el goal solo después de que supere el estándar de calidad.

   • Elegir esta habilidad no autoriza por sí mismo create_goal. Sigue las instrucciones reales de la herramienta y las reglas de mayor prioridad. La adopción expresa por parte del usuario del Goal automático condicional, o una instrucción aplicable del sistema/desarrollador, proporciona una solicitud permanente solo donde esas reglas la acepten. La disponibilidad de la habilidad o una tarea ordinaria por sí sola no es esa autoridad; si el host requiere una solicitud explícita separada, no infieras permiso en contra de ese requisito.
   • Si Goal nativo no está disponible o no está permitido, no lo simules con archivos u otro controlador. Continúa con el trabajo autorizado compatible; divulga la limitación concreta solo cuando sea material para el resultado o un Goal explícitamente solicitado.
   • Usa una única cadena de objetivo concisa.
   • Incluye fundamentos suficientes para la finalización: el resultado solicitado evaluado mediante lectura y lógica, más cualquier evidencia explícitamente obligatoria. Cada umbral o método añadido debe seguir la solicitud; escribirlo en el objetivo no crea autoridad.
   • Incluye límites de alcance cuando restrinjan el trabajo.
   • Un presupuesto se proporciona solo cuando se solicita explícitamente y es compatible con el esquema nativo real. Si un presupuesto solicitado no puede representarse mediante el Goal nativo de Cursor, detén esa transición dependiente y divulga la capacidad faltante; no descartes ni simules el presupuesto en silencio.
   • Formula un goal claro y permitido sin volver a preguntar únicamente para habilitar el modo o aprobar su redacción técnica. Pregunta solo cuando una elección faltante cambie materialmente el resultado solicitado, la autoridad o la evidencia obligatoria. Una solicitud de solo definición sigue siendo solo definición.

Estándar de Calidad del Goal

Antes de create_goal, el objetivo debe responder:

• ¿Qué cosa concreta será verdadera cuando esto esté hecho?
• ¿Qué material y fundamentos lógicos reales lo establecen, y qué evidencia empírica solicitó explícitamente el usuario?
• ¿Qué resultado solicitado o condición binaria o cuantitativa significativa define el éxito?
• ¿Qué límites de alcance importan?
• ¿Qué debería hacer que el agente se detenga y pregunte?

Bueno:

Reemplazar A por B en el entorno especificado. Finalizar cuando la edición esté presente y la lectura del código afectado establezca coherencia con la solicitud.

Bueno:

Resolver la pregunta de diseño especificada a partir de fuentes y lógica relevantes. Finalizar cuando la conclusión esté respaldada y se aborden las contradicciones materiales.

Débil:

Hacer que el proceso de pago sea más rápido.

Débil:

Seguir investigando los comentarios del PR.

Heurísticas de Cuantificación

• Para errores, define la corrección requerida y explícala a través del código afectado y la lógica. La reproducción y un validador que falla y luego pasa requieren una solicitud explícita de esa evidencia.
• Para pruebas explícitamente solicitadas, nombra el escenario ordenado y su condición de aprobación; respeta un comando especificado.
• Para rendimiento, razona a partir de mecanismos, trabajo y contexto. Etiqueta la complejidad calculada como cálculo; reivindica una mejora medida solo a partir de mediciones reales. No inventes una métrica, objetivo, método o recuento de ejecución.
• Para trabajo de calidad, usa el resultado solicitado, evaluado ordinariamente mediante lectura y lógica; no añadas lint, comprobaciones de tipos ni pruebas automáticamente.
• Para investigación, define la decisión que la investigación debe habilitar, las fuentes o sistemas dentro del alcance y el estándar de evidencia.
• Para operaciones, define el estado resultante solicitado. No inventes ventanas de monitoreo, umbrales ni trabajo de reversión.

Preguntas Aclaratorias

Pregunta solo cuando una reescritura razonable corra el riesgo de perseguir el resultado incorrecto. Mantén la pregunta corta y orientada al validador faltante o al límite de alcance.

Formas de pregunta útiles:

• "¿Qué métrica debería definir el éxito aquí: latencia, costo, precisión o comportamiento visible para el usuario?"
• "¿Contra qué entorno debo verificar: local, staging o producción?"
• "¿Cuál es la evidencia mínima que deseas antes de que marque este goal como completado?"

Cuando un criterio significativo se sigue directamente de la solicitud, formúlalo sin otra confirmación. Pregunta solo cuando una elección no resuelta cambie materialmente el resultado o la evidencia obligatoria.