建议:添加 sr-screener,一种基于协议的研究筛选技能

贡献列出了在"需要维护者批准 + 讨论"下的新技能,因此我在提交之前就开启了此功能。 **它是什么。** `sr-screener` 负责在 `deep-research` (问题、协议、搜索) 和 `academic-paper` (撰写评论) 之间的研究选择步骤。它将提案或 PROSPERO 协议转换为用户确认的资格规则。然后,它使用两个盲评审员子代理 (仅限 Read 和 Grep) 和一个第三个评审员来筛选标题/摘要和全文,并解决他们的分歧。共有八种模式: 协议、快速、试点、ta-screen、ft-screen、裁决、审计和报告。 **为什么在这里。** `deep-research` `systematic-review` 模式生成了协议和搜索,而 `academic-paper` 使用 `literature_corpus[]`,但套件中没有任何功能来生成和记录每条记录的筛选决策。 `sr-screener` 将其输出写入 `literature_corpus[]` 项,这些项与 `literature_corpus_entry.schema.json` 进行验证。它还写入 Prisma 2020 计数和 `academic-paper` 的方法草案。 **人在环节。** - 在用户确认协议之前,没有任何记录被筛选。 - 每批次子代理调用都等待用户批准成本估算。 - 缺失或格式不正确的决策会使记录处于待处理状态;它永远不会成为默认的"排除"。 - 方法草案在任何事项处于待处理状态时都保留数字,并为团队自己的验证留下 `[TO COMPLETE]` 位置。 - 审查团队在报告任何数字之前验证决策。 **证据。** 它源自我用于诊断准确性审查中对约 16,000 条记录进行双标题/摘要筛选的精简筛选代理。在该仓库中尚未测量筛选准确性。一个合成端到端测试(`scripts/test_sr_screener_pipeline.py`)运行了该技能的脚本。 **对维护者的问题。** 1. 默认评审员模型是 `haiku` 用于评审员 A/B,以控制成本: 10,000 条记录的搜索大约需要 400-500 个代理调用。贡献说明称 ARS 提示已校准为"永远不使用 Haiku"。是否应该将默认值移至 `sonnet`,或者是否可以将每个角色、用户确认的配置保留为例外? 2. 路由: 我添加了 Claude.md 路由规则 8 (筛选与 `deep-research` `systematic-review` 的区别),但尚未有 `issue_133_routing` 固定文件。您是否希望在同一 PR 中添加固定文件? 3. Pi Wrapper 不包装技能;我将 `pi/` 保持不变,作为社区维护的内容。实现已在我的分支上准备好: https://GitHub.com/erfanz97/academic-research-skills/tree/feat/sr-screener-skill