Tools¶

Import a tool by name — from toolroom import git — and call it, git.commit(…). No declaration needed: the bridge translates keyword arguments into flags mechanically, and every tool on your PATH already works. These pages document the stubs: what each curated tool accepted at the version footman last read it from, with that tool's own help text per flag.

Nothing here is a wrapper. The stubs are generated by fm tools.sync, which asks the installed binaries what they take, and fm tools.audit reports which tools have released a newer version since. A flag missing from a stub still runs — every verb ends in **flags: Any, so a stub can suggest but never forbid.

Where a flag defaults on, its documentation names the spelling that turns it off, because that is the one thing the bridge cannot infer: clean=off emits mkdocs build --dirty, not --no-clean.

The In-process column is a deliberate choice, not a capability dump. Tasks run concurrently as threads, and a tool call is normally a subprocess — isolated, trivially parallel. A Python tool with a [console_scripts] entry point can run in footman's own process instead, skipping the spawn:

• default — footman prefers in-process. mkdocs (macOS strips DYLD_* from subprocesses, so cairo only resolves in-process), zensical and coverage (pure Python) qualify, and their entry points accept an argument list, so they stay parallel.
• available — an entry point exists but running it in-process buys nothing: basedpyright ships a Python launcher that just spawns node, so footman subprocesses it anyway.
• no — a Rust/Go/Node binary with no Python entry point; always a subprocess.

See the footman host page for how in-process tools stay parallel (and the one case that can't).