commit-categories
Commit Categories
Categorize commits by the files they touch, using the primary area for commits spanning multiple categories.
| Category | Path patterns |
|---|---|
| API | src/workerd/api/ (excluding node/ and pyodide/) |
| Node.js compat | src/workerd/api/node/, src/node/ |
| Python | src/workerd/api/pyodide/, src/pyodide/ |
| Rust | src/rust/ |
| Cloudflare APIs | src/cloudflare/ |
| I/O | src/workerd/io/ |
| JSG | src/workerd/jsg/ |
| Server | src/workerd/server/ |
| Build | build/, MODULE.bazel, BUILD.bazel |
| Types | types/ |
| Docs / Config | Documentation, agent/tool configs, .md files |
| Tests | Changes exclusively in test files |
| Other | Anything that doesn't fit above |
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