create-skill

${var} — A natural-language description of the skill to create. Required. Example: "monitor Hacker News for AI papers and send a summary" or "track gas prices on Ethereum and alert when below 10 gwei".

If ${var} is empty, exit CREATE_SKILL_NO_VAR:

./notify "create-skill aborted: var empty — pass a description e.g. \"monitor X for Y\""

Then stop.

Today is ${today}. Your task is to generate a complete, production-ready skill from ${var}, score it against a quality bar, and ship it as a PR — never commit directly to main.

Steps

1. Parse the request. Extract from ${var}:

   • Core action verb (monitor, fetch, generate, analyze, alert, track, scan, etc.)
   • Data source(s) — APIs, websites, RSS, on-chain, GitHub, etc.
   • Output format — notification, article, file, PR, dashboard, etc.
   • Configurable parameter(s) the new skill will accept via its own ${var}
   • Suggested cadence (daily, hourly, weekly, on-demand)

   Save a one-paragraph structured request summary; you'll use it in the PR body.

2. Duplicate detection (deep — not just ls). Find functional overlap, not just name collision.

   keywords=$(echo "${var}" | tr '[:upper:]' '[:lower:]' | grep -oE '[a-z]{4,}' \
     | grep -vE '^(send|with|from|that|this|when|each|into|over|some|like|just|than|then|also|will|have|been|using|monitor|track|fetch|alert)$' \
     | sort -u)
   for kw in $keywords; do
     grep -liE "$kw" skills/*/SKILL.md | head -5
   done
   

   Read the top 3 candidates fully. For each, judge: does it already do this? Could the request be solved by running an existing skill with a different var=?

   • Near-duplicate exists → exit CREATE_SKILL_DUPLICATE. Notify with the existing skill name and a one-line suggestion ("use existing {skill} with var={...} instead"). Stop.
   • Functionally adjacent → design the new skill to complement (different angle/cadence/output). Document the boundary in the PR body.

3. Research the data sources. For every API or data source the new skill needs:

   • WebSearch for the current API documentation. Cross-check against a secondary source when feasible (a recent GitHub repo using it, an official changelog, or a Stack Overflow answer dated ≥2026) to confirm the endpoint isn't deprecated.
   • WebFetch the canonical docs URL — record it as a comment in the SKILL.md and in the PR body's "Sources researched" section.
   • Identify exact endpoints, required headers, auth scheme, response schema, and rate limits.
   • Note every required environment variable / API key.
   • Determine fallback strategy when an optional API key isn't set (WebSearch / WebFetch / cached data / public endpoint).

   Research bar (soft): at least one confirmed source URL or exemplar (a working docs page or a public repo using the API). If none, do not hard-abort — log CREATE_SKILL_INSUFFICIENT_RESEARCH, ask the operator via ./notify with what was tried and why each source failed, and stop. The operator can re-dispatch with a clearer prompt or a source hint.

4. New-secret guard. Secrets values are never inspectable from the workflow — only names are listed. Use gh api repos/:owner/:repo/actions/secrets --jq '.secrets[].name' to read the names of secrets already configured (this endpoint returns names only, never values). Cross-reference with env-var usage in aeon.yml and existing workflows. For each env var the new skill needs:

   • Name present → continue.
   • Name missing → record as NEW_SECRET_REQUIRED. The generated skill must gracefully degrade or skip when the secret is absent (no hard crash). Add a ### Required secrets section to the PR body listing what the operator must add to GitHub Actions secrets before enabling.

   If the secret has no graceful fallback, the generated skill's step 1 must do:

   if [ -z "$VAR" ]; then ./notify "{skill} skipped: VAR not set"; exit 0; fi