tldr

Three markdown files — CHANGELOG.md, BACKLOG.md, and CLAUDE.md — plus two slash commands. That’s Runway. It keeps Claude Code oriented across sessions so you’re not re-explaining your project from scratch every time.

I work on personal projects solo — just me and Claude Code. No sprint planning, no standups, no Jira. But I’m a big fan of process, and when context-switching between sessions started costing me real time, I wanted a better system.

What I built is called Runway: a lightweight workflow that lives entirely inside your source code, driven by Claude Code slash commands.

The Origin Story

It started with Glizzy Relay . I was tracking bugs and features in my head (bad) and losing thread between Claude Code sessions (worse). So I started keeping a CHANGELOG.md — and once I had that, it made sense to document what was coming too. Then I needed a place to capture how to approach the project: the architectural decisions, the known gotchas, the things you always forget.

Three files. That was the whole insight.

When I generalized this into a workflow for squalr.us and validated it on Desktop Tracker, the pattern held. So I packaged it as a Claude Code skill marketplace plugin.

The Three Files

Runway is built around three markdown files checked into your repo:

  • CHANGELOG.md — the authoritative record of what shipped and when
  • BACKLOG.md — bugs, features, and ideas, classified by type and effort
  • CLAUDE.md — how to approach the project: architecture decisions, known gotchas, project-specific context

Two slash commands drive the whole thing:

  • /add-to-backlog — describe something in plain English; Claude pulls relevant code context and writes a structured entry
  • /ship-from-backlog — pick an item; Claude creates the version branch, writes the changelog entry, bumps the version, builds, commits, and pushes

Why This Works for Solo Devs

I didn’t need assignees. I didn’t need a ticket system where a developer “picks up” a work item. I needed a continuously evolving document that stayed current with the code. Because the files live in the repo, they maintain their own relevance. When a new feature eliminates a bug, the bug comes out of the backlog. When a bug fix changes the implementation path for a planned feature, the feature description gets updated to match. No stale tickets rotting in a sidebar.

The other big benefit: token savings. Each session starts from a snapshot of where the project actually is. New context window, same mental model. It genuinely feels like you’re picking up from exactly where you left off — because you are.

No new tools to install. I didn’t want to spend time evaluating and wiring up packages like beachball just to manage a changelog. With Runway, I wrote what I wanted the workflow to be in plain English, and the skills handle the rest. No config files, no dependencies, nothing to maintain.

Capturing ideas while they’re flowing. When you’re deep in building something, ideas and issues come fast — and you don’t want to break flow to write them up properly. With /add-to-backlog, I fire off a thought in plain English and keep moving. Claude Code handles the classification, effort estimation, and relevant code context. The idea is captured while it’s fresh; the structured backlog item is waiting when I’m ready to act on it.

How Is This Different from Spec-Driven Development?

Fair question. The key difference is direction and timing.

Spec-driven development is prescriptive and upfront — you define what the system should do before you build it, then implement to the spec. The spec is the source of truth, and the code is meant to match it.

Runway is descriptive and continuous. Nothing is written before the code — you’re capturing what is, what happened, and what you noticed while building. The backlog isn’t a spec; it’s a running catch bucket for ideas and issues that surface during active development. The code is the source of truth, and the markdown files stay current with it.

A few other distinctions:

  • Specs are top-down. Runway is bidirectional — fixing a bug can update a feature description, a new feature can close a bug.
  • Specs are often written once. Runway files are continuously evolving; they’re never “done.”
  • Specs prescribe behavior. CLAUDE.md prescribes approach — how to think about the project, not what to build.
  • The AI continuity angle has no spec-driven analog. Picking up across Claude Code context windows isn’t a problem spec-driven workflows were designed to solve.

The closest thing Runway resembles is a living sprint backlog combined with an architecture decision record and a release log, all auto-maintained by the AI as a side effect of doing the work.

A Couple Implementation Details I’m Proud Of

Lazy bootstrapping. The first time you run /add-to-backlog or /ship-from-backlog, Runway checks whether BACKLOG.md and CHANGELOG.md exist. If they don’t, it triggers a separate internal bootstrap skill to create them. The bootstrap logic is not bundled into the main skills — it only gets loaded into context when it’s actually needed. Keeps the primary skills lean.

Format adaptation. Desktop Tracker already had a running CHANGELOG.md with a slightly different versioning format. Runway bootstrapped the backlog, appended to the existing CLAUDE.md, and updated the changelog — all while adapting to the format already in place rather than overriding it. That felt like exactly the right behavior.

Install It

/plugin marketplace add squalrus/runway

Run /add-to-backlog once and it sets everything up. Works on an existing project or a fresh one.

If you’re shipping personal projects with Claude Code and tired of re-explaining yourself every session, give it a shot.