Hermes Engineering Profiles
Three independent Hermes specialists for DevSecOps, AI Engineering and Software Engineering, built from a versioned skill catalog with explicit contracts and qualification limits.
- Domains
- AI
- DevSecOps
- Platform
- Technologies
- Hermes Agent
- Python
- YAML
Overview
Three independent specialists on one versioned base: ai-devsecops-engineer, ai-engineer and software-engineer. Each profile is a native Hermes distribution with its own distribution.yaml, config.yaml and SOUL.md.
The public MIT-licensed repository contains 24 canonical skills: 22 technical skills and two shared skills. The profiles carry 8, 8 and 12 skills respectively, including generated shared copies. The documented Hermes baseline is v0.22.5.
Problem
A reusable engineering profile needs more than a role prompt. It needs an explicit scope, contextual instructions, repeatable installation and a way to detect drift as shared capabilities evolve.
This project keeps the reusable base independent of a particular client, account, cloud, model or framework. Project-specific context and authorized access are supplied when creating an instance.
Three specialists, explicit scopes
ai-devsecops-engineer covers infrastructure changes, IAM and secrets, Kubernetes and GitOps, incident response and software supply-chain work.
ai-engineer covers agents, model routing, retrieval and memory, evaluation and LLMOps.
software-engineer covers full-stack applications and SaaS, API contracts, quality and release workflows.
One source, three distributions
catalog.json is the canonical inventory. The two shared capabilities, agent-folder-architect and project-context-architect, are authored once in shared-skills/ and generated into all three profiles.
The build checks integrity without writing by default; regeneration requires --write. The validator fails closed on invalid contracts or generated-copy drift. Technical skills are maintained in their owning profile.
Installation and adaptation
Clone the repository to a stable path, choose a directory under profiles/, and install it as a named instance with the native Hermes profile installer. The monorepository root is not itself an installable distribution.
For example: hermes profile install ./profiles/software-engineer --name software-lab. Then use hermes -p software-lab setup to configure authorized providers and access, and hermes -p software-lab chat to start the instance.
Provider, model, credentials and runtime state are not shipped in the source. The installation guide documents the prerequisites and update workflow.
Qualification: evidence and limits
The qualification report dated 2026-11-01 records LOCAL_PASS_NATIVE_BLOCKED on Linux, x86_64 and Python 3.13.5. It reports 96 repository tests and 10 original architect tests passing with synthetic fixtures, plus static validation and shared-integrity checks.
Native installation remains BLOCKED in that report because Hermes CLI was unavailable. The 78 behavioral evaluation cases are written but NOT_RUN, with zero model calls. Corpus validation checks structure and rubrics; it does not measure model competence.
Provider, MCP, cloud, IAM, database and production integrations were not exercised. These results describe repository contracts and helpers, not production readiness or guaranteed model behavior.
Security and trade-offs
The configuration declares manual approvals, but a profile is not an operating-system sandbox. Skills guide model behavior without guaranteeing perfect compliance. Authorized runtime access still needs to be configured and governed separately.
Generating shared copies reduces manual duplication while making source ownership explicit. It also requires the build and validator to stay in the maintenance workflow.
This is an independent project built on Hermes, not an official Nous Research release. The linked security documentation, qualification report and known limits define the current scope.