--- name: pick-issue-begging-for-help description: | Use this skill to pick exactly one open GitHub issue that genuinely needs an outside contributor: scan a given list of repository owners, prefer repositories with little recent activity, narrow to issues labeled "bug" or "enhancement" that are unassigned and have no claimed work in the thread, filter for actionable and reproducible reports, and prefer the oldest surviving candidate. Then post a single short comment announcing intent to work, addressed to the reporter and to the project architect — the repo owner or the most active recent committer. One issue per run, one comment per run, then stop. --- Treat the input as a list of GitHub account names — the OWNERS — supplied by the user or read from the current context; refuse to run if no owners are given, and do not invent owners from memory. Use the `gh` CLI for every read and write against GitHub, so authentication, rate limits, and pagination are handled by the official tool rather than by ad hoc HTTP calls. List the public, non-archived, non-fork repositories of each owner (for example with `gh repo list --no-archived --source --visibility public`), and discard mirrors, template repos, and repos whose description or topics mark them as deprecated. Rank the surviving repositories by staleness: the longer it has been since the last push, the higher the rank, because this skill targets projects that visibly lack maintainer bandwidth. Drop any repository whose default branch has had a push in the last fourteen days, because active maintainers are likely to handle their own backlog without outside help. Pick one repository at random from the remaining, staleness-ranked pool, biased toward the top of the ranking but not deterministic, so repeated runs spread attention across the owner's portfolio. List the open issues in the chosen repository filtered to the labels `bug` and `enhancement` only (for example with `gh issue list --repo / --state open --label bug --label enhancement --json number,title,createdAt,assignees,labels,comments`), and ignore every issue that carries any other disqualifying label such as `wontfix`, `invalid`, `duplicate`, `question`, `discussion`, `help wanted: no`, `blocked`, or `needs-info`. Discard any issue that has an assignee, because an assignment is GitHub's explicit signal that someone already owns the work. Discard any issue that is locked, pinned as a long-running tracker, or marked as a meta/epic with child checkboxes, because such issues are coordination artifacts, not units of work. Read the full discussion thread of every remaining candidate, including reactions and linked pull requests, and discard any issue where a human has written a comment expressing intent to fix — phrases like "I'll take this", "working on it", "PR incoming", "assign me", "mind if I try", or their equivalents in other languages. Discard any issue that already has an open pull request linked to it (visible via the timeline or via `gh issue view --json closedByPullRequestsReferences,timelineItems`), because duplicating that work wastes everyone's time. Filter the survivors for actionability: a `bug` issue must contain a concrete reproduction — steps, expected behavior, actual behavior, or a failing example — and an `enhancement` issue must describe a specific change with an observable outcome, not a vague wish. Discard issues whose body is shorter than three sentences, consists mostly of a screenshot with no text, or asks an open-ended question instead of describing a defect or a change. Discard issues that depend on a third-party service, hardware, or paid account the contributor cannot reasonably access, because the fix cannot be validated end-to-end. Among the issues that survive every filter, pick the single oldest by `createdAt`, because long-lived backlog items are the ones most begging for help; break ties by the highest comment count, then by the lowest issue number. Stop the selection at exactly one issue — do not shortlist, do not "queue up" several, do not return a ranked list — the contract of this skill is one pick per run. Identify the reporter as the `user.login` of the chosen issue, and identify the project architect as either the repository owner (when the owner is a user account) or, when the owner is an organization, the contributor with the most commits to the default branch in the last twelve months (for example via `gh api repos///contributors` combined with `gh api repos///commits?since=...`). If the reporter and the architect are the same account, mention that account once in the comment and do not duplicate the handle. Post one comment on the chosen issue (for example with `gh issue comment --repo / --body ...`) that opens by `@`-mentioning the reporter and the architect, states plainly that you plan to work on this issue, asks whether anyone objects or has context to share before work begins, and offers to step aside if someone else is already mid-fix. Keep the comment to a few sentences of plain prose — no headings, bullet lists, checkboxes, emojis, signatures, marketing language, or AI-disclosure boilerplate — because maintainers read short messages and ignore long ones. Do not promise a deadline, a design, or a pull request body inside the announcement comment; the comment exists to claim the work softly, not to pre-litigate the fix. Do not open a pull request, do not create a branch, do not edit any source file, and do not run any build as part of this skill — handing off to a separate fix-one-issue run is the correct next step. Do not pick a second issue from the same repository in the same run, even if the first candidate turns out to be unsuitable after the comment is posted; re-run this skill from the top instead. If every repository or every issue is filtered out, report that no suitable issue was found, name the filters that rejected the strongest candidates, and stop without posting anywhere.