Current experiments from MyLiveLab https://mylivelab.com/lab/ 2026-10-17T12:00:00Z Allie Bayless https://mylivelab.com/lab/shared-terminal-platform.html2026-10-17T12:00:00Z

How the Tide apps are sharing interface components and connecting through TideDeck while remaining useful on their own.

<p>I didn't set out to build a terminal application platform. I just wanted a better email client.</p> <p>That became TideMail. Then came Tide, TideFTP, TideGit, TideDock, and other projects. Different applications, but I kept solving the same problems: layouts, navigation, themes, text editing, and configuration.</p> <p>Eventually, I started asking why I was rebuilding the same things.</p> <h2>Sharing the Pieces</h2> <p>That's where <strong>TideUI</strong> and <strong>Ripple</strong> come in.</p> <p>TideUI provides reusable terminal interface components, while Ripple handles text editing. Rather than maintaining different implementations across applications, I want improvements to benefit the entire family.</p> <p>This week's work on TideMail's native offline spellchecker was another reminder of how much complexity hides behind seemingly simple features.</p> <h2>Connecting Everything with TideDeck</h2> <p>One of the more interesting developments has been building APIs into <strong>Tide and TideMail specifically for TideDeck</strong>.</p> <p>Instead of treating every Tide application as an isolated tool, I'm exploring how they can communicate with a central interface.</p> <p>The idea is that TideDeck can bring functionality from different applications together without duplicating their underlying logic.</p> <p>That changes the architecture quite a bit. The applications still need to work independently, but now they can also participate in a larger ecosystem.</p> <h2>Plugins and Extensibility</h2> <p>This week also brought major improvements to TideMail's plugin system.</p> <p>I added PGP signing, encryption, and decryption through a GnuPG plugin, along with in-app plugin browsing and management.</p> <p>The goal is to keep the core applications focused while making them extensible.</p> <p>TideFTP also received improvements for handling large directory trees, including parallel scanning, streaming, and better retry handling.</p> <p>Not everything should be shared. Some problems belong to individual applications, and that's fine.</p> <h2>Where This Is Going</h2> <p>AI has accelerated my development workflow, but it's also made good architecture more important. Building features faster doesn't help much if every project becomes an isolated collection of duplicated code.</p> <p>My goal isn't to create some enormous framework.</p> <p>I want a family of lightweight terminal applications that share useful components, expose APIs where appropriate, and work both independently and together through TideDeck.</p> <p>Some experiments will work. Others probably won't.</p> <p>That's what MyLiveLab is for: documenting the process and what I learn along the way.</p> <p>What started as one email client is slowly becoming a connected ecosystem of terminal tools.</p> <p>And that's a lot more interesting than I originally planned.</p> <p><em>Projects: <a href="https://github.com/allisonhere/tidemail">TideMail</a> · <a href="https://github.com/allisonhere/tide">Tide</a> · TideDeck</em></p> https://mylivelab.com/lab/skillz.html2026-10-12T12:00:00Z

Why I keep my coding agent skills in one repo, and what goes into them.

<p>I use a few different coding agents, and I want them to have the same basic context about my projects. Which repos belong together. Where the shared UI code lives. How I build and release things.</p> <p><a href="https://github.com/allisonhere/skillz">skillz</a> is where I keep those instructions.</p> <p>A skill is a folder with a Markdown file in it. It tells an agent when the instructions apply and what it needs to know. Some have reference files or templates alongside them.</p> <p>The Tide projects are a good example of why I want this. They're separate repos, but they share UI code and conventions. An agent working in one repo might have no reason to know that the thing it's about to build already exists in another. The Tide skill gives it that context and tells it where to look.</p> <p>Other skills cover terminal UI design, Go CLI releases, and the content workflow for my Astro sites. These are things specific to how I work, so it makes sense to keep them somewhere I can edit.</p> <p>There's an installer and a little terminal picker, too. For Claude Code and Codex, the installer links back to the repo. I can change an instruction once and have both use the updated file. Hermes gets a copy, so that one needs another install after an edit.</p> <p>I like having the instructions in ordinary files. I can read what I'm asking the agents to do, change anything that's wrong, and keep the history in Git.</p> <p>The collection is personal, so some of it assumes my projects and setup. If you're curious, <a href="https://github.com/allisonhere/skillz">the repo is public</a>. You can see what I've put in there and adapt anything useful.</p> https://mylivelab.com/lab/starting-the-lab-notebook.html2026-10-10T12:00:00Z

A place to show experiments while they're still half-built, including the ones that don't make it.

<p>MyLiveLab has always shown finished work. This section is for everything before that point: the prototypes, the dead ends and the &quot;what if I tried this&quot; ideas.</p> <h2>How it works</h2> <p>Each note has a status:</p> <ul class="bullet-list"><li><strong>In progress</strong>: I'm actively poking at it.</li><li><strong>Shipped</strong>: it turned into something real.</li><li><strong>Shelved</strong>: it taught me something, and I moved on.</li></ul> <p>Notes are short on purpose. What I tried, what happened, what's next.</p> <h2>Subscribe</h2> <p>There's an <a href="/lab/feed.xml">Atom feed</a> if you'd rather read these in a feed reader, such as Tide RSS.</p>