Agentfactory

/agentfactory

Create one governed Hermes agent for:

$ARGUMENTS

A Hermes agent is not a generic prompt. It is a purpose-built, self-contained autonomous operating unit with identity, scope, capabilities, memory, verification, deployment, handoff, audit trail, and a tested kill switch.

Hermes agents may be used as single workflow executors, department-specific assistants, or a coordinated enterprise operating layer. Even in a whole-company system, each Hermes agent must keep a narrow ownership boundary and escalate across boundaries instead of silently expanding authority.

Non-Negotiable Contract

• Follow the phase sequence exactly: taste gate -> intent intake -> deep research -> manifest draft -> capability stack -> HERMES-{SLUG}-SPEC.md -> file generation -> introspect -> verify -> closeout and registry.
• Start every new Hermes agent with zero permissions. Add only the tools, MCP scopes, APIs, files, and workflows proven necessary by research and the manifest.
• Do not create or deploy an agent whose purpose conflicts with taste.md, taste.vision, or hermes-factory.taste.md.
• Do not generate agent files before writing HERMES-{SLUG}-SPEC.md.
• Do not mark an agent production-ready until the kill switch has executable test evidence.
• Do not accept contradictory memory seeds. Resolve or remove contradictions before file generation so every Hermes agent remains memory-coherent.
• Do not claim independent verification unless the verifier metadata proves a separate agent, process, model, workspace, or explicitly isolated same-session pass.
• Keep all output reproducible: the same intent answers and repo evidence must produce a functionally equivalent Hermes agent.
• Treat revcli or any other business runtime as the control plane when it already owns authorization, approval, audit, or system-of-record writes. Hermes agents call the runtime's governed actions instead of bypassing it.
• Treat runtime compatibility as a machine contract, not prose. Every Hermes agent must include hermes.runtime.json with parseable invocation, authority, approval, audit, kill-switch, and fixture evidence fields.
• Treat runtime capacity as a machine contract, not optimism. Every Hermes agent or fleet must include development_host_profile, target_runtime_profile, host_capacity_profile, capacity_binding, concurrency_budget, maximum parallel runs, queue/backpressure behavior, and degrade_policy; never assume the developer machine and production host have the same specs, and never assume either can run every Hermes agent at once.
• Any command capability must pin cwd, allowed argv shape, allowed config paths, env allowlist, max input size, input schema, denied flags, and expected exit/status behavior.
• Do not mark an enterprise or REVCLI-facing agent active when verification_status is operator_exception, when runtime evidence is missing, or when read-write/destructive authority is paired with exception-based verification.
• Keep .minimaxing/state/CURRENT.md updated enough that a /compact can resume without losing the active phase, open questions, generated paths, or verification status.

Quality Constraints

| ID | Constraint | Factory Enforcement | |----|------------|---------------------| | C1 | Reproducible | Kernel questions, manifest schema, spec, and file formats are deterministic. | | C2 | Auditable | Every capability grant has a manifest justification and verification evidence. | | C3 | Malleable | Operators may override defaults, but every override is recorded in the manifest and spec. | | C4 | Least privilege | Agents start with zero permissions; each permission is explicitly granted. | | C5 | Killable | The kill switch must be documented, executable, and tested before production status. | | C6 | Memory-coherent | Memory seeds require contradiction checks across semantic, procedural, error-solution, episodic, and causal graph tiers. | | C7 | Taste-aligned | The purpose must pass project taste and factory taste gates. | | C8 | Compaction-safe | Current phase, decisions, pending gates, and paths are recorded in .minimaxing/state/CURRENT.md or a workflow artifact before risky transitions. | | C9 | Failure-cataloged | Agent Factory ships with a failure-mode catalog and seeds relevant error-solution entries for each agent. | | C10 | Zero-trust verification | Readiness is decided by verification evidence, not executor confidence. | | C11 | Runtime-bound | Production readiness requires a parseable runtime contract and executable runtime evidence. | | C12 | Side-effect-safe | Side effects require argument constraints, approval gates, audit events, and rollback or compensation proof. | | C13 | Capacity-aware | Development host capacity, target runtime capacity, concurrency budget, queue behavior, and degradation policy must be declared and verified before production readiness. |

Agent Factory Workflow Artifact

Agent Factory is a workflow on its own, not a template generator. Every invocation must create and maintain a durable artifact before the Hermes manifest or spec is accepted:

mkdir -p .taste/workflow-runs
STAMP="$(date +%Y%m%d-%H%M%S)"
AGENT_FACTORY_ARTIFACT=".taste/workflow-runs/${STAMP}-agentfactory.md"

OpusWorkflow Inheritance

For mutating AgentFactory work, /opusworkflow is the default outer route and /agentfactory is the inner contract. Direct /agentfactory invocation remains valid, but it must inherit the same Claude/Opus planner-reviewer plus MiniMax-M2.7-highspeed executor policy before files change.

outer_route: opusworkflow
inner_contract: agentfactory

Required section order:

# Agent Factory Run: {agent intent}

## Task
## Taste Gate
## Intent Intake
## Deep Research Brief
## Source Ledger
## Runtime Audit
## Capacity-Aware Runtime
## Manifest Draft
## Capability Stack
## Research Sufficiency Introspection
## Hermes SPEC Decision
## File Generation Notes
## Readiness Introspection
## Independent Verification Evidence
## Registry And Memory Closeout
## Outcome

Required behavior:

• ## Deep Research Brief must follow the same effectiveness-first shape as /workflow: collaborative research plan, search -> read -> refine loop, source ledger, contradiction handling, and follow-up research before freezing the manifest.
• ## Source Ledger must separate cited sources, reviewed-but-not-cited sources, and rejected/downweighted sources.
• ## Runtime Audit must name the target runtime's auth, approval, audit, state, irreversible actions, and kill switch surfaces.
• ## Capacity-Aware Runtime must record both the development host profile and the target runtime profile. Use bash scripts/parallel-capacity.sh --json only for the development host or for a truly local target runtime. When the agent will run on a cloud server, container host, VPS, CI runner, managed queue, or another fleet runtime, record target runtime evidence from infrastructure config, provider limits, runtime telemetry, deployment docs, or an explicit operator-provided capacity contract. Concurrency budgets derive from the target runtime, not the dev PC, unless capacity_binding.target_equals_development_host is true.
• ## Independent Verification Evidence must record executor/verifier metadata and never overclaim isolation.
• ## Outcome must state whether the agent is draft, experimental, active, paused, or blocked.

Compaction Safety

Claude Code re-attaches only a bounded slice of invoked skill content after compaction. Treat this skill as compaction-sensitive:

• Before leaving any phase, write the current phase, pending gate, generated paths, source ledger status, and unresolved risks into AGENT_FACTORY_ARTIFACT.
• If resuming after /compact, /resume, or a stale CURRENT.md, re-read .claude/skills/agentfactory/SKILL.md, AGENT_FACTORY_ARTIFACT, SPEC.md, and hermes-registry.md before continuing.
• Never rely on memory of the skill body alone after compaction. Reload the file from disk when any later phase depends on the manifest schema, generated file formats, or verification requirements.

Phase 0: Taste Gate

1. Read taste.md and taste.vision.
2. Read hermes-factory.taste.md. If it does not exist, create it before continuing with these required sections:

• principles: least privilege, auditability, reproducibility, killability, bounded autonomy
• enterprise_operating_model: Hermes agents are workflow-bounded operating units that may compose into department or company systems
• non_goals: no omnipotent agent, no hidden credentials, no unmanaged business writes, no unverified production readiness
• approval_philosophy: destructive, external, financial, legal, credential, or customer-visible actions require explicit approval unless the manifest proves bounded policy authorization

1. Check whether the proposed agent purpose aligns with taste.md, taste.vision, and hermes-factory.taste.md.
2. Record a taste decision:

• PASS: proceed
• NEEDS_ALIGNMENT: ask focused questions or update taste with explicit operator approval
• BLOCKED: stop because the purpose contradicts taste

1. Update the workflow artifact with taste evidence and the decision.

Hard gate: BLOCKED stops the factory. Do not continue to intent intake.

Phase 1: Hermes Intent Intake

Ask these 12 kernel questions verbatim before any research, planning, or agent file generation:

1. What is this Hermes agent's exact purpose in one sentence, with no weasel words?
2. What is the hard scope boundary: what will this agent NEVER do?
3. What decision authority level does it have: read-only, read-write, or destructive-allowed?
4. What escalation trigger makes it stop and ask a human?
5. What success metric will prove in 30 days that it is working?
6. What failure mode describes what a bad version of this agent looks like?
7. What target runtime environment will run it?
8. What memory must be pre-seeded before the first run?
9. What tools, MCP servers, APIs, files, and workflows is it explicitly authorized to use?
10. Who is the operator and accountability owner?
11. What deployment lifecycle does it use: ephemeral, persistent, or scheduled?
12. What is the kill switch, and how is it tested?

Rules:

• If any answer is missing, mark intake INCOMPLETE.
• If tool authorization says "whatever it needs", reject it and request an explicit list.
• If decision authority is destructive-allowed, require a separate approval policy and rollback proof.
• If the kill switch cannot be tested, the agent cannot be production-ready.

Phase 2: Deep Research

Research before designing the Hermes agent. Use the smallest effective research budget that resolves material unknowns.

Required research branches:

| Branch | Required Evidence | |--------|-------------------| | Repo overlap | Existing agents, workflows, scripts, policies, profiles, skills, or runtime modules that overlap the intended purpose. | | Runtime integration | How the target runtime invokes actions, stores state, handles auth, logs audit events, and applies approval policy. | | Development host capacity | Local CPU/RAM class, configured MAX_PARALLEL_AGENTS, Codex max_threads, and local verification ceiling from scripts/parallel-capacity.sh or equivalent. | | Target runtime capacity | Cloud/server/VPS/container/CI/managed-runtime CPU/RAM class, provider limits, autoscaling behavior, production concurrency limit, queue/backpressure behavior, maximum parallel runs, and degrade policy. | | Runtime authority chain | Which system owns policy, which system owns durable state, which system is the system of record, and which writes are forbidden bypasses. | | Approval and side-effect matrix | Every external, customer-visible, financial, legal, destructive, credential, workflow-state, or system-of-record action and its approval gate. | | Identity and credentials | Runtime principal, auth mode, credential owner, vault/provider, env var names, expiry, rotation, revocation, and secret redaction. | | Observability and evidence | Trace IDs, audit event schema, runtime evidence path, retention, redaction, and replay/recovery surfaces. | | Failure modes | Relevant existing error-solution memories plus newly identified failure modes for this agent category. | | External best practices | Current official docs or primary sources for agent guardrails, MCP, auth, approvals, observability, and deployment patterns when the design depends on them. | | Taste contradictions | Any mismatch between intended behavior and taste.md, taste.vision, or hermes-factory.taste.md. |

Research output must include:

• collaborative research plan
• iterative search -> read -> refine loop log
• effective research budget and why it was not inflated
• source ledger with cited, reviewed-but-not-cited, and rejected/downweighted sources
• repo evidence with file paths and line references when available
• contradictions and how they were resolved
• implications for manifest, capabilities, memory seed, verification, deployment, and kill switch
• follow-up research performed or an explicit reason it was not needed

Research sufficiency gate:

• PASS: evidence is enough to draft the manifest.
• FIX_REQUIRED: run another research loop before design.
• REPLAN_REQUIRED: the intended agent should be split, narrowed, or blocked.
• BLOCKED: unresolved runtime, auth, approval, data, legal, or destructive-action ambiguity prevents safe design.

Hard gate: unresolved auth, approval, destructive action, or system-of-record ambiguity blocks manifest drafting.

REVCLI Readiness Overlay

Apply this overlay whenever target_runtime includes revcli, revis, odoo, a CRM, a sales workflow, or any customer/company operating workflow. If any required item cannot be proven from repo evidence or operator intake, return BLOCKED or REPLAN_REQUIRED.

| Requirement | Contract | |-------------|----------| | Role-scoped profile | Declare exactly one primary REVCLI role or narrowly justified extension: signal-ingestor, opening-seller, qualified-seller, manager-approver, owner-auditor, or delivery-owner. | | REVCLI policy authority | Hermes may interact, draft, classify, call bounded tools, or prepare handoffs, but workflow state transitions must go through REVCLI/Revis policy surfaces. | | System-of-record boundary | Odoo, CRM, or Postgres writes must be mediated by REVCLI domain service, runtime API, MCP bridge, or approved adapter; direct unmanaged writes are forbidden. | | Correlation fields | Every material run must carry agent_profile_id, agent_session_id, agent_run_id, trace_id, workflow_run_id, approval_id when applicable, opportunity_id or target object ID, actor_id, and audit event hash when the runtime supports it. | | Auth mode | Declare seat-attached for human-attended sessions or fleet-commercial for unattended/service agents. Consumer subscription/session credentials are forbidden for shared autonomous fleets. | | Approval gate map | First outbound touch, proposal send, close won/lost, owner reassignment, pricing/redline, evidence export, profile suspension, production workflow execution, and external side effects must map to explicit approval gates. | | Tool and egress allowlist | Tools, MCP servers, APIs, commands, domains, and network destinations start denied and are allowlisted per workflow/profile. | | Trace and audit evidence | The runtime contract must name the audit sink and prove redacted runtime events, tool calls, approvals, business-object mutations, and evidence exports are recorded. | | Kill-switch compatibility | Generated agents must honor tenant, workflow, profile, provider, queue, credential, and sandbox/network kill switches where the runtime exposes them. | | Closed-loop terminal state | Sales/prospecting agents must route work to closed-won, closed-lost, nurture-active, or archived, never open-ended

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: waitdeadai
• Source: waitdeadai/minmaxing
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.