Team Challenge: Build Something You'll Actually Use, With Mellea

[psschwei]

Summary

Each team member builds an application or piece of software for their own personal use, using Mellea. What you build is up to you — the only rule is that it has to be something you would genuinely use (or want to use). No toy demos built for the sake of the exercise.

The goal is not the artifact. The goal is what we learn from the act of building.

Why

We build Mellea, but we don't always live in it. When everyone on the team goes through the end-to-end experience of picking a real problem, reaching for Mellea to solve it, and shipping something they personally care about, three things fall out:

1. (a) Gaps in Mellea — the moments where you reach for a capability and it isn't there, or isn't there in the shape you need.
2. (b) Gaps in our docs — places where an agent (or you) couldn't figure out how to do something with Mellea that Mellea can actually do. Every one of these is a documentation bug.
3. (c) Hallucinations as design signal — when an agent invents a Mellea API that doesn't exist, that's not just a failure, it's a vote. The agent is telling us what the "obvious" shape of the library would be. Some of those hallucinations are bad ideas; some are features we should seriously consider building.

What counts

Anything you'd actually use. Some seeds to get the imagination going (not a menu — build your own thing):

• A personal inbox triager
• A thing that summarizes your calendar and suggests what to focus on
• A writing assistant tuned to your style
• A tool that watches a repo and flags PRs you should care about
• A CLI that does one specific annoying thing you do by hand today
• Something weirder — a journaling companion, a shopping list disambiguator, a recipe adapter, a Slack digest, whatever

If you're debating whether it counts: will you still open it next week, on your own, unprompted? If yes, it counts.

Deliverables

Three things, in order of importance:

1. A written reflection (required)

A short writeup covering:

• What you built and why you wanted it. One or two paragraphs.
• (a) What Mellea was missing. Concrete capabilities you reached for that didn't exist, or existed but were awkward.
• (b) Where agents got stuck. Moments where you (or your coding agent) couldn't figure out how to do something in Mellea. For each, note whether it was actually possible — if yes, that's a docs issue.
• (c) Notable hallucinations. APIs, functions, or patterns the agent invented that should exist. Include the hallucinated snippet if you have it. Treat these as design suggestions, not failures.
• Anything else surprising.

Length is up to you. Bullet points are fine. Don't polish it — we want the raw notes.

2. Filed issues against Mellea (required)

Every (a) and (b) finding that survives a sanity check becomes a GitHub issue on the Mellea repo. Link them from your writeup. Label feat for (a), docs for (b). For (c), file issues for the hallucinations you think are genuinely good ideas — tag them as design proposals.

This is the mechanism by which this exercise actually improves Mellea. If the findings stay in your head, the exercise failed.

3. A live demo (required)

Show the team what you built at a team meeting. Five to ten minutes. Demo the tool, then walk through your top two or three findings from the writeup. Seeing each other's builds is half the value.

Timeline

• Kickoff: team meeting where we discuss the challenge and people share what they're thinking of building (lightweight — no commitment needed).
• Build window: two to three weeks, worked around your normal responsibilities. This is meant to be a side quest, not a sprint.
• Demo day: a single team meeting where everyone presents.

Exact dates TBD.

Ground rules

• Use Mellea. The point is to exercise the library. If you find yourself going around it, that itself is a finding — note it.
• Use agents. Part of the point is seeing how well Claude Code, Cursor, Copilot, etc. can build with Mellea. Agent friction is signal.
• Don't sandbag the problem. Pick something you actually want. Motivation changes what you notice.
• Don't worry about code quality. Nobody is reviewing your repo for style. Ship something that works for you.
• Share early and often. Drop screenshots, frustrations, and hallucinated-API screenshots in the team channel as you go. Half the fun is the running commentary.

Non-goals

• This is not a competition.
• This is not a way to sneak production features into the roadmap. If something you build turns out to be genuinely useful to the team or to users, great — but that's a bonus, not the target.
• This is not a deliverable of polished, shippable software. A working prototype that you use is strictly better than a polished app you don't.

Success criteria

We will consider this exercise a success if, at the end:

1. Every team member has used Mellea to build something they use.
2. We have a pile of concrete, well-sourced issues filed against the repo.
3. We have at least a few hallucination-driven design ideas worth seriously debating.
4. The team has a shared, lived understanding of what it's like to be a Mellea user in 2026.

[psschwei]

I am planning to convert my dev-rel-skills into a mellea program

[ajbozarth]

I already had a project like this on my plate. I plan to convert my goals agent into a mellea program. My work on generative-computing/mellea-contribs#54 was actually my first step, as the gap that made me not use mellea originally was the lack of mcp support.