Note Taking App for Developers: Markdown, MCP and Notes Checked Against Your Code

Farah, backend engineer, on call one week in five. During an October incident the runbook said make replay-dlq. The target had been renamed three months earlier.

Setup. Each runbook is a note from the runbook template with two extra fields at the top:

# Runbook: replay dead-letter queue
Last verified: 2026-10-21 by Farah
Breaks if: Makefile targets or the consumer CLI change

## Steps
1. `make dlq-replay TOPIC=orders` (expect "replayed N messages")

The team's repository is connected through the GitHub connector, and this note opts in to verification from its Settings. Background verification compares the commands in the note against the code and proposes a diff when they disagree, which she accepts or dismisses. The rename would have shown up as a suggested fix weeks before the incident.

Ines, staff engineer on a payments team. Third discussion this year about moving webhooks off the main API. Every time, the reasons from the last discussion were in a Slack thread nobody could find.

Setup. One running note from the decision log template, one entry per decision, always with a "because" and a review date:

## 2026-10-14: Keep webhooks in the API process
Because: p99 is 40 ms, separate service adds a deploy and a queue
Disagreed: Omar (wants isolation for retries)
Revisit: 2027-01-15 or if p99 > 200 ms

Before any refactor, she asks Claude Code to search her Scribelet notes for "webhooks" and list each decision with its date. The agent reads the log over MCP and flags where the code no longer matches. The fourth argument took ten minutes.

Dev, contract full-stack developer. Three clients: a Rails shop, a Next.js startup and a Django agency project. Each has deploy steps, credentials locations and quirks he forgets between visits.

Setup. One desk per client. Each desk holds a Client handbook note (stack, deploy, who approves what), a running debug log and the decisions he made for them. When Claude Code connects to the Scribelet MCP server, the OAuth consent screen asks which desks the agent may use, and he grants only the client he is working for that week. Switching clients means switching the connection, not hoping the agent ignores the wrong notes. At the end of a contract he exports the notes to Markdown and hands the client's handbook over with the code.

Sana, eight months into her first job. CORS errors, a flaky test that depends on timezone, Docker running out of disk. Each fix took an afternoon. Each came back.

Setup. A note per problem, titled by the symptom, not the cause, because the symptom is what she will search for:

# Jest test fails only after 7 p.m.
Cause: test builds "today" with toISOString(), which is UTC
Fix: use a local-date helper
Seen in: [[Billing service]], [[Reports service]]
#til #testing

Wikilinks to each service mean the service note's backlinks panel lists every gotcha it has. Three months later she asked the AI chat "why do date tests fail in the evening" and got her own note back, with a link to it.

Paul, lead of a six-person platform team. Docs were split across a wiki, READMEs and personal notes, and nobody trusted any of them.

Recommendation. Anything the code depends on, or that must be reviewed with a change, goes in the repo: READMEs, ADRs, API docs, the deploy guide. That is docs as code, and a notes app should not replace it. Notes are for what comes before and around the code: investigations, meeting decisions not yet written up as ADRs, personal runbooks under construction, on-call logs. When a note becomes stable and shared, it graduates into the repo as a pull request. With Scribelet Team, the platform team shares one desk for the pre-repo material; each engineer keeps a personal desk for the rest.