| name | nsfc-research-foundation-writer |
| version | 0.1.2 |
| description | 当用户明确要求"写/改研究基础""研究基础+工作条件+风险应对编排"时使用。为 NSFC 正文"（三）研究基础"写作/重构，并同步编排"工作条件"和"研究风险应对"，用证据链证明项目可行、资源条件对位研究内容、风险预案可执行。 |
| author | Bensz Conan |
| metadata | {"author":"Bensz Conan","short-description":"NSFC（研究基础+工作条件+风险应对）编排写作","keywords":["nsfc-research-foundation-writer","研究基础","可行性分析","工作条件","平台团队","风险应对"],"triggers":["研究基础","前期基础","可行性","工作条件","平台","风险应对"]} |
| config | skills/nsfc-research-foundation-writer/config.yaml |
| references | skills/nsfc-research-foundation-writer/references/ |
NSFC（三）研究基础编排写作器
BenszAPI 任务工作区
本 Skill 的新任务中间文件统一写入 ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/。同一任务复用一个任务根目录；多 Skill 协作才创建 shared/。正式交付物不写入该目录，历史隐藏目录只允许显式兼容读取、迁移或清理。
与 bensz-collect-bugs 的协作约定
- 当用户环境中出现因本 skill 设计缺陷导致的 bug 时，优先使用
bensz-collect-bugs 按规范记录到 ~/.bensz-skills/bugs/，严禁直接修改用户本地 Claude Code / Codex 中已安装的 skill 源码。
- 若 AI 仍可通过 workaround 继续完成用户任务，应先记录 bug，再继续完成当前任务。
- 当用户明确要求“report bensz skills bugs”等公开上报动作时，调用本地
gh 与 bensz-collect-bugs，仅上传新增 bug 到 huangwb8/bensz-bugs；不要 pull / clone 整个 bug 仓库。
目标输出（契约）
- 写入落点（2 个文件）：
extraTex/3.1.研究基础.tex（包含“研究风险的应对措施”）extraTex/3.2.工作条件.tex
- 禁止改动：
main.tex、extraTex/@config.tex、任何 .cls/.sty
- 核心目标：用“证据链 + 条件对位 + 风险预案”回答评审的三个问题：你做过吗？你做得成吗？出问题你怎么兜底？
参数与输出模式（建议显式提供）
project_root：标书项目根目录（如 projects/NSFC_Young）output_mode（默认 apply）：
preview：只输出两段可复制的 LaTeX 正文草稿（并标注应写入的目标文件路径），不写入文件apply：仅写入两份目标文件（见“目标输出”），不触碰其他文件
必需输入（最小信息表）
写入安全约束（必须遵守）
- 仅编辑两份
extraTex/3.*.tex 文件；不得修改 main.tex、extraTex/@config.tex、任何 .cls/.sty
- 目标文件若已包含标题命令（如
\\subsection{...} / \\subsubsection{...}），只替换正文内容，不改标题与结构层级
- 信息不全时先提问补齐；不得捏造论文题目/期刊/专利号/样本量/指标等“看起来像真的”细节
工作流（按顺序执行）
- 定位项目与目标文件：
- 验证
project_root 是否存在，不存在时报错并提示用户指定正确路径
- 检查
extraTex/ 目录是否存在，不存在时提示用户先初始化/拷贝模板项目；必要时可在用户确认后创建
- 确认
project_root 和 output_mode（默认为 apply）
preview 模式：只生成内容预览，不写入文件（适合调试）apply 模式：将生成的内容写入 extraTex/3.1.研究基础.tex 和 extraTex/3.2.工作条件.tex
- 仅编辑这两个文件，禁止修改
main.tex、extraTex/@config.tex、任何 .cls/.sty
- 生成
3.1 研究基础（证据链优先）：
- 研究积累：围绕
2.1 的关键任务，列出“做过什么/掌握什么/已有平台什么”。
- 阶段性成果：只写可核验内容（论文/专利/数据/原型/预实验现象）；不确定的细节用占位符要求用户补齐。
- 可行性四维：理论/技术/团队/条件各给 1–3 个支撑点，并与研究内容逐条对齐。
- 在
3.1 中显式写“研究风险的应对措施”：
- 至少 3 条风险（技术/进度/资源各至少 1 条）
- 每条：风险描述 → 早期信号（触发阈值/现象）→ 预案/替代路线（含降级目标与可交付）
- 生成
3.2 工作条件（条件对位研究内容）：
- 已具备条件：逐条列出，格式建议：
- 平台：XXX 平台（已具备 / 可访问）
- 数据：XXX 数据集（已获取 / 可公开获取）
- 样本：XXX 医院/机构（已签署合作协议 / 伦理审批中）
- 算力：XXX 服务器 / GPU（已配置 / 共享使用）
- 团队分工：成员 A 负责 XX，成员 B 负责 YY
- 合规路径：伦理审批（XXX 委员会，周期 X 个月）
- 尚缺条件与解决途径：逐条列出，格式建议：
- 缺少条件：XXX（影响：YYY）
- 解决途径：采购 / 合作 / 替代数据源 / 实验降级方案
- 时间表与责任人：如用户提供，应写入；如未提供，用占位符标记
- 一致性校验：
- 校验 1：检查
3.2 工作条件 是否能逐条支撑 2.1 的关键任务
- 方法：列出
2.1 的每个关键任务，确认 3.2 中有对应的条件支撑
- 示例：
- 任务 1：XXX 实验 → 条件：XXX 平台、XXX 样本
- 任务 2：YYY 算法 → 条件：YYY 算力、ZZZ 数据
- 校验 2：检查风险预案是否与年度计划可兼容
- 方法：列出
2.3 的每年里程碑，确认风险预案有对应的降级方案
- 示例：
- 第一年：样本获取 → 风险：样本入组慢 → 预案：有替代数据源与降级验证方案
- 校验失败时的处理：
- 如果发现不一致，标记为
[需补充：XXX] 并提示用户
验收标准（Definition of Done）
质量契约验证（来自 config.yaml）
- 研究基础必须覆盖：
- 与本项目相关的研究积累（证据链）
- 已取得的阶段性成果（可核验）
- 可行性要点（理论/技术/团队/条件）
- 研究风险与应对措施（显式写出）
- 工作条件必须覆盖：
- 已具备条件（平台/数据/样本/算力/团队/合规）
- 尚缺条件与解决途径（时间/预算/合作/采购/替代方案）
详细检查清单
见：references/dod_checklist.md
可选脚本自检（只读）
- 仅校验 skill 自身结构一致性：
python3 skills/nsfc-research-foundation-writer/scripts/validate_skill.py
- 同时检查某个项目的输出文件（存在性 + 轻量内容启发式）：
python3 skills/nsfc-research-foundation-writer/scripts/run_checks.py --project-root <你的project_root>
常见问题与边缘情况
Q1: 项目目录中没有 extraTex/ 目录怎么办？
A: 建议先确认 project_root 指向正确的标书项目根目录；若确实缺少 extraTex/，请手动创建：
mkdir -p "<你的project_root>/extraTex"
Q2: 我还没有写 2.1 研究内容，可以直接写 3.1 研究基础 吗？
A: 不建议。3.2 工作条件 需要与 2.1 的关键任务对齐。建议先使用 nsfc-research-content-writer 完成 2.1。
Q3: 信息表中的某些内容我不方便公开怎么办？
A: 可以提供"可核验线索"而非完整内容。例如：
- ❌ "我们在 Nature 上发表了论文 XXX"
- ✅ "我们发表过相关论文（可提供 DOI/题录/接收函编号等可核验线索）"
Q4: 风险应对必须写 3 条吗？
A: 是的，至少 3 条（技术/进度/资源各至少 1 条）。即便你认为风险较低，也建议按三类各写 1 条“低风险 + 监测信号 + 预案”，避免评审认为你没有兜底意识。
Q5: 我的信息表内容很少，能生成完整的研究基础吗？
A: 可以。AI 会根据你提供的信息生成内容，并在不确定的地方使用占位符（如 [请补充：XXX]），请你后续补全。
变更记录
- 本技能的变更历史记录在本目录的
CHANGELOG.md，并同步到根级 CHANGELOG.md；SKILL.md 仅维护“AI 执行规范”。
