Structured scratch tracking document for investigation state during bug hunts - prevents re-reading code, losing context, and rabbit holes; maintains external memory so you don't re-derive conclusions
KJ/workerd C++ style guidelines for code review. Covers naming, type usage, memory management, error handling, inheritance, constness, and formatting conventions. Load this skill when reviewing or writing C++ code in the workerd codebase.
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.
Bootstrap skill for discovering additional skills and context from a parent project when workerd is used as a submodule. Load this skill when tasks span project boundaries (e.g., Sentry/production investigation, integration testing, cross-repo debugging).
Guidelines for posting pull request review comments via GitHub CLI, including suggested edits format, handling unresolved comments, etiquette, and report/issue tracking. Load this skill when reviewing a PR via GitHub and posting inline comments.
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
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/.
JS/TS style guidelines and review checklist for workerd. Covers TypeScript strictness, import conventions, export patterns, private field syntax, error handling, feature gating, and test structure. Load this skill when reviewing or writing JavaScript or TypeScript code in src/node/, src/cloudflare/, or JS/TS test files under src/workerd/.
Step-by-step guide for updating the V8 JavaScript engine in workerd, including patch rebasing, dependency updates, integrity hashes, and verification. Load this skill when performing or assisting with a V8 version bump.
Detailed guide for authoring .wd-test files in workerd, with examples of bindings, Durable Objects, multi-service configs, TypeScript tests, and network access.
Performance optimization, API design & compatibility, security vulnerabilities, and standards spec compliance for workerd code review. Covers tcmalloc-aware perf analysis, compat flags, autogates, web standards adherence, and security patterns. Load this skill when reviewing API changes, performance-sensitive code, security-relevant code, or standards implementations.
Memory safety, thread safety, concurrency, and critical detection patterns for workerd code review. Covers V8/KJ boundary hazards, lifetime management, cross-thread safety, and coroutine pitfalls. Load this skill when reviewing any C++ code.
TypeScript implementations of Cloudflare product APIs (AI, D1, R2, Vectorize, etc.). It is common, but not required, for top-level .ts files to re-export from internal/ via cloudflare-internal: specifiers. This allows for a clean separation between public API surface and internal implementation details. Each product test directory contains: Mock wiring uses wrapped bindings: moduleName = "cloudflare-internal:<product>-api" with innerBindings pointing fetcher at the mock service. Shared instrumentation-test-helper.js lives in internal/test/.
TypeScript and JavaScript layer implementing Node.js compatible built-in modules for Workers. It is split across multiple layers: It is common, but not required, for top-level .ts files to re-export from internal/ via node-internal: specifiers. This allows for a clean separation between public API surface and internal implementation details. See README.md for 12 policy rules governing compat scope and philosophy. node:* modules are gated behind the nodejs_compat compatibility flag. The node:asynchooks module can be enabled individually via the nodejsals compatibility flag.
Per-isolate JavaScript/TypeScript bootstrap: scripts that run synchronously at context creation, before any user code. Gated by the per-isolate-javascript-bootstrap autogate (config: workerd-autogate-per-isolate-javascript-bootstrap). C++ entry point: src/workerd/io/per-isolate-bootstrap.c++. - Scripts are compiled as functions with a context-extension object — the pseudo-globals require, module, exports, compatFlags, autogates, primordials, utils are in scope but NOT on globalThis (see perisolate-env.d.ts). - Module system is bootstrap CommonJS: require('webstreams/queue') + module.exports = {...}. The src/node/ ESM-only rule does NOT apply here. Circular requires are a FATAL startup error…
TypeScript reimplementations of crypto APIs that must be replaced when the typescriptimplementedstreams compat flag is on. Parent directory conventions (primordials discipline, private-brand dispatch, no instanceof) apply — see src/per_isolate/AGENTS.md. DigestStream is one of only two WritableStream subclasses in the runtime. When the streams flag swaps globalThis.WritableStream for the TypeScript class, a C++ subclass of the C++ WritableStream no longer passes the brand checks used by pipeTo, and instanceof WritableStream becomes false. Reimplementing the subclass in TypeScript is what restores the…
TypeScript reimplementation of the File System Access API's writable stream, needed when the typescriptimplementedstreams compat flag is on. Parent directory conventions (primordials discipline, private-brand dispatch, no instanceof) apply — see src/per_isolate/AGENTS.md. FileSystemWritableFileStream is one of only two WritableStream subclasses in the runtime. When the streams flag swaps globalThis.WritableStream for the TypeScript class, a C++ subclass of the C++ WritableStream no longer passes the brand checks used by pipeTo, and instanceof WritableStream becomes false. Reimplementing the subclass in TypeScript is what…
TypeScript Streams implementation with a backend-blind reader layer and two consumer backends behind the StreamConsumer/ByteStreamConsumer fence. Authoritative docs are IN-SOURCE — read the file headers first. Parent directory conventions (primordials discipline, JSG capture trap, private-brand dispatch, no instanceof) apply here — see src/per_isolate/AGENTS.md. The spec's tee() gives each branch its own controller and queue, fed by a reader on the original. The queued backend instead has ONE queue with N consumers (cursors), one per live branch: tee() forks the stream's…
Python Workers runtime layer. Replaces Pyodide's loader with a minimal substitute adding memory snapshot support. TS+Python; modules registered as pyodide-internal:* BUILTIN modules. pool/emscriptenSetup.ts runs in vanilla V8 isolate -- CANNOT import C++ extension modules. Python SDK (internal/workers-api/) now lives in cloudflare/workers-py and is installed from PyPI. Keep existing code for backward compatibility; new features go to workers-py. Tests live in src/workerd/server/tests/python/. pywdtest.bzl macro: expands %PYTHONFEATUREFLAGS template, handles multiple Pyodide versions, snapshot generation/loading, per-version compat flag isolation. Tests are size="enormous" by…
Plain text files in a repository that tell a coding agent how the project works: commands to run, conventions to follow and things to avoid. CLAUDE.md, AGENTS.md, cursor rules and skills are the common kinds.
CLAUDE.md or AGENTS.md?
CLAUDE.md is read by Claude Code. AGENTS.md is an open format that Codex, Cursor and other agents read. Many projects keep one and point the other at it.
What is a skill?
A folder with a SKILL.md that describes one capability, such as filling PDFs or reviewing code. The agent loads it only when the task calls for it.
Can I search my own team's files too?
Your agents already can, over MCP, limited to the files you're allowed to read. Searching them from this page is coming.