Guide: Coding agent

The auto-sde plugin ships a coding agent tuned for real engineering work: it reads code with scoped shell commands, makes the smallest correct change, and verifies it. This guide walks a typical loop.

Install it

muaz plugins install auto-sde

It comes from the plugin registry, signed by muaz’s publisher key — the install banner says verified when the signature checked out. You will be shown what it asks for (network access, the built-in tools it uses, and the verify-and-debug skill’s shell:* pre-approval) and asked whether to trust it. Declining still installs it; its tools just prompt on every use.

Start it

From the browser UI, pick coding on the Agents page and hit chat. From the terminal:

muaz chat --agent coding

From the terminal, run it inside the repository you want it to work on; in the browser UI, point the working directory field on the new-chat page at the repo. Either way the file tools and shell are confined to that session’s working directory for its whole lifetime.

What makes it effective

• A live task list. For anything multi-step the agent calls write_tasks and keeps exactly one item in progress. In the UI this renders as a collapsible Tasks panel; in the REPL it prints as a checklist. You always see the plan.
• Diff-preview approvals. File edits (edit_file / write_file / patch_file) are ask by default — you approve a colored diff of the exact change, not opaque JSON. Read commands (read_file, search, safe shell) run freely.
• Cross-session memory. Tell it a durable fact (“this repo uses pnpm and vitest”) and it records it with the memory tool — filed under the right scope: repo conventions stay with the working directory (shared with every agent that works there), your preferences go to the global notebook, the agent’s own habits to its agent notebook. Next session in that repo, the notes are already in its system prompt.
• Delegation. For a self-contained sub-task it can call spawn_agent to hand off to another agent and fold the result back in.

A typical turn

1. Ask for a change: “add a --json flag to the list command and cover it with a test.”
2. The agent writes a task list, searches for the command definition, and reads just the relevant slice.
3. It proposes an edit — you get a diff to Approve once / Approve for session / Deny with a reason.
4. It runs the nearest test (ask on shell, unless you allow-listed the test runner), reports what it ran, and marks the task done.

Tune approvals

Give the agent more autonomy by moving specific tools to auto, or scope a session-wide allowance from the approval prompt. See Tools & approval. For a hard egress lock on an agent, set network: none (strips web tools, refuses HTTP MCP) — see Security.