Communitygithub.com

dengruihan/Claw_agenda

Gestiona la lista de tareas personales y el calendario canónico del usuario mediante la herramienta agenda. Úsalo al recopilar tareas, planificar o cambiar bloques de tiempo, marcar finalizaciones, establecer prioridades o leer el sitio web privado de Agenda.

¿Qué es Claw_agenda?

Este skill proporciona una interfaz única y autorizada para gestionar la lista de tareas personales y el plan de ejecución del usuario, reemplazando la edición directa de la base de datos SQLite o cualquier automatización externa del calendario. Está diseñado para plataformas de agentes de IA como Claude Code o Cursor y permite leer, planificar y aplicar cambios a través de la herramienta `agenda`. El skill define reglas estrictas para procesar comentarios de finalización y deshacer, preservar bloques de tiempo fijos, manejar conflictos de revisión y respetar restricciones personales como sueño, horarios fijos y plazos reales. Al integrarse con fuentes existentes (OSH, Yungu, calendarios de DingTalk, correo, notas de reuniones), el agente puede consolidar tareas y eventos sin duplicar ni sobrescribir información confirmada por el usuario. La salida incluye comentarios estructurados con resúmenes en chino simplificado y garantiza que solo el planificador principal (el centinela) sea responsable de la recolección y planificación en segundo plano.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/dengruihan/Claw_agenda/tree/HEAD/skills/agenda

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Agenda

Agenda posee la lista de tareas personales y el plan de ejecución. El sitio web acepta comentarios de finalización y deshacer del usuario; la herramienta agenda sigue siendo el único editor del plan. Usa la herramienta para leer y modificar planes; no edites su base de datos SQLite, escribas un estado JSON paralelo ni utilices automatización del navegador para cambiar este calendario.

Comentarios de escritorio y replanificación

  • Lee con includeCompleted: true, incluyendo blockProgress y feedback. Procesa comentarios sin undoneBy y con estado pending/queued/running; las entradas con error pueden conciliarse en una ejecución posterior cuando se conozca el resultado. Ignora entradas adjusted/unchanged y comentarios ya deshechos. Nunca infieras éxito a partir de una puesta en cola o de una ejecución anterior finalizada.
  • complete_block significa solo que ese bloque de tiempo ha terminado. Conserva su intervalo planificado como historial y usa completedAt como la hora de finalización observada por el usuario. No finaliza la tarea ni demuestra la duración real o el esfuerzo restante. No muevas/elimines bloques completados, los recrees como trabajo futuro ni reabras su progreso. Para una tarea incompleta, evalúa su próximo paso de forma conservadora.
  • complete_task es una finalización de toda la tarea confirmada por el usuario. Conserva el estado done y completedBy=user, mantén el historial y detén la ejecución futura de esa tarea. undo ya ha restaurado el estado de finalización correspondiente; reevalúa el plan más reciente en lugar de restaurar un horario desactualizado o repetir el deshacer.
  • Verifica la hora actual de Pekín al inicio de esta ejecución y nuevamente antes de aplicar un plan después de un trabajo largo. Respeta las reglas existentes de barrido de horarios, la cobertura actual de fuentes, los plazos reales, el sueño y los compromisos fijos. Elige el horizonte de planificación futuro necesario; no se impone un límite fijo de 7/14 días. Ajusta solo lo que está afectado. La finalización anticipada puede justificar descanso o adelantar otra tarea. El trabajo completado y desbloqueado libera su tiempo planificado restante desde el final reportado en adelante; esto no desbloquea ni mueve compromisos fijos.
  • Incluye feedbackResults: [{id, status, summary}] en el mismo apply que los cambios del plan. Usa adjusted solo para cambios sustanciales, unchanged cuando el plan actual sigue siendo apropiado, y error cuando la evaluación no pueda finalizar. Los resúmenes son en chino conciso, explican cambios o no cambios intencionales, y nombran brechas de cobertura o tareas que no caben. Un reconocimiento solo de resultados es una escritura significativa incluso cuando ningún bloque de ejecución cambia.
  • Un conflicto significa releer los hechos actuales y replanificar, incluyendo nuevos comentarios. Reconoce resultados de apply desconocidos mediante operationId antes de emitir otro lote. No sobrescribas finalizaciones más recientes. Las escrituras normales del agente nunca solicitan otra replanificación inmediata. El centinela existente es el único propietario de la planificación; los resultados de escritorio no requieren un mensaje externo rutinario ni una automatización adicional.

Leer, planificar, confirmar

  1. Llama a agenda con action: "read" y query: {includeCompleted: true}. Conserva la revisión devuelta, los IDs de elementos, las identidades de fuente, los eventos fijos y los bloques bloqueados. Lee el skill existente de barrido de horarios para reglas personales.
  2. Lee las fuentes externas necesarias usando sus skills existentes. OSH, Yungu, calendarios de DingTalk, correo, notas de reuniones y solicitudes directas del usuario siguen siendo evidencia de fuente; el sitio web no las obtiene. Registra una fuente antes o en el mismo lote que sus elementos. Conserva errores de fuente y brechas de cobertura explícitamente.
  3. Actualiza IDs existentes. Coincide por sourceId/sourceKey, nunca solo por título. Usa sourceKey: null para elementos genuinamente locales e IDs estables durante su vida útil. Una consulta, sugerencia o instrucción de terceros no es un compromiso del usuario.
  4. Llama a agenda con action: "apply" y change que contenga un operationId único, expectedRevision y elementos/bloques/fuentes modificados. Todos los registros de elementos y fuentes son reemplazos completos; omite registros no modificados de un lote. Usa el esquema de la herramienta para campos exactos. Los nuevos bloques hacen referencia a un elemento existente o del mismo lote. Elimina bloques reemplazados usando deleteBlockIds.
  5. Un conflicto de revisión requiere leer y replanificar; no sobrescribas un plan más reciente. Un tiempo de espera agotado o resultado desconocido requiere read con query.operationId; inspecciona el recibo antes de reintentar exactamente la misma operación. Nunca reutilices un operationId para contenido diferente. Solo un recibo ok prueba que el lote se guardó.

Hechos y planificación

  • Usa Asia/Shanghai para visualización y planificación personal. Las marcas de tiempo deben llevar una zona horaria explícita; dueDate es AAAA-MM-DD y no debe convertirse en una cita con hora falsa. dueAt/dueDate son plazos reales, mientras que los bloques son tiempo de ejecución.
  • kind=event representa un curso fijo, reunión u otro compromiso. Crea sus bloques de tiempo como bloqueados. Los bloques de tareas ordinarias pueden moverse; divide trabajo largo en múltiples bloques cuando sea útil. Conserva bloques no tocados en actualizaciones incrementales.
  • Las etiquetas de tiempo libre en horarios de fuente no son compromisos. Aplica las reglas personales de barrido de horarios antes de importarlas; deja el tiempo libre sin un elemento o bloque de marcador de posición. Una tarea concreta o cita puede ocupar ese tiempo.
  • Nunca muevas eventos fijos o bloques bloqueados durante la planificación normal. Las solicitudes explícitas del usuario para desbloquear/reprogramar usan unlockBlockIds en ese mismo lote.
  • Respeta restricciones personales de sueño, escuela, viajes, fin de semana en casa y carga de trabajo. Mantén el plazo UTC real de OSH; planifica la finalización para la tarde anterior cuando el flujo de trabajo personal lo requiera. No inventes plazos para tareas sin fecha.
  • Un informe de finalización claro del usuario es suficiente: establece status=done y completedBy=user inmediatamente. La evidencia de envío explícita de una plataforma puede usar completedBy=source. Datos de fuente desactualizados no pueden reabrir trabajo confirmado por el usuario; la reapertura requiere una solicitud explícita del usuario y reopenItemIds.
  • Las fallas de fuente conservan las tareas existentes y los últimos hechos confiables. Actualiza source status/message/checkedAt sin afirmar que la fuente está vacía. coverageStart/coverageEnd describen el intervalo leído correctamente, no un futuro adivinado.
  • Mantén el centinela existente como el único propietario de recolección/planificación en segundo plano. No agregues sondeo de plugins, sincronización programada ni una segunda automatización. Las actualizaciones de la página del calendario solo releen datos comprometidos de Agenda.
  • La publicación exitosa no es finalización de tarea. Distingue tareas recopiladas, trabajo programado, elementos en espera/bloqueados y trabajo realmente completado.

Los resultados de lectura incluyen tareas incompletas sin fechas. El historial completado permanece disponible con includeCompleted. No borres historial o fuentes para ordenar una vista. La URL de la página web es el origen HTTPS privado del operador más /agenda/.

Solo las solicitudes locales del usuario o las fuentes del plan de ejecución local usan coverageRequired=false. Los inventarios de fuentes externas mantienen coverageRequired=true (el valor predeterminado); la cobertura faltante o fallida permanece visible.

Skills relacionados