Getting AI to do work isn’t hard anymore. You prompt it, it codes, it ships. That part is more or less solved.

The part that isn’t solved: keeping track of everything that’s happening.

Every morning I’d open my laptop and spend 15–20 minutes just getting oriented. What PRs need my review? What did someone comment on my open PR overnight? What Jira tickets are blocked waiting on me? These aren’t hard questions, but answering them meant opening four tabs, scanning through noise, and mentally assembling a picture that should just… exist.

So I built MorningDash.

What It Does

MorningDash is a terminal dashboard that gives you one view of your developer morning:

  • Pull requests waiting for your review
  • Your own open PRs and their current status
  • Unread GitHub notifications
  • Assigned and in-progress tickets from your issue tracker (Jira, Linear, or GitHub Projects)

You run md in your terminal, or open the panel in VS Code/Cursor, and it assembles all of that in a few seconds.

Two Ways to Use It

Pick wherever you spend your mornings.

Terminal (md) — run it once, get the picture, move on. Good if you already live in the terminal and want a clean read-only briefing before you start.

VS Code / Cursor panel — same data, but it lives in your editor as a persistent tab. It auto-refreshes on an interval, lets you approve PRs or mark notifications as read without leaving the editor, and picks up your config from the workspace root, your home directory, or VS Code settings — whichever it finds first.

I lean toward the VS Code panel for day-to-day use. The terminal version is great for a quick check; the panel is better when you want it always visible while you work.

The Stack

The project is a monorepo with three packages:

@morningdash/core handles all the data — GitHub API calls, issue tracker adapters, config loading. Framework-agnostic TypeScript, shared by both surfaces.

@morningdash/cli is the terminal UI. Built with Ink, which lets you write React components that render to the terminal. Surprisingly good fit for a read-only display problem.

@morningdash/vscode is the editor extension. The extension host manages the panel lifecycle and talks to GitHub directly; the webview is a React app bundled as an IIFE that renders the dashboard and sends messages back (approve PR, mark read, refresh). Two separate build targets — CommonJS for the extension host, browser bundle for the webview.

The issue tracker integrations use an adapter pattern across all three, so adding a new tracker means implementing one interface without touching anything else.

Config is resolved in priority order: workspace .morningdash.json → ~/.morningdash.json → VS Code settings.

Honest Status

The version on GitHub is a vibe-coded port of a tool I actually use at my job. The original was built specifically for that team’s setup (GitHub + Jira, specific workflows). This one is generalized and more complete on paper, but I haven’t run it in anger yet.

The real one I use every day. It works well enough that I notice when it’s broken.

That gap between “works for me” and “works for you” is the whole engineering problem.

What I’d Do Differently

The thing I underestimated: configuration surface area. Each issue tracker has a different auth model, different concepts for what “assigned to me” means, different pagination behavior. The adapter pattern handles it cleanly in theory. In practice you spend most of your time on the connective tissue between what trackers return and what you want to display.

If I were starting over, I’d pick one tracker and get the full experience right before building the abstraction.

Try It

The repo is at github.com/ricardo-leiva/morningdash. It needs Node 18+ and pnpm.

If you’ve built something similar, or have opinions on the Ink approach or VS Code webview architecture, I’d like to hear it.