Organizing the workspace

The assistant starts every session without memory of the previous one. It does not remember what you agreed on yesterday, which controller caused trouble last month, or why the interpreter reads a particular word exactly this way. It knows what is written in your working folder; what stayed in the chat does not exist for it.

That is why the working folder is not order for the sake of order but the assistant's memory. A few hours spent on it once save the same explanations in every following session.

What to keep in it

One folder, opened in Visual Studio Code:

work\
├── AGENTS.md         what the assistant must know every time
├── interpreters\     interpreter sources, one folder per interpreter
├── programs\         real NC programs of the machine and expected results
├── projects\         CAM projects with the machine
├── manuals\          controller programming manual
└── notes\            your practices and analyzed cases

The names do not matter; the separation does: sources apart from test data, your knowledge apart from the official documentation.

Programs and the machine

Put several real NC programs of this machine into programs\, not just one: generated by its postprocessor, written by hand, from other CAM systems. The assistant takes the spellings of the words from them: the same axis can appear as B90, B=90 and B1=90, and the interpreter must understand every spelling that occurs in your programs. If there is a postprocessor that generates these programs, put it there too: it shows which variants of the words will appear.

Keep the CAM project with this machine (*.stcp) next to them and, if you have it, the expected result: what the machine does with the program. The controller manual in manuals\ is the main source of what the words mean; without it the assistant will guess.

Ask the assistant to make a list of the words in all programs — this is what the inspect-nc-programs skill does. The list shows which words the interpreter already understands and which it does not, and serves as the list of what to check after every change.

AGENTS.md — a short permanent memo

This file is read at the start of every session, so keep it short — no more than a page — and move the details to notes\. What deserves a place in it:

  • the machine, the controller and its version, which interpreter serves it;
  • the versions of the CAM system and ENCY Tuner the interpreter must work in;
  • where things are: programs, projects, manual, notes;
  • working rules — read the programs and the manual first, keep a change minimal, after every change run all programs and compare with the previous result;
  • restrictions you have already formulated once — written down the way you said them. Otherwise, a month later the assistant will again propose an idea you rejected for good reason.

Ask the assistant to draft it and correct the draft — that is faster than starting from an empty file.

notes — where your experience accumulates

After every analyzed case — a short file: what was wrong, how it was found, what helped and why exactly that. It is the "why" that saves time later.

  • One topic — one file, not one growing file: a small file is easy to find and cheap to read.
  • Describe the current state. Remarks such as "it used to be different" go stale over time; if the folder is under version control, the history is there anyway.

Also keep a written list of the requests and decisions for the current task in notes\. In a long conversation the assistant compresses earlier messages, and details get lost; a written list keeps them. Before reporting "done", ask the assistant to go through it item by item and show the evidence for each.

When a way of working starts repeating — the same check, the same sequence for a family of controllers — write it down as your own skill: a folder with a SKILL.md file, like the supplied skills. A client finds skills only in its skills folder, so put your skill where the others are installed (see advanced setup); a file in notes\ is read by the assistant only if you point to it. A skill that names customers or the specifics of your particular machines must not be delivered with the interpreter or published.

Two ways to keep history

Folders and copies — you keep the history yourself

Before a significant change you copy the interpreter folder, keep the results of earlier runs next to the programs, and dated folders serve as the history. This is a perfectly workable approach. Its price is that the history relies on your memory: forget to make a copy, and the previous state is gone.

Git — the tool keeps the history

The same folder, but the past is the responsibility of a tool made for exactly that. It also removes the main worry of working with an assistant: every state is saved, so a failed edit costs a minute to roll back, not a working interpreter.

You do not have to learn git for this. Ask in words, and the assistant does it:

  • "commit, axis B1 is read" — it commits the change with a message saying why;
  • "compare with what we had on Friday" — it shows what has changed;
  • "find when the G83 cycle stopped being simulated" — it searches the history;
  • "put it back as it was before the last edit" — it restores from the history instead of retyping.

If git is not installed, ask the assistant to install it — the official download is at git-scm.com. Ask it at the same time to exclude the build output (bin, obj) and logs from the history.

When the open folder must be the interpreter folder

For a C# interpreter, Visual Studio Code must be opened on the folder of the interpreter itself — that is how building and debugging with the F5 key work. The memo and the notes then end up above the open folder. Two techniques are enough:

  • Keep everything in one repository. Let the whole work\ folder be the repository, with the interpreter folders inside it. Git works from any nested folder, and there is still one history.
  • Make the memo visible from the interpreter folder. Claude Code reads instruction files in the folders above the open one by itself and needs nothing. Kilo Code reads only the open folder: point to the memo in its settings, or put a short two-line AGENTS.md into the interpreter folder: rules — in ..\..\AGENTS.md, notes — in ..\..\notes\. In detail — in advanced setup.

Install the skills for the user rather than for the working folder: then they are available with any folder open, and it is enough to put them in place once.

What must not be in it

Passwords, tokens, license files, customer archives unrelated to the interpreter, and unrelated repositories. The assistant may read everything that is in the working folder, and if you keep a history, it stays in the history. If a customer's program is needed only as an example, give a shortened one: a few blocks with the word being checked and the program header.