/nsfc-research-foundation-writer

name: nsfc-research-foundation-writer
description: '当用户明确要求"写/改研究基础""研究基础+工作条件+风险应对编排"时使用。为 NSFC 正文"（三）研究基础"写作/重构，并同步编排"工作条件"和"研究风险应对"，用证据链证明项目可行、资源条件对位研究内容、风险预案可执行。'
metadata:
  author: Bensz Conan

NSFC（三）研究基础编排写作器

目标输出（契约）

• **写入落点（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`：仅写入两份目标文件（见“目标输出”），不触碰其他文件

必需输入（最小信息表）

• 若用户未提供，请先收集/补全：[references/info_form.md](references/info_form.md)

流程

输入

按用户请求和配置文件提供必要输入；缺失信息应明确列出并停止依赖该输入的步骤。

执行步骤

• 当用户环境中出现因本 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 仓库。

1. **定位项目与目标文件**：

• 验证 `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`

2. **生成 `3.1 研究基础`（证据链优先）**：

• 研究积累：围绕 `2.1` 的关键任务，列出“做过什么/掌握什么/已有平台什么”。
• 阶段性成果：只写可核验内容（论文/专利/数据/原型/预实验现象）；不确定的细节用占位符要求用户补齐。
• 可行性四维：理论/技术/团队/条件各给 1–3 个支撑点，并与研究内容逐条对齐。

3. **在 `3.1` 中显式写“研究风险的应对措施”**：

• 至少 3 条风险（技术/进度/资源各至少 1 条）
• 每条：风险描述 → 早期信号（触发阈值/现象）→ 预案/替代路线（含降级目标与可交付）

4. **生成 `3.2 工作条件`（条件对位研究内容）**：

• **已具备条件**：逐条列出，格式建议：
• 平台：XXX 平台（已具备 / 可访问）
• 数据：XXX 数据集（已获取 / 可公开获取）
• 样本：XXX 医院/机构（已签署合作协议 / 伦理审批中）
• 算力：XXX 服务器 / GPU（已配置 / 共享使用）
• 团队分工：成员 A 负责 XX，成员 B 负责 YY
• 合规路径：伦理审批（XXX 委员会，周期 X 个月）
• **尚缺条件与解决途径**：逐条列出，格式建议：
• 缺少条件：XXX（影响：YYY）
• 解决途径：采购 / 合作 / 替代数据源 / 实验降级方案
• 时间表与责任人：如用户提供，应写入；如未提供，用占位符标记

5. **一致性校验**：

• **校验 1**：检查 `3.2 工作条件` 是否能逐条支撑 `2.1` 的关键任务
• 方法：列出 `2.1` 的每个关键任务，确认 `3.2` 中有对应的条件支撑
• 示例：
• 任务 1：XXX 实验 → 条件：XXX 平台、XXX 样本
• 任务 2：YYY 算法 → 条件：YYY 算力、ZZZ 数据
• **校验 2**：检查风险预案是否与年度计划可兼容
• 方法：列出 `2.3` 的每年里程碑，确认风险预案有对应的降级方案
• 示例：
• 第一年：样本获取 → 风险：样本入组慢 → 预案：有替代数据源与降级验证方案
• **校验失败时的处理**：
• 如果发现不一致，标记为 `[需补充：XXX]` 并提示用户
• 如果用户未提供 `2.1` 或 `2.3`，跳过对应校验并提示用户

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 执行规范”。

输出

输出 Skill description 所承诺的交付物，并明确格式、路径和失败返回形式。

输出管理

本 Skill 的新任务中间文件统一写入 `./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/`。同一任务复用一个任务根目录；多 Skill 协作才创建 `shared/`。正式交付物不写入该目录，历史隐藏目录只允许显式兼容读取、迁移或清理。

校验

质量契约验证（来自 config.yaml）

• 研究基础必须覆盖：
• 与本项目相关的研究积累（证据链）
• 已取得的阶段性成果（可核验）
• 可行性要点（理论/技术/团队/条件）
• 研究风险与应对措施（显式写出）
• 工作条件必须覆盖：
• 已具备条件（平台/数据/样本/算力/团队/合规）
• 尚缺条件与解决途径（时间/预算/合作/采购/替代方案）

详细检查清单

见：[references/dod_checklist.md](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>`

失败与恢复

保留错误证据和已完成产物；仅在输入、环境或外部依赖恢复后从最近的失败步骤重试。

约束

1. 仅编辑两份 `extraTex/3.*.tex` 文件；不得修改 `main.tex`、`extraTex/@config.tex`、任何 `.cls/.sty` 2. 目标文件若已包含标题命令（如 `\\subsection{...}` / `\\subsubsection{...}`），**只替换正文内容**，不改标题与结构层级 3. 信息不全时先提问补齐；不得捏造论文题目/期刊/专利号/样本量/指标等“看起来像真的”细节

公共硬约束

• 任务需要落盘时，使用唯一的 `./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/` 根目录；共享材料放入 `shared/`，Skill 专属材料放入该 Skill 的 `input/`、`output/`、`log/`。
• 正式交付物、源代码和正式计划按项目约定保存，不写入任务工作区；未经授权不覆盖、删除、迁移或远程写入。
• 项目维护变更检查 BAC 可用性并记录需求、AI 产出、工具结果、文件改动和验证摘要；BAC 只做过程审计，不替代署名、责任或合规判断。
• 不记录 API Key、访问令牌、密码、Cookie、环境/凭据文件、私有 Prompt、身份信息、本地用户名、主机名或不必要的大体积原始数据。
• 文件路径必须规范化并限制在授权项目范围内；外部 URL、子进程和网络访问遵循最小权限，防止路径遍历、SSRF 和命令注入。
• Skill 版本唯一记录在自身 `config.yaml:skill_info.version`；公开 API、协议、目录或配置变更同步文档与 `CHANGELOG.md`。
• 仅将 Skill 或 Bensz 基础设施本身的设计缺陷交给 `bensz-collect-bugs`；先脱敏写入 `~/.bensz-skills/bugs/`，当前任务不中断，只有用户明确要求才公开上报，禁止直接修改用户已安装的 Skill 源码。

<!-- End of canonical common constraints. -->

Skill 专属约束

不得超出本 Skill description 和上方流程所声明的范围；不将未验证的信息伪装成确定结论。