---
name: gitlink-research-matching
version: 1.0.0
description: "科研协作智能匹配：纯远程只读分析一个 GitLink 科研仓库——委托 gitlink-insight 取贡献者活跃画像，再自研科研角色匹配（贡献者→数据/算法/工程/评测 角色 × 开放 Issue 科研角色需求），输出证据导向的《科研协作匹配建议记录》。当用户需要判断科研仓库里某个任务该交给哪种科研角色的人、仓内缺不缺会卡住匹配的资源时触发。"
metadata:
  requires:
    bins: ["gitlink-cli"]
  cliHelp: "gitlink-cli issue --help"
---

# gitlink-research-matching（科研协作智能匹配）

**CRITICAL — 开始前必须先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md)，其中包含认证、权限处理和 API 注意事项。**
**CRITICAL — 本 Skill 全程只读，不向仓库写任何内容（不指派、不建 Issue、不评论——科研匹配只是建议，不应污染他人仓库）。**
**CRITICAL — GitLink 操作只能用 `gitlink-cli`，禁止用 `gh`（GitHub CLI）操作 GitLink 资源。**

## 说明

本 Skill 面向**科研场景**，回答一个 `gitlink-insight` 和 `gitlink-issue-triage` 都不回答的问题：**这个科研仓库里的某个开放任务，该交给哪种科研角色的人来做？仓内有没有这种人、缺不缺会卡住匹配的资源？**

它**委托** `gitlink-insight` 跑贡献者活跃画像（"人"侧输入），自己专注科研独有的四部分：①贡献者科研角色推断；②开放 Issue 科研角色需求分析；③人-任务匹配；④服务匹配的仓内资源探测。

**产物哲学（重要）**：输出的是**证据导向的匹配建议记录**，不是分数排名。每条建议先呈现"看到了什么"（Issue 原文 + 贡献者历史证据），让科研负责人**自行决策**；匹配只是建议，不指派、不写入。

## 与 `gitlink-insight` / `gitlink-issue-triage` 的边界

| 维度 | `gitlink-insight`（被委托） | `gitlink-issue-triage`（**完全不碰**） | **`gitlink-research-matching`（本 Skill）** |
|---|---|---|---|
| 核心问题 | 谁**活跃**/贡献多 | 这个 Issue 是**什么工程类型** | 这个**科研任务**该哪种**科研角色**的人做 / 缺什么**科研资源** |
| 分类体系 | 不分类，只活跃度排名 | Bug/Feature/文档/咨询 + 后端/前端/PM | **数据/算法/工程/评测**（科研角色） |
| 动词 | 洞察（指标） | 分拣 + **写入**（打标签/指派/评论） | 匹配（**只读建议**） |
| 产物 | 健康度/周报/贡献者表 | 分拣方案表 + 实际打标签 | 《科研协作匹配建议记录》 |

> 职责正交：insight 管"谁活跃"，triage 管"工程分类+打标签"，本 Skill 管"科研角色匹配"。完全不碰 triage（避免与写入型 triage 纠缠），Issue 的科研角色分析全自研。

## 科研角色分类体系

4 角色，每角色配套可观测信号（贡献者画像）+ Issue 关键词（任务需求）。这是区别于 triage 的后端/前端/PM、insight 的不分类的根本。

| 科研角色 | 职责含义 | 贡献者画像信号（PR 标题 `name` / 分支 `pull_request_head`） | Issue 需求关键词 |
|---|---|---|---|
| **数据** | 数据采集/清洗/标注/数据集制作/加载 | 标题或分支含 `data/`、`dataset`、`dataloader`、`prepare_*`、`download_*` | 数据集、dataset、dataloader、标注、annotation、数据缺失 |
| **算法** | 模型结构/损失/训练逻辑/核心方法 | 标题或分支含 `model`、`loss`、`train`、`src/`、`net`、`backbone` | 模型、model、训练、loss、损失、网络、精度、architecture |
| **工程** | 部署/性能/环境/基础设施 | 标题或分支含 `docker`、`requirements`、`deploy`、`ci`、`env`、`Makefile` | 部署、deploy、环境、docker、安装、fps、内存、推理速度 |
| **评测** | 指标/评测脚本/benchmark/结果验证 | 标题或分支含 `eval`、`evaluate`、`metrics`、`MOTA`、`test`、`benchmark` | 评测、eval、metric、MOTA、MAP、指标、benchmark、复现结果 |

> **科研独有性**：「评测」角色在 dev triage 里根本不存在；「数据」在 triage 里被归成 question/feature，但在科研里是独立角色。

### 多角色标注规则

- 每个贡献者/Issue 标注**主角色 + 次角色**（次角色可空）。
- 主角色 = 证据最多/信号最强的角色；次角色 = 有明确信号但弱于主角色。
- 语义优先，关键词兜底：你是 AI Agent，价值在读懂 Issue 意图（如"训练 loss 不收敛"即使无"算法"字眼也应归算法），上表关键词只是兜底。

### 置信度规则

- 🟢 高：该角色有 ≥2 条明确证据（如 2+ 个该方向 PR）。
- 🟡 中：1 条明确证据，或主次各 1 条但主角色略强。
- 🔴 低：仅 `user +info` 关键词推断 / 信号模糊或冲突。

## ⚠️ 关键接口坑（已实测，务必遵守）

| 需求 | 正确做法 | 说明 |
|---|---|---|
| 读文件内容 | `file +get`→`file +blob`（base64）两步走 | `file +get` 只返回 sha，`content` 恒为 None |
| 读 README | `file +readme` | 唯一一步取明文 content 的命令 |
| PR 按贡献者过滤 | **客户端过滤**（`pr +list` 无服务端 author 过滤） | 按 `data.issues[].author_login` 过滤 |
| PR 状态判断 | 客户端按 `pull_request_status`（0=open,1=merged,2=closed） | `--state` 仅影响统计计数，列表可能含全部状态 |
| PR 标题/作者字段 | `.name`（标题）、`.author_login`（作者） | **平铺字段**，非嵌套；列表项**不含改动文件路径** |

> 数据结构要点：`pr +list` / `issue +list` 返回的 `data` 是**对象**，PR/Issue 列表在 **`data.issues[]`**（不是 `data[]`）。
> `repo +info` **无 `language` 字段**，主语言需从 requirements/文件后缀推断。
> ⚠️ **仓库选择坑**：避免用 GitHub 镜像 repo（`mirror=true`，协作数据在源站，GitLink 上 Issue/PR 基本为空）；优先选原生协作 repo。

## 工作流概览

| 步骤 | 操作 | 命令 |
|------|------|------|
| ① 仓库元信息 + 贡献者活跃画像（委托） | 语言/开放数 + 活跃贡献者 top-5 | `repo +info` + 委托 `gitlink-insight` 工作流3 |
| ② 贡献者科研角色推断（自研） | top-5 每位 → 主+次角色 + 证据 + 置信度 | `pr +list`（客户端按 author 过滤，最近30条）/ `issue +list` / 按需 `user +info` |
| ③ Issue 科研角色需求分析（自研） | 每个 open Issue → 主+次角色 + 原文证据 | `issue +list --state open` / `issue +view` |
| ④ 人-任务匹配（自研） | ②×③ 交叉 → 谁适合做哪个 Issue + 置信度 | （分析，无命令） |
| ⑤ 仓内资源互补（自研，服务匹配） | 数据/权重有无 + 缺资源型 Issue | `dataset +list` / `release +list` / `file +readme` |
| ⑥ 综合裁决 | 四类证据汇总 → 匹配建议记录 | （分析，无命令） |

> 全程只读，串联 ≥6 类 CLI 调用。

---

## 详细工作流

### Step ① 仓库元信息 + 贡献者活跃画像（委托）

```bash
gitlink-cli repo +info --owner <o> --repo <r> --format json
# 委托 gitlink-insight 工作流3（贡献者洞察）：按 ../gitlink-insight/SKILL.md 的「工作流 3」执行
#   → 取活跃贡献者（按合并 PR 数排序），截断 top-5
```

记录：主语言（供 Step ②③ 关键词映射）、开放 Issue 数、活跃贡献者 top-5（不足 5 人以实际为准）。

> 活跃贡献者也可直接从 PR 列表聚合 author_login 得到（见 Step ② 的 PR 拉取）。

### Step ② 贡献者科研角色推断（多源，自研）

对 top-5 每位贡献者：

```bash
# a. 拉取该仓库全部 PR（列表项含 author_login / name 标题 / pull_request_head 分支 / pull_request_status）
gitlink-cli pr +list --owner <o> --repo <r> --format json \
  | jq '[.data.issues[] | {author: .author_login, title: .name, branch: .pull_request_head, status: .pull_request_status}]'
#   → 客户端按 author == "<contributor>" 过滤，取最近 30 条
#   → 看 title(name) + 分支(pull_request_head)，按角色体系匹配

# b. 该贡献者关闭/参与过的 Issue（客户端按 author_login 过滤）
gitlink-cli issue +list --owner <o> --repo <r> --state closed --format json \
  | jq '[.data.issues[] | {author: .author_login, subject}]'
```

**按需深挖（仅当 a+b 信号不足以判定主角色时）**：

```bash
# c. user +info（只看名/简介关键词，不深挖其他 repo 内容）
gitlink-cli user +info --login <user> --format json
```

**输出**：每位贡献者 → 主角色 + 次角色（可空）+ 证据（哪几条 PR/Issue 支撑）+ 置信度（见角色体系置信度规则）。

> ⚠️ PR 列表项**不含改动文件路径**，贡献者方向只能靠 PR 标题 `name` + 分支名 `pull_request_head` 推断（如分支 `feature/dataloader` → 数据角色）。

### Step ③ Issue 科研角色需求分析（自研）

```bash
gitlink-cli issue +list --owner <o> --repo <r> --state open --format json \
  | jq '[.data.issues[] | {number, subject, author: .author_login, tags: .issue_tags}]'
# 逐个读详情
gitlink-cli issue +view --owner <o> --repo <r> --number <n> --format json
#   → 读 subject + description，按角色体系的 Issue 关键词语义归类
```

**输出**：每个 open Issue → 所需主角色 + 次角色 + 原文证据片段。

> 与 triage 的根本区别：triage 归 bug/feature/咨询，本 Skill 归**科研角色需求**（这个 Issue 本质需要数据/算法/工程/评测哪种人）。"训练 loss 不收敛" triage 可能归 bug，本 Skill 归**算法**。

### Step ④ 人-任务匹配（自研）

②（贡献者角色）× ③（Issue 角色需求）交叉：

- **主角色匹配**：Issue 主角色 == 贡献者主角色 → 高置信度候选。
- **次角色匹配**：Issue 主角色 == 贡献者次角色，或 Issue 次角色命中 → 中置信度候选。
- **无匹配 → 分两类**（关键，避免"缺人/缺资源"混淆）：
  - **角色缺口**：Issue 所需角色无任何 top-5 贡献者覆盖（**缺人**）→ 记入报告"未匹配/缺口"表，类型=角色缺口，**不进入 Step⑤**。
  - **缺资源型**：Issue 在"要数据/要权重/要评测基准"，即使有人匹配也会被资源卡住 → 在 Step⑤ 用资源探测确认，并在匹配建议里打资源前提标签。

> 区分原则：先判角色是否有人覆盖（Step④），再判资源是否就绪（Step⑤）。**缺人 ≠ 缺资源**，两者报告分列。

### Step ⑤ 仓内资源互补（收窄，服务匹配，自研）

**只查与 open Issue/任务相关的资源缺口**，不做全面复现性清点（那是 `gitlink-research-compliance` 的活）：

```bash
# 数据集有无
gitlink-cli dataset +list --owner <o> --repo <r> --format json
#   → .data.releases（计数：.data.releases | length）
# 预训练权重/数据包
gitlink-cli release +list --owner <o> --repo <r> --format json
#   → .data.releases（计数同上）
# README 数据/权重说明（明文）
gitlink-cli file +readme --owner <o> --repo <r> --format json
#   → 搜 download/weights/pretrained/数据集/指标 等
```

**判定**：
- 识别**缺资源型 Issue**：Issue 在"要数据/要权重/要评测基准"（关键词：数据集、weights、pretrained、download、指标、复现结果），而仓内 `dataset +list` 为空 / 无权重 release。
- 给 Step④ 匹配建议打**资源前提标签**：如"某某适合做（算法），但阻塞于缺评测数据集"。

> 与 `gitlink-research-compliance` 的区别：它问"仓库整体能不能复现"（全面清点），本 Skill 只问"**这个任务**缺不缺资源、会不会卡住匹配的人"（服务匹配，点到为止）。

### Step ⑥ 综合裁决

汇总四类证据，输出《科研协作匹配建议记录》。**先证据，后建议**，匹配只是建议，不指派、不写入。

## 综合匹配建议报告模板

````markdown
🤝 科研协作匹配建议记录 — <owner>/<repo>
═══════════════════════════════════════════════════
生成日期: <YYYY-MM-DD>   主语言: <lang>
开放 Issue: <n>   贡献者画像: top-<N>（委托 gitlink-insight）
建议方式: 纯远程只读（gitlink-cli repo/issue/pr/dataset/release/file）。
说明: 所有匹配均为只读建议，不指派、不写入；请结合团队实际自行决策。

───────────────────────────────────────────────────
一、贡献者科研角色画像（top-<N>）
───────────────────────────────────────────────────
| 贡献者 | 活跃度(insight) | 主角色 | 次角色 | 置信度 | 证据 |
|--------|-----------------|--------|--------|--------|------|
| <user> | <合并PR n> 最近活跃<date> | 算法 | 评测 | 🟢高 | PR"改进loss"×3, 分支 eval/*×2 |

───────────────────────────────────────────────────
二、开放 Issue 科研角色需求
───────────────────────────────────────────────────
| #Issue | 标题 | 主角色需求 | 次角色 | 缺资源型? | 原文证据 |
|--------|------|-----------|--------|-----------|----------|
| <n> | <标题> | 算法 | — | 否 | "训练 loss 不收敛"→算法 |
| <m> | <标题> | 评测 | — | ⚠️是 | "缺评测数据集，dataset+list为空" |

───────────────────────────────────────────────────
三、人-任务匹配建议（核心）
───────────────────────────────────────────────────
| #Issue | 建议人选 | 匹配角色 | 置信度 | 资源前提 | 理由 |
|--------|----------|----------|--------|----------|------|
| <n> | <userA> | 主角色(算法) | 🟢高 | 无 | 该Issue需算法，userA主角色算法(3个loss相关PR) |
| <m> | <userB> | 次角色(评测) | 🟡中 | ⚠️阻塞于缺评测数据集 | 该Issue需评测，userB次角色评测，但仓内无数据集 |

未匹配/缺口 Issue:
| #Issue | 所需角色 | 类型 | 说明 |
|--------|----------|------|------|
| <k> | 工程 | 角色缺口 | top-5无工程角色贡献者（缺人，非缺资源） |
| <j> | 数据 | 缺资源型 | Issue要数据但仓内无数据集（缺资源，非缺人） |

───────────────────────────────────────────────────
四、仓内资源互补（仅服务匹配）
───────────────────────────────────────────────────
[证据]
  • GitLink 原生数据集: dataset +list → <有n个/无>
  • 预训练权重: release +list → <有n个/无>
  • README 数据/权重说明: "<原文片段>" / 未发现
[发现]
  • 缺资源型 Issue: <#j, #m ...>（共n个）
  • 这些 Issue 即使匹配到人也会被资源卡住

═══════════════════════════════════════════════════
匹配状况概览（统计，非评分 — 算分会惩罚"正确识别缺口"）
  开放 Issue: <n>
  ├─ 已匹配(有候选贡献者): <a>  (🟢高置信 <h> / 🟡中置信 <m>)
  ├─ 角色缺口(缺人): <b>         — 所需角色 top-<N> 未覆盖
  └─ 缺资源型(缺数据/权重): <c>   — 有人匹配也会被卡住
  贡献者角色覆盖: 数据<✓/✗> 算法<✓/✗> 工程<✓/✗> 评测<✓/✗>
═══════════════════════════════════════════════════
````

> 报告主体是建议表与证据，概览只给一眼可读的计数。不算分、不评级——匹配是建议而非客观事实，分数会惩罚"正确识别缺口"的行为（准确标出角色缺口反让覆盖度/消化力扣分）。

## 使用示例

见 [`examples/matching-run.md`](examples/matching-run.md)：在 `<验证仓库>` 上的完整匹配记录。

## 注意事项

- 本 Skill **全程只读**，不写仓库、不建 Issue、不指派——科研匹配只是建议，应尊重他人仓库。
- **不碰 `gitlink-issue-triage`**：triage 会写入（打标签/指派/评论），本 Skill 避免与其耦合，Issue 科研角色分析全自研。
- 多源画像有**截断策略**控制成本：贡献者取 top-5；PR/Issue 历史取最近 30 条；`user +info` 仅对"角色不明者"按需补，不全员深挖、不读用户其他 repo 内容。
- `pr +list` 无服务端 author 过滤，须客户端过滤；`--state` 不精确，按 `pull_request_status` 二次判断。
- 角色关键词表是**兜底**，语义优先（AI Agent 读懂 Issue 意图）。
- 资源互补严格**服务匹配**，不做全面复现性清点（那是 `gitlink-research-compliance`）。
- 团队实际分工受成员可用性影响，匹配建议仅供参考，不替负责人决策。
