uberblickGitHub

Uberblick / Use cases

Product intent that agents read before they build.

A coding agent that starts from the issue alone will implement the issue. One that starts from the pages that say what the product should do will implement the product. This is how Uberblick is built, with its own workspace and the ub-agents loop.

The problem

An issue is a request, not a specification. The reasoning behind it lives in a design review, a decision from last month, a page that explains how the feature should behave in the edge cases. If that reasoning sits in a chat thread or a stale Markdown file, the agent never sees it, and the reviewer has to catch every gap by hand.

How it works

  1. Write the intended behaviour first, as a document. Not the implementation: who it is for, the jobs, the rules, the scenarios with the exact expected result. Pin the pages that matter in the sidebar, so an agent that has never seen the workspace starts from get_sidebar and knows where to look.
  2. File the issue with pointers. The issue cites the pages it depends on by title and id. Nothing in the issue restates them, so there is one place to be wrong.
  3. The agent reads before it writes. The preparer and the implementer search the workspace for the pages the change touches, read them, and check the decision records that link the issue. The reviewer checks the result against the same pages, not against the issue text.
  4. The pull request updates the pages. Every PR carries a short "Corpus update" section: which document, which block, what it now says. The workspace describes the product as shipped, never code that has not merged.

What it looks like in our workspace

On 10 October we reviewed the web UI's design. The findings became ten "Web UI:" pages (typography, page layout, blocks, colour and so on) and two decision records, written into the workspace before any issue existed. Then fourteen issues were filed, each pointing at its page. The loop picks them up in priority order; each implementer reads its page over MCP, builds against it, and the PR's corpus update keeps the page true.

Decision · decided 10 October 2026Uberblick product workspace

Where does the web UI use monospace?

Only for text a person would paste somewhere: code, terminal output and ids in Settings. Everything else is set in the UI face.

Mono reads as machine output. Used for labels and timestamps it made the chrome look like a debug overlay and competed with real code blocks.

Linksuberblick-2#1551Web UI: typography

When the implementer of #1551 asks find_decisions for that issue, this record comes back. It does not have to rediscover the rule, and it cannot quietly undo it.

What you need

  • Uberblick, with a workspace bound to the project directory, so ub mcp serve picks the right corpus.
  • An MCP client for your agent: ub mcp install claude or ub mcp install codex.
  • A rule in your agent instructions, in AGENTS.md or the equivalent: start from the pinned documents, cite pages by id, and update them in the PR. Ours is in the repo.
  • Optional: ub-agents, if you want the loop to run from GitHub labels rather than by hand.

Where it stops

Uberblick does not run the agents and does not review code. It holds the pages and the decisions, and answers the agent's questions over MCP. The quality of what the agent builds is bounded by what the pages say; a page that is vague produces a vague implementation, only faster.