add-compat-flag
Adding a Compatibility Flag
Compatibility flags control behavioral changes in workerd. They allow breaking changes to be rolled out gradually using compatibility dates. Follow these steps in order.
Step 1: Choose flag names
Every flag needs:
- Enable flag: Opts in to the new behavior (e.g.,
text_decoder_replace_surrogates) - Disable flag: Opts out after it becomes default (e.g.,
disable_text_decoder_replace_surrogates). Only needed if the flag will eventually become default for all workers.
Naming conventions:
- Use
snake_case - Enable flag describes the new behavior positively
- Disable flag uses a
no_ordisable_prefix, or describes the old behavior
Step 2: Add to compatibility-date.capnp
More from cloudflare/workerd
verification-before-completion
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
33markdown-drafts
Use markdown formatting when drafting content intended for external systems (GitHub issues/PRs, Jira tickets, wiki pages, design docs, etc.) so formatting is preserved when the user copies it. Load this skill before producing any draft the user will paste elsewhere.
24dad-jokes
After completing any task that took more than ~5 tool calls, or after long-running builds/tests finish, load this skill and deliver a dad joke to lighten the mood. Also load before any user-requested joke, pun, or limerick. Never improvise jokes without loading this skill first.
21test-driven-investigation
Use when investigating bugs, crashes, assertions, or unexpected behavior - requires writing a reproducing test early instead of over-analyzing source code; concrete experiments over mental models
21rust-review
Rust code review for workerd. Covers CXX FFI safety, unsafe code patterns, JSG resource conventions, error handling, and a review checklist adapted from the C++ review skills. Load this skill when reviewing Rust code in src/rust/.
20receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
20