SkillsLLM
Back to catalog

research-units-pipeline-skills

by WILLOSCAR

Pending

Research pipelines as semantic execution units: each skill declares inputs/outputs, acceptance criteria, and guardrails. Evidence-first methodology prevents hollow writing through structured intermediate artifacts.

175stars
17forks
Python
Added 1/27/2026
View on GitHubDownload ZIP
Data Processingclaudeclaude-codecodexgptpipelineresearchresearch-paperresearch-projectresearch-toolskillstoolsunitsvibevibe-codingvibecoding
Installation
# Add to your Claude Code skills
git clone https://github.com/WILLOSCAR/research-units-pipeline-skills
README.md

research-units-pipeline-skills

一句话：让 Pipeline 会"带人 / 带模型"做研究——不是给一堆脚本，而是给一套语义化的 skills，每个 skill 知道"该做什么、怎么做、做到什么程度、不能做什么"。

WIP

  1. 在 Appendix 增加了表格
  2. 持续打磨写作技巧，提升写作上下限（已经尝试了增加 role playing 的 soft 约束）
  3. 去除模板话描述

Todo

  1. 加入多 cli 协作，multi-agent design （在合适的环节接入 API，替代或者分担 codex 执行过程中的压力）
  2. 完善剩余的Pipeline，example 新增例子
  3. 精简Pipeline中冗余的中间内容，遵循优雅的奥卡姆剃刀原则，如无必要，勿增实体。

核心设计：Skills-First + 拆解链路 + 证据先行

传统的研究流水线常见两种极端：

  • 只有脚本：能跑，但过程黑盒，失败了不知道改哪里。
  • 只有文档：看起来都对，真正执行时全靠“人肉判断”和经验。

这套 repo 的做法是三句话（看完就能上手）：

  1. Skill 是“可执行的说明书”（不是函数名）
  • 每个 skill 都写清楚：要用什么输入、必须产出什么文件、什么算 DONE、哪些行为禁止（例如 C2–C4 禁止写正文）。
  1. 把流程拆成可恢复的小步（Units）
  • 整体分成 C0→C5 这 6 个 checkpoint。
  • 每一步是一个 unit，依赖关系写在 UNITS.csv：失败了只修这一小步对应的产物，然后从这里继续。
  1. 先证据、后写作
  • C2–C4 先把“可写的证据底座”建出来（结构 + 映射 + 证据包 + 引用），C5 才进入写作与合并。

你会因此得到：

  • 可复用：同一个 skill 能在多个 pipeline 里复用（换交付方式不必重写逻辑）。
  • 可引导：执行者（人/模型）不用猜“该做到什么程度”，照着验收标准做即可。
  • 可约束：有明确禁区（guardrails），减少越界与漂移（尤其是提前写正文）。
  • 可定位：失败会落到具体“哪个 unit + 哪个中间产物”，便于定点修复而不是全量重跑。

一眼看懂：你遇到的问题 vs 这里怎么解决

| 你遇到的问题 | 这里的机制 | 你会去看/去改哪里 | |---|---|---| | 流程黑盒：失败了不知道改哪里 | unit 合同 + 质量门报告（FAIL 指向具体中间产物） | UNITS.csv / output/*REPORT*.md / output/*TODO*.md | | 文档松散：执行靠经验 | skill 语义化（inputs/outputs/acceptance/guardrail） | .codex/skills/*/SKILL.md | | 写作空洞/模板话 | evidence-first（C2–C4）+ 写作自循环（C5） | outline/* / sections/* / output/WRITER_SELFLOOP_TODO.md | | 想换交付但不想重写流程 | pipeline 只负责编排，能力沉淀在 skills | pipelines/*.pipeline.md |

English version: README.en.md.

codex 参考配置


[sandbox_workspace_write]
network_access = true

[features]
unified_exec = true
shell_snapshot = true
steer = true

一句话启用（推荐：对话式跑一篇 survey）

  1. 在本仓库目录启动 Codex：
codex --sandbox workspace-write --ask-for-approval never
  1. 在对话里说一句你要什么（例子）：

给我写一篇关于 LLM agents 的 LaTeX survey

它会自动：新建一个 workspaces/<时间戳>/ → 先检索/整理论文 → 生成大纲 → 停在大纲确认点（C2） 等你回复 “同意继续” → 再写草稿并生成 PDF。

可选：你也可以直接指定“用哪条流程”（需要 PDF 就选 latex 版本）：

用 pipelines/arxiv-survey-latex.pipeline.md 给我写一个 agent 的 survey（启用 strict；先停在 C2 等我确认）

术语解释（读到这里就够用）：

  • workspace：一次运行的输出目录（在 workspaces/<name>/）
  • pipeline：一条“从检索→结构→证据→写作→输出”的步骤清单（在 pipelines/*.pipeline.md）
  • skill：某一步的执行说明书/能力模块（在 .codex/skills/*/SKILL.md）
  • unit：流程中的一步（UNITS.csv 一行）
  • checkpoint / C2：会暂停等人确认的节点；C2=确认大纲后才写正文
  • strict：开启严格质量门；失败会停下来并写报告（在 output/）

你会得到什么（分层产物 + 自循环入口）

一个 workspace 里主要是两类东西：运行清单 + 分阶段产物。

运行清单（看进度/看卡点）：

  • UNITS.csv：一行一个步骤（依赖/输入/输出/验收），卡住就看当前哪个 unit 是 BLOCKED
  • DECISIONS.md：需要你确认的点（最重要的是 C2：确认大纲后才写正文）
  • STATUS.md：运行日志（当前跑到哪一步）

分阶段产物（你真正关心的内容）：

C1（找论文）:
  papers/papers_raw.jsonl → papers/papers_dedup.jsonl → papers/core_set.csv
  + papers/retrieval_report.md   # 这次检索/筛选的说明

C2（搭骨架；不写正文）:
  outline/outline.yml + outline/mapping.tsv
  (+ outline/taxonomy.yml / outline/coverage_report.md)  # 可选：更结构化/更可审计

C3（做“可写”的证据底座；不写正文）:
  papers/paper_notes.jsonl + papers/evidence_bank.jsonl → outline/subsection_briefs.jsonl
  (+ papers/...