How I Teach an AI Assistant to Write VCF Operations Orchestrator Code My Way
I have a particular way of writing VCF Operations Orchestrator code. Most of the logic lives in actions, integrations use reusable services, and workflows connect those pieces together. Logging, parameter validation and documentation are part of that structure. An AI assistant needs that context to produce a useful change. A request to “write an Orchestrator action” leaves plenty of room for code that solves the immediate problem but doesn’t fit the repository. My approach is to keep the development conventions alongside the code. Repository instructions describe the project, skills explain recurring tasks, and a separate reviewer checks the changes against those conventions. This article explains how I have organised those pieces in my Orchestrator project using Claude Code. In Why I Write Actions and Not Workflows (Mostly), I explain why I keep most of my logic in JavaScript actions. That makes the code easier to work with outside the Orchestrator editor and gives development tools something useful to inspect. The same structure gives an AI assistant useful examples to follow. It can read an existing service, see how that service calls another module, and compare a proposed change with the surrounding code. However, examples need context. A file may contain an older pattern or an exception for a particular integration. Asking the assistant to copy whichever file it finds first leaves that decision to chance. I want the repository to answer three questions: Those questions…