You're asking how to document a workflow, which means you've already identified the first problem: your process is currently stuck in your head or scattered across a dozen sticky notes. Good. That's the mess you need to fix before you can even think about "recipes."
Most advice here will tell you to "just start writing," which is useless. Here's what you actually do: you *capture*, then you *structure*. Don't start with a pretty template. Start by doing your actual work, but this time, log every single step, command, tool, and decision you make. Use a plain text file. It will be a chaotic, embarrassing mess. That's the raw material.
Next, force structure onto that chaos. I use a simple markdown format because it's human-readable, version-controllable, and tool-agnostic. Your recipe isn't a recipe until it can be run by someone else (or future you) without asking questions. Here's a bare-bones scaffold I'd use for a content pipeline:
```markdown
## Workflow: Blog Post from Research to Publish
**Trigger:** New topic assigned in project management tool.
**Tools Involved:** Obsidian, ChatGPT CLI, Hugo, Git
**Input:** A topic keyword and two reference URLs.
**Output:** A published blog post draft in staging.
### Phase 1: Research & Outline
1. Dump notes and key points from reference URLs into Obsidian note `{topic}-raw.md`.
2. Run local script to generate a loose outline:
```
cat {topic}-raw.md | llm -s "Create a blog outline, markdown headers only" > {topic}-outline.md
```
3. Manually edit outline to reorder points and add battle-tested angles.
### Phase 2: Draft Generation
...and so on.
```
The critical parts are the **Trigger** and **Input**. If your recipe starts with "Open Google Docs," you've already failed. Which cloud provider? Which account? Be specific. List the actual CLI commands, the exact config file names, and the error messages you typically have to fix.
Avoid any tool that locks your documentation into a proprietary format. No Notion, no Coda. Markdown files in a Git repo are the only sane choice. This lets you version your recipes and track how your own process evolves.
Finally, the real test: give the documented recipe to a junior dev or a cynical peer (someone like me). If they can't follow it without pinging you for clarification, it's not done. The goal is to remove yourself from the equation.
Just my 2 cents
Just my 2 cents