Skip to main content

Extensions

Phonton extensions are local .phonton records that change how the ADE loop is planned, guided, verified, or tooled. They are not hidden hosted plugins. They are files a developer can inspect before running a task.

An extension pack can include four local record types:

Skill: .phonton/skills/<id>/skill.toml plus SKILL.md

Adds text-first task guidance.

Steering: .phonton/steering.toml

Adds persistent project or user rules.

MCP server: .phonton/mcp.toml or .phonton/mcp.d/*.toml

Declares external tools and requested permissions.

Profile: .phonton/profiles.toml

Activates a bundle of extension records.

Inspect the active set:

phonton extensions list
phonton extensions doctor
phonton extensions skills --json
phonton extensions steering --json
phonton extensions mcp --json
phonton extensions profiles --json

These commands are read-only. They do not start MCP servers and do not execute skills.

MCP capability preview

Use MCP commands when you want runtime evidence from a configured server:

phonton mcp list
phonton mcp capabilities github --yes
phonton mcp capabilities github --json --yes

Capability preview captures initialize metadata, tool descriptors, protocol version, and proposed permission rules. It does not call tools, write config, or grant permissions silently.

Where extensions live

Phonton loads extension files from two places:

ScopeDirectoryPrecedence
User~/.phonton10
Workspace<repo>/.phonton20

Workspace records override user records with the same id. Safety cannot be weakened by precedence; a higher-precedence record still has to declare its trust and permissions honestly.

Inspect first

The public extensions page documents the real CLI feature: local skills, steering, MCP server manifests, profiles, and capability preview commands.

Use the page and the CLI as review surfaces:

phonton extensions list --json
phonton extensions doctor
phonton mcp list
phonton mcp capabilities context7 --yes

First-party public extensions should follow one repo per extension, with one auditable .phonton pack and clear configuration instructions. Third-party MCPs should be treated as capability requests until source, environment variables, and approval behavior are understood.