Examples and tips

Concrete things to hand Sudo, and what he actually does behind each one. You type plain language; you never name a command or write the code yourself. The commands shown are what he runs, so you can recognise them in the transcript or reproduce them in the terminal window.

Asking questions

These need nothing turned on. He reads, and changes nothing.

"Which endpoints are reachable without authentication?" grep -l over /workspace/code/endpoints/ for the public access mode, then reads each match's header to report the route.

"What does the support-triage agent do, and which tools can it call?" cat /workspace/code/agents/support-triage.cs — the whole agent, system prompt and tool set included, is one file.

"What changed in the configuration in the last 24 hours?" jq over /proc/audit.

"Are any scheduled tasks failing?" /proc/scheduled-tasks for the status and last outcome, then /proc/exceptions for the errors behind the failures.

"How many Ticket nodes are there, and what does one look like?" graph stats Ticket and graph sample Ticket -n 3.

"Which node types have no search index?" /proc/nodetypes against /proc/indexes, joined with awk.

"What did this endpoint look like before Tuesday?" graph history on the endpoint's node, and diff between two versions.

Making changes

These need Allow changes on, and each one ends with a diff you approve.

"Add an endpoint that returns open tickets grouped by product." Reads /reference/code/endpoints/ for the file shape and /docs for the endpoint scope, mints a UID with uid endpoint /api/…, writes the file, builds it until it compiles, and commits.

"Here is a CSV. Build me a schema and a connector for it." file-stats /stage/products.csv for the columns, their types and their null counts, then a node schema under config/schemas/nodes/ and a data connector under code/data-connector-tasks/, both in one commit, because they only make sense together.

"The support agent should also search the wiki." Edits the agent's tool set in place with sed, builds, diffs to show you the one changed line, and commits.

"Add a Region field to Customer and backfill it from the address." The schema change and the migration that backfills it in one commit, because build lets a schema and the code using it compile together. After you approve it, run migration starts it and /proc/runs/<id>/log reports progress.

"Turn on the copy disclaimer and shorten chat retention to 30 days." One config/*.json document, two values, one small diff.

"Delete the old ingest-from-ftp task." Removes the file and commits the deletion. Deleting a built-in is refused; naming something already gone is a warning, not an error.

Operating

"Run the nightly refresh now and tell me if it worked." run task "Nightly refresh", then reads /proc/runs/<id>/status and log as it progresses.

"Something broke after the last deploy. What is throwing?" /proc/exceptions grouped by type, then the audit trail for what changed around that time, then the file itself.

"Reindex Ticket and tell me when it is done." run reindex Ticket, then polls the run folder.

Tips

Say what you want, not which surface. "Users should be able to filter tickets by product" is a better prompt than "add a facet", because the right answer might be a facet, an index setting or a schema field, and he can look before deciding.

Let him plan first on anything multi-step. He writes the steps to his to-do list before starting and marks them off as he goes; /session/todo.md and the terminal window both show where he is. If he skipped that on something big, asking him to plan it out first is worth the turn.

Give him the file rather than describing it. Upload the CSV, the JSON sample or the spec to Stage and say "use this". file-stats on a real file beats any description of it.

Point at what you are looking at. The chat knows which admin page is in the foreground, so "make this one read-only" resolves to the endpoint you have open.

Ask for the diff early. "Show me what that would change" before committing is a cheap way to catch a misunderstanding while it is still one file.

Correct in the chat, not in the review screen. The diff is deliberately read-only. Telling him what is wrong keeps one copy of the truth; editing around him would leave the file in his shell disagreeing with what was applied.

Open the terminal when you want to look yourself. It drives the same session, so you see his working directory and his uncommitted files, and tab completion offers them.

Put conventions in a skill. Anything you would otherwise repeat at the start of every conversation belongs in a skill.

One commit per idea. A commit that changes one thing is one thing to review. If he has drifted into changing several, asking him to commit the first part on its own is usually faster than reading all of it.

Read next

• Commands — everything used above.
• Reviewing and approving — what happens after commit.
• Skills — teaching him your conventions.