grounding: claude-tag users/proactivity.md

Routines, per Claude Tag's own docs

Every row on this site's tasks board is a one-shot unit of work. Grounded in docs/docs/claude.com/docs/claude-tag/users/proactivity.md ("Set up routines"), a routine is a genuinely different shape: standing work that runs on a schedule rather than once. This page grounds the site's second table, routines, in that doc.

1. The definition

"You can give Claude standing work from any channel it's in. This standing work is called a routine: a job that runs on a schedule, such as watching a channel, following a pull request, or posting status updates... it uses that channel's connections with the same permissions as a typed request."

-- proactivity.md, opening. "Uses that channel's connections with the same permissions as a typed request" is the same claim subagentroles.com's permissions board already makes about this repo's own read routes: a routine doesn't get elevated privilege just because it's scheduled instead of interactive.

2. Three real shapes claude-tag names

Scheduled jobs — "every weekday at 9am, read the open threads in this channel... post a one-line status per item."
Watch channels — "watch #product-announce... once a day, post here if anything is relevant."
Follow a pull request — "subscribe to PR #482... when CI finishes or a review lands, post here."

-- proactivity.md, "Set up standing work." This site's trigger_kind column doesn't reuse these three names directly, because none of this repo's real routines are Slack-triggered — instead it generalizes to the actual trigger mechanisms this ecosystem uses: cron_schedule (a real Cloudflare Cron Trigger), session_tool_call (a routine set up mid-session via a tool call, the closest analogue to "describe the schedule in one message"), and heartbeat_dispatch (a pipeline chained off a recurring tick rather than a fixed time).

3. Failure has a real, specified shape

"A recurring job that can't reach its repository skips that run and retries on its next schedule; after three consecutive failed runs spanning at least an hour, it disables itself. A one-time job that can't reach its repository is disabled on the first failure; the routine's page shows why."

-- admins/configure-github.md, "Scheduled work uses the same connection" (cross-referenced from proactivity.md's own "Related resources"). The routines board's retry_policy column exists specifically to check each real repo routine against this bar — and one of the three seeded rows, rtn_cron_job_crawl, honestly fails the comparison: this repo's own workers/cron trigger has no documented retry-then-disable policy, unlike the real claude-tag mechanism this doc specifies. Flagged, not hidden.

4. Standing work is scoped, not personal

"Standing work is visible to the channel: jobs post into the channel they belong to. Routines keep running if their creator leaves the organization, but stop firing if the creator is removed from the channel."

-- proactivity.md, "Manage standing work." This is the same scope-not-person binding subagentidentities.com's access bundles already model for credentials: a routine belongs to the scope it runs in, the same way bundle_docker_mcp_toolkit belongs to the cloud__* surface regardless of which session invokes it, not to whichever operator happened to set it up.

What this site adds