Skip to content

docs(readme): Claude Code Routines comparison section#27

Merged
stackbilt-admin merged 5 commits intomainfrom
docs/routines-comparison
Apr 16, 2026
Merged

docs(readme): Claude Code Routines comparison section#27
stackbilt-admin merged 5 commits intomainfrom
docs/routines-comparison

Conversation

@stackbilt-admin
Copy link
Copy Markdown
Member

Summary

Anthropic shipped Claude Code Routines (research preview) in April 2026. Routines and cc-taskrunner solve overlapping problems differently. New users evaluating the taskrunner deserve to know the alternative exists and when each substrate is the right fit.

What's added

A new section "cc-taskrunner vs. Claude Code Routines" between "Why This Exists" and "Quick Start":

  • 12-row capability table — where it runs, cost model, trigger types, cadence floor, local FS access, runs-while-laptop-closed, queue management, branch isolation, safety hooks, blast radius, GitHub event triggers, setup overhead
  • "When cc-taskrunner is right" — queue management, local FS access, sub-hour cadence, blast-radius enforcement, hook-level safety
  • "When Routines are right" — single repeatable task, GitHub-event-driven, runs while laptop off, MCP-only mutations
  • Honest disclosure — Stackbilt itself runs the taskrunner in paused mode and uses Routines for several scheduled workloads. Complementary, not competitive.

Why now

Without this disclosure, anyone landing on the README in April 2026 would have to discover the taskrunner-vs-routines trade-offs the hard way after adoption. Better to lay them out upfront so users pick correctly the first time.

Why not deprecate cc-taskrunner instead?

Real cases where taskrunner remains the right tool:

  • Sub-hour cadence (routines have 1h cron minimum)
  • Local filesystem access outside any GitHub repo
  • Queue management with FIFO + dependencies
  • Bash-hook OS-level safety enforcement
  • Blast-radius gating via charter blast

These are real differentiators. The taskrunner stays useful; routines just took some of its workload.

Test plan

  • Render check on GitHub (table, anchor links, decision-rubric formatting)
  • No code changes — README + CHANGELOG only

🤖 Generated with Claude Code

Codebeast and others added 5 commits April 10, 2026 06:34
Adds the standardized Stackbilt-dev security reporting template to this
repository. The template is the canonical per-repo security file rolled
out across the entire Stackbilt-dev organization as part of the outbound
disclosure policy (Stackbilt-dev/docs#15).

Key points:
- Primary reporting channel: admin@stackbilt.dev
- GitHub Security Advisory link scoped to this repo
- Response target matrix (critical 24h ack / 7d fix, high 48h / 14d)
- Full policy link at https://docs.stackbilt.dev/security/
- Explicit "do not open public GH issues for vulns" rule

This replaces the implicit policy that existed via the Stackbilt-dev
organization profile with an explicit per-repo file, so the GitHub
security tab surfaces it and external researchers have a clear
reporting path.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Closes #16. Adds an opt-in guard that captures a baseline snapshot of
typecheck + test state on main BEFORE the task branch is created,
re-runs the same checks on the branch AFTER the task commits, and
automatically reverts the branch (delete locally, skip push/PR, mark
failed) when any check transitioned pass→fail.

Opt-in paths
- Per-task: `"ratchet": true` in the task JSON
- Category default: `refactor` and `bugfix` tasks ratchet automatically
- Environment: `CC_RATCHET=1` force-enables for every task

Never ratcheted
- `docs`, `tests`, `research`, `deploy` categories (no regression surface
  or outcomes aren't code-level)

Decision rule
Only pass→fail transitions revert. fail→fail (unchanged broken surface)
and skip→fail (first-time check on a pre-existing breakage) are both
`keep`. fail→pass is `keep`. The goal is to gate regressions, not
punish tasks for inheriting broken state.

Snapshot surface
- `npm run typecheck` exit code → pass/fail/skip
- `npm test` exit code → pass/fail/skip
- Each check is independent and degrades to `skip` when the repo has
  no corresponding script in `package.json`. Zero new dependencies.

Integration points
- Baseline captured right after `git pull --ff-only`, before the task
  branch is checked out (so we measure true main state).
- Post-validation runs after commits but BEFORE push, so a regressed
  branch never reaches origin and never opens a PR.
- Ratchet state is local to each execute_task() call — initialized up
  front so operator-authority tasks (which skip branch creation) don't
  trip unbound-variable errors under set -u.

Applied symmetrically to taskrunner.sh and plugin/taskrunner.sh.

Smoke-tested ratchet_decision() against 5 transition cases:
- skip→skip: keep ✓
- pass→pass: keep ✓
- pass→fail: revert (rc=1) ✓
- fail→fail: keep (no regression) ✓
- skip→fail: keep (first-time surface) ✓

Env knobs
- CC_RATCHET=1|0              force-enable/disable, overrides task fields
- CC_RATCHET_TIMEOUT=<seconds> per-check timeout (default: 180)
- CC_DISABLE_RATCHET=1         legacy alias for CC_RATCHET=0

Closes #16

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Should've been in the prior commit but Edit bailed on an unread file.
Squash candidate on merge.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…ion (#25)

The worktree-protection pattern (C:* glob for Windows-path pollution,
added in #6) was being appended to .gitignore and staged, causing every
auto-generated PR to include unsolicited .gitignore modifications.

Move the exclusion to .git/info/exclude, which provides identical git
ignore behavior but is local to the repository and never committed.

Closes #25

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Anthropic shipped Claude Code Routines (research preview) in April 2026 —
saved Claude Code configurations that run on Anthropic's cloud on a
schedule, via API trigger, or on GitHub repository events. Routines and
cc-taskrunner solve overlapping problems differently. New users
evaluating the taskrunner deserve to know the alternative exists and
when each substrate is the right fit.

New "cc-taskrunner vs. Claude Code Routines" section between "Why This
Exists" and "Quick Start" includes:
- 12-row capability comparison table (where it runs, cost model, trigger
  types, cadence floor, local FS access, runs-while-laptop-closed, queue
  management, branch isolation, safety hooks, blast radius, GitHub event
  triggers, setup overhead)
- Explicit "when cc-taskrunner is right" decision rubric (queue management,
  local FS access, sub-hour cadence, blast-radius enforcement, hook-level
  safety)
- Explicit "when Claude Code Routines are right" decision rubric (single
  repeatable task, GitHub-event-driven, runs while laptop off, MCP-only
  mutations)
- Honest disclosure that Stackbilt itself runs the taskrunner in paused
  mode and uses Routines for several scheduled workloads — complementary
  not competitive

Framing throughout: pick the substrate that fits the work, neither
obsoletes the other in a real ecosystem.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@stackbilt-admin stackbilt-admin merged commit 678372a into main Apr 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant