TLDR - A friend showed me a small macOS-only menu bar app that lists local dev ports. I'm one of the dozens of people who uses Linux (Fedora KDE in particular) as my primary operating system. I used OpenCode to fork and create a working KDE Plasma widget called Portmanteau.

I keep encountering the same problem: I see a cool, new AI or developer tool that I want to try, except they all seem to be macOS only. A few years ago that usually meant time to move on. Now I tend to think, "I can probably fork that."

This time the tool was Port Menu, a simple little macOS menu bar app for seeing local development servers. If you run a bunch of Vite, Rails, Django, Flask, Next.js, or whatever servers during the day, the basic idea is obvious: show me the ports, tell me which project owns them, and let me open or kill them without spelunking through terminal tabs.

But again, macOS-only, so I did what any enterprising vibe coder would do. I started an OpenCode session with a pretty low-stakes question:

This looks macOS only. how feasible would a port to linux be?

Asking More Questions

The first answer was optimistic in the way AI and agents often are. The port scanning idea is very portable. Linux has ss, lsof, /proc/<pid>/cwd, git, kill, and all the raw ingredients you need.

But the app itself was not going to be a normal port. The original is a SwiftUI/AppKit menu bar app. A KDE version wants to be a Plasma widget. That means QML, Plasma packaging, a panel representation, a popup, and a different set of desktop integration edges.

After some poking and additional questioning, the answer got less shiny and more useful. This was not really a port. It was a KDE reimplementation of the same idea:

• The algorithm is portable.
• The Swift UI is not worth trying to reuse.
• A KDE Plasma widget is a good target for my actual desktop.
• The scanner should be a small helper that emits JSON.
• The widget should stay mostly UI-focused.

That became the shape of the project: a Linux scanner plus a Plasma 6 widget.

Planning Using Tickets (tk)

The next thing I asked for was a plan. And then captured it using ticket tk. I really dig ticket and recommend it if you're working with agents.

Can you plan out the steps/tickets that we need to create this? Let's use tk (ticket) to create epics/tasks/etc.

My agent proposed five epics:

• Linux Scanner Core
• KDE Plasma Widget MVP
• User Actions and Safety
• Packaging and Local Install
• Polish, Reliability, and Release Readiness

The agent created 38 tickets as part of those epics, added dependencies, and tk ready gave us an implementation order. This is when a project crosses from "exploratory chat" to "work queue".

I then made the irresponsible request:

Can you work on implementing this? Ideally don't stop until all tickets are completed :)

And it mostly did.

What The Agent Built

The agent built the Linux version as a separate linux/ tree so the original macOS app stayed untouched. That feels like the right shape: keep the idea, do not pretend the SwiftUI app was coming with us.

The important pieces were a Python scanner, a JSON contract, and a Plasma widget. The scanner figures out what is listening locally and the widget turns that into a panel popup I can actually use.

It also added the first set of actions: open, copy URL, copy port, and kill. Some of those survived. Copy port did not.

The agent closed all its own tickets too. I do not think of "all tickets closed" as a quality signal, so I did a review pass. That caught real problems: packaging was too fragile, scanner timeouts could break the JSON contract, and Plasma had a few runtime quirks that only show up when you actually run the thing.

This is part of the loop. Ask a question. Plan. Implement. Review. Test.

User Testing

After some agent work, it was my time to test and complain about rough edges.

I had the agent install and activate the plugin. I realized I didn't have any local dev ports that were currently in use. But again, not a problem. We have agents. I just asked the agent to start a tiny Flask server to test detection. The scanner saw it:

{
  "port": 5000,
  "processName": "python",
  "cwd": "/tmp/opencode",
  "projectName": "opencode",
  "url": "http://localhost:5000"
}

That is the addictive part of agentic development. A random idea becomes a panel widget, then a test server shows up in it, and suddenly the thing is real enough to complain about.

One button was blank because the icon name did not exist in my Plasma theme. That button was supposed to mean "copy port." The second button already looked like copy. So I asked the obvious question.

why are there two copy-looking actions next to each other?

My agent simplified to:

• Open
• Copy URL
• Kill

Then kill did not work from the widget, even though the helper worked directly. The confirmation dialog path was broken. We made the red X kill immediately, which matches what the icon implies anyway.

This is where I still feel involved in the loop. The agent can implement the feature, but it cannot feel that a tiny blank square in my panel is weird. It cannot be annoyed by two copy buttons. It cannot look at a red X that does not kill the thing and say, "no, that feels wrong."

Port Menu to Portmanteau

While my agent was busy working on the app, I had time for other important endeavors. Like renaming the project. Portmanteau sounds sorta like Port Menu and sorta is itself a portmanteau. Feels a little old timey to me. I thought it was clever. I'm not sure if you'll agree with me. I also had time to switch to a ship icon because I felt like that was clever too.

The Workflow is the Learning Here

This is not a full, traditional software project. It's a small piece of personal software. It was ~10 messages back and forth with an agent. But it's legitimately useful to me. The productive loop was small:

• Ask if an idea is feasible.
• Push back on the optimistic parts.
• Fork or build off existing progress.
• Plan and actually use the plan (I do this with ticket).
• Let the agent chew through implementation.
• Try it out on the real desktop.
• Complain about the parts that feel wrong.
• Get it into a usable shape.

That is an excellent agent task: small enough to steer, annoying enough that I would not have done it by hand, and concrete enough that I could tell when it worked.

Think about all the rough edges in your life that you can solve with 10 questions and an overeager intern.

I'm going to continue to find cool ideas that are macOS only. I'm gonna continue to fork them. Translating ideas or projects across operating systems no longer feels like a giant project. Sometimes it is just a conversation with an agent, a few questions, and a tiny ship icon in your system tray.

Portmanteau is a KDE Plasma widget for local development ports. It is still rough, but it works on my Fedora KDE setup. And that's all I need :)