add-cron

⚠️ Before any call to wrangler (do this BEFORE any other wrangler command in this skill)

eval "$(node "${CLAUDE_SKILL_DIR}/../../scripts/wrangler-env-init.mjs")"

This line loads CLOUDFLARE_API_TOKEN from User scope (Windows registry / shell rc on Mac/Linux) if it is not already in process.env, and adds the pnpm bin to PATH (for bash sessions where pnpm setup has not yet propagated). Without it, wrangler fails with "command not found" on Mac (Spotlight), or may use a different Cloudflare account than the one the user expects.

Add Cron - Scheduled tasks (auto-routing between 3 clocks)

Communication

• Detect the user's language from the conversation (the user's own messages, anywhere in the session - not just this invocation: a bare slash command like /bootstrap carries no language signal by itself). If nothing in the conversation gives a signal, fall back to the OS locale (node -e "console.log(Intl.DateTimeFormat().resolvedOptions().locale)") before defaulting to English. ALWAYS reply in that language for every user-facing message: questions, progress, confirmations, summaries, errors - including any example text quoted in this skill, which is illustrative and must be translated, never sent verbatim.
• Use plain, non-technical business language. Never expose internal script names (*.mjs) or jargon; describe actions in human terms.
• When generating user-facing content for the scaffolded project (UI labels, emails, copy), write it in the user's language too.
• Show progress as a short natural-language checklist (in-progress and done states).

You add a scheduled task to the current Next.js project. You decide yourself which clock is best, based on the nature of the task. You ask the user NOTHING about this choice - you act, then you explain in 1 sentence what you did in the final summary.

Non-tech audience: language rules

The users of this plugin may be non-technical. In EVERYTHING you show to the user:

• Zero gratuitous jargon. No "Worker", "Action", "workflow", "endpoint", "slot", "trigger", "cron expression", "bearer token", "repo", "yaml" without explanation. When a technical term is unavoidable, put it in parentheses or explain it in a short clause.
• Speak in business terms, not infrastructure. Say "a scheduled task" rather than "a cron", "your shared clock" / "a dedicated clock" / "the GitHub clock" rather than "the hypervibe-jobs worker" / "CF Worker" / "GitHub Action", "your site" rather than "your Next.js endpoint", "your keys" rather than "your env vars".
• NEVER suggest commands to type. The user does not open a terminal. When an action is possible (delete, test, view the logs, change the schedule), offer it in natural language - "tell me 'delete task X' and I'll take care of it", "do you want me to run it right now to test it?". Claude executes, the user does not type.
• Avoid tech anglicisms ("skipped", "overkill", "fallback", "deploy") in user-facing blocks. Internal use only.