choose-loop-wakeup-interval
정보
이 스킬은 자동화된 루프 웨이크업을 스케줄링할 때 최적의 `delaySeconds` 값을 선택하는 전략을 제공합니다. 캐시를 고려한 3단계 결정 로직으로 간격을 선택하며, 런타임 클램핑과 반올림 특성을 처리하고, 원격 측정에 적합한 추론을 보장합니다. 자율 루프 설계, 폴링 주기 조정, 또는 간격 관련 성능 문제 진단 시 사용하세요.
빠른 설치
Claude Code
추천npx 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-intervalClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
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
GitHub 저장소
연관 스킬
executing-plans
디자인executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.
requesting-code-review
디자인이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.
connect-mcp-server
디자인이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.
web-cli-teleport
디자인이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.
