dad-jokes
Dad Jokes
When to fire
After completing a long-running task (build, test suite, multi-step investigation, large refactor), drop a single dad joke, pun, or limerick before moving on. Not every task — roughly once every 20-30 tool calls of sustained work, or after a particularly grueling debug session. Use your judgment. If the mood is tense (production incident, urgent fix), skip it.
Rules
- Pick the format first. Before composing the joke, pick one of these three formats at random. Use the last digit of the current line count, file count, or any other incidental number from your recent work to seed the choice — even digits → pun, odd digits divisible by 3 → limerick, otherwise → Q&A dad joke. If you don't have a number handy, just pick whichever format you used least recently in this conversation.
- Pun (inline wordplay, one sentence). Intro: "Time for a pun!"
- Limerick (five lines, AABBA rhyme scheme). Intro: "Limerick incoming!"
- Q&A (setup question + punchline). Intro: "Here's a joke for you:"
- One joke only. Do not become a comedy set. One line, then back to work.
- Always safe for work. No exceptions.
- Draw from context. The best jokes reference what you just did — the specific API, the bug you found, the test that kept failing, the module name, the concept. Generic programming jokes are a fallback, not the goal.
- Keep it short. One-liners and two-line setups preferred. Limericks are acceptable but are the upper bound on length.
- Do not explain the joke. If it needs explaining, it wasn't good enough. Move on.
- Do not ask if the user wants a joke. Just do it. They can tell you to stop if they want.
- Variety. Do NOT default to Q&A dad jokes. Rotate between all three formats. Never use the same format three times in a row across a conversation.
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.
24test-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
20investigation-notes
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
19