Discover open issues/PRs for allowed owners #5

Summary

Implement discovery of open work across allowed GitHub owners so the hive can list candidate issues and/or PRs before claiming worktrees or starting babysit cycles.

Problem / context

The skill’s first operational step is “what should we work on?” Without a scoped discover command:

• Agents may wander into arbitrary orgs/repos (safety and noise problem).
• Operators lack a single view of open issues (to implement) vs open PRs (to babysit) across rmems/* and Limen-Neural/*.
• pr-babysit already hard-scopes to those owners for PR babysitting; worktrees-hives must reuse the same allowlist for discovery and expand it to issues, not only PRs.

This is milestone B1 of the core hive loop: discover → claim/worktree → orchestrator → issue→PR → babysit.

Prior art: ~/.agents/skills/pr-babysit/SKILL.md (owner allowlist, gh pr view / checks, watchlist mental model). Discover is the multi-repo generalization of “what’s open?” before add / claim.

Goals

• Support owners: rmems, Limen-Neural, or both (default: both unless operator narrows).
• List open issues and/or open PRs with at least: URL, title, and for PRs a CI rollup (pass/fail/pending summary from statusCheckRollup or gh pr checks).
• Refuse other owners/repos unless the user explicitly overrides (e.g. named owner/repo in the command).
• Document the discover command in SKILL.md (command table + behavior + safety).
• Produce output usable by humans and by the orchestrator (Multi-subagent orchestrator (capped parallel) #7) / claim path (Claim issue → branch → worktree isolation #6).

Non-goals

• Claiming issues, creating branches, or worktrees (that is Claim issue → branch → worktree isolation #6).
• Opening PRs or implementing issue bodies (Issue → PR workflow (never auto-merge) #8).
• Full PR babysit cycles, review threads, or watchlist persistence (PR babysit cycle (threads + CI) #9, Watchlist / persistent state file #12).
• Deep CI taxonomy / Codacy vs Actions classification (CI taxonomy (Actions vs Codacy vs third-party) #10) — discover only needs a rollup, not full taxonomy.
• Auto-merge, Graphite, or cross-org search beyond allowlist.
• Building a permanent multi-repo database; a session report (and later watchlist integration) is enough for v1.

Detailed acceptance criteria

• Owner allowlist constant/docs: rmems, Limen-Neural (match epic + pr-babysit).
• discover supports filters at least:
  • owner: rmems | Limen-Neural | both (default both or documented default)
  • kind: issues | prs | all
  • optional: single owner/repo, labels, limit
• For each open issue: number, title, URL, repo, labels (nice-to-have), state.
• For each open PR: number, title, URL, repo, head/base (nice-to-have), CI rollup (e.g. all green / failing count / pending), mergeable if cheap.
• Request for owner outside allowlist errors clearly unless explicit override flag/phrase is present; override is logged in output.
• Empty results are a clean message, not a crash.
• Auth failure (gh auth status) fails fast with remediation.
• SKILL.md documents discover syntax, defaults, allowlist, and override policy.
• Never merges; discover is read-only on GitHub.
• Linear footer preserved: RM-5.

Design options

Recommendation: D (hybrid) — start with owner allowlist + gh search / per-repo list; optionally seed known Limen-Neural and rmems repo names from pr-babysit for faster local loops. Prefer read-only gh for agent portability.

Suggested CLI shape (illustrative, not binding)

discover [--owner rmems|Limen-Neural|both] [--kind issues|prs|all]
         [--repo owner/name] [--limit N] [--label X] [--override-owner ...]

Output shape (illustrative)

Markdown table or structured sections:

Dependencies

Blocked by: ideally #2 stub exists so discover has a home; not strictly required to prototype CLI snippets in docs first.

Risks

• API rate limits when scanning many org repos — paginate, cache, respect --limit.
• Noise (hundreds of stale issues) — default limits, optional label filters, “updated recently” sort.
• Private repo visibility depends on gh auth token — document required scopes.
• Override abuse — require explicit user intent; never default to “all of GitHub.”
• CI rollup flakiness (statusCheckRollup pending/unknown) — show raw rollup, don’t pretend green.
• Divergence from pr-babysit allowlist if one skill updates owners and the other does not — document single shared allowlist policy.

Suggested plan

1. Codify allowlist + override policy in SKILL.md (mirror pr-babysit wording).
2. Implement issue discovery for one owner, then both; print table.
3. Add PR discovery with CI rollup via gh pr view --json statusCheckRollup or checks summary.
4. Add --repo narrow path and refuse non-allowlisted owners without override.
5. Wire example into README/SKILL command table; note read-only.
6. Hand off sample output format to Claim issue → branch → worktree isolation #6/Multi-subagent orchestrator (capped parallel) #7 authors so claim/orchestrator can parse or copy IDs.

Prior art / references

• pr-babysit owner scope and success criteria for PRs.
• Epic: never auto-merge; platform-neutral skill packaging.
• Example org surface: Limen-Neural Julia/Rust neural stack; rmems personal tooling repos.

Hybrid layer

Primary implementation layer: python (primary); see #37 P2, #30 P1

This issue remains valid under the Python/Rust hybrid architecture (epic #21). Rust owns worktrees, state, process supervision, and hard safety; Python owns orchestration/policy; agent skills document how agents drive both.

Linear: https://linear.app/rpd-34/issue/RM-5/worktrees-hives-gh5-discover-open-issuesprs-for-allowed-owners (RM-5)