Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Schedule a future resume of work - e.g. '/gsd:resume-at 09:00', '/gsd:resume-at +2h', or '/gsd:resume-at 04:00 --cmd /gsd:execute-phase 9'
.claude/skills/davepoon-gsd-resume-at/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-19 | ✗→✓ | ▲ Improved | 626% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 62% | 0% |
| case-10 | ✓→✗ | ▼ Worse | 103% | 0% |
| case-11 | ✓→✗ | ▼ Worse | 140% | 0% |
| case-12 | ✓→✗ | ▼ Worse | 104% | 0% |
<objective> Schedule a future Claude Code session that automatically resumes the current GSD project at the requested time. Useful when:
/gsd:execute-phase 9 at 04:00) for off-peak quota use> No-token fallback. If you've hit your usage cap and the skill itself won't run (it needs tokens to parse args and call CronCreate — the very moment you don't have any), /exit the rate-limited session and invoke the shell wrapper from a plain terminal: > > bash > /exit # leave the rate-limited Claude session first > gsd-resume-at 17:41 # then schedule from your shell — no tokens consumed > # or with explicit duration / project: > gsd-resume-at +3h --project ~/code/myproject > # if gsd-resume-at isn't on PATH: > $CLAUDE_PLUGIN_ROOT/bin/gsd-resume-at +3h > # or fully absolute: > ~/.claude/plugins/cache/gsd-plugin/gsd/<version>/bin/gsd-resume-at +3h > > > Pure shell — uses nohup sleep to schedule an OS-level timer, no Claude tokens consumed. macOS only for v1; the script will tell you if you're on another platform. Does NOT survive a reboot — for durable cross-reboot scheduling, use this skill (/gsd:resume-at) when tokens are available. > > The plugin's Stop hook will surface this same hint automatically when it detects a rate-limit message in the session transcript.
This skill is a thin wrapper. The plugin already covers the resume itself (HANDOFF.json + /gsd:resume-work). What was missing was a way to ask Claude to come back at time T. This skill provides the scheduling on-ramp; Claude Code's built-in /schedule (or CronCreate primitive) does the durable cron storage. </objective>
<process>
HH:MM — today at that local clock time. If the time has already passed today, schedule for tomorrow at the same time.2026-04-28T08:00, 2026-04-28T08:00:00-04:00) — absolute timestamp. Use as-is.+<duration> — relative offset from now. Accept +30m, +2h, +90m, +1d. Compute absolute target as now + duration.If no argument is provided, ask the user via AskUserQuestion: "When should I resume? (e.g. 09:00, +2h, or 2026-04-28T08:00)". If parsing fails, surface the input and the supported forms; do not guess.
/gsd:resume-work (the plugin's standard resumption entry point — restores HANDOFF.json + STATE.md and routes to next action). If the user passed --cmd "<command>", use that command instead. Useful overrides:--cmd "/gsd:next" — resume by jumping to the next workflow step (skips the status-print phase of resume-work)--cmd "/gsd:execute-phase 9" — resume directly into a specific phase--cmd "/gsd:quick <task description>" — schedule a quick task for laterSkill tool to invoke /schedule if the host CLI exposes it; otherwise fall back to CronCreate directly. Pass:prompt: the resolved command (default /gsd:resume-work)time: the absolute timestamp computed in step 1 (ISO 8601, with the local timezone)When /schedule/CronCreate isn't available in the current Claude Code build, surface that explicitly — don't silently no-op. Tell the user the plugin's resume-at skill needs the host's scheduling support, and link them to /schedule documentation.
HANDOFF.json is checkpointed every ≤60s during active work, so the resume reflects state from at most ~60s before this scheduling call (or from the most recent /compact if the session is currently idle)--cmd and the current session has uncommitted dirty state (a non-empty git status -s), warn that a future /gsd:resume-work will pick up whatever HANDOFF reflects at scheduling time — they may want to /gsd:pause-work explicitly first to capture intent before scheduling.</process>
<output_format> After scheduling, emit a confirmation block:
✓ Resume scheduled
When: 2026-04-27 22:00 PDT (2026-04-28 05:00 UTC)
Command: /gsd:resume-work
Project: /Users/you/your-project
HANDOFF: written 47s ago (auto-postool)If a /clear boundary makes sense (long session, scheduling at the end of an active day), suggest /clear per references/continuation-format.md. Otherwise, just confirm and stop — the user is presumably about to step away. </output_format>
<rules>
/gsd:resume-work.--cmd with a non-/gsd: command (e.g. /help), pass it through anyway. Resume-at schedules; it does not gatekeep what runs./loop covers that).</rules>
<notes>
/schedule and CronCreate already handle persistence-across-restarts, timezone math, and authorization correctly. Building our own would duplicate complex code and drift over time. Resume-at exists purely to translate GSD-flavored input (+2h, default /gsd:resume-work) into the form /schedule expects./gsd:resume-work and not /gsd:next: resume-work prints status and routes — useful when you might forget where you were. next jumps straight to action. Default is the safer first-impression choice; users with a clear destination override via --cmd./gsd:resume-work (deletes HANDOFF after restoring) and /gsd:pause-work (writes HANDOFF on demand). resume-at schedules; resume-work restores; pause-work captures.</notes>
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-21 | pass→pass | 11,818 | 6,811 | -42% | 1 | 1 | 0% | 2,382 | 3,107 | +30% | 0 | 0 | — |
case-01 | fail→fail | 7,170 | 4,917 | -31% | 1 | 1 | 0% | 1,231 | 2,107 | +71% | 0 | 0 | — |
case-02 | fail→fail | 10,338 | 6,123 | -41% | 1 | 1 | 0% | 1,831 | 2,098 | +15% | 0 | 0 | — |
case-03 | fail→fail | 6,468 | 5,098 | -21% | 1 | 1 | 0% | 1,141 | 2,111 | +85% | 0 | 0 | — |
case-04 | fail→fail | 3,007 | 5,439 | +81% | 1 | 1 | 0% | 431 | 2,109 | +389% | 0 | 0 | — |
case-19 | fail→pass | 2,584 | 5,582 | +116% | 1 | 1 | 0% | 378 | 2,745 | +626% | 0 | 0 | — |
case-05 | fail→fail | 3,256 | 6,298 | +93% | 1 | 1 | 0% | 459 | 2,121 | +362% | 0 | 0 | — |
case-06 | fail→fail | 4,374 | 6,263 | +43% | 1 | 1 | 0% | 644 | 2,128 | +230% | 0 | 0 | — |
case-07 | fail→fail | 6,175 | 7,810 | +26% | 1 | 1 | 0% | 1,146 | 2,599 | +127% | 0 | 0 | — |
case-08 | pass→pass | 5,702 | 3,653 | -36% | 1 | 1 | 0% | 949 | 2,534 | +167% | 0 | 0 | — |
case-09 | fail→pass | 7,578 | 1,736 | -77% | 1 | 1 | 0% | 1,290 | 2,091 | +62% | 0 | 0 | — |
case-10 | pass→fail | 5,224 | 4,535 | -13% | 1 | 1 | 0% | 999 | 2,030 | +103% | 0 | 0 | — |
case-11 | pass→fail | 4,763 | 6,068 | +27% | 1 | 1 | 0% | 891 | 2,134 | +140% | 0 | 0 | — |
case-12 | pass→fail | 5,390 | 4,265 | -21% | 1 | 1 | 0% | 988 | 2,015 | +104% | 0 | 0 | — |
case-13 | fail→fail | 3,280 | 10,812 | +230% | 1 | 1 | 0% | 560 | 2,676 | +378% | 0 | 0 | — |
case-20 | pass→fail | 6,509 | 5,695 | -13% | 1 | 1 | 0% | 1,126 | 2,151 | +91% | 0 | 0 | — |
case-14 | fail→fail | 8,539 | 11,098 | +30% | 1 | 1 | 0% | 1,292 | 3,109 | +141% | 0 | 0 | — |
case-15 | fail→fail | 6,373 | 6,827 | +7% | 1 | 1 | 0% | 1,010 | 2,182 | +116% | 0 | 0 | — |
case-16 | pass→pass | 6,877 | 6,019 | -12% | 1 | 1 | 0% | 1,280 | 2,947 | +130% | 0 | 0 | — |
case-17 | fail→fail | 6,925 | 5,926 | -14% | 1 | 1 | 0% | 1,245 | 2,079 | +67% | 0 | 0 | — |
case-18 | fail→fail | 5,310 | 6,623 | +25% | 1 | 1 | 0% | 1,027 | 2,167 | +111% | 0 | 0 | — |
case-22 | fail→fail | 3,728 | 5,564 | +49% | 1 | 1 | 0% | 551 | 2,107 | +282% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 7 counted toward the lift figure. The other 15 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of -9 percentage points is the difference between those two pass rates over the 7 comparable cases. 8 cases got worse with the skill loaded, and they are included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.