Skills

The skill surface

The host's skill catalog in v3 holds 17 skills. Each one is an assembler: one indexed entry that loads only the chapter (a file under its references/ folder) the request needs.

The other skill files still ship in the package (76 in total). They are off the host index, so the host never lists them. Specialist starter recipes live under skills/specialists/, and the dashboard launcher lives under skills/playbooks/dashboard/.

One of those off-index skills is guild-dashboard. It is an on-demand playbook, not a host-indexed skill. /guild:status dashboard launches the local benchmark web dashboard over this project's runs and knowledge. The old /guild:dashboard alias only prints that new spelling.

On Codex, the package exposes the skills under .agents/skills/guild/**.

The 17 skills

What this means for you

• A v2 skill name may now be a chapter. For example, verify-done is a chapter of guild-quality, and context-assemble is a chapter of guild-execute-plan. Ask for the behavior; the assembler loads the chapter.
• Most work starts from a command. Each phase command dispatches to exactly one assembler (see the command reference).
• The gates stay in the skills. Spec approval, the team decision, the QA release gate, and every wiki write sit inside the assembler that owns them.

Deeper: the chapter list per assembler is the references/ folder of that skill in the plugin repo at tag v3.0.0.

Maintain and evolve

/guild:maintain is self-maintenance. It has one entry and one assembler. Every sub-verb goes to the same skill, which routes the first token to its own chapter. An unknown sub-verb prints usage and stops.

Try it

/guild:maintain audit
/guild:maintain evolve <id> --target=skill
/guild:maintain rollback <skill> [n]

Sub-verbs

In the v3.0.0 skill, gc has no chapter yet. The assembler reports that and stops.

The eleven evolve targets

Every evolve names one target from a sealed set of eleven. The target decides the home, and the home decides what is written. A twelfth target is a code change, not a config key. If you omit --target, the assembler infers it.

Project targets write only this repo. They never touch the plugin install directory, and they refuse paths outside the repo root, including ../ and symlinks. Plugin targets write a candidate and stop. Nothing reaches src/, hooks/, skills/, commands/, agents/ or templates/. The result reports the candidate path and next_need: operator.

Two rules override the target you name:

• A delta that changes what is allowed (permissions, approval, allowed-tools) is proposal-only on every target, with or without --auto. The live file is unchanged. This is a heuristic, not a parser.
• The writer handles prose only. A .ts, .js, .sh or .json file is treated as machinery and becomes a candidate whatever target you named.

--auto

--auto runs unattended and is the cheap curator only: lint and a hash check, no model. It carries playbook and skill. Every other target fails closed with next_need: operator, before any candidate is queued. The replacement comes from a deterministic template, not from a model rewriting the file.

The pipeline and promotion gate

For a skill, evolve runs ten steps: snapshot, load evals, run the current skill (A) against the proposed one (B), write assertions, grade, build a flip report, replay history in shadow mode, apply the promotion gate, then promote or archive. The flip report and shadow report must come from the scripts, never by hand. A skill is never edited without passing the gate.

The gate promotes B if any one holds:

1. Zero regressions and at least one fix.
2. No flip change and total tokens down by at least 10%.
3. Regressions exist and you approve explicitly.
4. A doc-only edit, with your recorded approval.

The result is written to .guild/evolve/<run-id>/gate.json. Rejected attempts go to .guild/evolve/<run-id>/archived/. They are never deleted.

Each applied change is a guild.evolve_delta.v1: a replace, add or remove of a named heading span. It must carry a before_hash. A mismatch, a missing span, or an add onto an existing heading is refused.

Rollback

Every applied change records its inverse span and both hashes in compact history. rollback <skill> [n] restores them, newest first, default n is 1. Without --apply it only shows what it would restore.

Rollback restores the span, not the whole file, so later edits elsewhere are kept. A blocked step blocks everything older. After a restore, Guild Stack re-runs the target's eval suite and reports passed, drift_suspected or failed_unrelated.

Audit

audit is static. It reads hook scripts, tooling scripts and MCP servers (guild-memory, guild-telemetry) and runs none of them. For each it records a SHA-256, line count, declared allowed-tools, network evidence, and writes outside .guild/. That puts what a script declares next to what its source does. It also lists any specialist other than researcher that declares WebFetch or WebSearch. The report is .guild/audit/<YYYY-MM-DD>.md, and hash changes since the previous audit are shown as drift.

Fix, gc and wiki revert

fix loads the systematic-debug discipline.

wiki revert <harvest_id> replays the harvest journal's inverse for one harvest write. It restores the decision page (a page that did not exist is deleted), the playbook span, and the search index. It never touches git. Use wiki-revert.js --list --run <run-id> to find the id. It does not undo a skill change or a page you wrote by hand.