Concrete Skill Candidates per Role – First Evaluation Cycle

1. What this is

This brief presents the concrete Hermes‑skill candidates selected for each role in the first evaluation cycle, together with the architectural constraints and the fatal objections raised by Joker. It consolidates the research, architecture, and objection data already supplied by upstream tasks.

The goal is to define a runnable, ARM‑only, offline‑safe evaluation plan that can be executed on the free Oracle VPS (agents‑01) within the 2670 s worker timeout.

All surviving skills are MIT‑licensed, pure‑script (Python/JS) packages that install via hermes skills install <skill> without requiring privileged operations.

2. What would make it work

Strictly ARM‑compatible, offline‑only skill set – eliminates x86‑only binaries and external HTTP calls.
Verified MIT‑licensed skills with a concrete SKILL.md in the repository (e.g., hermes-agent-sec-review, github-workflow-ops).
Pre‑run migration that creates the D1 skill_lift table before any evaluation script runs.
Lightweight Bash driver (eval.sh) that clones the designated repo, runs baseline tests, installs the role’s skill(s), re‑runs the tests, and records lift metrics in D1.
All steps execute as the regular user on the ARM64 VPS (2 OCPU / 12 GB RAM) with no sudo or systemd usage.

3. What would kill it

Joker’s fatal objections – each paired with a concrete failure scenario – must be avoided entirely:

Unverified / inferred skills: Installing a non‑existent skill (e.g., task-synthesis) aborts the eval script.
Remote‑fetch / exfiltration: Skills that perform uncontrolled HTTP calls (e.g., anysearch, github-trending-spider) trigger a security‑audit failure.
Architecture mismatch – x86‑only binaries: Running an x86 binary such as vercel-optimize on the ARM box yields “exec format error” and aborts the install.
Privileged‑operation requirement: Any skill invoking sudo or systemd (hypothetical cyborg-ops-helper) cannot run.
Resource over‑commit: Skills bundling large ML models cause OOM on the 12 GB box.
License incompatibility: GPL‑v3 (or similar) licenses would force the whole fleet repo to be GPL, violating policy.
Missing D1 table / schema: Absence of skill_lift causes the final INSERT to fail, losing all lift data.
Non‑existent hermes skill sync command: Scripts that call this command abort.
One‑model‑request bottleneck: Any eval that exceeds the 2670 s terminal timeout kills the worker.
Missing deterministic correctness check: Without a pass/fail predicate the pipeline stalls for manual adjudication.

4. The stack and how it runs

Compute: All skill code runs on the free Oracle VPS agents-01 (ARM64, 2 OCPU, 12 GB RAM). No Docker, no sudo, no systemd.

Skill storage: Verified skills are installed into the profile’s ~/.hermes/skills/ directory via hermes skills install <skill>. This directory is the single source of truth.

Evaluation orchestration: A bash driver eval.sh in the workspace iterates over each role, clones the target repo (Shrikant’s the-pantheon for cycle 1), runs the baseline test suite, installs the role’s survivor skills, re‑runs the tests, and writes lift metrics into the D1 skill_lift table.

Batman’s objection handling: Batman’s earlier objection about the vercel-optimize x86 binary was resolved by removing that skill from the candidate set – a decision reflected in the survivor list.

Kratos’ judgment call: The board comment confirms that evaluation must remain strictly ARM‑only; no separate lightweight VM will be provisioned for x86‑only skills.

5. Questions for Shri

For future cycles, should we allowlist any skill that requires outbound HTTP access (e.g., a vetted search API), or keep the evaluation permanently offline?
Which ARM‑compatible replacement should we adopt for any role that currently has no viable skill after pruning (e.g., if Loki needs a web‑search capability without anysearch)?
Can you confirm the exact schema and location of the migration script that creates the D1 skill_lift table, so we can embed the step reliably in eval.sh?