choose-loop-wakeup-interval
Acerca de
Esta habilidad proporciona una estrategia para seleccionar valores óptimos de `delaySeconds` al programar reactivaciones automatizadas en bucle. Implementa una lógica de decisión de tres niveles consciente de la caché para elegir intervalos, maneja peculiaridades de ajuste y redondeo en tiempo de ejecución, y garantiza un razonamiento listo para telemetría. Úsela al diseñar bucles autónomos, ajustar la cadencia de sondeo o diagnosticar problemas de rendimiento relacionados con intervalos.
Instalación rápida
Claude Code
Recomendadonpx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/choose-loop-wakeup-intervalCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
Choose Loop Wakeup Interval
Pick delaySeconds for ScheduleWakeup → respects prompt cache 5-min TTL + scheduler whole-min granularity + [60, 3600] clamp. Non-trivial: "wait ~5 min" → worst-of-both zone → pay cache miss without amortizing wait.
Reasoning travels w/ ScheduleWakeup tool desc at call time → but loop already scheduled. This skill hoists reasoning → planning time.
Use When
- Designing autonomous
/looporScheduleWakeupcontinuation → pick per-tick delay - Heartbeat cadence for long-running agent
- Tuning polling vs. cost/cache-warmth
- Post-hoc: loop cost review → mis-sized interval
- Guide/runbook w/
delaySecondsexample
In
- Required: What loop waits for (event, state transition, idle tick, periodic check)
- Required: Next tick needs fresh ctx (cache-warm) or cold re-read OK (cache-miss OK)
- Optional: Known lower bound on event occurrence ("build ≥4 min")
- Optional: Cost ceiling (ticks × per-tick cost)
Do
Step 1: Classify the Wait
Tier decision:
- Active watch (cache-warm): Change expected <5 min → build near done, state transition, just-kicked proc
- Cache-miss wait: Nothing worth checking <5 min → cache cold OK
- Idle: No specific signal → checking in case
→ Classification: active-watch, cache-miss, or idle.
If err: Can't classify → no honest answer to "what waiting for?" → loop shouldn't exist → skip to Step 5.
Step 2: Apply Three-Tier Decision
Pick delaySeconds:
| Tier | Range | Cache | Use when |
|---|---|---|---|
| Cache-warm | 60 – 270 s | Warm (<5-min TTL) | Active watch — fast cheap re-entry |
| Cache-miss | 1200 – 3600 s | Cold; miss buys long wait | Idle, or event can't happen sooner |
| Idle default | 1200 – 1800 s (20–30 min) | Cold | No specific signal; periodic |
Do not pick 300 s. Worst-of-both: cache misses, wait too short to amortize. Reaching for "~5 min" → drop to 270 s (warm) or 1200 s+ (amortize).
→ Specific delaySeconds from one of three tiers, not round-minute habit.
If err: Keep landing on 300 s → real question is "should loop exist at this cadence?" → re-examine Step 1.
Step 3: Size for Minute Boundary
Scheduler fires on whole-min boundaries. delaySeconds = N → actual N to N + 60 s, depending on call second.
Example:
ScheduleWakeup({delaySeconds: 90})atHH:MM:40→ targetHH:(MM+2):00→ actual 140 s, not 90 s.
Sub-minute intent meaningless. Value = floor, not precise. Min of skew matters → cadence too tight for this mech.
→ Accepted actual wait up to 60 s longer than requested. Cache-warm: 270 s → ~330 s → tips into cache-miss.
If err: Near-ceiling values common (265 s for cache-warm) → pad down → 240 s preserves warmth under worst-case skew.
Step 4: Respect the Clamp
Runtime clamps delaySeconds → [60, 3600]. Out-of-range → silently adjusted. Telemetry: chosen_delay_seconds vs. clamped_delay_seconds + was_clamped: true.
Plan vs. clamped, not requested:
- Req <60 → actual 60 s + skew (up to 120 s)
- Req >3600 → actual 3600 s (1 h)
- No ceiling extension → multi-hour = multi tick
→ Value in [60, 3600] or clamp accepted.
If err: Genuinely multi-hour ("wake in 4 h") → chain wakeups (3600 s tick reschedules) or cron loop (CronCreate w/ kind: "loop").
Step 5: Write Specific reason
reason = telemetry + user status + cache-warmth reasoning. 200-char limit. Specific.
- Good:
checking long bun build,polling for EC2 instance running-state,idle heartbeat — watching the feed - Bad:
waiting,loop,next tick,continuing
Reader = user glancing at status → write for them.
→ Concrete one-phrase reason sensible to glancing user.
If err: No specific reason → revisit loop existence (Step 1, Step 6).
Step 6: Recognize Don't-Loop Case
Not every "come back later" = scheduled wakeup. Do NOT schedule when:
- User actively watching → their input is trigger, not timer
- No convergence criterion → no "done" def
- Interactive task (asks user between ticks)
- Cadence <clamp floor (60 s) → tight polling = event-driven, not loop
→ Conscious choice: schedule wakeup vs. no loop. "Because I could" ≠ reason.
If err: User keeps interrupting wakeups → pattern wrong, not interval.
Check
- Wait classified: active-watch, cache-miss, or idle
-
delaySecondsin one of three tier ranges (60–270, 1200–3600, 1200–1800 idle) - Value ≠ 300 (worst-of-both)
- Value in
[60, 3600]or clamp explicitly accepted - Minute-boundary skew accounted (value = floor)
-
reasonconcrete + <200 chars - Don't-loop check done → wakeup warranted
Traps
- Round-minute default (300 s): #1 mistake. "About 5 min" feels natural, is wrong. → 270 s or 1200 s+.
- Ignoring minute-boundary skew: 60 s req near min end → ~120 s actual. Cache-warm: past 5-min TTL.
- Sub-min precision: Min granularity. 85 vs. 90 vs. 95 s = noise. Pick + move.
- Opaque
reason:"waiting"= nothing. Write for user status line. - Justifying unnecessary loop: Vague "watching for?" → no interval helps → loop shouldn't exist.
- Hand-clamping in prompt: Don't clamp in reasoning ("cap at 3600"). Runtime clamps.
- Forgetting 7-day age-out: Dynamic loop reaped after 7 days default (up to 30). Long loops end before ceiling.
Examples
Example 1 — Cache-warm active watch
bun build kicked off → agent checks quick → cache warm at results.
- Classify: active watch (Step 1)
- Tier: cache-warm (Step 2) → 240 s
- Min boundary (Step 3): worst-case ~300 s → under 5-min TTL w/ 60 s buffer
- Reason (Step 5):
checking long bun build
Example 2 — Idle heartbeat
Autonomous agent watches low-volume feed 1×/h.
- Classify: idle (Step 1)
- Tier: idle default (Step 2) → 1800 s (30 min)
- Min boundary (Step 3): irrelevant → 60 s skew negligible
- Reason (Step 5):
idle heartbeat — watching the feed
Example 3 — Anti-pattern
Agent wants "wait 5 min" → remote API retries → 300 s req.
- Problem: cache cold at 5 min → 300 s pays miss but too short to amortize
- Fix: → 270 s (warm) or 1500 s (amortize). Not 300.
→
manage-token-budget— cost ceilings; cache-aware sizing is one leverdu-dum— observe/act pattern; this skill sizes observe-clock when cron-lessread-continue-here— cross-session handoff; this = within-session wakeupswrite-continue-here— complement ofread-continue-here
Repositorio GitHub
Frequently asked questions
What is the choose-loop-wakeup-interval skill?
choose-loop-wakeup-interval is a Claude Skill by pjt222. Skills package instructions and resources that Claude loads on demand, so Claude can perform choose-loop-wakeup-interval-related tasks without extra prompting.
How do I install choose-loop-wakeup-interval?
Use the install commands on this page: add choose-loop-wakeup-interval to Claude Code as a plugin, or clone its repository into your skills directory, then restart Claude so it picks up the skill.
What category does choose-loop-wakeup-interval belong to?
choose-loop-wakeup-interval is in the Design category, tagged design.
Is choose-loop-wakeup-interval free to use?
Yes. choose-loop-wakeup-interval is listed on AIMCP and free to install. It runs inside Claude, so no separate service account is required to use the skill itself.
Habilidades relacionadas
Utilice la habilidad executing-plans cuando tenga un plan de implementación completo para ejecutar en lotes controlados con puntos de revisión. Esta habilidad carga y revisa críticamente el plan, luego ejecuta tareas en pequeños lotes (por defecto 3 tareas) mientras reporta el progreso entre cada lote para la revisión del arquitecto. Esto asegura una implementación sistemática con puntos de control de calidad integrados.
Esta habilidad despacha un subagente revisor de código para analizar los cambios en el código frente a los requisitos antes de proceder. Debe usarse después de completar tareas, implementar funciones principales o antes de fusionar con la rama principal. La revisión ayuda a detectar problemas de forma temprana al comparar la implementación actual con el plan original.
Esta habilidad proporciona una guía integral para que los desarrolladores conecten servidores MCP a Claude Code mediante transportes HTTP, stdio o SSE. Cubre la instalación, configuración, autenticación y seguridad para integrar servicios externos como GitHub, Notion y APIs personalizadas. Úsala al configurar integraciones MCP, al configurar herramientas externas o al trabajar con el Protocolo de Contexto del Modelo de Claude.
Esta habilidad ayuda a los desarrolladores a elegir entre las interfaces web y CLI de Claude Code mediante el análisis de tareas, y luego permite la teletransportación fluida de sesiones entre estos entornos. Optimiza el flujo de trabajo gestionando el estado y el contexto de la sesión al cambiar entre web, CLI o móvil. Úsala para proyectos complejos que requieren diferentes herramientas en varias etapas.
