Change skills
These are the operations the Admin Assistant uses to modify your workspace. They only run when the Allow changes toggle is on, and they split into three stages that map to the workflow: propose (stage a change), apply (commit an approved change), and test (verify a saved change).
The key boundary: proposing stages a change in memory and validates it; nothing reaches your workspace until you approve a specific proposal and the Operator applies it.
Propose — staging a change
Each propose-* tool takes a draft, renders it into the exact export format the workspace-definitions zip uses, computes the "before" from the live configuration with the same exporter, and then validates it:
- round-trips the code through the same parser the workspace uses to load it;
- compiles code bodies against the matching execution scope and returns line/column diagnostics on failure;
- runs the secret deny-list over the change;
- flags policy regressions (for example, widening an access mode) as blocking concerns.
A proposal that fails validation is never marked ready to approve. Nothing is written to the workspace at this stage — a proposal is a reviewed before/after diff waiting for your approval.
Code surfaces
| Tool | Proposes a change to |
|---|---|
propose-endpoint |
A code endpoint. |
propose-tool |
An AI tool. |
propose-agent |
An agent. |
propose-skill |
A reusable agent skill. |
propose-prompt-template |
An AI prompt template. |
propose-code-task |
A custom-code scheduled task. |
propose-data-connector |
A data-connector scheduled task. |
propose-migration |
A migration task. |
propose-entity-post-processing |
An entity post-processing script. |
propose-shell-script |
A shell-script task. |
Schema
| Tool | Proposes a change to |
|---|---|
propose-schema-node |
A node type. |
propose-schema-edge |
An edge type. |
propose-schema-renderer |
A node renderer. |
propose-schema-style |
A node style. |
Indexes, NLP, and search
| Tool | Proposes a change to |
|---|---|
propose-index |
A graph index. |
propose-code-index |
A custom-code index. |
propose-search-code-index |
A custom-code search index. |
propose-nlp-spotter-from-node |
A node-derived NLP spotter. |
propose-nlp-pattern-spotter |
An NLP pattern spotter. |
propose-nlp-pipeline |
An NLP pipeline. |
propose-nlp-linking |
An entity-to-node linking configuration. |
propose-search-settings |
Search settings. |
propose-search-facets |
Search facets. |
propose-search-synonyms |
Search synonyms. |
propose-search-replacement |
A forced search replacement pattern. |
Settings and access
| Tool | Proposes a change to |
|---|---|
propose-ui-settings |
Front-end UI settings. |
propose-embedding-settings |
Embedding / model preferences. |
propose-ai-provider |
An AI provider configuration. |
propose-access-group |
An access group. |
propose-access-grant |
An access grant. |
Managing proposals
The assistant can also reshape its own set of staged proposals before you approve them: list the pending proposals, read one proposal's full before/after diff, and discard a proposal it has decided to abandon. These act only on staged proposals in the current session, not on the workspace.
Apply — committing an approved change
Applying is the only stage that writes to your workspace, and only the Operator agent can do it. It re-runs the Reviewer's static checks as a final guard, consumes a one-time approval token tied to the exact diff you saw, and wraps the write in the workspace's configuration-tracking pipeline so each applied change is a single git commit.
| Tool | What it does |
|---|---|
apply-proposal |
Applies one approved proposal. |
apply-batch |
Applies a set of approved proposals together (respecting their dependencies). |
rollback-last |
Reverts the most recent applied change. |
Approval is per-diff
The approval token is bound to the exact "after" content you reviewed. If the proposal changes after you approve it, the token no longer matches and the apply is refused — you are re-prompted with the new diff. Changes that widen an access mode cannot be batch-approved; they require explicit per-step approval.
Test — verifying a saved change
After a change is applied, the Verifier runs test-* tools against the saved configuration to confirm it behaves as intended. These tools do not modify configuration; they execute the saved artefact (so they may have the same side effects running it normally would) and report the result. On failure, the assistant can escalate to rollback-last.
| Tool | What it verifies |
|---|---|
test-endpoint |
Runs a saved endpoint. |
test-tool |
Runs a saved AI tool. |
test-agent-run |
Runs a saved agent end-to-end. |
test-code-task |
Runs a saved scheduled task. |
test-index-materialize |
Materializes a saved custom index. |
test-search |
Runs a search against the current configuration. |
test-spotter |
Runs a saved NLP spotter over sample text. |
Verification runs against saved artefacts
Tests target already-saved configuration by its identifier, not the in-memory proposal. The workflow is: Operator applies → Verifier tests the saved item → on failure, roll back. This is why the assistant applies first and verifies second.
Next steps
- Read-only skills — the inspection tools that run before any change.
- Examples — end-to-end tasks that exercise propose, apply, and verify.