Skills
File, source, and policy management skills — plus the one package-authoring skill.
brain-core ships nine skills under its skills/ folder, following the
standard skill contract: a directory per skill
with a SKILL.md and, for the management bundles, scripts/ that call the
package's HTTP routes with the per-stream session ticket. Most skills declare
requiredFeatures frontmatter, so a caller who lacks the grant never sees the
skill at all — it is not advertised, listed, or injectable.
The catalog splits into three groups: management bundles that wrap the HTTP surface, operational workflows for everyday filesystem work, and the package-authoring skill.
Management bundles
These wrap slices of the brain-core route surface for bulk and administrative operations that would be tedious as individual tool calls.
| Skill | Requires | Surface |
|---|---|---|
manage-sources | drive.read | Source CRUD plus the sync lifecycle: list, get, create, update, delete, kind catalog and schemas, browse, discoverable roots, sync, sync status, cancel, reset, reindex, a scoped re-embed with the active model (a source, folder or file — the estimate by default, started only on an explicit confirm), enable/disable. 16 scripts. drive.read is the skill's advertise floor; the mutating scripts escalate to drive.mount, the sync scripts to drive.sync, and browse.sh / discoverable.sh to drive.mount as well. |
manage-files | drive.write | Bulk file operations: list, search, read, raw bytes, create, modify, mkdir, copy, upload, approve, and the pending-change queue. Complementary to the fs_* tools, which remain primary for one-off calls. 11 scripts. |
manage-uri-policy | drive.policy | Read manifest baselines, read the effective merged policy, and patch per-source path rules. 3 scripts. See URI policies. |
git | drive.read | Drive git on a git-backed source through the governed git routes — status/branch/diff/log/log-stats/show/commit/outgoing/repos, stage/unstage/discard, commit, branch/checkout, restore, and fetch/pull/push to a connected remote — the same routes the Git Control panel uses (write and remote ops are gated server-side by drive.write + the source's exec policy). One generic git.sh helper, plus guidance on the raw-shell and external-GitHub-MCP git planes. Because git routes only act on an already-attached source there is no throwaway repo, so the skill's write examples carry point-of-use consequence warnings — push publishes to the user's real remote and is irreversible. |
manage-uri-policy is deliberately gated by its own feature (drive.policy):
it carries no grant below the admin tier — admin holds it through its
enumerated default grant and owner through the '*' wildcard — and the grant
can be extended to any custom role without touching code — see
roles and features.
Operational skills
Day-to-day workflows over the fs_* tool family:
| Skill | Requires | What it does |
|---|---|---|
brain-start | drive.read | Assess the workspace — tree view plus broad searches — and propose concrete next steps; accepts an optional goal and path focus. |
connect-business-data | drive.read | Decide how to bring external business data (analytics, marketing/campaign exports, financial reports, CRM) into a fresh project — attach-as-source, build-a-connector, or wrap-as-package — so it becomes indexed, fs_search-able brain knowledge the agents can act on. |
sync | drive.sync | Trigger delta sync across configured sources. |
organize | drive.write | Analyze workspace structure, find duplicates, propose and apply reorganization. |
The package-authoring skill
Package authoring is one skill, create-package. It covers every way a
package reaches the platform — an installed node package, a project
_packages/ drop built into the WASM sandbox, and a plain markdown package
discovered in a synced source with no install step at all — and it ends at a
proof gate: a package is finished when it loaded and a tool, widget, or
skill of it ran, not when the files exist.
It is not feature-gated and not manual-only. Any caller sees it in their package overview, and the model may activate it from a plain request ("teach the agent how we do releases", "give it a button for this", "connect our CRM", "why did my package not load"). Discovery happens through the skill's description, so it fires on the outcome the user describes, not only on the word "package".
SKILL.md is a router — the decision rule, the three reach paths, a trigger
table, and the done gate — and dispatches into nine references, each mapped to
one task shape and to the matching page of this documentation:
| Reference | Covers | Documentation |
|---|---|---|
skills-and-context.md | SKILL.md frontmatter, rules, instructions, agents, docs, and what actually reaches the prompt | Skills, Contributions |
manifest-and-discovery.md | The package.json#neuralis block and what the loader scans | Manifest, Directory contract |
tools-and-schemas.md | Strict JSON Schema tools and the x-neuralis extension | Tools |
runtime-and-build.md | Lifecycle exports, routes, trust-tier dispatch limits, hooks and commands, the WASM build | Lifecycle, Routes, WASM build |
surfaces-and-design.md | Widgets, dock entries, cards, renderers, and the design rules | App surfaces |
connectors-and-uri-policies.md | Source connectors, MCP/HTTP connectors, declared sources, path protection | Connectors, URI policies |
config-and-credentials.md | Declared platform config keys and declared credential ids | Configuration, Credentials |
team-and-workflows.md | Team members with identity files, and shipped workflow templates | Agents, Workflows |
test-and-ship.md | The test harness, load verification, and publishing | Testing, Marketplace |
Two bundled scripts back the done gate: a static pre-flight that checks a
package tree without a running server, and a runtime check that reads the
package's load status (loaded, partial, error, or missing) from the
platform.
The complete worked examples — one per install class — are the contract examples.
What packages.author still gates
The skill is open, the capabilities are not. packages.author (manager
and above by default) gates the package-authoring UI affordances and the
install, build, and rescan routes; writing package files needs drive.write;
reading the platform's package diagnostics needs core.observe. A caller
without them can read the whole authoring contract and will be denied at the
write, the build, or the diagnostics call — which is the point: the agent can
name exactly which capability is missing instead of guessing. See
roles and features.
Why authoring lives in brain-core
Package authoring is filesystem work: scaffolding writes through
packages://, validation reads manifests and schemas from disk, and builds
run against the project package directory. The authoring skill sits next to
the tools it orchestrates.
Other contributions
Beyond skills, brain-core contributes a rules file, a model-guidance
instruction, and a drive-overview document that teach every agent URI identity,
connector-first read behavior, search freshness, and recovery via revert. It
also ships one team member — Coder, a software-engineering agent template
that works directly in connected codebases, extends existing owners, and
verifies changes where they run — with its own identity files, plus the Sources
digest workflow template. How these reach the system prompt is described in
contributions.
brain-core contributes no subagents. The platform's universal roles ship from
agent-core — see agent-core agents — and the package
contract its old authoring subagents encoded now lives in the create-package
skill above, which any of them can activate.