Inspiration

Bugs, decisions and open questions come up in conversation: stand-ups, pair debugging, thinking aloud while coding. Most of them never reach the issue tracker. Bee already records these conversations and even lists action items, but a developer needs more than a to-do line: a typed, well-formed issue in the right repository, with evidence, that does not duplicate one that already exists.

What it does

bee-issue-drafter reads a conversation recorded by Bee and drafts GitHub issues from the technical parts only:

classifies each item as bug, feature, task or question, with summary, details and acceptance criteria;
quotes the exact transcript lines it relied on as evidence;
ignores personal and off-topic speech, remarks about the recording itself, and work that is already done;
checks existing open and closed issues and skips likely duplicates;
creates nothing until I confirm each issue;
in watch mode, drafts issues automatically for each new finished Bee conversation.

How I built it

Bee CLI (@beeai/cli) in --json mode to list conversations and fetch transcripts, called at runtime from Python.
Python command-line tool (python -m bee_issues) with check, list, transcript, draft, watch, publish and eval commands.
LLM behind a small provider interface (DeepSeek in the demo; Claude API and Claude on Amazon Bedrock also supported). The model sees transcript lines labelled U1, U2, ... and must answer in JSON, citing those labels. Quotes in the issue body are copied from the real Bee transcript and unknown labels are dropped, so the model cannot invent evidence.
GitHub REST API with a fine-grained token limited to Issues on one repository.
Evaluation: an eval command scores drafts against hand-written expected issues (precision, recall, type accuracy). Synthetic cases cover speech-recognition errors, pure chit-chat, repeated mentions and finished work.
38 unit tests with no network calls; CI on Windows and Ubuntu.

Challenges I ran into

Unpredictable recording boundaries. One sentence landed outside its conversation, and a 30-second recording showed up as CAPTURING and then disappeared. Longer recordings worked. This also exposed a bug in my own watch mode (started mid-recording, it skipped that recording), which I fixed with a test.
Duplicate detection on reworded titles. While recording the demo, the same recording drafted twice produced "Dark mode toggle resets after refreshing settings page" and "Fix dark mode toggle resetting on settings page refresh", and the check let the second one through. I replaced pure character similarity with a blend of keyword overlap and containment (ignoring leading verbs like fix/add/decide), then verified it on 15 re-drafted titles (all caught) and on every pair among 60 titles (no different items merged).
Privacy. Bee records everything, including other people and my private life. The repository contains only synthetic data, real transcripts stay in git-ignored folders, and the tool only processes conversations I pick.
Undocumented JSON shape. I read the bee-cli source to parse transcripts.

Accomplishments that I'm proud of

End-to-end on a real Bee device: on three scripted recordings, every technical item in the transcripts was found (10 of 10) with no extra issues; chit-chat, remarks about the recording and finished work were ignored.
The first real run produced one false positive ("quick test for the demo" became a task). The eval command caught it, a one-line prompt rule fixed it, and the synthetic set confirmed nothing else got worse.
Contributed back to Bee: bee-computer/bee-cli#27 adds bee now --hours N and a clearer empty state, with tests — a friction point I hit while building this.

What I learned

Bee's own summaries already list action items, so the value is in what comes after: structure, evidence, and fitting into the developer's existing tracker without duplicates.
With speech input, measuring beats guessing: small hand-written expected lists were enough to find and fix real problems.
For an always-on wearable, user control over what is captured and shared matters as much as the AI features.

What's next

Use bee stream instead of polling so drafts appear as soon as a conversation ends.
Route issues to the right repository when one person works on several projects.
Assign issues based on who spoke (speaker identification).

Demo: https://youtu.be/SyOC9ALOYgs · Code (MIT): https://github.com/KunnnnnQ/bee-issue-drafter