The System View: Governance Docs, Active Configuration, and 38 Skills

The harness is configured by a combination of environment variables, TOML settings, and Markdown governance documents that the planner and synthesizer read at runtime. Editing any of these traditionally meant opening a terminal, finding the file, editing it, and restarting the server. The System view collapses that into a file browser with an inline edit mode — three groups of files in a sidebar, a content pane that renders the selected file, and two live panels that reflect the current running state without requiring a restart to read.

System view with AGENTS.md selected. The sidebar shows all three file groups plus the two LIVE virtual entries at the bottom. The Edit button appears for all files flagged as editable.

The File Sidebar

The sidebar has three static groups and one live section:

Files marked with a small "edit" label in the sidebar open in read mode by default. Click Edit to switch the content pane to a textarea; Save writes the file via PUT /api/system/file/{key} and clears the edit state. Files larger than 80 KB are truncated with an amber warning — the file is still readable, just not fully shown.

Active Config

The Active config pane is a live snapshot of the process environment and resolved settings at the moment you open it. It has three sections.

Active config: environment variables in the top section, runtime settings in the middle. The HARNESS_ENDPOINTS JSON shows the two inference backends currently registered — qwen3-8b at port 8082 and qwen3.6-35b at port 8083, both via llama.cpp.

Environment (non-secret) shows every env var the harness exposes that doesn't contain credentials. The current values:

Runtime settings shows the resolved config object after all overrides are applied:

The third section, Synthesis instructions, renders the active SYNTH_INSTRUCTION variants — one block per task type. This is the instruction the synthesizer reads verbatim when composing the output document, and it's what the autoresearch loop mutates during experiments.

Skills Registry

The Skills registry lists all 38 installed skills with five columns: SKILL (name with leading slash), HOOK (colored chip), AUTO (whether the skill fires without explicit invocation), PROMPT (whether it injects text into the synthesis prompt), and DESCRIPTION.

Skills registry filtered to all hooks. Colored chips show hook type; AUTO ✓ means the skill triggers automatically from matching task language; PROMPT ✓ means it adds text to the synthesis prompt directly.

Hook taxonomy

Skills are organized by where in the pipeline they attach:

AUTO and PROMPT flags

The AUTO column indicates which skills fire without the user writing the slash command explicitly. The trigger is a keyword match in the task string: /deep fires on tasks containing "comprehensive" or "exhaustive"; /contextualize fires on self-referential tasks. This is what makes skills composable — a task like "exhaustively research RAG architectures and save to ~/Desktop/out.md" will automatically engage /deep without any explicit flag, because the planner recognizes "exhaustively" as the auto-trigger.

The PROMPT column marks skills that inject text directly into the synthesis prompt rather than running separate pipeline steps. /cite and /date are the main examples — they add a few lines to the synthesis instruction that the LLM reads alongside the research context, at near-zero token cost.

The System view is the operational dashboard for the parts of the harness that don't change run-to-run — the governance layer, the inference config, and the skill set. The Runs view covers what happened; the System view covers what the harness is.