mcpField
G
grant-builder

grant-builder

github.com/aperivue文档处理353111 次安装1 天前更新
代码仓库

关于 grant-builder

用于根据资助指南撰写研究项目申请的技能，可生成申请章节、里程碑、分工和评估计划。它强调基于证据的论述、问题框架需经用户确认，以及切实可行的执行计划。

主要功能

  1. 01按资助指南调整申请结构
  2. 02撰写研究目标和申请章节
  3. 03规划里程碑与机构分工
  4. 04构建评估和风险框架
  5. 05标记缺乏依据的论述和假设

适用场景

  1. 01准备资助项目的研究计划
  2. 02组织韩国产学合作项目申请
  3. 03审查项目目标、验证和执行计划

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/aperivue/medsci-skills --skill grant-builder

安装后在 Claude Code 中输入/grant-builder确认已加载。

附带文件skill.yml

详细介绍

Grant-Builder 技能

使用目标项目要求的语言撰写提案正文。根据请求，生成所需部分：概念摘要、重要性、创新性、研究方案、具体目标、工作包、里程碑表、按机构划分的角色、评估框架、评审风险备忘录。

韩国政府资助项目模式

当用户申请韩国产学合作项目（산학과제）或研究计划书（연구계획서）时—— 例如 MOHW、MOTIE、MSS 或地区产学合作项目——请采用以下调整。 韩国项目术语需保留在括号中，因为这是资助机构模板使用的原文。

文档结构（三附件格式）
附件内容
1（첨부1, 기본정보）项目名称、参与机构、研究人员简历、论文／专利记录
2（첨부2, 매칭확인서）各机构的成本分担确认，通常在各机构举行启动会议后最终确定
3（첨부3, 연구계획서）10 页研究计划书——结构如下
1. Significance & Aims (약 2p)
   - clinical problem with quantitative framing
   - domestic + international trends (3–5 year literature / guideline window)
   - differentiation of the proposed work

2. Research Content & Methods (약 4p)
   - staged roadmap (Phase 1 – N with time ranges)
   - pipeline schematic (mandatory when an AI pipeline is in scope)
   - per-subproject institution and personnel assignment

3. Team Capability (약 1p)
   - expertise + representative record (SCI papers, patents) per investigator
   - cross-institution synergy (hospital = data / clinical; university = algorithm)

4. Expected Outcomes & Utilization (약 2p)
   - quantitative targets: SCI papers, patents
   - qualitative targets: clinical impact, standardization contribution
   - linkage to follow-on larger grants (positioning as a seed)

5. Budget Plan (약 1p)
   - RA salaries, computing equipment, consumables, academic activities, indirect costs
小规模资助（< KRW 30 million）
  • 面向非专业评审撰写；假设评审者并非你所在的细分领域专家。
  • 强调可行性，而非技术新颖性。
  • 优先遵守篇幅／格式要求；超出模板会导致评分扣分。
  • 尽可能纳入初步数据或试点结果。
  • 定量目标应保持保守——未达到承诺目标所受的惩罚，大于适度超额完成保守目标所带来的收益。

工作流

阶段 1：解读资助项目征集要求

提取资助机构、征集主题、资格限制、交付成果要求、时间线和评估标准。如果没有征集文本，则推断通用的学术医疗 AI 提案结构，并标明所作假设。

阶段 2：界定问题

明确临床痛点、当前工作流的局限、现有 AI 或标准护理为何不足，以及项目成功后谁将受益。

**关卡：**向用户呈现问题界定（临床痛点、差距、拟议解决方案）。在构建提案章节前获得确认——问题界定不当会导致提案无法获得资助。

阶段 3：构建提案主线

始终阐明：问题、差距、拟议解决方案、团队为何能够执行、可衡量的产出。

阶段 4：转换为提案章节
  • 重要性必须回答：这在临床上为何重要、为何是现在、为何值得为拟议解决方案提供资助。
  • 创新性：真正的新意是什么、为何这种整合是新的、新颖性为何有用而非仅具技术性。
  • 研究方案：数据集和参与站点、模型或工作流组件、验证计划、基准／对照、失败分析、风险缓解。

调用 search-lit 支持重要性论述和既有技术定位；仅在 /search-lit 确认 DOI 或 PMID 后引用文献，否则标注为 [UNVERIFIED - NEEDS MANUAL CHECK]。任何未经确认的临床定义、诊断标准或指南建议均标注为 [VERIFY]，并向用户询问。如果评估框架薄弱，则调用 design-study；仅当提案需要论文风格的叙述章节时，才调用 write-paper。

阶段 5：执行计划

按季度或年度制定里程碑、机构级职责、依赖关系和交接事项，以及所需基础设施。不得编造预算细节，也不得承诺用户未提供证据的数据集、合作伙伴或基础设施。

默认结构

## Proposal Summary
Title: ...
Goal: ...
Clinical problem: ...

### Significance
...

### Innovation
...

### Approach
Aim 1. ...
Aim 2. ...
Aim 3. ...

### Milestones
- ...

### Consortium roles
- ...

### Major risks and mitigations
- ...

定稿前

请检查并向用户指出任何不足：

  1. 临床需求是否明确且可信？
  2. 创新之处是否不止于“我们将使用 AI”，并具有临床意义？
  3. 研究目标是否与可衡量的产出相关联，并设有明确的基准或成功标准？
  4. 验证计划是否令人信服，包括外部验证或部署路径？
  5. 多机构合作结构是否切实可行，且每家机构都承担不同、功能上相互整合的角色？
  6. 是否说明了计算资源、标注和监管方面的需求？
  7. 对于项目时间安排而言，研究目标是否过多？
  8. 整体是否体现出一个获得资助的项目，而非一篇论文？

评论

支持 Markdown