vigiles API reference
    Preparing search index...

    Interface AgentSpec

    A subagent definition (compiles to agents/<name>.md). Unlike a skill — reference material the model reads on activation — a subagent is a delegated worker with a contract: a dispatch description, an allowed-tools rail, an optional model, a system-prompt body, and the rules it must follow. That tool contract + those rules are the "railway" a subagent runs on, and they're exactly the compile-time-verifiable surface vigiles owns: the body's file()/cmd()/symbol() marks are checked like any instruction file, and the tools list is verified against the real tool set.

    interface AgentSpec {
        _specType: "agent";
        body?: string | InstructionFragment[];
        color?: string;
        description: string;
        disallowedTools?: readonly string[];
        model?: string;
        name: string;
        output?: OutputContract<
            Readonly<Record<string, OutputFieldType>>,
            Readonly<Record<string, OutputFieldType>>,
        >;
        purity?: AuthoredPurity;
        rules?: Record<string, Rule>;
        sections?: Record<string, string | InstructionFragment[]>;
        tools?: readonly string[];
    }
    Index

    Properties

    _specType: "agent"
    body?: string | InstructionFragment[]

    The lead/intro prose of the system prompt (the "You are…" opener), before any sections. Carries verified file()/cmd()/symbol()/ref() marks. No markdown headers — use sections for those.

    color?: string

    Subagent UI colour (Claude Code frontmatter, e.g. "pink", "blue"). Optional.

    description: string

    When to dispatch this subagent — the trigger (frontmatter).

    disallowedTools?: readonly string[]

    The DENY-side contract — tools the worker may NOT use. Use this INSTEAD OF tools, not with it: tools is an allowlist (only these), so a tool not listed is already unavailable and a disallowedTools entry would be redundant. disallowedTools earns its place only when there's NO allowlist (the agent inherits ALL tools) and you want to subtract a few — e.g. disallowedTools: ["Bash"] on an otherwise-unrestricted worker. Rendered to the disallowedTools: frontmatter; close-typos are flagged (a typo'd entry blocks nothing). For a read-only floor prefer a tight tools list + purity.

    model?: string

    Model alias (e.g. "sonnet", "opus", "haiku", "inherit"). Optional.

    name: string

    Subagent name (frontmatter + dispatch handle).

    output?: OutputContract<
        Readonly<Record<string, OutputFieldType>>,
        Readonly<Record<string, OutputFieldType>>,
    >

    The typed result contract — what this worker returns on success/error. When set, compiles to an ## Output contract section instructing the worker to end with a vigiles:ok / vigiles:err block, so its outcome is parseable and testable (see result(), parseAgentResult, assertAgentOk).

    Declare this agent's purity floor — compile rejects a tool contract looser than it. "pure" allows only read-only tools; "bounded" also allows decidable side-effecting tools (Write, Edit, …) but bars Bash / unknown-effect / inherits-all; "dangerously-unrestricted" (or omitting it) enforces nothing. "pure"/"bounded" require an explicit tools list — a wildcard or absent-tools (inherits-all) is always a violation.

    rules?: Record<string, Rule>

    Rules the worker must follow — rendered as a ## Rules section.

    sections?: Record<string, string | InstructionFragment[]>

    Named ## sections of the system prompt (e.g. Purpose, Core Principles, Capabilities) — the shape real subagents actually take. Same verified-ref + no-nested-## rules as a CLAUDE.md spec's sections. Use body for the intro and sections for the structured rest.

    tools?: readonly string[]

    The allowed-tools contract — the rails the worker runs on. Each entry must be a known built-in tool (Read/Write/Edit/Bash/Grep/Glob/WebSearch/WebFetch/ NotebookEdit/TodoWrite/Task/Skill) or an MCP tool (mcp__server__tool). Omit to inherit all tools. Verified at compile time.