Other

/skill-creator

Create/edit/audit/eval golem skills. Triggers: create skill, skill eval, live eval, JSONL mining.

$ golems-cli skills install skill-creator
91% best pass rate
64 assertions
16 evals
fixtures
6 workflows

Updated 5 days ago

Take skills from "drafted" to "proven" through rigorous multi-layer evaluation.

Installation

bash ~/Gits/golems/skills/golem-powers/skill-creator/scripts/install.sh

The installer is idempotent — safe to re-run. It:

  1. Symlinks the skill into ~/.claude/commands/skill-creator (golem-powers convention)
  2. Ensures $SKILL_CREATOR_REPO/.claude/agents/, $SKILL_CREATOR_REPO/.codex/agents/, and $SKILL_CREATOR_REPO/scripts/ exist as the project-scope home
  3. Symlinks the session-miner agent definition into the project-scope agents dir (gates the sub-agent so only skillCreator-family sessions can spawn it)
  4. Symlinks the parser into the project-scope scripts dir

Run bash scripts/install.sh --dry-run to preview without changes. bash scripts/install.sh --help for usage.

Core Loop: DRAFT → EVAL → RED → GREEN → SMOKE → SHIP

Every skill change goes through this pipeline. No exceptions.

1. DRAFT — Understand the Skill

  • Read the SKILL.md or MCP tool definition completely
  • brain_search for: prior evals, user complaints, known issues, related skills
  • Identify: what does this skill claim to do? What's the baseline without it?
  • Document intent, inputs, outputs, edge cases
  • Classify: capability uplift (may become obsolete) vs encoded preference (durable)

2. EVAL DESIGN — Create Structured Test Cases

Design eval cases as structured JSON in evals/evals.json:

{
  "id": 1,
  "name": "descriptive-kebab-name",
  "category": "compliance|structure|quality",
  "description": "What this eval tests",
  "prompt": "The input scenario given to the agent",
  "assertions": [
    {
      "type": "tool_usage|content|negative",
      "name": "assertion-name",
      "description": "What correct behavior looks like"
    }
  ]
}

Cover: happy path, edge cases, failure modes, interaction with other skills. See references/scoring-rubric.md for scoring methodology.

3. RED — Baseline Measurement (without skill)

  • Run each eval WITHOUT the skill loaded
  • Score baseline performance across all eval cases
  • Document baseline scores
  • Gate: If baseline >70%, the skill may not be adding value — flag it

4. GREEN — With-Skill Measurement

  • Run each eval WITH the skill loaded
  • Score delta between with_skill and without_skill
  • Gate: Delta <10% = marginal, consider retiring. Delta >30% = clearly valuable.
  • Maximum 3 iterations before flagging for human review

5. SMOKE — Live Agent Testing

Two tiers based on skill importance:

Tier A: Static Smoke (all skills)

  • Review evals.json assertions manually
  • Verify no contradictions between skill instructions and assertions
  • Check that strongest discriminators are tested

Tier B: Live Agent Smoke (flagship skills only)

  • Run live-eval-runner.sh for top 3 discriminator evals
  • Agent routing: Claude skills → Sonnet, code skills → Codex, audit skills → Cursor
  • Compare captured output against assertions
  • Gate: Live delta must be within 15% of static delta
  • Results stored in evals/results/live-{date}.json and brain_store'd

See workflows/live-eval.md for the full live eval workflow.

6. SHIP — Package and Document

  • Ensure every skill ships with its evals (no eval = no ship)
  • brain_store eval results, delta scores, issues found
  • Update skill metadata (version, last-eval-date, compliance-score)
  • Follow workflows/create-skill.md and workflows/audit-skill.md for SKILL.md structure compliance before shipping structural changes.
  • REGISTER a NEW skill — committed ≠ installed. A new golem-powers skill is invisible to every agent until it's symlinked into ~/.claude/skills/<name> + ~/.claude/commands/<name> (run golem-install, which auto-discovers + links every golem-powers/*/ dir; or symlink the one new skill). Then VERIFY it appears in the available-skills list — committing/merging does NOT register it. (2026-05-30: /weave was committed + merged but unusable by any agent until the symlinks existed. See workflows/create-skill.md "Final Step: REGISTER".)

Declaring Required Environment Variables

Add optional requires: frontmatter only when a skill cannot do its job at all without an environment variable:

requires:
  - FILE_HOST_TOKEN

List variable names (^[A-Z][A-Z0-9_]*$), never secret values. The declaration and runtime behavior are two halves of one contract: lint proves the metadata is well-formed, but the skill body must fail loud when a requirement is missing. Carry this one-line instruction in the body:

If FILE_HOST_TOKEN is unset, tell the user and stop. Do not guess, improvise a fallback, or report partial success.

Eval Methodology

with_skill vs without_skill comparison is MANDATORY. No exceptions.

Eval Result Provenance — Validity Gate

No provenance = no eval. Every static or live eval result MUST record one provenance entry per agent or eval arm with:

FieldRequired value
model_requestedAlias or model ID requested by the caller
model_effectiveModel ID observed at runtime
effort_effectiveEffort observed at runtime
model_observation_sourceCLI status line, session JSONL model field, or API response metadata
effort_observation_sourceCLI status line, session JSONL effort field, or API response metadata

model_effective must be the concrete runtime ID, not a floating alias or friendly display label, and uses an ID token with no whitespace. Observation sources begin with the exact case-sensitive labels shown above; append details after :, -, , or ( when useful.

JSON records use eval-result-provenance.schema.json. Markdown records use an ## Eval Provenance table with these fields plus an agent_or_arm column. Examples inside fenced code blocks are not evidence.

When runtime observation was impossible, the corresponding value and source MUST say NOT DETERMINED; omission, inference, and silent fallback are invalid. This is valid honesty but the checker marks the result NON_COMPARABLE; it cannot support a cross-arm/model delta claim. A NON_COMPARABLE record that contains any score, delta, or positive comparability claim is mechanically INVALID, not merely discouraged by prose. Pre-contract historical results may use provenance: alias-only and are also non-comparable; an alias-only record that carries a score, delta, or positive comparability claim is likewise INVALID. New results may not use that historical escape.

Before publishing or citing a score/delta, run the checker with --require-comparable. Exit 0 means comparable evidence, exit 3 means honest retained history that cannot carry the claim, and exit 1 means invalid input. Run the mechanical provenance check in workflows/audit-skill.md before scoring. An invalid result is not evidence and receives no score, delta, or verdict.

The requested alias is insufficient: cmuxlayer spawn_agent.model has a confirmed defect that silently drops non-alias models while reporting them honored. A requested model records intent, not runtime outcome—the same false surface class as delivered:true or exit 0 without live verification.

Behavioral Compliance Scoring

WeightDimensionWhat it measures
70%ComplianceDoes the agent follow the skill's instructions?
20%StructureDoes the output match expected format?
10%QualityIs the output actually good/useful?

Scoring Thresholds

ConditionAction
Baseline >70%Skill may not add value — flag and explain
Delta <10%Marginal — consider if complexity is worth it
Delta >30%Clearly valuable — ship with confidence
Compliance <50% with skillInstructions unclear — rewrite before shipping

Agent Routing for Live Evals

Skill typeTest withWhy
Claude behavior skillsSonnet (default)Tests actual Claude compliance
Code implementation skillsCodex (default, no model flag)Tests code quality
Audit/review skillsCursor (default)Tests review thoroughness

Workflows

/skill-creator:ab-compare/skill-creator:audit-skill/skill-creator:cleaner/skill-creator:create-skill/skill-creator:live-eval/skill-creator:mine-session