Workflows

A workflow is simply a term I am using to describe any process or workflow I use to be efficient and productive when coding with LLMs.

It might refer simply to a mentality I maintain when working, it might refer to a simple tool or process I'm using to be more productive, or it might refer to a complex web of systems I am using to achieve some goal.

For each workflow I will typically produce a handoff for coding agents that I will give to you.

Let me give you some examples

...that's all fantastically vague. Let me give you some concrete examples of what I mean by workflows :

  • tmux configurations for easily switching between multiple projects
  • a simple tool for tracking completion status and switching between agent instances across multiple projects
  • personalised GitHub and PR review integrations for a terminal coding workflow
  • integrated tools for issue tracking
  • approaches for temporarily storing ephemeral plans and thoughts related to project
  • approaches to long term note taking and knowledge management
  • ...anything and everything that is something you do now to make your work easier later

You might even say that I define a workflow as anything that helps your work... flow 😏

Maximum value, minimal puns, zero spam

Join my newsletter for new workflows. I'll let you know about new content whenever I publish it

Why do I need a handoff?

Back in the old days of coding tutorials if you were to go to some blog to learn about some tool or process some guy on the Internet is using, you would expect them to then show you step by step how to code that tool. Or, at least, you would get a link to the repo containing the implementation of the tool

But...

...if I am creating some tool to help improve my workflow, I don't just start coding it up anymore.

I tell an LLM to implement it, and typically minutes later it is done

LLMs are fantastic at creating small isolated tools or configurations, which is almost always what these workflows require.

I'll end up with some code that I could share with you of course, but in the age of LLMs it doesn't make any sense to share the information with you this way. Mainly because:

  • You're probably going to use an LLM to implement it on your end
  • The point in this case isn't to learn the code behind how these little workflow improvement tools are constructed
  • Implementing the exact solution that suited my own personal preferences likely will not suit yours.
  • LLMs make it extraordinarily easy to tailor our tools to our own preferences. We should utilise that.

Instead of giving you step-by-step instructions on implementing the workflow I will instead give you a handoff file that is optimised for LLMs.

These handoff files aim to capture the reasoning for the workflow and how it was implemented on my machine, with specific instructions to adapt the implementation to the environment and preferences of the user (that's you) who will be implementing a similar workflow on another machine.

The general idea is you simply pass the handoff .md to your own coding agent and it will walk you through setting up a solution that is the same in spirit to what I have done, but it is tailored to you.

You should almost NEVER use my workflows EXACTLY as is.

LLMs enable an age of cheap, changeable, hyper-personalised tooling and workflows. You should always adapt these to suit your preferences and evolve them over time.

Get new workflows in your inbox

Join my newsletter to receive new content when I publish it. No spam, unsubscribe whenever you like.

Browse workflows