skills/gitlink-research-matching/SKILL.md

@@ -0,0 +1,257 @@
+---
+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`）。
+- 团队实际分工受成员可用性影响，匹配建议仅供参考，不替负责人决策。

skills/gitlink-research-matching/examples/matching-run.md

@@ -0,0 +1,160 @@
+# gitlink-research-matching 运行记录模板
+
+> **状态说明（重要，务必先读）**：本文档是一份**可复现执行脚本模板**，包含完整的命令序列、`jq` 解析逻辑与**预期输出结构**。
+>
+> 它**尚未在理想的"原生协作型科研仓库"上填入真实报告数据**。原因：探测发现 GitLink 平台上原生科研仓库普遍缺乏协作 PR+Issue 数据（多为 GitHub 镜像、单作者展示型、或大赛 repo），少数有 PR 的仓库（如 `mindspore/mindspore`）是 CCF 比赛 repo——每个 PR 是一支队伍的独立参赛作品，而非同仓库协作改模块，与本 Skill「同仓库科研角色协作分工」的核心设计错配，硬跑会产出扭曲的空报告。
+>
+> **如何使用本模板**：找到一个 GitLink 上**原生（`mirror:false`）、有 ≥10 个协作 PR、有多个 open Issue 的科研仓库**后，把下文 `<owner>/<repo>` 替换为目标仓库，逐 Step 执行命令，将真实输出与推断填入对应位置，替换本说明段，即得到一份真实的《科研协作匹配建议记录》。
+>
+> 命令与 `jq` 解析逻辑均已用 `gitlink-cli` 实测数据结构校验（见下文「数据结构基准」），替换仓库后可直接复用。
+
+---
+
+## 0. 环境与前置
+
+```bash
+gitlink-cli auth status          # 确认已登录
+gitlink-cli pr +list --help      # 确认子命令可用
+```
+
+**数据结构基准**（实测 `gitlink-cli`，2026-06-29）：
+- 所有命令 `--format json` → `{ok, data, meta}`。
+- `pr +list` / `issue +list` 的 `data` 是对象，PR/Issue 列表在 **`data.issues[]`**。
+- PR 项：`author_login`（作者，平铺）、`name`（标题）、`pull_request_head`（分支）、`pull_request_status`（0=open,1=merged,2=closed）。
+- Issue 项：`number`、`subject`、`author_login`、`issue_tags`。
+- `dataset +list` / `release +list`：列表在 `data.releases[]`（计数 `length`；`dataset +list` 在某些仓库可能报 parse error，需注意）。
+- `repo +info`：有 `issues_count`/`pull_requests_count`/`mirror`，**无 `language`**。
+- `user +info --login <login>`：返回 `login`/`name`/`bio`（可能为 null）。
+
+---
+
+## Step ① 仓库元信息 + 贡献者活跃画像
+
+```bash
+# 仓库元信息
+gitlink-cli repo +info --owner <owner> --repo <repo> --format json \
+  | jq '{name:.data.name, issue:.data.issues_count, pr:.data.pull_requests_count, mirror:.data.mirror}'
+```
+**预期输出结构**（待填）：
+```
+{ "name": "<...>", "issue": <n>, "pr": <n>, "mirror": false }
+```
+
+```bash
+# 委托 gitlink-insight 工作流3 取贡献者活跃画像 → 活跃贡献者 top-5
+#   按 ../gitlink-insight/SKILL.md「工作流 3」执行，记录每位：合并PR数、最近活跃时间
+```
+
+**或直接从 PR 聚合作者活跃度**（与 insight 互补）：
+```bash
+gitlink-cli pr +list --owner <owner> --repo <repo> --format json \
+  | jq '[.data.issues[].author_login] | group_by(.) | map({author:.[0], n:length}) | sort_by(-.n) | .[0:5]'
+```
+**预期输出结构**：
+```
+[ {"author":"<u1>","n":<x1>}, {"author":"<u2>","n":<x2>}, ... ]   # top-5
+```
+
+**记录（待填）**：主语言=___；开放 Issue=___；活跃贡献者 top-5 = ___
+
+---
+
+## Step ② 贡献者科研角色推断（多源）
+
+对 top-5 每位贡献者拉取其 PR（标题+分支作为角色证据）：
+
+```bash
+gitlink-cli pr +list --owner <owner> --repo <repo> --format json \
+  | jq -r --arg u "<contributor>" '.data.issues[] | select(.author_login==$u) | "\(.name) | 分支:\(.pull_request_head // "?") | 状态:\(.pull_request_status)"'
+```
+**预期输出结构**（每位贡献者，待填）：
+```
+<PR标题1> | 分支:<branch1> | 状态:<0/1/2>
+<PR标题2> | 分支:<branch2> | 状态:<0/1/2>
+```
+
+按需深挖（角色不明者）：
+```bash
+gitlink-cli user +info --login <contributor> --format json \
+  | jq '{login:.data.login, name:.data.name, bio:.data.description}'
+```
+
+**角色推断（按 SKILL.md 角色体系，待填）**：
+
+| 贡献者 | 主角色 | 次角色 | 置信度 | 证据 |
+|--------|--------|--------|--------|------|
+| `<u1>` | ___ | ___ | ___ | `<PR标题/分支>→<角色>` |
+
+---
+
+## Step ③ Issue 科研角色需求分析
+
+```bash
+gitlink-cli issue +list --owner <owner> --repo <repo> --state open --format json \
+  | jq '[.data.issues[] | {number, subject, author:.author_login, tags:.issue_tags}]'
+```
+**预期输出结构**：
+```
+[ {"number":<n>,"subject":"<标题>","author":"<u>","tags":[...]}, ... ]
+```
+
+逐个读详情：
+```bash
+gitlink-cli issue +view --owner <owner> --repo <repo> --number <n> --format json \
+  | jq '{subject:.data.subject, desc:(.data.description // "" | .[0:200])}'
+```
+
+**Issue 科研角色需求（待填）**：
+
+| #Issue | 标题 | 主角色需求 | 次角色 | 缺资源型? | 原文证据 |
+|--------|------|-----------|--------|-----------|----------|
+| `<n>` | `<标题>` | ___ | ___ | ___ | `"<原文>"→<角色>` |
+
+---
+
+## Step ④ 人-任务匹配（分析，无命令）
+
+②（贡献者角色）× ③（Issue 需求）交叉。规则见 SKILL.md Step④。
+- 主角色匹配 → 高置信；次角色匹配 → 中置信；无覆盖 → 角色缺口（记入缺口表）。
+
+**匹配建议（待填）**：
+
+| #Issue | 建议人选 | 匹配角色 | 置信度 | 资源前提 | 理由 |
+|--------|----------|----------|--------|----------|------|
+| `<n>` | `<u>` | ___ | ___ | ___ | ___ |
+
+---
+
+## Step ⑤ 仓内资源互补（服务匹配）
+
+```bash
+# 数据集
+gitlink-cli dataset +list --owner <owner> --repo <repo> --format json \
+  | jq '{releases_len:(.data.releases|length?)}'     # 注意：某些仓库可能 parse error
+# 权重/release
+gitlink-cli release +list --owner <owner> --repo <repo> --format json \
+  | jq '{releases_len:(.data.releases|length)}'
+# README 数据/权重说明
+gitlink-cli file +readme --owner <owner> --repo <repo> --format json \
+  | jq -r '.data.content' | grep -iE "download|weights|pretrained|数据集|指标|dataset" | head -5
+```
+**预期输出结构**：数据集=___个；release=___个；README 数据/权重说明=___。
+
+**判定**：识别"缺资源型 Issue"（Issue 要数据/权重，仓内无）→ 给匹配建议打资源前提标签。
+
+---
+
+## Step ⑥ 最终报告（待真实数据填充）
+
+> 按 SKILL.md「综合匹配建议报告模板」填写四张表 + 缺口表 + 统计概览。模板见 `../SKILL.md`。
+
+---
+
+## 附：在 mindspore/mindspore 上的探测记录（说明为何该仓库不适配）
+
+为完整记录探测过程，此处留存 `mindspore/mindspore`（CCF 比赛 repo）的实测数据，作为**仓库选型反例**：
+
+- **仓库本质**：CCF MindSpore AI 应用创新大赛仓库。每个 PR = 一支队伍的**完整参赛项目作品**（非协作改模块）；唯一 Issue = 大赛公告。
+- **数据**：19 个 PR（14 open / 5 closed），top 作者 Cvmax7(4)、limingjing2024(2)、zijunliang(2)…；PR 标题如"孕心导航——基于MindSpore的智慧孕育AIGC守护者""基于ViLT多模态模型的网络暴力检测"，分支是队名（如 `孕心导航_plugins`）。
+- **为何不适配**：PR 标题语义全是"参赛应用主题"，硬映射到 数据/算法/工程/评测 角色是牵强的；无真正待分配的 Issue（唯一 Issue 是赛公告），故"人-任务匹配"核心③为空；每人是自己参赛项目全栈，"贡献者角色画像"会全标成全栈，扭曲 Skill 设计。
+- **结论**：演示本 Skill 需要的是"同仓库协作分工"型仓库，而非大赛作品提交型仓库。