upstream-recon

在与开源项目交互之前对其进行调查——PR、问题或评论。 使用之前：提出问题、提交 PR 或评论现有线程。 触发条件：“上游侦察”、“我应该公关这个吗”、“他们会合并吗”、 “检查项目”、“调查回购协议”、“公关策略”、“提出问题”、 “检查现有问题”、“我应该发表评论吗”或用户想要的任何时间 与他们不维护的存储库进行交互。 在要提交问题或 PR 时也要主动使用 - 检查现有的 线程可以防止重复和浪费精力。

## 概述（中文）

在与开源项目交互之前对其进行调查——PR、问题或评论。
使用之前：提出问题、提交 PR 或评论现有线程。
触发条件：“上游侦察”、“我应该公关这个吗”、“他们会合并吗”、
“检查项目”、“调查回购协议”、“公关策略”、“提出问题”、
“检查现有问题”、“我应该发表评论吗”或用户想要的任何时间
与他们不维护的存储库进行交互。
在要提交问题或 PR 时也要主动使用 - 检查现有的
线程可以防止重复和浪费精力。

## 原文

# Upstream Recon

Investigate a repo's culture and existing threads before interacting. Prevents
duplicate issues, wasted PR effort, and uninformed comments.

**Arguments**: `<owner/repo> [topic-keyword]`

## Procedure

Use `gh` CLI throughout. Run independent queries in parallel.

1. **Repo metadata** — stars, forks, license, last push date, archived status
2. **Top 10 contributors** — commit counts. Is it one person with 90%+ commits?
3. **Existing issues search** — search open AND closed issues for the topic keyword.
   Check for duplicates, prior art, and maintainer responses. Report what was found.
4. **Recent 30 PRs** (all states) — get the lay of the land
5. **Merged PRs** (last 20) — who merges them? How fast? What types get accepted?
6. **Closed-without-merge PRs** (last 50, filter `mergedAt == null`) — deep-dive
   2-3 notable rejections: read comments for maintainer reasoning
7. **Open PRs** — how many sit with 0 reviews? For how long?
8. **Topic deep-dive** (if keyword given) — read comments on 2-3 most relevant
   existing issues/PRs to understand maintainer sentiment and community workarounds

## Analysis Dimensions

- **Governance**: Solo maintainer / small team / community-driven
- **External PR reception**: Welcoming / selective (bugs yes, features no) / closed shop
- **Issue responsiveness**: How fast do maintainers respond to issues? Do they engage or auto-close?
- **Merge velocity**: Days from open to merge for external contributors
- **Rejection patterns**: Ghosted? "Building it myself"? "File issue first"? Bot auto-closed?
- **Topic overlap**: Has this been attempted or discussed before? Active workarounds?

## Recommendation

End the report with one of:

- **MERGE-LIKELY** — project merges external feature PRs, no competing work, maintainer receptive
- **MERGE-UNLIKELY** — maintainer builds features themselves, similar PRs closed/ignored, feature contradicts direction
- **FILE-ISSUE-FIRST** — feature not yet discussed, maintainer is selective but responsive to issues, gauge interest before coding
- **COMMENT-ON-EXISTING** — existing issue/PR already covers this, add your workaround or +1 there instead
- **DUPLICATE-EXISTS** — exact issue already filed, do not create another

Include concrete next steps (e.g., "comment on #13738 with your workaround",
"start with a bug fix PR to build credibility", "file an issue referencing #189",
"fork and maintain independently").