Neural Inverse Govern / Skills and harness packs
Agent know-how, reviewed before it ships and signed when it does.
A registry of skills, rules, commands and subagents with scanning and separated review, and signed, layered harness packs rolled out by experiment behind an eval gate.
- Assets
- Skills, rules, commands, subagents
- Review
- Separated, up to three approvals
- Signing
- Ed25519 manifests and packs
- Rollout
- A/B experiments, eval-gated
- Usage data
- Identifiers and counts only
Overview
Skills and harness packs are how an organisation shares what its AI agents should know and how they should work. The skills registry holds skills, rules, slash commands and subagents in the formats Claude Code, Codex and the Neural Inverse engine already read, and adds scanning, review, versioning and assignment. Harness packs layer a company's instructions, skills, tools, model routing and evals on top of a starter for each engine. Govern signs every published version, decides which version each person receives, and gates new pack versions on evals. Packs are not policy: agent policy is evaluated separately and always wins.
What it does
What skills and harness packs cover.
Authoring, review, delivery, rollout and measurement of what agents are given to work with.
Four asset typesSkills in the Agent Skills folder format, and rules, slash commands and subagents as Markdown with front matter. Organisation assets are shared; personal assets reach only their owner.
Safe bundlesUploads are checked for links, path tricks, case collisions and size before anything is stored, then kept as a canonical archive identified by its SHA-256, in the database, so the registry works air-gapped.
ScanningOn upload and on submission: secrets and sensitive data with your DLP patterns, hidden instructions such as invisible Unicode and override phrasing, executable code, and files that are not what they claim. Blocking findings refuse the submission.
Separated reviewReviewers hold review rights and did not write or submit the version. One to three approvals are required, more for versions with executable code, and high findings must be acknowledged explicitly.
VersionsSemantic versions with a changelog and diff. Published versions never change; deprecate one to discourage it, or yank it for safety so it is never delivered again and clients remove it.
AssignmentsAssign an asset to the organisation, a team or a project as default, required or blocked, following the latest version or pinned to one. A blocked name blocks every asset of that name, personal ones included.
Signed deliveryEach person receives an Ed25519-signed manifest of their effective assets for a project and engine, with blocked names, exclusions and yanked versions, valid offline for a period you set.
Personal choicesPeople may remove a default asset and install any published organisation asset nothing assigns. They cannot remove a required one.
Usage and adoptionInstall, uninstall and use events per asset, metadata only, with how many people still have a yanked version installed.
Layered harness packsNeural Inverse starters for Claude Code, Codex and the Neural Inverse engine, sector packs on top, then your company layer. A layer can lock fields so no lower layer changes them.
Signed pack versionsEvery published pack version is validated and signed. Secrets are vault references only, and any field named like a credential is refused. Published versions never change.
Pack assignmentAssign a pack version per engine to the organisation, a team or a repository. The most specific assignment wins, and a newer parent changes nothing until you assign again.
Eval promotion gateA sector or company version can be assigned, tested or promoted only after a passing eval run on the target engine, recorded by a dedicated eval runner key that no role or ordinary API key holds.
Experiments and staged rolloutRun a candidate version against the current one in sticky buckets per person or project. Raise the rollout step by step, then promote, roll back or stop.
Outcome metricsPer version: sessions, suggestions kept, edited and discarded, tasks completed, duration, tokens and cost. Results compare arms only once both reach the minimum sample.
Skills in packsA pack can reference registry assets by type, name and version range, resolved against your registry, so packs and the registry share one reviewed copy.
Required and blocked assets are applied by the client that installs them. What an agent may actually do is decided by agent policy and Govern's gateways, which no skill or pack can weaken.
How it works
From an uploaded skill to a promoted pack.
- UploadUpload a bundle as a draft version of a skill, rule, command or subagent.
- ScanSubmission scans for secrets, hidden instructions and executable code.
- ReviewReviewers who did not write it approve or reject the version.
- PublishThe approved version becomes immutable and part of signed manifests.
- EvaluateA pack version that uses it passes its evals on the target engine.
- Roll outAn experiment raises the new pack step by step, then promotes it or rolls it back.
Who uses it
Built for every role that answers for AI.
Platform and developer experience teamsPublish harness packs, assign them per engine, and run experiments and rollouts.
Skill authorsUpload and version skills, rules, commands and subagents, and submit them for review.
ReviewersApprove or reject versions they did not write, acknowledging high findings, with stricter review for executable code.
EngineersReceive what is assigned to them, remove what is optional, and install published organisation assets.
Enforced and recorded
What Govern guarantees about what agents receive.
Govern decides and signs what each person receives. Nothing reaches a manifest without review, and nothing signed can be altered.
Enforced
Fails closedNo signing key, no manifest. A scan that cannot run means no submission.
No self-reviewThe author or submitter of a version can never approve it.
Locked layersA lower pack layer that sets a locked field is refused at publish and again at assignment.
Eval gateA version without a passing eval run cannot be assigned, tested or promoted. An override is reserved to a super administrator and audited.
Signed and expiringManifests carry a signed validity window, so one captured before a block or a yank stops verifying when the window ends.
Recorded
Registry changesEvery upload, submission, review, publish, deprecation, yank, assignment and setting change, in the change's own transaction.
Pack changesPacks, versions, assignments, experiments, eval runs and runner keys, in the change's own transaction.
UsageIdentifiers, counts and outcomes only; no code, prompt or completion is stored.
Self-hosted and in your cloudYour operator configures the signing key; the public keys are served by your own installation.
Air-gappedBundles are stored in the database, so the registry needs no object store or outside access.
Offline machinesSigned manifests stay valid for the grace period you set; required items and blocked names stay in force.
Hosted by usWe run it for you. Custom packs and experiments depend on the plan; a self-hosted installation includes everything.
Get started
Set it up with the documentation.
Talk to our team.
Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation.