DEV Community

Cover image for Dev Process Tracker: Local Service Management with a CLI + TUI
John Munn
John Munn

Posted on

Dev Process Tracker: Local Service Management with a CLI + TUI

#devchallenge #githubchallenge #cli #githubcopilot

GitHub Copilot CLI Challenge Submission

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built Dev Process Tracker (devpt), a local development service manager with both CLI and TUI workflows.

It is built for a common reality: multiple local services, mixed startup methods, and failures that are hard to diagnose quickly.

With devpt, I can:

  • register known services (add)
  • run lifecycle actions (start, stop, restart)
  • inspect runtime state (ls, status)
  • check logs (logs)
  • switch to an interactive workflow (devpt)

Managed vs discovered (why both matter)

This is a core design choice.

  • Managed: services you explicitly define in devpt (name, cwd, command, expected ports)
  • Discovered: anything currently listening on local TCP ports, even if started outside devpt

Example:

  • You register frontend in devpt with npm run dev on port 3100.
  • An older npm run dev process from another terminal is still running on 3100.

devpt ls --details shows both, so you can spot the duplicate and stop the stale process quickly.

Why not just PM2, Docker Compose, or make targets?

Those tools are useful, but they solve different parts of the problem.

  • PM2: great for managed Node processes, but not a broad local process/discovery lens across mixed stacks.
  • Docker Compose: excellent for containerized services, but many teams run hybrid local stacks (host + containers).
  • make targets: good shortcuts, but not a runtime inventory or diagnostics surface.

devpt focuses on cross-stack local runtime visibility + lifecycle control + crash diagnostics in one interface.

Demo

A Day in the Life

Start the day: what’s already running?

./devpt ls --details
Enter fullscreen mode Exit fullscreen mode

./devpt ls --details

This gives you a single inventory view of everything currently listening on your machine, both services you’ve explicitly registered with devpt and processes that were started elsewhere and forgotten about.

Bring up your local stack

./devpt add frontend ./sandbox/servers/node-basic "npm run dev" 3100
./devpt add api ./sandbox/servers/python-basic "python3 server.py" 3300
./devpt start frontend
./devpt start api
Enter fullscreen mode Exit fullscreen mode

Bring up your local stack

Here, devpt is managing the same kinds of commands developers actually run every day, not simplified or synthetic examples.

Investigate a problem and recover

./devpt status frontend
./devpt logs frontend --lines 60
./devpt restart frontend
./devpt stop api
Enter fullscreen mode Exit fullscreen mode

Investigate

When something goes wrong, control and diagnosis stay in one place. You can see crash state, inspect recent logs, and take action without switching tools or terminals.

Switch to interactive mode

./devpt
Enter fullscreen mode Exit fullscreen mode

TUI

The same workflow is available in a TUI, making it practical to leave running during the day and interact with it as your local environment changes.

My Experience with GitHub Copilot CLI

I used Copilot CLI as a high-speed drafting and reasoning partner, then manually constrained behavior to fit project requirements.

Example 1: command validation

Prompt:

gh copilot suggest "add command validation for managed service commands and include tests for blocked patterns"
Enter fullscreen mode Exit fullscreen mode

Impact on final product:

  • accelerated initial validation/test scaffold
  • final logic was tightened manually to project-safe patterns and clearer CLI errors

Example 2: crash diagnostics design

Prompt:

gh copilot suggest "show crash reason and recent log tail in status command for crashed services"
Enter fullscreen mode Exit fullscreen mode

Impact on final product:

  • helped shape the CRASH DETAILS section design
  • final output and heuristics were edited to reduce noise and improve signal

Example 3: what did not work

One early suggestion pushed a broader TUI refactor than needed. I rejected that direction because the risk of interaction regressions was too high for challenge scope.

What I kept instead:

  • focused UI behavior improvements
  • no disruptive state model rewrite

That tradeoff kept the tool stable while still improving usability.

Net effect on my workflow

  • faster implementation drafts
  • better early edge-case discovery
  • tighter feedback loops during test writing
  • final behavior remained intentionally human-reviewed

Detailed prompt-level evidence is documented in:

Who This Is For

devpt is for developers running mixed local stacks (Node, Python, Go, containers) who need reliable runtime visibility and fast failure diagnosis.

Core question it answers: what is actually running, and what should I do next?

Top comments (0)