dad-jokes
$
npx mdskill add cloudflare/workerd/dad-jokesDelivers dad jokes, puns, or limericks after long tasks or upon user request to lighten the mood.
- Helps reduce tension and add humor during extended work sessions or after stressful debugging.
- Integrates with no external tools or APIs, relying solely on internal logic for joke generation.
- Decides joke format based on random seeding from incidental numbers or least-used format in conversation.
- Presents jokes with a brief intro in one of three formats, then returns to work immediately.
SKILL.md
.github/skills/dad-jokesView on GitHub ↗
--- name: dad-jokes description: 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. --- # 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. - **Avoid "Why did the X break up with Y?"** Those are overdone and often not very good. If you want to do a breakup joke, make it more specific and less formulaic. ## Inspiration sources - KJ/Cap'n Proto concepts: promises, fulfillment, pipelines, capabilities, orphans - workerd concepts: isolates, bindings, compatibility flags, Durable Objects, alarms, hibernation, jsg, apis, streams - Build system: bazel, compilation, linking, caching, sandboxing - Debugging: assertions, stack traces, serialization, autogates, dead code paths - General runtime: workers, events, streams, tails, traces, pipelines, sharding - Parent project context
More from cloudflare/workerd
- add-autogateStep-by-step guide for adding a new autogate to workerd for gradual rollout of risky changes, including enum registration, string mapping, usage pattern, and testing.
- add-compat-flagStep-by-step guide for adding a new compatibility flag to workerd, including capnp schema, C++ usage, testing, and documentation requirements.
- bazel-test-hygieneMandatory 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.
- commit-categoriesCommit categorization rules for changelogs and "what's new" summaries. MUST be loaded before categorizing commits in changelog or whats-new commands. Provides the canonical path-based category table used to group commits by area.
- find-and-run-testsHow to find, build, and run tests in workerd. Covers wd-test, kj_test target naming, bazel query patterns, and common flags. Also covers parent project integration tests if workerd is used as a submodule. Load this skill when you need to locate or run a test and aren't sure of the exact target name or invocation.
- identify-reviewerIdentifies the local user's GitHub account and git identity before performing code reviews. Load this skill at the start of any PR review, code review, or commit log analysis so findings can be framed relative to the user's own prior comments, commits, and approval status.
- investigation-notesStructured 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-styleKJ/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.
- markdown-draftsUse 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.
- module-registryLoad 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.