amiel-35 wants Mike workflows to travel as portable packs

A documentation-only proposal sketches a shared format for describing legal workflows before anyone writes the engine that runs them.

workflowknowledge-management

amiel-35 has opened a proposal that doesn't touch how Mike actually runs - instead, it tries to pin down what a Mike "workflow" looks like on paper. The submission is just a specification and two worked examples: one for an assistant-style back-and-forth, one for a tabular document-review pass. The bet is that agreeing on the shape first makes everything downstream easier - reviewing a workflow, versioning it, translating it, swapping it between forks, or letting an outside contributor propose a new one.

The interesting bits are the design questions left on the table: what every workflow must declare, what's optional, how prompts attach to individual steps, and whether one definition can really cover both a chat-style flow and a row-by-row review without bending. Whatever gets agreed here will quietly set the rails for any runtime that later loads and validates these packs.

So what Worth watching for legal-ops leads and product teams who want workflows to be shareable artifacts rather than bespoke configurations buried in code.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

2 commits from amiel-35/mikelaw-oss, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
f36519a0 docs(workflows): add declarative workflow pack format Amiel Lavon 2026-05-05 ↗ GitHub
557a990c docs(workflows): add declarative workflow pack format Amiel Lavon 2026-05-05 ↗ GitHub

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-307.md from inside the repo you want the changes in.

⬇ Download capture-thread-307.md