Feature

${var} — Optional. If set, build this specific feature for the FIRST watched repo only. If empty, iterate every watched repo and pick per-repo.

This skill is the multi-repo sibling of external-feature:

	feature (this skill)	external-feature
Per run	Iterates every watched repo, ships one PR per repo	Single repo per run
Repo source	memory/topics/watched-repos.md	memory/topics/watched-repos.md (or ${var} override)
Use it for	Weekly broad sweep — keep every repo moving	Targeted enhancement on one repo
Notification	One per successfully-built feature (per repo)	One per run

Today is ${today}. Read memory/MEMORY.md and the last 7 days of memory/logs/ before starting.

Voice

If soul/SOUL.md and soul/STYLE.md are populated, read both and match the operator's voice in every per-repo notification. If they are empty templates or absent, use a clear, direct, neutral tone — short sentences, no corporate launch-language.

Config

This skill reads the candidate repo list from memory/topics/watched-repos.md. If the file is missing or empty, log FEATURE_NO_CONFIG and exit cleanly (no notification — empty config is not an error).

Format: one owner/repo per line. Markdown bullets like - owner/repo are fine; comment lines starting with # are ignored.

Steps

1. Load the target list

Parse memory/topics/watched-repos.md into a list of owner/repo entries.

If ${var} is set, restrict the list to the first repo only and use ${var} as the feature spec for it.

2. For each repo in the list, run steps 3–10 independently

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}).

3. Pick what to build for this repo

In this priority order:

a. If ${var} is set AND this is the first repo, build that.
b. Check yesterday's repo-actions output in 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.

4. Clone the repo

Into a per-repo temp directory:

gh repo clone owner/repo /tmp/feature-build-${repo-name}
cd /tmp/feature-build-${repo-name}

5. Read the codebase

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.

6. Implement the feature

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.

7. Branch and push

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>

8. Open a PR

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*"

9. Update memory

Log what was built (per repo) to memory/logs/${today}.md. Include the repo name in every log line so per-repo history stays distinct:

## Feature — owner/repo
- **Built:** <feature name>
- **Why:** <trigger>
- **PR:** <url>
- **Files:** <list>
- FEATURE_OK

10. Notify — one per successfully built feature

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.

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.

11. Final wrap-up

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.

Sandbox Note

All GitHub operations go through gh CLI — handles auth internally via GITHUB_TOKEN. No env-var-authenticated curl from bash. The ./notify call uses the standard fan-out pattern.

Environment Variables

• GH_TOKEN / GITHUB_TOKEN — required. Cross-repo access (the token needs permission to fork/push/PR on every watched repo).

Guidelines

• ONE feature per repo per run. Don't bundle unrelated changes inside a single PR.
• Understand before you change. Read the codebase first. Don't guess at conventions.
• Match the repo's style. If they use tabs, use tabs. If they use semicolons, use semicolons.
• Small, high-quality PRs > ambitious rewrites. A 10-line bug fix beats a 500-line refactor.
• If the repo has CI, make sure your changes won't break it.
• Never push to main/master. Always branch.
• If you can't find anything worth doing on a repo, log "no suitable feature" and skip — that's a valid outcome.
• Don't add unnecessary abstractions, comments, or documentation the repo doesn't need.