# Skills and harness packs · Neural Inverse Govern > 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. Source: https://neuralinverse.com/govern/skills-harness/ --- ![](/photos/team.jpg) [Neural Inverse Govern / Skills and harness packs](https://neuralinverse.com/govern/) # 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 ↓](https://neuralinverse.com/#capabilities)[How it works ↓](https://neuralinverse.com/#workflow)[Enforced and recorded ↓](https://neuralinverse.com/#enforcement)[Where it runs ↓](https://neuralinverse.com/#where)[Get started ↓](https://neuralinverse.com/#get-started) 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 types:** Skills 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 bundles:** Uploads 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. - **Scanning:** On 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 review:** Reviewers 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. - **Versions:** Semantic 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. - **Assignments:** Assign 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 delivery:** Each 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 choices:** People may remove a default asset and install any published organisation asset nothing assigns. They cannot remove a required one. - **Usage and adoption:** Install, uninstall and use events per asset, metadata only, with how many people still have a yanked version installed. - **Layered harness packs:** Neural 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 versions:** Every 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 assignment:** Assign 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 gate:** A 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 rollout:** Run 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 metrics:** Per 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 packs:** A 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. 1. Upload Upload a bundle as a draft version of a skill, rule, command or subagent. 2. Scan Submission scans for secrets, hidden instructions and executable code. 3. Review Reviewers who did not write it approve or reject the version. 4. Publish The approved version becomes immutable and part of signed manifests. 5. Evaluate A pack version that uses it passes its evals on the target engine. 6. Roll out An 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 teams:** Publish harness packs, assign them per engine, and run experiments and rollouts. - **Skill authors:** Upload and version skills, rules, commands and subagents, and submit them for review. - **Reviewers:** Approve or reject versions they did not write, acknowledging high findings, with stricter review for executable code. - **Engineers:** Receive 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 closed:** No signing key, no manifest. A scan that cannot run means no submission. - **No self-review:** The author or submitter of a version can never approve it. - **Locked layers:** A lower pack layer that sets a locked field is refused at publish and again at assignment. - **Eval gate:** A version without a passing eval run cannot be assigned, tested or promoted. An override is reserved to a super administrator and audited. - **Signed and expiring:** Manifests carry a signed validity window, so one captured before a block or a yank stops verifying when the window ends. Recorded - **Registry changes:** Every upload, submission, review, publish, deprecation, yank, assignment and setting change, in the change's own transaction. - **Pack changes:** Packs, versions, assignments, experiments, eval runs and runner keys, in the change's own transaction. - **Usage:** Identifiers, counts and outcomes only; no code, prompt or completion is stored. Where it runs ## Wherever your engineers run agents. [Deployment options](https://neuralinverse.com/deployment/) - **Self-hosted and in your cloud:** Your operator configures the signing key; the public keys are served by your own installation. - **Air-gapped:** Bundles are stored in the database, so the registry needs no object store or outside access. - **Offline machines:** Signed manifests stay valid for the grace period you set; required items and blocked names stay in force. - **Hosted by us:** We 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. - [Harness packs](https://neuralinverse.com/docs/govern/harness-packs/) - [Agent policy](https://neuralinverse.com/docs/govern/agent-policy/) - [Agent instruction files](https://neuralinverse.com/docs/context/agent-files/) - [Roles and permissions](https://neuralinverse.com/docs/govern/roles/) Related [Agent policy and approvals → Allow, ask and deny rules for coding agents, with named approvers.](https://neuralinverse.com/govern/agent-policy/)[Context for agents → Governed, attributed context from your code, issues and team knowledge.](https://neuralinverse.com/govern/context/)[Models and prompts → The model catalog, who may use which model, versioned prompts and what AI use costs.](https://neuralinverse.com/govern/models/) ![](/photos/team.jpg) ## Talk to our team. Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation. [Request access](https://neuralinverse.com/contact/?topic=access)[Contact us](https://neuralinverse.com/contact/)