Code Map

Fisk AI turns any fisk-based command-line application into a safety-first LLM agent. It introspects the application’s command tree, exposes the allowed commands as tools, and runs an agent loop against the Anthropic API that calls those tools to satisfy a prompt. This code map explains how that is built.

Snapshot

Generated 2026-07-16 against commit e92647e on branch main. Commits after this one may make parts of this map stale.

Create a Code Map for your code using the Choria Codemap Plugin for Claude Code

The mental model

There is one core and several faces. The core is the tool model: a fisk application is introspected once, its runnable leaf commands become named tools, and reserved tags plus include and exclude rules decide which of them an LLM may ever see. That same tool set is then consumed three ways. The run command wraps it in an agent loop that calls the model, runs the tools the model asks for, and feeds results back under a budget. The mcp command serves the tools over the Model Context Protocol for an external client. The a2a command serves them over a NATS-based agent-to-agent protocol. Safety is not a layer on top; it is built into the core, so every face inherits the same guardrails: commands run through exec with an argument vector rather than a shell, output is capped, credentials are stripped from the child environment, and a tagged command can require a human to approve it before it runs.

Fisk CLI appcommand treeTool modelcommands as toolsAgent loopMCP serverA2A / NATSAnthropic APIMCP clientPeer agents
One tool model, three faces. The agent loop is the only face that talks to the model; the dashed edge is the model's response feeding the next iteration.

What a run looks like

The default run face drives the loop until the model produces a final answer or a budget stops it. Only the answer reaches stdout; traces and the run summary go to stderr, so the output stays safe to pipe.

$ fisk-ai run --tool-output --no-tui 'how many consumers on the busiest stream?' -> stream_ls ok -> consumer_ls --stream ORDERS ok The ORDERS stream is busiest and has 4 consumers. run summary: llm_calls=3 tool_calls=2 tokens=4102/210 latency=3.9s

Explore

Next

Start with Architecture for the package layering, then follow the subsystem pages in menu order.