When Should Claude Code Crack a Joke?

The tests finish. The screen shows 214 passed and none failed. Claude summarizes the result in a few sentences. Then a separate line appears:

“Noice. Smort.”

The first part is about the work. The final line contributes nothing to the code. It does not find a bug, speed up the tests, or suggest a better architecture. It only changes the tone of the conversation.

Claude did not improvise that joke. It came from sitcom-flavour, a Claude Code plugin built by my friend Emre Erkan.

I should be clear at the outset: I do not use the plugin, and it does not fill a gap in my own workflow. I still think it is worth sharing because of the care with which Emre turned a small idea into a finished product.

What does a Claude Code plugin do?

Claude Code plugins add new layers to how the coding assistant works. A plugin can introduce commands, run scripts when particular events occur, or give the model additional context at the start of every session.

Teams can use that mechanism to load project rules, explain internal terminology, reinforce code-review criteria, or make a workflow reusable. Beyond that, the developer decides what a plugin is for.

Emre has used the same mechanism for something lighter.

sitcom-flavour adds short quote banks from shows selected by the user to Claude's context when a session starts. The lines are grouped by situations such as tests passing, a fix failing, a cost estimate missing the mark, or legacy code proving stranger than expected.

There is no separate matching engine inside the plugin to detect those situations. The code gives Claude the lines and the rules for using them. The model decides whether any line suits the moment.

The plugin does not give Claude a new reasoning capability. It defines the material Claude can draw from and the boundaries within which it should use it.

I have been using Codex for most of my coding lately, which may explain why I did not immediately try the plugin myself. Codex also supports the SessionStart hooks bundled with plugins, so a Codex version could be prepared with a small adaptation. I do not know whether Emre will build one, but perhaps a reader will port it and open a pull request.

Adding a joke is easier than knowing when to stay quiet

Putting a sitcom line into a coding assistant is the easy part. The harder question is where that line should never appear.

The plugin therefore sets some boundaries. The useful answer should come first. A quote should be limited to one line. It should not appear in code, commit messages, pull request descriptions, or documentation. It should stay silent during a production outage, data loss, or a moment when the user is clearly struggling.

These are not hard safety rules enforced by code. They are behavioural instructions given to Claude, and the model may sometimes interpret them incorrectly. The project does not make a larger technical claim about how it works.

Defining the boundaries still matters. When you add personality to a tool, the central design decision is not which joke it should use but when that personality should recede. Without that restraint, a small element of fun can quickly become workplace noise.

Small projects create value in other ways

sitcom-flavour does not turn Claude Code into a better programmer. Nor does it claim to shorten a team's delivery time or improve software quality.

Its value lies elsewhere.

The choice of shows, the way quotes are grouped by situation, the adjustable frequency, and the effort to hold back in serious moments all reveal the developer's product taste. The technical structure may be small, but the idea has not been left half-finished. It has settings, personal quote banks, tests, documentation, and its own website.

The README could explain the steps for adding your own show in a little more detail.

Not every side project has to solve a major problem. Some exist to try a new technology, turn a personal preference into a product, or pursue the question: “Can I build this?”

I recognise that impulse. I once added my daily step count to this website. It did not solve an important problem for visitors. Its value to me was more personal: keeping the number visible gave me a small reason to keep walking. There was also satisfaction in having brought it onto the site—in being able to say, “I made this.”

That is partly why I understand where Emre's project comes from. A tool does not become meaningless simply because everyone does not need it. Personal utility, curiosity, and the wish to put something working into the world can be reason enough to build.

That is how I see sitcom-flavour: not as a productivity tool I would recommend to everyone, but as a small, complete, personal experiment by a developer who wanted to make his tool feel a little more like his own.

You can inspect the code in the project's GitHub repository.