Add a /tools REPL command (and 'borg tools') listing available tools

[stefanthearchitect]

Context

borg ships a fixed tool set (read_file, write_file, edit_file, edit_lines, grep, glob, list_dir, bash, bash_output, kill_shell, verify, ask_user, finish — internal/tools/). There's no way for a user to see what the agent can do or which tools are permission-gated.

The task

Add a /tools REPL command (and optionally a borg tools CLI subcommand) that lists each tool's name, one-line description, and whether it's mutating (permission-gated) or read-only. The registry already exposes Name(), Description(), Mutating().

Acceptance

• /tools prints the tool list with the read-only vs gated distinction.
• Wire it through the existing slash-command menu (internal/tui/).
• A test. Coverage ≥90%.

[Om-Beast]

Hi @stefanthearchitect! I'd like to work on this issue if it's available.

My plan is to implement a /tools REPL command that lists the registered tools using the existing tool registry metadata (Name(), Description(), and Mutating()), clearly distinguishing read-only and permission-gated tools. I'll also integrate it into the existing slash-command menu, and if it fits the current CLI structure, add the corresponding borg tools command as well.

I'll include tests and ensure the implementation meets the requested coverage target.

Looking forward to contributing!

[stefanthearchitect]

Thanks @Om-Beast — this is a great first issue to pick up, and your plan is spot-on. Go ahead and take it. 🎉

A few pointers so it lands cleanly:

• The registry API you cited is exactly right (Name()/Description()/Mutating()), and the ordered Registry in internal/tools/tools.go is what you want to iterate — it preserves tool order, so the listing will read naturally.
• One integration note: the registry is currently a private field on *agent.Agent (tools *tools.Registry in internal/agent/loop.go), so the TUI can't reach it directly. Please add a small exported accessor on the agent (e.g. Agent.ToolList() returning name/description/mutating triples) and have both surfaces call it. That keeps us on the repo's one-source-of-truth rule — the same seam serves /tools (REPL) and borg tools (CLI) without duplicating the field list.
• For the REPL wiring: add an entry to slashCmds and a case "/tools": in the command switch in internal/tui/model.go (follow how /context / /usage are done).
• Doing the borg tools CLI subcommand too would be very welcome and fits naturally alongside the other cmd/borg commands, but it's optional — the /tools command is the core ask.

Tests + the ≥90% coverage gate are enforced in CI (make cover-gate), so please include a test for the listing/formatting. Open the PR against main and squash-merge when green. Shout if you get stuck on anything!