Give Your Assistant Questions to Ask, Not Guesses to Make

Guessing is the default

Open a repository with eight services and ask an assistant why the checkout API returns a 502. It will read the code, find a plausible port, and suggest a fix. Often the fix is for a system that is not the one on your laptop: the port was reassigned, the database never started, or the file it wants to edit is regenerated on the next flisk up.

The assistant is not careless. It was handed a pile of files and no way to ask a question. Everything it says about the running system is inference.

What it can ask instead

Flisk ships a control plane for exactly this. flisk mcp runs a Model Context Protocol server over stdio, and flisk connect claude (or cursor, or codex) writes the entry into the host's MCP config in one command. After that the assistant has tools instead of hunches.

• status returns stacks, resources, ingress URLs, ports and readiness, so the first question is answered with data.
• logs returns a bounded snapshot of recent output, so it reads the failing service rather than reading the code and imagining the failure.
• resource_list and network_list give the real service names and the URL that actually answers.
• resource_run runs a one-off command with the environment that service has in the stack.

None of these is clever. That is the point. A boring, structured answer to "is the orders service ready" removes a whole class of confident nonsense.

It can also ask what not to touch

The costliest assistant mistake in a generated project is a hand edit to a generated file. The config_explain tool takes a path and says whether the file is generated or user-owned, and what editing it would do on the next up. config_verify then checks that the generated files still match .flisk/project.json and that every service.json is valid.

That turns a rule you would otherwise paste into every prompt (never edit anything under .flisk/) into something the tool can answer for itself, per file.

A small setup that pays back quickly

flisk connect claude
flisk up
# then ask: which services are not ready, and why?

Try it on the last bug you debugged by hand. If the assistant reaches the cause through status and logs without you pasting anything, the control plane is doing its job. If it still guesses, the answer it needed was probably missing from the stack, and that is worth fixing in a service.json rather than in a prompt.