skill-enabler

SKILL.md preview

---
name: skill-enabler
description: Flip enabled:false → enabled:true for a comma-separated list of skill slugs in aeon.yml — validate against skills/, fail loudly on already-enabled or missing slugs, commit, open a PR with per-skill rationale
var: ""
tags: [dev, meta]
---

> **${var}** — REQUIRED. Comma-separated list of skill slugs to enable (e.g. `skill-a,skill-b,skill-c`). Empty var is a no-op — log `SKILL_ENABLER_NO_INPUT` and exit silently (this skill is explicit opt-in only; an empty `var` must never flip switches by accident). Pass `dry-run:slug1,slug2` to validate without committing or opening a PR.

Today is ${today}. Skills can sit at `enabled: false` for days while the operator is occupied elsewhere. The human review of "is this skill ready to run" is not what blocks activation — the typing is. This skill makes the typing one command.

## Why this exists

Flipping `enabled: false → true` in `aeon.yml` is mechanical:

- The text-edit is a single regex-safe substitution per skill
- Validation is straightforward: skill directory exists, current state is `enabled: false`, slug doesn't appear under `chains:` (which would conflict with a top-level entry)
- The risk is low: the worst case is a noisy skill, fixed by a one-line revert PR

So the bottleneck is "open the file, find the line, edit, commit, push, open a PR, wait for CI" — 5 minutes of friction per skill, applied N times, batched into operator sprints that don't happen. This skill collapses that loop: operator dispatches with `var=slug1,slug2,slug3`, gets a PR with one merge-button click.

**Explicit opt-in is the safety bar.** No scheduled run, no automatic discovery. The operator names the slugs. The skill validates them and writes a PR — nothing flips on `main` until the operator clicks merge.

## Steps

### 1. Parse var

- `${var}` empty → log `SKILL_ENABLER_NO_INPUT` and exit. **Do not flip anything on empty var.** Send no notification — silence is correct when there's nothing to do.
- `${var}` starts with `dry-run:` → `MODE=dry-run`. Strip the prefix; the remainder is the slug list. In dry-run: parse + validate + report, but do **not** edit `aeon.yml`, commit, or open a PR.
- Otherwise → `MODE=execute`. Treat `${var}` as the slug list.

Split the slug list on comma. Trim whitespace from each entry. Drop empty entries (handles trailing commas). Lowercase each slug. Deduplicate, preserving first-seen order.

Validate slug format: each must match `^[a-z0-9][a-z0-9-]{0,63}$`. Slugs that fail this check are tagged `BAD_SLUG_FORMAT` in step 3 — they don't poison the run, but they don't get enabled either.

If after parsing the input list is empty (e.g. `var` was just commas/whitespace), log `SKILL_ENABLER_NO_INPUT` and exit silently.

### 2. Read source state

Required reads — all in the current working directory (this fork's repo root):

- `aeon.yml` — the file to patch. Read once at start; rewrite once at end.
- `skills/` directory — `ls skills/` gives the set of skills present in this fork. A slug must have a `skills/${slug}/` directory or it's `MISSING_DIRECTORY`.
- `skills.json` (optional) — used for the per-skill rationale ("registered skill: <description>"). Missing `skills.json` is a warning, not a failure; rationale falls back to the SKILL.md frontmatter `description` field, then to the slug itself if both are absent.

If `aeon.yml` is missing or unreadable → log `SKILL_ENABLER_NO_CONFIG` and exit with notification (operator can't proceed without it).

### 3. Validate each slug

For each parsed slug, walk these gates **in order**. The first failing gate is the slug's verdict; do not check subsequent gates for that slug.

| Gate | Pass condition | Failure tag |
|------|----------------|-------------|
| 1. Format | matches `^[a-z0-9][a-z0-9-]{0,63}$` | `BAD_SLUG_FORMAT` |
| 2. Directory | `skills/${slug}/SKILL.md` exists | `MISSING_DIRECTORY` |
| 3. Present in aeon.yml | `aeon.yml` contains a top-level entry `${slug}:` under `skills:` | `NOT_IN_AEON_YML`

…