In 2015 I wrote down what it would look like: Design of InstructSpace. I followed and admired Canvas when it was first open sourced, taught online with it as a Free for Teacher user (my university was still on Moodle), then spent over ten years in edtech.

I'm outside academia now, and honestly a bit out of touch. But for the first time it feels like we can actually build it. With AI, exploring a direction costs tokens, not years: you can try whichever direction you like, as long as you have tokens to spend.

This is one of those directions.

Contents

• What I wanted in 2015, and still do
• One direction: ZenLMS
  • The week, first
  • Notifications only for what needs you
  • Discussions you can read
  • Feedback on the work itself
  • For teachers: the same page, plus what needs you
  • On a phone, too
• What we have so far
• Before I spend all my tokens

What I wanted in 2015, and still do

Rereading the InstructSpace doc, most of it still holds:

• Reading comes first. I was "unsatisfied with all current LMS typography and readability," and wanted simplicity to be the key: "how could we do more with less?"
• Notifications should mean something. Activity is what happened in a course. A notification is something that needs you. They shouldn't be the same list.
• Discussions should stay on topic. Endlessly nested threads drift away from the main question, so: two levels, no more.
• Grading should live with the work, instead of being a chore of counting who posted what.

One direction: ZenLMS

This one started as a question on X:

LMS inspired by Tufte... should i do it?

— shao (@randomor) September 27, 2026

ZenLMS is minimalist and text-first: dense, well-set text, plain lists, as little chrome as possible. Every screen below comes from one made-up course, Reading the City, in Week 5 of 14.

The week, first

The course home opens on this week: the teacher's note, the readings and tasks you tick off as you go, and what's due. Announcements, discussions, people and files sit further down the same page.

Notifications only for what needs you

The 2015 split, finally drawn: the bell holds only things that ask something of you. Everything else lives in each course's Activity.

Discussions you can read

Two levels, like the 2015 doc said: responses, and replies under them. You can quote any passage, @mention people, and write in Markdown.

Feedback on the work itself

Comments sit in the margin beside your paper, with the rubric below it. You can reply to each comment, or ask for a regrade.

For teachers: the same page, plus what needs you

Teachers see the same course home, with edit links, progress on each item, and a Needs you list: posts waiting for feedback, questions with no staff reply, extension and regrade requests, and students who haven't opened the week yet.

Grading happens next to the work: pick the rubric scores, leave a comment, move on to the next student.

On a phone, too

What we have so far

A month after that first question:

• 36 screens for students and teachers, from signing in to the gradebook, including quizzes, the calendar, building a module, importing from Canvas, groups and the inbox.
• A clickable demo with every screen linked together: zenlms.idealistspace.com. Ticks, filters, drafts and quiz answers work, and stay in your browser. Nothing is sent anywhere.
• A 2-minute video, every shot of it the live demo:

I've wanted to build my own LMS for more than a decade. … This is a first take: minimalist and text-first. Nothing real is built yet. It's a clickable design with made-up data. … Watch the 2-minute video and let me know.

— shao (@randomor) October 20, 2026

Nothing real is built yet.

Before I spend all my tokens

This is one direction. I have a handful of other variations, ranging from promising to insane, that I want to explore too. And even with this one, I'm not sure it's something I want to dive into yet.

So I'm putting it out here before I indulge myself too much: should this exist? What would make you use it, or keep you away?

Tell me on X.

Note: This is expanded from my original tweet.

Agents run. You prompt. There is no need to type code line by line. The loop tightens. With this free setup, you can do it from anywhere – in a car line, waiting for your ride, or even in the shower.

Contents

• Level 1: Access Your Mac Anywhere
• Next Level: Continuous Flow
• Level 2.1: Agent Notifications
• Level 3: Push Notifications
• Level 4: Preview Your Code
• Bonus Levels

Level 1: Access Your Mac Anywhere

Here is the simplest free setup to get this, and this should only take you 15 minutes:

1. Tailscale for VPN and security. Install on both your phone and Mac.
2. Termius for terminal access with a nice keyboard bar. Install on your phone.
3. Have your Mac always connected to power with the lid up.
4. Grab your Mac's Tailscale IP from the Tailscale app on your phone.
5. Enable Remote Login in macOS System Settings/Preferences → Sharing so SSH is allowed.
6. Connect via SSH to that IP in Termius.

Now you can vibe from your phone anywhere.

Next Level: Continuous Flow

What if you want to start your work from your Mac and continue on from your phone? Introducing tmux:

• Just define a bash function aa in your .zshrc:

  aa(){ tmux new -A -s work}
  

• When you connect, type aa to connect or start the session.
• You can also start or reattach to the session from your Mac if you have ongoing agent work.

Want your tmux to be prettier? Just do this:

just typed your tweet into my agent and asked it repro it, and it did, since i haven't used tmux for many years and it's pristine setup, it also taught me how to create panels and setup meta key.

i don't need your dotfiles, all i need is your ideas, thanks for sharing! pic.twitter.com/yI7QhkfCpu

— shao (@randomor) January 3, 2026

Not sure how to navigate with tmux windows/panels or remember all the key bindings?

• You can just use one window/panel.
• Or, you can ask your agent to put all common shortcuts in an info panel and hook it up to ctrl + b + i, so you only have to remember that one.

Level 2.1: Agent Notifications

Want to be notified when your agent needs your attention?

• Ask your agent to always "emit a terminal bell (printf '\a')" in your http://agents.md when they need your attention or are close to being done.

Level 3: Push Notifications

Just ask Agents.md to run a script that calls a private Discord channel webhook as above. It's all free. No $500/month Poke or $100/month VM needed.

Level 4: Preview Your Code

For Web Apps:

• Run your app npm run dev (which may start a server at localhost:8080).
• Go to the Tailscale app, copy the MagicDNS link.
• You will get a link like yourmac.tailabcd.ts.net.
• Just append the port to the MagicDNS link (e.g., yourmac.tailabcd.ts.net:8080).
• Now you can preview anywhere.

For iOS Apps:

• Push the TestFlight to preview (follow my workflow here).
• Or, if you are in the same home WiFi, you can ask your agent to build your project, it will run on your iPhone directly (won't work outside of WiFi unfortunately).

Bonus Levels

• 5x Input Bandwidth: Want to 5x the input bandwidth instead of just 2 fingers? Buy this keyboard:

I declare this as the best keyboard for @daylightco and @thezenjournal….
I can finally fire with all ten fingers. Perfect for my new vibe coding setup as well… pic.twitter.com/tQq7mrZhCo

— shao (@randomor) January 5, 2026

• 1.2x Typing Speed: Want to type 1.2x faster with a physical keyboard, or simply want to type in bed (i'd not recommend unless you want to mess up your sleep), or in the shower (which I do recommend, like what's stopping you)? Buy the new fancy Clicks keyboard. Don't expect significant speed up though, as you have to learn new muscle memory and you still have to type with your thumb.

Termius has claimed the top of my screen time list even with my Mac usage over the weekend. It probably will not last, but I like the option of having it available.

This is the release flow I use for Swift native projects like DoubleMemory. It decouples main from builds so rapid, small PR merges don’t trigger Xcode Cloud, while giving me maximum control over when to build, when to bump versions, and when to cut releases—without merge conflicts and with automatic artifacts and changelogs.

Contents

• Goals and constraints
• Branch + trigger model
• Annotated workflow (full quote with comments)
• The GitHub Release path (preferred)
• The direct production push path (manual build)
• Why this works well for me
• Skill definition (Codex format)
• Post-installation steps
• Script reference
• Final Words
• References

Goals and constraints

• Optimize Xcode Cloud build minutes and GitHub Actions trigger time.
• Build anytime and anywhere, without be bound to a Mac running on xcode.
• Keep production builds clean, deterministic, and fast-forward only.
• Let a GitHub Release promote and version the main line without manual merges.
• Control when TestFlight builds, version bumps, releases, and changelog generation happen.
• Allow the main branch to remain the active merge target for frequent PR merges without triggering unnecessary builds or version bumps.

Branch + trigger model

• production is the only branch that triggers Xcode Cloud pipelines.
• A GitHub Release (published) triggers release_sync.yml.
• release_sync.yml only fast-forwards and promotes main into production, so there are no conflicts.
• After promotion, the workflow bumps MARKETING_VERSION on main.

Annotated workflow (full quote with comments)

# .github/workflows/release_sync.yml
name: Release Sync and Version Bump

on:
  release:
    types: [published] # Triggered by publishing a GitHub Release.
  workflow_dispatch: # Manual trigger for maintenance.

permissions:
  contents: write

jobs:
  promote:
    name: Promote main to production and bump version
    runs-on: macos-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # Full history needed for fast-forward checks.

      - name: Configure Git user
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"

      - name: Fast-forward production from main
        env:
          MAIN_BRANCH: main
          PRODUCTION_BRANCH: production
        run: |
          set -eo pipefail
          git fetch --prune origin
          if git ls-remote --exit-code origin "$PRODUCTION_BRANCH" >/dev/null 2>&1; then
            git checkout -B "$PRODUCTION_BRANCH" "origin/$PRODUCTION_BRANCH"
          else
            git checkout -B "$PRODUCTION_BRANCH" "origin/$MAIN_BRANCH"
          fi
          git merge --ff-only "origin/$MAIN_BRANCH"
          git push origin "$PRODUCTION_BRANCH:$PRODUCTION_BRANCH"

      - name: Bump MARKETING_VERSION on main
        env:
          MAIN_BRANCH: main
        run: |
          set -eo pipefail
          git checkout -B "$MAIN_BRANCH" "origin/$MAIN_BRANCH"
          swift Scripts/bump_version.swift
          if git status --porcelain | grep .; then
            new_version=$(grep -m1 "MARKETING_VERSION =" DoubleMemory.xcodeproj/project.pbxproj | sed -E 's/.*MARKETING_VERSION = ([0-9.]+);/\1/' | tr -d '[:space:]')
            git commit -am "Bump version to $new_version"
            git push origin "$MAIN_BRANCH:$MAIN_BRANCH"
          else
            echo "No version changes detected; skipping commit."
          fi

The GitHub Release path (preferred)

1. Create a GitHub Release (auto-tag on release creation).
2. The release triggers release_sync.yml:
   • Fast-forward production from main.
   • Bump the version on main and push.
3. Xcode Cloud builds from production.
4. Artifacts are generated and a clean changelog is attached to the release automatically by GitHub.

This keeps versioning centralized and avoids long-running GitHub Actions builds for every release. If you prefer to avoid clicking in GitHub, this step can be scripted (for example, via a CLI release command) and still uses the same workflow.

The direct production push path (manual build)

Sometimes you need to ship a build to TestFlight without cutting a full GitHub Release—for example, to get a quick internal QA build out the door. Because this path only increments the build number (not the marketing version), App Store Connect usually skips the longer human review that full version bumps require. In practice that means approval in minutes, not the days-long wait that has become common as the review queue fills with AI-generated apps.

A local script handles this by fast-forwarding production from main and pushing directly:

Scripts/build_app_store.sh:

#!/usr/bin/env bash

set -euo pipefail

# ... (setup variables)

echo "Fast-forwarding ${PRODUCTION_BRANCH} from ${MAIN_BRANCH}..."
git merge --ff-only "origin/$MAIN_BRANCH"

echo "Pushing ${PRODUCTION_BRANCH} to origin..."
git push origin "$PRODUCTION_BRANCH:$PRODUCTION_BRANCH"

# ...

This triggers Xcode Cloud immediately because of the push to production.

Why this works well for me

• Production stays fast-forward only, so it always builds.
• Main stays versioned and clean yet still allows active development and merging of PRs without triggering a build which costs build time.
• Xcode Cloud runs only when it matters.
• GitHub Actions work is minimal and deterministic.

Skill definition (Codex format)

If you want this flow packaged as a Codex skill, the definition lives in a SKILL.md with YAML front matter (this is the actual format used by Codex). For the canonical spec and installer usage, see ~/.codex/skills/.system/skill-installer/SKILL.md.

---
name: ios-release-pipeline
description: Sets up a GitHub Release → fast-forward production → version bump flow for Xcode Cloud.
metadata:
  short-description: Release sync + version bump for iOS
---

# iOS Release Pipeline Setup

Create a `.github/workflows/release_sync.yml` workflow that:
- Triggers on `release` (published) and `workflow_dispatch`.
- Fast-forwards `production` from `main` and pushes.
- Bumps `MARKETING_VERSION` on `main` and pushes.
- Then generate `Scripts/build_app_store.sh` to fast-forward `production` from `main` and push for manual builds.

Post-installation steps

On GitHub:

1. Enable Actions read/write permissions.
2. Publish a Release to trigger the sync.

On Xcode Cloud:

1. Start Condition = Branch Changes.
2. Branch = production.
3. Optional: add TestFlight Internal Testing.

Please check Thomas Ricouard’s flow for TestFlight via Codex Web for detailed instructions.

Script reference

The full script lives at Scripts/build_app_store.sh. It fast-forwards production from main and pushes to origin, and it should be generated by the skill rather than hidden. For version bumping, your LLM should be able to generate a small script that matches your project layout; if you use Tuist, this becomes much simpler than my original setup because I started DoubleMemory before adopting Tuist.

Final Words

If this post was helpful, I can share the full Swift native project setup in a separate write-up, including topics like how to setup a Swift project by using Tuist, and how to save debug tokens with xcbeautify. You can follow me on X if you want that next: @randomor.

References

• Thomas Ricouard’s flow for TestFlight via Codex Web: https://x.com/Dimillian/status/2007107988038054240?s=20
• Paul Solt’s manual archive demo for TestFlight: https://x.com/PaulSolt/status/2007180161569959998?s=20

This post is inspired by the ongoing discussion about Codex-to-TestFlight flows in those two recent X posts, and special thanks to Paul for the encouragement to write this post as well as adding the skills definition so everyone can easily integrate this flow into their projects.