loop

PRIMARY skill for clock-based session wakes via scheduleCallback. Use when the user asks for reminders, delays, or recurring checks inside the active conversation — "remind me in 5 minutes", "tomorrow

SKILL.md

GitHub

Loop (PRIMARY for clock-based session wakes)

Session loops inject a message into the current session at a future clock time (delay or cron). They preserve conversation context, history, and workspace, surviving tab switches and app restarts while staying bound to this session's lifecycle.

The MCP tool is scheduleCallback (or scheduled_task__scheduleCallback). The skill name is loop.

vs call-me-back (hard split)

Signal Skill
Wall clock / relative delay / cron loop (this skill)
Process exit, kanban/ticket status, webhook, watcher call-me-back

"끝나면 알려줘" / "작업 끝나고 깨워줘" that means a job or external event finished → call-me-back, not a guessed delaySeconds.

Core Policy: Session-First by Default

When a user asks for a time-based reminder or recurring check inside an active conversation, they almost always expect it in this conversation. Wrong skill choice is usually selecting global schedule / createScheduledTask, which drops session context.

Always default to loop for:

  • "Remind me in X minutes / hours / days" ("X분 뒤에 알려줘")
  • "Tomorrow at 9" / "내일 9시에 알려줘" when continuing this chat
  • "Follow up on this later" ("나중에 확인해줘") when later means a clock time
  • In-session recurring checks ("매일 아침 9시에 이 작업 현황 알려줘")
  • Any relative delay or wall-clock reminder that should reuse this chat's history

When to escalate to global schedule

Escalate to schedule (createScheduledTask) ONLY when:

  • The user explicitly asks for independent, permanent, or app-wide automation ("even if I close this chat", "전역 백그라운드 작업으로 등록해줘").
  • The run must be a standalone assistant task with no session context.
  • It is multi-agent coordination driven by global scheduled tasks.

Handling Ambiguous Requests

If intent is ambiguous (e.g., "매일 9시에 주가 체크해서 알려줘" with no global/permanent wording):

  1. Proceed with loop immediately — do not ask first by default.
  2. Ask only when the request looks like always-on automation that should survive this chat. Then explain once:
    • Loop (default): injects into this chat; invalidated if the session is deleted.
    • Global Scheduled Task: app-wide cron; survives closing/deleting this session.

If ambiguous between time and completion event, ask one clarifying question, or prefer call-me-back when a concrete process/ticket/system was named.

Routing decision

Is the wake driven by a completion event (process / kanban / webhook / watcher)?
  Yes -> call-me-back
  No  -> Should the run stay bound to the current session?
           Yes / Unclear -> loop (scheduleCallback) [DEFAULT]
           Explicit global -> schedule (createScheduledTask)

Both one-shot (delaySeconds) and recurring (cronExpression) are supported. Pick the timing mode, not a different skill — unless the signal is event-based.

Workflow

1. Choose timing mode

Provide exactly one of:

  • delaySeconds — one-shot delay (1–86400). Example: 300 for "check back in 5 minutes".
  • cronExpression — recurring. Example: 0 9 * * * for daily 09:00 local.

Do not pass both. Do not pass neither.

2. Create the schedule

scheduleCallback(
  message="...",           // required instruction injected when it fires
  name="...",              // optional Planning panel label
  delaySeconds=300         // OR cronExpression="0 9 * * *"
)

Requirements:

  • Must run from an active session (tool binds automatically).
  • message must be self-contained for when the agent wakes.
  • assistantId is NOT required.

3. Manage existing session schedules

  • getScheduledTask(taskId)
  • toggleScheduledTask(taskId, enabled=false)
  • deleteScheduledTask(taskId)

Users can also manage these from the session Planning panel.

4. Set expectations honestly

  • One-shot schedules are deleted after they fire.
  • Deleting the session removes its loops; they do not recreate a session.
  • Recurring loops keep firing until paused, deleted, or the session is removed.

Guardrails

  • Do not use createScheduledTask for in-session time reminders; use loop.
  • Do not approximate job completion with delaySeconds; use call-me-back.
  • Do not ask for assistantId when setting a session reminder.
  • Do not require teamwork scaffolding for simple session loops.
  • Prefer delaySeconds for relative delays; cron for named wall-clock recurrence.
  • Give distinct name values when scheduling multiple loops.

Related skills

  • call-me-back — wake on process/kanban/webhook completion (not the clock)
  • schedule — global cron that survives beyond the current session
  • delegate — spawn a child session now
  • teamwork — multi-agent workspace constitution; not needed for simple loops
  • gatekeeper — Creator–Reviewer quality gate for backlog cycles

User guide

Session-clock wakes, writer/reviewer backlog cycles, and copy-paste recipes: docs/user/guides/loop.md (KO) · docs/user/en/guides/loop.md (EN).