JS

04Applied workflow system

Operator-Safe AI Workflows

Two small tools built so a non-technical person could drive AI edits to a live design file without being able to break it, and without needing me in the room.

Role
Workflow design, constraints, tool design, handoff, testing, and operational documentation
Timeframe
2026, packaged and handed off
Status
Working · handed off to one operator
Outcome
A constrained editing pipeline and a written operating harness that let a non-technical operator make AI-assisted design edits, with the destructive moves removed from the tool rather than from the instructions.
How I work, on every project
I decide what the system is for, what it is forbidden to do, and what the finished outcome must be. AI agents execute against written guidance, and that guidance is ready only when the outcome is explicit and agreed.

What this is

Two small tools, built to answer a question I kept running into: what does it take for someone who does not write code to use an AI tool on something that matters, and keep using it after the person who built it walks away.

The setting was Figma. Someone needs to update copy across an existing set of layouts. The AI can do it. The risk is not that the copy comes out badly. The risk is that a text edit quietly changes a frame's auto-layout, and nobody notices until a deck goes out looking wrong.

For these two I also did the handoff.

The problem

A working prototype is not a deliverable. It is a demonstration that the thing is possible.

The failure mode is predictable. The tool works when its author drives it. It is handed to an operator. The first time it produces something unexpected, the operator cannot tell whether they did something wrong, whether the file was already broken, or whether the tool is having a bad day, and there is no safe way to find out. So they stop using it, and they go back to doing it by hand, and the project failed.

The design work is deciding what the operator must not be able to do, and then removing it from the tool rather than from the instructions.

What the constraints actually are

Snapshot NORMALISED FROM THE PLUGIN Proposal TEXT ONLY Guardrails LAYOUT AND TOKENS UNTOUCHED Approval A NAMED PERSON WITH A NOTE Dry run NOTHING WRITTEN Apply THE PLUGIN ONLY NEVER THE API READS GO THROUGH THE API · WRITES HAPPEN ONLY THROUGH THE PLUGIN · NO PATH WRITES ON ITS OWN
Every change travels this line with no way around it. Reads go through the API; writes happen only through the plugin, so no automated process can write to a design file on its own.

The content guardian is text-only, and that is enforced rather than requested. It may propose and apply changes to existing text content, and it must preserve layout, typography, color, spacing, auto-layout, components, variants, tokens, and geometry. It is not a tool for generating new design. It is a tool for protecting existing design while the words change.

Changes travel a fixed path with no way around itC1: export a normalized snapshot from the plugin, generate a proposal, check it against guardrails, approve it with a named approver and a note, run a dry run, then apply.

The read path and the write path are deliberately different systems. Reads go through the API. Writes happen only through the plugin. There is no code path where an automated process can write to a design file on its own.

The brand manifest is a single source of truth, and a test fails when generated files drift from it. Configuration control here is a check that goes red.

The second tool is not code at all. It is a written harnessC3 that lets a non-technical operator drive an AI coding agent against a design file: standing instructions, safety rules, change modes, prompts, a checklist, and setup notes. Its main rule is inspect first, plan second, write only after confirmation. For anything touching layout, the agent creates a variation beside the original rather than overwriting it, so the recovery step is doing nothing rather than undoing something.

The decisions I would defend

Take the dangerous options away rather than documenting them. A safety rule in a document is a rule an operator can miss. A capability the tool does not have is a rule that cannot be missed.

Make the safe move the lazy move. Creating a variation beside the original is less work than overwriting and recovering. Operators do the easy thing, so the easy thing has to be the correct one.

The handoff is the product. The checklist, the setup guide, the quick start, and the standing rules are the part that determines whether the tool survives contact with someone who did not build it.

Evidence

  • 27 test files coveringC2 the approval pipeline, the guardrail builder, the patch generator and validator, and manifest drift
  • 14 documentation files covering scope rules, the handoff checklist, setup, and the operator workflow
  • The packaged harness as delivered, with its safety rules, change modes, and quick start

Status

Working and handed off. The guardian pipeline runs end to end, and the harness was packaged and delivered as a kit.

Known gaps. These are small tools at personal and single-team scale, not products. The handoff went to one operator, and one operator is an anecdote rather than evidence that the design generalizes. Some support was still needed after delivery, which is why the checklist exists. Nothing here has been tested with an operator I did not have direct access to.

Claims ledger

What this page asserts, and where each assertion is checked. Each entry names its evidence and the source-repository commit it was checked against. A number that is not in this ledger does not appear on the page.

C1

A text-only Figma content assistant enforces a fixed path (snapshot, proposal, guardrail check, named approval, dry run, apply) and separates read from write: reads go through the API while writes happen only through the Figma plugin, so no automated process can write to a design file on its own.

documented
Repository README workflow and approval CLI, plus the V1 scope rules document
checked 2026-08-30 at c8b41590
C2

27 test files cover the approval pipeline, guardrail builder, patch generator and validator, and brand-manifest drift, alongside 14 documentation files covering scope rules, handoff checklist, setup, and the operator workflow.

documented
Repository test and documentation inventory
checked 2026-08-30 at c8b41590
C3

A written operating harness lets a non-technical operator drive an AI coding agent against a design file under standing rules: inspect first, plan second, write only after confirmation, and create a variation beside the original rather than overwriting it. It was packaged and delivered as a kit with safety rules, change modes, a checklist, and a quick start.

documented
The delivered harness kit: standing instructions, safety rules, change modes, prompts, checklist, setup notes, and quick start
checked 2026-08-30, no repository: a career fact

Next

01Civilocity Estimator