A good delphi programming software workflow is small. Open the project folder, ask for one change, read the diff and run your build command. Arraydeck follows that loop with real tools, so each step leaves a card in the chat that you can expand and inspect, from the first search to the last exit code. Nothing is hidden behind a summary. If a step looks wrong, you stop the loop there, reject the change and rephrase the request, and the files stay as they were before that step. The same four steps work on a tiny unit and on a project with many forms. Beginners and long-time maintainers can both start with a read-only search, because it changes no file and still shows how the project is laid out.
Choose the folder that holds your .dpr and .pas files as the working folder of the chat. The file tools work inside it, so pick the project you want to change and not a parent folder with unrelated work. A parent folder with many projects makes the first search harder to read and raises the risk of editing the wrong unit.
Write one task in plain words, such as the name of a procedure and what should change, and pick Auto-run, Ask first or Plan only before you send it. Small tasks give small diffs that are easy to read. Name the unit when you know it; the agent can find it with glob, but a named unit narrows the first search.
Expand the edit_file card, read every added and removed line, then accept or reject the change. If you used Plan only, read the plan first and switch to Ask first to carry it out step by step. A very long diff means the task was too big, so reject it and split the request into two smaller ones.
Let Shell run your build command and your test command, and read the real exit code on the card. A passing build is a good sign, but only your own tests tell you whether the behaviour is still right. Run the build before the tests, and keep both cards open so that a failure can be traced to one change.
.6 entriesGreeter.passavedGreeter.pasreadbuild.batexit 0unit Greeter;
interface
function Greet(const Name: string): string;
implementation
function Greet(const Name: string): string;
begin
if Name = '' then
Result := 'Hello, guest'
else
Result := 'Hello, ' + Name;
end;
end.Greet takes a name and returns a greeting. When the name is empty it answers Hello, guest, otherwise it joins the name to the text, and Result holds the return value of the function. The interface section announces the function, and the implementation section holds its code, which is the layout of every unit.
Beginners who are learning Delphi often ask where a value ends up on disk. Ask Arraydeck to find where the setting is written. The agent runs grep for the setting name across your .pas files, then read_file opens the matching unit and the answer appears in the chat with file names and lines. Nothing changes. Open the unit in your own editor to confirm that the procedure is the one you meant, and note the file name before you ask for an edit. This read-only search is a good first request on any project you did not write yourself. Write down the file and line before you ask for any edit, because a precise file name and line number make the next request short and the next diff easy to follow for anyone who reads your project after you.
Ask for a safer handler: find the procedure that creates an object and make sure it gets released. The agent searches with grep, reads the unit and proposes the change with edit_file, wrapping the code in try ... finally ... Free. In Ask first the diff appears and nothing is written until you accept it. Then Shell runs your build command, and the card shows the real exit code. Run your tests too. A build that passes proves the syntax only, not that the object is freed in every path, so read the diff slowly. Run the tests once more after you accept the diff, and keep the old version of the unit in your own backup or version control until you are sure that the handler still frees every object in every branch.
Here is how to modernize Delphi apps in small steps: rename an unclear procedure, one name at a time. Ask the agent to rename it in every unit. It uses grep to list each place where the name occurs, then edit_file changes each file, and the diffs show every line that moves. Rename once. Review all of the diffs together, because a matching word inside a string or a comment is not always a call, then build the project and run your tests before you accept the last file. Repeat the rename for the next procedure only when the build and the tests pass, so that a mistake always sits in one small diff and never hides inside a long list of unrelated changes across many units.
Pascal triangle logic explained in a short unit makes a fair practice request. Ask the agent to read the loop and describe, line by line, what each variable holds in each pass. It calls read_file, then answers in the chat without writing anything, so Plan only is enough. Check the explanation by running the unit yourself through your build command and by following the loop on paper for 3 or 4 rows. If the agent and the program disagree, trust the program and ask the question again with the exact line quoted. Do the same for a second loop if the first answer helped, and ask for a shorter explanation when a paragraph feels long, because you can always request more detail on exactly the line that confuses you.
