Menu
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).
Basé sur la classification professionnelle SOC
Load when working with the module registry in workerd — reading, modifying, debugging, or reviewing module resolution, compilation, evaluation, or registration code. Provides pointers to three reference documents covering the legacy registry, V8 module internals, and the new registry design.
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.
Mandatory rules for running bazel tests during development. Load this skill before running any bazel test command, especially when validating fixes or verifying regression tests. Prevents false confidence from cached results, filter flags that silently match nothing, and partial test runs that miss breakage.
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
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.
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.
| name | parent-project-skills |
| description | 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). |
This project (workerd) may be embedded as a submodule within a larger project. When your task requires context beyond workerd itself — such as investigating production issues, writing integration tests, or understanding deployment architecture — you should check for additional skills and context in the parent project.
Determine if a parent project exists by checking for a git root above the workerd directory:
../../.git or ../../AGENTS.md relative to the workerd root../../ (two levels up from workerd)Check for parent project skills:
../../.opencode/skills/*/SKILL.md../../AGENTS.md or ../../AGENTS.md for project-wide contextLoad relevant skills by reading the SKILL.md files. These are not registered in the skill tool — read them directly with the Read tool.
Check for submodule-specific context:
../../.opencode/skills/*/SKILL.md files that may reference workerd specificallyworkerd is an open-source project. The parent project is typically proprietary/internal.
You MUST enforce a strict one-way information boundary:
When working across the boundary, frame all workerd-side artifacts in terms of workerd's own public concepts (Workers, Durable Objects, isolates, IoContext, etc.) without referencing how the parent project orchestrates them.