メニュー
Build, enhance, or revive GitHub repos - ship one feature PR per watched repo (watched), make the best single enhancement on one external repo (external), or revive the top dormant repo (dormant).
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/aaronjmars/aeon --skill featureコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Write a publication-ready article in one of three angles - a trending long-form piece, a watched-repo thesis, or a project-through-a-lens essay. Optional Replicate hero image with --visual.
Curated trending across GitHub repos and the Hugging Face Hub (models, datasets, spaces) - filtered, clustered, and labeled by momentum with a one-line why-notable per pick.
Crypto market scanner and single-token analyst - movers scans top winners/losers/trending or on-chain runners with pump-risk flags; single-token produces a verdict-first deep report for one token.
SOC 職業分類に基づく
SKILL.md を表示中
| type | Skill |
| name | Feature |
| category | dev |
| description | Build, enhance, or revive GitHub repos - ship one feature PR per watched repo (watched), make the best single enhancement on one external repo (external), or revive the top dormant repo (dormant). |
| var | |
| mode | write |
| commits | true |
| permissions | [{"contents":"write"},{"pull-requests":"write"}] |
| requires | ["GH_GLOBAL?"] |
| tags | ["dev","build","growth"] |
${var} — Selector
target[:arg] [--fix-issues],target ∈ {watched, external, dormant}. Empty orwatched= build a feature on every watched repo (one PR each);external:<owner/repo>= one best enhancement on that external repo;dormant= revive the highest-scoring dormant repo. A leadingbuild:<owner/repo | issue-url | free-text instruction>— the shape the Telegram "ship which opportunity?" force-reply sends viarepo-scanner's offer — is intercepted first and routed into the external branch on that target/instruction.--fix-issuesbiases the chosen branch toward fixing an open GitHub issue. Full grammar below.
This skill merges three repo-work modes behind one selector so no capability is lost:
| Branch | Selector | Per run | Repo source | Use it for |
|---|---|---|---|---|
| watched (§A) | empty / watched | Iterates every watched repo, ships one PR per repo | memory/watched-repos.md | Weekly broad sweep — keep every repo moving |
| external (§B) | external[:owner/repo[#N]] | Single repo per run | memory/topics/repos.md catalog (or ${var} override) | Targeted enhancement / issue fix on one repo |
| dormant (§C) | dormant[:owner/repo] | Single dormant repo per run | memory/watched-repos.md scored by dormancy | Reactivate a stale high-★ repo with one visible fix |
Today is ${today}. Read memory/MEMORY.md and the last 7 days of memory/logs/ before starting — and before notifying, drop anything already reported in the last ~3 days of logs.
Telegram force-reply interception — check this FIRST, before parsing anything else. If ${var} starts with build:, it is the "ship which opportunity?" force-reply that repo-scanner offers (routed here as with ). Strip the prefix with and treat the remainder as an — route it straight into the branch (§B), reusing that branch's existing logic (do run the watched or dormant branches for a value, and do not duplicate §B). Normalize the remainder into a §B target:
featurevar="build:<the operator's reply>"${var#build:}build:owner/repo → run §B as if external:owner/repo (B2 "clone that repo").https://github.com/owner/repo/issues/N) or owner/repo#N → run §B as if external:owner/repo#N (B2 "fetch that issue").owner/repo: add retry to the client → run §B on owner/repo, using the trailing text as the explicit enhancement to build (see §B4's "requested enhancement" note — skip the auto-pick).The remainder may itself contain colons — keep them. This is a complete run once §B ships its PR (or cleanly skips); do not then fall through to the normal selector.
Parse ${var} into a target and optional flags:
watched → watched branch (§A): sweep every watched repo, ship one feature PR each.watched:<feature-spec> → watched branch, but build <feature-spec> on the FIRST watched repo only.external → external branch (§B): auto-pick one catalog/watched repo and make the best single enhancement.external:<owner/repo> → external branch on that specific repo.external:<owner/repo>#N → external branch on that specific issue.dormant → dormant branch (§C): auto-select the highest-scoring dormant repo and revive it.dormant:<owner/repo> → dormant branch on that specific repo (skip selection).--fix-issues (with any target) → bias the branch toward fixing an OPEN GitHub issue rather than a proactive change (see each branch's "with --fix-issues" note).Example values: `` (empty → watched sweep), watched, watched:add a dark-mode toggle, external, external:acme/api, external:acme/api#42, dormant, dormant:acme/legacy-lib, external --fix-issues, dormant --fix-issues.
Dispatch to exactly one branch. Do not run branches you weren't selected into.
If soul/SOUL.md and soul/STYLE.md are populated, read both and match the operator's voice in every written output — per-repo notifications (§A), and the revival tweet draft (§C step 5). If they are empty templates or absent, use a clear, direct, neutral tone — short sentences, no hashtags, no emojis, no corporate launch-language.
All branches read operator-controlled files under memory/ (runtime config — reference the paths exactly, never edit them here):
memory/watched-repos.md — candidate repo pool. One owner/repo per line (markdown bullets like - owner/repo are fine; comment lines starting with # are ignored). Used by watched and dormant; also the OWNER fallback for external. If missing or empty on the watched branch, log FEATURE_NO_CONFIG and exit cleanly (no notification — empty config is not an error). On dormant, log REPO_REVIVE_NO_CONFIG and exit cleanly.
memory/topics/repos.md — full repo catalog with descriptions, stack, and opportunities. Preferred repo source for the external branch; if absent, fall back to memory/watched-repos.md.
memory/topics/stale-models.md — stale AI model names and their current replacements. Used only by the dormant branch's stale-model audit. Example shape:
# Stale Models
## Considered stale (flag if a watched repo's README/config still references these)
- gpt-3.5
- claude-2
- claude-instant
- gpt-4 (without version suffix)
- text-davinci
## Current models (suggest these as replacements)
- claude-sonnet-4-6
- claude-opus-4-7
- gpt-4o
- gemini-2.0
If the file is missing, the dormant branch skips the "stale model" fix category entirely (other categories still apply) and logs REPO_REVIVE_NO_MODEL_CONFIG: skipping model audit.
Runs when ${var} is empty or watched[:<feature-spec>]. Ships one PR per watched repo in a single run.
Parse memory/watched-repos.md into a list of owner/repo entries. If the file is missing or empty, log FEATURE_NO_CONFIG and exit cleanly (no notification).
If ${var} is watched:<feature-spec>, restrict the list to the first repo only and use <feature-spec> as the feature spec for it.
A failure on one repo must NOT stop the others — catch the failure, log it, continue. Use a fresh working directory per repo (e.g. /tmp/feature-build-${repo-name}).
In this priority order:
a. If ${var} is watched:<feature-spec> AND this is the first repo, build that.
b. Check yesterday's repo-actions output in output/articles/repo-actions-*.md (most recent file) for ideas scoped to THIS repo. Pick the highest-impact idea that's autonomously implementable.
c. Check open GitHub issues labelled ai-build on this repo:
gh issue list -R owner/repo --label ai-build --state open
d. Check memory/MEMORY.md for planned features or next priorities tied to this repo.
e. If none of the above yields anything for this repo, log FEATURE_SKIP: <repo> — no suitable feature found and skip to the next repo. Do NOT send a notification for skipped repos.
With --fix-issues: promote step (c) — open ai-build issues — to the top priority ahead of (a)/(b), and only build from an open issue. If this repo has no open ai-build issue, log FEATURE_SKIP: <repo> — no open ai-build issue and skip it.
Into a per-repo temp directory:
gh repo clone owner/repo /tmp/feature-build-${repo-name}
cd /tmp/feature-build-${repo-name}
Understand the project structure, README, package.json/config files, recent commits, and the area you'll modify:
git log --oneline -20
Read the area you'll modify in full before changing anything.
Write clean, complete code. No TODOs or placeholders. Match the existing code style exactly — indentation, naming, patterns. Don't introduce new dependencies unless absolutely necessary. Don't refactor unrelated code — stay focused on one improvement.
Content-filter-sensitive documents. A few standard governance files are built almost entirely from sensitive-term-heavy boilerplate — CODE_OF_CONDUCT.md, abuse/moderation policies, harassment-reporting docs (terms like harassment, sexualized language, violence, abuse). Free-generating that body can trip the model's output content-filter, which aborts the entire run with API Error: Output blocked by content filtering policy (exit 1) even when the work is otherwise done. For these files do NOT free-generate the body:
curl so the body never passes through model output — curl -fsSL https://www.contributor-covenant.org/version/2/1/code_of_conduct/code_of_conduct.md -o CODE_OF_CONDUCT.md. Don't route it through WebFetch: that pulls the text into context, and you would still have to re-emit the whole body in a Write call — the filter scores generated tokens, so transcribing it can trip the abort just like free-generating it. curl -o writes the file without the model ever emitting the body.Edit (that one line is not sensitive); pull the contact convention from the repo's existing SECURITY.md/CONTRIBUTING.md.## Summary and every ./notify message descriptive — name the file, say it's the Contributor Covenant, and link the PR. Never paste the document body into the result text; the verbose final output is the most likely filter trigger.git checkout -b feat/<short-feature-name>
git add -A
git commit -m "feat: <description of what was built>"
git push -u origin feat/<short-feature-name>
gh pr create -R owner/repo \
--title "feat: <short description>" \
--body "## What
<Description of the feature>
## Why
<What triggered this — repo-actions idea, issue, or gap identified>
## Changes
- file1: what changed
- file2: what changed
---
*Built autonomously by Aeon*"
Log what was built (per repo) to memory/logs/${today}.md under the consolidated ### feature heading (see Log below). Include the repo name in every log line so per-repo history stays distinct.
For each repo with a shipped PR, send a separate ./notify so the operator gets a detailed per-repo message. The notification should be rich enough that a reader understands exactly what was built, why it matters, and how it works WITHOUT clicking the PR link. Skipped/failed repos send no notification.
Do NOT compress into 1–2 lines. Every section below is REQUIRED.
*Feature Built — ${today} — owner/repo*
<Feature name>
<2–3 sentence description of what the feature does in plain language. Explain it like you're telling a non-technical reader in the community what just got added to the project.>
Why this matters:
<2–3 sentences on why this is relevant to the project RIGHT NOW. What problem did users/developers have before? What triggered this — a repo-actions idea, a GitHub issue, a gap in the codebase? How does it move the project forward?>
What was built:
- <file/component>: <what was added/modified — be specific about the functionality, not just "added endpoint">
- <file/component>: <same level of detail>
- <file/component (if applicable)>: ...
How it works:
<3–4 sentences on the technical implementation. Approach taken and why. Libraries/APIs used. How it integrates with existing code. Any interesting design decisions.>
What's next:
<1–2 sentences on follow-up work or how this connects to the broader roadmap.>
PR: <url>
BAD (too short — do NOT do this):
"Feature Built: Data Export. Users can download results as JSON/CSV. PR: url"
GOOD level of detail:
Per-section answers like the template above. A reader who never clicks the PR should still come away knowing what changed and why.
After iterating every repo, end with a ## Summary listing each watched repo and its outcome: PR url, skipped, or failed. If every repo was skipped, do NOT send a notification at all — just log the per-repo skip lines.
Runs when ${var} starts with external. Ships one enhancement PR to one repo per run. Needs cross-repo access — GH_GLOBAL must be present.
Read memory/MEMORY.md for current priorities.
If ${var} is external:<owner/repo>#N — fetch that issue and work on it.
If ${var} is external:<owner/repo> — clone that repo, skip to step B3.
If ${var} is external (no arg) — find a repo to improve:
memory/topics/repos.md for the full repo catalog with descriptions, stack, and opportunities.memory/watched-repos.md for the OWNER, then:
gh repo list ${OWNER} --limit 30 --json name,pushedAt,description,primaryLanguage \
--jq 'sort_by(.pushedAt) | reverse | .[:15]'
memory/watched-repos.md if it exists.Pick a repo that:
REPO="owner/repo"
WORK_DIR="/tmp/external-work"
rm -rf "$WORK_DIR"
gh repo clone "$REPO" "$WORK_DIR" -- --depth 50
cd "$WORK_DIR"
Before doing anything, deeply understand the codebase:
package.json / Cargo.toml / pyproject.toml / go.mod etc.git log --oneline -20gh issue list --repo "$REPO" --state open --limit 10gh pr list --repo "$REPO" --state open --limit 5Requested enhancement (force-reply build: path). If this run was reached via the Selector's build: interception carrying a trailing free-text instruction (e.g. owner/repo: add retry to the client), that instruction is the change — implement it directly and skip the priority list below (still honor --fix-issues if it was passed). Only fall through to the priority list when the build: value was a bare repo/issue with no explicit instruction, or when this run wasn't reached via build: at all.
Pick ONE thing from this priority list:
Priority 1 — Open issues (if any exist):
ai-build, bug, enhancement, good-first-issuePriority 2 — Code improvements (if no good issues):
Priority 3 — New features (if codebase is clean):
Pick the highest-impact, lowest-risk change. One change per run.
With --fix-issues: restrict the decision to Priority 1 only — work an open issue (prefer ai-build/bug/enhancement/good-first-issue) and add Closes #N. If the repo (or the specified #N) has no workable open issue, log EXTERNAL_SKIP: <repo> — no workable open issue and exit without a PR.
If generating a governance/policy file (CODE_OF_CONDUCT.md, abuse/harassment docs), follow the content-filter-sensitive documents procedure in §A6 — curl -o the canonical body straight to disk, never free-generate it.
Write clean, production-ready code:
BRANCH="ai/SHORT-DESCRIPTION"
git checkout -b "$BRANCH"
git add -A
git commit -m "TYPE: [description]
[optional body explaining why]"
Use conventional commit types: fix:, feat:, test:, docs:, chore:. If fixing an issue, add Closes #N to the commit body.
git push -u origin "$BRANCH"
gh pr create --repo "$REPO" \
--title "TYPE: [short description]" \
--body "## Summary
[What and why — 1-2 sentences]
## Changes
- [file-level description]
## Context
[What prompted this — issue, TODO, code review finding, etc.]
---
Built by [Aeon](https://github.com/aeon)"
Send via ./notify:
external-feature: [repo] — [what was done]
PR: [url]
Append to memory/logs/${today}.md under the consolidated ### feature heading (see Log below).
Runs when ${var} starts with dormant. Reactivates one dormant repo per run with a single high-visibility, low-effort fix — not a feature.
If ${var} is dormant:<owner/repo>, use that repo. Otherwise auto-select:
memory/watched-repos.md into a list of owner/repo candidates. If missing/empty, log REPO_REVIVE_NO_CONFIG and exit cleanly (no notification).gh api:
gh api "repos/$REPO" --jq '{stars: .stargazers_count, pushed_at, archived, default_branch}'
pushed_at > 60 days ago (excluding pushes from this skill or other Aeon-bot accounts — check the most recent non-bot human commit via gh api "repos/$REPO/commits?per_page=10" and skip bot authors)memory/logs/ for REPO_REVIVE_OK lines mentioning this repo)score = stars × log10(days_dormant + 1)Selected: owner/repo (score: X, Yd dormant, N★)If zero repos pass the filters: log REPO_REVIVE_SKIP: no eligible repos and exit (no notification).
Inspect the selected repo via gh api:
gh api "repos/$REPO/git/trees/HEAD?recursive=1" --jq '.tree[].path' \
| grep -E '\.(md|json|js|ts|py|toml|yaml|yml)$' | head -50
Look for these stale signals — check at most 3 files per category:
A. Stale AI model references (only if memory/topics/stale-models.md is populated):
stale-models.mdB. Missing README elements:
C. Open community issues (fetch up to 10):
gh api "repos/$REPO/issues?state=open&per_page=10" \
--jq '.[] | {number, title, comments, created_at, labels: [.labels[].name]}'
Look for issues that are simple to close with a README clarification or a small code fix.
D. Stale metadata:
Rank the stale signals by effort-to-impact. Pick the single highest-impact, lowest-effort fix:
| Fix type | Effort | Impact |
|---|---|---|
| Update model list in README | very low | high (signals active maintenance) |
| Add Quick Start section | low | high (reduces friction) |
| Close simple issue with README clarification | low | high (community signal) |
| Update repo description + topics | very low | medium |
| Add install badge | very low | low |
With --fix-issues: force category C — pick a simple open community issue and close it with a README clarification or a small code fix. If no simple issue exists, log REPO_REVIVE_SKIP: no simple issue to fix and exit.
Do NOT attempt:
vuln-scanner for that)Clone, branch, change, commit, push, PR:
gh repo clone "$REPO" "/tmp/repo-revive-${REPO##*/}"
cd "/tmp/repo-revive-${REPO##*/}"
git checkout -b "chore/revive-${today}"
# ... apply the targeted change ...
git add -A
git commit -m "chore: <what you changed>
Periodic maintenance pass — repo is at ${STARS}★ and worth keeping fresh."
git push -u origin "chore/revive-${today}"
gh pr create --title "chore: <what you changed>" --body "<concise body>"
If the repo doesn't accept outside PRs or the clone fails, fall back to updating description + topics via API (requires you to be the owner — skip if not):
gh api -X PATCH "repos/$REPO" -f description="..." -f homepage="..."
Write one tweet draft (≤ 280 chars) announcing the update. Voice rules:
Save to /tmp/revival-tweet.md.
Write notification to /tmp/repo-revive-notify.md:
*Repo Revive — ${today}*
**${owner/repo}** (${N}★, ${N}d dormant)
fix: <one-line description>
pr: <PR URL or "no PR — updated via API">
tweet draft:
"<exact tweet text>"
Then: ./notify -f /tmp/repo-revive-notify.md.
Append to memory/logs/${today}.md under the consolidated ### feature heading (see Log below).
Append one consolidated block under a single ### feature heading in memory/logs/${today}.md (the health loop parses this shape). Start with a discriminator line naming the branch that ran, then the branch-specific bullets. Preserve every status code so per-branch history stays greppable.
Watched branch:
### feature
- Branch: watched
- **Built:** <feature name> — owner/repo
- **Why:** <trigger>
- **PR:** <url>
- **Files:** <list>
- FEATURE_OK
Per-repo skips/failures each get their own line: - FEATURE_SKIP: <repo> — <reason>. If config is missing: - FEATURE_NO_CONFIG.
External branch:
### feature
- Branch: external
- **Repo:** owner/repo
- **What:** <description of enhancement>
- **PR:** <url>
- **Why:** <what prompted it — issue, TODO, proactive improvement>
No workable issue under --fix-issues: - EXTERNAL_SKIP: <repo> — no workable open issue.
Dormant branch:
### feature
- Branch: dormant
- **Target:** owner/repo (N★, Nd dormant)
- **Fix:** <one-line description>
- **PR:** <URL or "API update">
- **Tweet draft:** yes/no
- REPO_REVIVE_OK
No eligible repos: - REPO_REVIVE_SKIP: no eligible repos — all recently revived or below threshold. Missing config: - REPO_REVIVE_NO_CONFIG. Missing model config: - REPO_REVIVE_NO_MODEL_CONFIG: skipping model audit.
Notify only on signal. The watched branch sends one rich per-repo message per shipped PR (skipped/failed repos send nothing; an all-skipped run sends nothing). The external branch sends one message per run. The dormant branch sends one message per revival via ./notify -f. A clean/no-change run sends nothing.
All GitHub operations go through the gh CLI — it handles auth internally via GITHUB_TOKEN/GH_GLOBAL, so no env-var-authenticated curl from bash is needed. ./notify / ./notify -f deliver reliably. For the one public-network exception — curl -o of a governance-file body (§A6/§B4) — if curl fails intermittently, that specific fetch is the only case where you may retry; do NOT route governance-file bodies through WebFetch (see §A6 for why).
No compound bash — one operation per call. Branches work inside per-repo temp dirs, so the natural reflex is cd /tmp/feature-build-x && git grep .... The non-interactive sandbox auto-denies any call chaining &&, ||, ;, or pipes (|) — it's rejected before it runs, burning a turn each. The working directory persists across Bash calls, so:
cd /tmp/feature-build-${repo-name} (or /tmp/external-work, /tmp/repo-revive-${name}) as its own call, then run each subsequent command separately.cd entirely and pass the path directly: git -C /tmp/feature-build-${repo-name} grep ..., gh repo clone owner/repo /tmp/feature-build-${repo-name} followed by gh ... -R owner/repo.$(...) subshells and $VAR expansion are also rejected in skill bash — compute literal values in the prompt instead.GH_TOKEN / GITHUB_TOKEN — required (available by default in Actions). Powers gh for all branches.GH_GLOBAL — required for the external branch and for any watched/dormant target you don't own: the token needs permission to fork/push/PR across every targeted repo. Optional when only working repos the default token already covers.