docs(readme): Claude Code Routines comparison section#27
Merged
stackbilt-admin merged 5 commits intomainfrom Apr 16, 2026
Merged
docs(readme): Claude Code Routines comparison section#27stackbilt-admin merged 5 commits intomainfrom
stackbilt-admin merged 5 commits intomainfrom
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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":
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:
charter blastThese are real differentiators. The taskrunner stays useful; routines just took some of its workload.
Test plan
🤖 Generated with Claude Code