feature

${var} — Selector target[:arg] [--fix-issues], target ∈ {watched, external, dormant}. Empty or watched = 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 leading build:<owner/repo | issue-url | free-text instruction> — the shape the Telegram "ship which opportunity?" force-reply sends via repo-scanner's offer — is intercepted first and routed into the external branch on that target/instruction. --fix-issues biases 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.

Selector

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 feature with var="build:<the operator's reply>"). Strip the prefix with ${var#build:} and treat the remainder as an external build target/instruction — route it straight into the external branch (§B), reusing that branch's existing logic (do not run the watched or dormant branches for a build: value, and do not duplicate §B). Normalize the remainder into a §B target:

• owner/repo → run §B as if external:owner/repo (B2 "clone that repo").
• an issue URL (https://github.com/owner/repo/issues/N) or owner/repo#N → run §B as if external:owner/repo#N (B2 "fetch that issue").
• free text like 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).
• anything else with no parseable repo → run §B passing the whole remainder as the enhancement instruction; §B B2/B4 already reason about selecting and scoping a target.

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:

• Empty or 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).
• Trailing --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.