SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsoss-triage

oss-triage

General & other

View repository

Updated 10-16 07:23

About this skill

OSS Triage

Help the user pick out issues from the target repository that they "can take on and can handle", read the relevant code, and output a plan for "which issue to pick + roughly how to change it". This skill is read-only: no fork, no code changes, no comments.

Entry: There are two sources for the target repository—

  • User-specified: "I want to contribute to facebook/react", "Help me look at the cli/cli repository"
  • oss-finder recommendation: pick one from the candidate list produced in the previous step

This skill's working directory convention:<root>/<owner>/<repo>(shallow clone, for read-only analysis).Does not pollute the current workspace. <root> Default C:/code_proj/github-proj/oss-proj; if you verbally specify another directory, replace <root>。

Communication guidelines: make it understandable and easy to follow (every skill must comply)

This skill is aimed atusers who can state requirements but are not necessarily familiar with GitHub details. Strictly follow the three rules below to avoid "can't understand the issue", "don't know what's going on", and "having to ask me back":

  1. Translate first, then act. Every time you get the original issue / PR text, first tell the user in 2-3 plain sentences:

    • What is this (bug report / feature request / pure discussion?)
    • What the reporter actually wants
    • What it looks like when done (acceptance criteria)

    Do not directly dump the raw issue body to the user. If the user is clearly unfamiliar with concepts such as issue / PR / fork, also explain with a one-sentence analogy (for example: "An issue is like sticking a sticky note on a public notebook to make a request; a PR is when you write the code and ask for it to be merged").

  2. Real-time progress updates. Before every non-idle action (pulling issues, cloning, running tests, reading code), explain in one plain sentence "what will be done next and why"; after the action, explain in one sentence "what just happened and what changed (e.g., cloned / located a certain file)". Keep the user able to follow the progress at all times, without repeatedly asking.

  3. Proactively give a status summary + next step. After completing each step, give a very brief summary: "current status" + "what the next step is / what is being waited on (you / maintainer / CI)". When the user needs to make a decision, clearly list the options and giveyour recommendation, do not leave it blank for the user to ask. This skill is read-only; any fork / comment / branch creation is handed off to oss-contribute, but before switching, clearly explain "which step to take next".

Operational boundaries

This skill is entirelyread-onlyoperations and can be executed automatically:

  • gh issue list / gh issue view / gh api repos/<owner>/<repo>/issues
  • gh search issues / gh search prs
  • gh repo view
  • git clone --depth 1(shallow clone to <root>/<owner>/<repo>）
  • within the workspace Grep / Read / Glob read code

This skilldoes notcreate a fork, write issue comments, create branches, or push. All results are output only for the user to see.

After entering the skill, first do

  1. Confirm that the gh CLI is logged in: 
    gh auth status
  2. Determine the target repository <owner>/<repo>：
    • User has specified → use it directly
    • Not specified → prompt the user to run oss-finder first, or directly provide a repository name
  3. Look at the repository's basic information and contribution guidelines: 
    gh repo view <owner>/<repo>
gh api repos/<owner>/<repo>/contents/CONTRIBUTING.md --jq .name 2>/dev/null

Scenario 1: Pick a workable issue for a repository

Triggering semantics:

  • "Pick an issue for "
  • "What can be done in this project"
  • "See if cli/cli has any tasks suitable for me"

Process:

  1. Pull candidate issues. Pull via two routes, merge and deduplicate:

    gh issue list --repo <owner>/<repo> --state open --label "good first issue" \
  --limit 50 --json number,title,labels,assignees,createdAt,commentsCount,url
gh issue list --repo <owner>/<repo> --state open --label "help wanted" \
  --limit 50 --json number,title,labels,assignees,createdAt,url

    Comment details are viewed in the next step with gh issue view --comments ; at the list stage only basic fields are fetched.

  2. Filter out the unworkable ones：

    • assignees non-empty → someone has already taken it, skip
    • the issue is pure discussion / a question (title contains "how to" or "question", or the body is a question rather than a task) → skip
    • there is an unmerged PR working on the same thing (see verification in step 3) → skip
    • in recent comments the maintainer explicitly says "already fixed / outdated / no longer needed" → skip

  3. Look deeply at candidate issues one by one(for the 2-4 most promising ones):

    gh issue view <number> --repo <owner>/<repo> --comments \
  --json number,title,body,state,labels,assignees,createdAt,closedAt,comments

    First give the user a plain-language translation of what this issue is about(what it is / what the reporter wants / what done looks like), then go through the checkpoints below. Checkpoints:

    • Whether someone is working on it: whether anyone in the comments has volunteered with "I'll take this"; use gh search prs "repo:<owner>/<repo> is:open <标题关键词>" to see if there is a linked PR
    • Whether it is still valid: whether the bug / requirement described in the body still holds
    • Whether the description is clear: whether there are reproduction steps / expected behavior / acceptance criteria; lower the priority of vague descriptions
    • Maintainer attitude: whether a maintainer has replied and whether they have pointed to the relevant code location

  4. Shallow clone and read the code, to verify "which files need to be changed to take this issue, and how difficult it is":

    mkdir -p <root>/<owner>
git clone --depth 1 https://github.com/<owner>/<repo>.git <root>/<owner>/<repo>

    If it already exists, update it:

    git -C <root>/<owner>/<repo> fetch --depth 1 origin
git -C <root>/<owner>/<repo> reset --hard origin/HEAD

    Then in <root>/<owner>/<repo> use Grep / Read / Glob to locate the code involved in the issue:

    • Search by keywords in the issue body (error messages, function names, module names)
    • Read the relevant files to confirm the scope of changes
    • For bug-type issues: try to walk through the problem path in the code to determine "whether the problem really exists"

  5. Output topic selection suggestions, and for each issue looked at in depth give:

## 选题建议：<owner>/<repo>

### 候选 1：#<number> <issue 标题>
- 现状：3 天前创建，未分配，无关联 PR，maintainer 回复过
- 问题本质：<一句话>
- 改动面：涉及 `src/xxx.py`、`tests/test_xxx.py`，约 2 个文件
- 改动思路：<大致方案，含关键函数/位置>
- 风险：需要处理 XXX 边界情况
- 建议：✅ 适合接（理由） / ⚠️ 有风险（理由） / ❌ 不建议（理由）

Finally, clearly state which issue is recommended to take, and that the next step is to proceed with oss-contribute.

Scenario 2: The user specifies a particular issue

Triggering semantics:

  • "See whether issue #123 can be taken"
  • "Help me evaluate this task"

Process:

  1. Pull the full issue text and comments: 
    gh issue view <number> --repo <owner>/<repo> --comments \
  --json number,title,body,state,labels,assignees,createdAt,comments
    After pulling it, translate first(see item 1 of the "Communication Guidelines" above), then check.
  2. Check each item according to the key points in step 3 of scenario 1 (whether it has been claimed / whether there is a PR / whether it is still valid).
  3. Shallow clone and read the code to verify whether the problem really exists and how large the scope of changes is.
  4. Output the conclusion: can be taken / cannot be taken, with reasons and a change approach.

Scenario 3: There is no suitable issue in the repository at all

Trigger semantics:

  • Scenario 1: Nothing left after filtering
  • The repository's issues are all discussions, all already claimed

Process:

  1. Clearly inform the user that this repository currently has no tasks available to take on; do not force a pick.
  2. Give three options:
    • Switch repositories: go back to oss-finder and switch to the next candidate
    • Relax labels: remove the good first issue restriction and look at all open issues (gh issue list --repo <owner>/<repo> --state open --limit 100), but remind the user that these may have a higher bar
    • Turn to documentation / testing contributions: check whether there are "improve documentation" type issues, or whether the README has outdated parts—these kinds of contributions are the most beginner-friendly
  3. Wait for the user to decide before continuing.

Exception handling

gh not logged in

Guide gh auth login(requires repo permission), then retry after completion.

Shallow clone failed (network / repository too large)

  • Retry once first
  • Still failing: switch to gh api to read the file tree and individual files without downloading the full code: 
    gh api repos/<owner>/<repo>/git/trees/main?recursive=1 --jq '.tree[].path' | grep -i <关键词>
gh api repos/<owner>/<repo>/contents/<path> --jq .content | base64 -d
    And inform the user of the network issue; a proxy may be needed.

Issue description is vague; cannot determine the scope of changes

Do not guess. Write "insufficient information" as one of the conclusions in the topic selection recommendations, mark it as ⚠️, and list the questions that need clarification from the maintainer. Suggest the user either switch issues, or accept the path of "leave a comment to ask clearly first, then start work" (the commenting action is done in oss-contribute).

Candidate issues all point to the same block of code

This indicates that the module is a hotspot and multiple people may be competing for it. Prioritize issues that point to less popular modules to avoid collisions when submitting.

Completion report

  • Target repository and basic information
  • Number of issues reviewed, reasons for filtering
  • For each issue examined in depth: "current state / essence of the problem / scope of changes / approach / risks"
  • A clear topic selection conclusion + next step (oss-contribute)
  • The ending must include a sentence stating "what the next step is / what is being waited on (you / maintainer / CI)"; do not leave it blank for the user to ask.