Token导航 LogoToken导航

Agent Skill · 研究检索

draft-polisher(草稿抛光机)

draft-polisher 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

draft-polisher 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为只读;许可证为 MIT,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 36,764。

总安装 1,862周安装 80GitHub Stars 422下载 653核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:draft-polisher(草稿抛光机)
来源仓库:https://github.com/willoscar/research-units-pipeline-skills
仓库路径:skills/draft-polisher
安装命令:
npx skills add https://github.com/willoscar/research-units-pipeline-skills --skill draft-polisher
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/willoscar/research-units-pipeline-skills --skill draft-polisher

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

draft-polisher 用于对初稿进行局部润色,提升可读性、术语一致性和冗余清理,但不负责结构调整。它适用于写作后期优化、报告语言打磨等场景。主要聚焦于去模板化、增强连贯性和精简重复表达,不涉及内容增删决策。建议在段落级修改后通过其他工具验证证据链完整性。

适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/draft-polisher

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/willoscar/research-units-pipeline-skills --ski…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它标注为只读,先用只读任务试一次,确认行为符合预期再扩大使用范围。

常见问题

6 条

draft-polisher 怎么安装?

在终端执行 npx skills add https://github.com/willoscar/research-units-pipeline-skills --skill draft-p…。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

draft-polisher 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

draft-polisher 需要什么权限?

权限级别是只读。该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

draft-polisher 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

draft-polisher 用的人多吗?

公开数据是累计安装 1,862 次,近一周安装 80 次,下载 653 次,GitHub 422 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

draft-polisher 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 3 个目录同时收录,说明这个 Skill 流传比较广。
  • 许可证明确为 MIT,商用和分发边界好判断。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。
  • 需要许可证清楚、并且有第三方扫描结果的团队项目。

不太适合

  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
draft-polisher

草稿抛光机 · 本页

1,862422只读MIT通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Draft Polisher (Audit-style editing)

Goal: turn a first-pass draft into readable survey prose without breaking the evidence contract.

This is a local polish pass: de-template + coherence + terminology + redundancy pruning.

Note: if the main issue is structural redundancy from section accumulation, push the change upstream to sections/ and use paragraph-curator before merge. draft-polisher should not be the primary place where you decide which paragraphs to keep.

Role cards (use explicitly)

Style Harmonizer (editor)

Mission: remove generator voice and make prose read like one author wrote it.

Do:

  • Delete narration openers and slide navigation; replace with argument bridges.
  • Vary rhythm; remove repeated template stems.
  • Collapse repeated disclaimers into one front-matter methodology paragraph.

Avoid:

  • Adding or removing citation keys.
  • Moving citations across subsections.

Evidence Contract Guard (skeptic)

Mission: prevent polishing from inflating claims beyond evidence.

Do:

  • Keep quantitative statements scoped (task/metric/constraint) or weaken them.
  • Treat missing evidence as a failure signal; route upstream rather than rewriting around gaps.

Avoid:

  • Overconfident language when evidence is abstract-only.

Role prompt: Style Harmonizer (editor expert)

You are the style and coherence editor for a technical survey.

Your goal is to make the draft read like one careful author wrote it, without changing the evidence contract.

Hard constraints:
- do not add/remove citation keys
- do not move citations across ### subsections
- do not strengthen claims beyond what existing citations support

High-leverage edits:
- delete generator voice (This subsection..., Next we move..., We now turn...)
- replace navigation with argument bridges (content-bearing handoffs)
- collapse repeated disclaimers into one methodology paragraph in front matter
- keep quantitative statements well-scoped (task/metric/constraint in the same sentence)

Working style:
- rewrite sentences so they carry content, not process
- vary rhythm, but avoid “template stems” repeating across H3s

Inputs

  • output/DRAFT.md
  • Optional context (read-only; helps avoid “polish drift”):

- outline/outline.yml - outline/subsection_briefs.jsonl - outline/evidence_drafts.jsonl - citations/ref.bib

Outputs

  • output/DRAFT.md (in-place refinement)
  • output/citation_anchors.prepolish.jsonl (baseline, generated on first run by the script)

Non-negotiables (hard rules)

  1. Citation keys are immutable
  • Do not add new [@BibKey] keys.
  • Do not delete citation markers.
  • If citations/ref.bib exists, do not introduce any key that is not defined there.
  1. Citation anchoring is immutable
  • Do not move citations across ### subsections.
  • If you must restructure across subsections, stop and push the change upstream (outline/briefs/evidence), then regenerate.
  1. No evidence inflation
  • If a sentence sounds stronger than the evidence level (abstract-only), rewrite it into a qualified statement.
  • When in doubt, check the subsection’s evidence pack in outline/evidence_drafts.jsonl and keep claims aligned to snippets.
  1. Citation shape normalization
  • Merge adjacent citation blocks in the same sentence (avoid [@a] [@b]).
  • Deduplicate keys inside one block (avoid [@a; @a]).
  • Avoid tail-only citation dumps: keep some citations in the claim sentence itself (mid-sentence), not only paragraph end.
  1. Quantitative claim hygiene
  • If you keep a number, ensure the sentence also states (without guessing): task type + metric definition + relevant constraint (budget/cost/tool access), and the citation is embedded in that sentence.
  • Avoid ambiguous model naming (e.g., “GPT-5”) unless the cited paper uses that exact label; otherwise use the paper’s naming or a neutral description.
  1. No pipeline voice
  • Remove scaffolding phrases like:

- “We use the following working claim …” - “The main axes we track are …” - “abstracts are treated as verification targets …” - “Method note (evidence policy): …” (avoid labels; rewrite as plain survey methodology) - “this run is …” (rewrite as survey methodology: “This survey is …”) - “Scope and definitions / Design space / Evaluation practice …” - “Next, we move from …” - “We now turn to …” - “From to,...” (title narration; rewrite as an argument bridge) - “In the next section/subsection …” - “Therefore/As a result, survey synthesis/comparisons should …” (rewrite as literature-facing observation)

  • Also remove generator-like thesis openers that read like outline narration:

- “This subsection surveys …” - “This subsection argues …”

Three passes (recommended)

Pass 1 — Subsection polish (structure + de-template)

Best-of-2 micro-polish (recommended):

  • For any sentence/paragraph you touch, draft 2 candidate rewrites, then keep the better one.
  • Choose with a simple rubric: move clarity, no template stem, citations stay anchored, and citation shape stays reader-facing (no adjacent cite blocks / dup keys).
  • Do not keep both candidates. Pick one and move on (the goal is convergence, not endless rewriting).

Role split:

  • Editor: rewrite sentences for clarity and flow.
  • Skeptic: deletes any generic/template sentence.

Targets:

  • Each H3 reads like: tension → contrast → evidence → limitation.
  • Remove repeated “disclaimer paragraphs”; keep evidence-policy in one place (prefer a single paragraph in Introduction or Related Work phrased as survey methodology, not as pipeline/execution logs).
  • Use outline/outline.yml (if present) to avoid heading drift during edits.
  • If present, use outline/subsection_briefs.jsonl to keep each H3’s scope/RQ consistent while improving flow.
  • Do a quick “pattern sweep” (semantic, not mechanical):

- delete outline narration: This subsection..., In this subsection... - delete slide navigation: Next, we move from..., We now turn to..., In the next section... - delete title narration: From <X> to <Y>,... - replace with: content claims + argument bridges + organization sentences (no new facts/citations)

  • If citation-injector was used, smooth any budget-injection sentences so they read paper-like:

- Keep the citation keys unchanged. - Avoid list-injection stems (e.g., “A few representative references include …”, “Notable lines of work include …”, “Concrete examples... include...”). - Prefer integrating the added citations into an existing argument sentence, or rewrite as a short parenthetical e.g.,... clause tied to the subsection’s lens (no new facts). - Vary phrasing; avoid repeating the same opener stem across many H3s.

  • Tone: keep it calm and academic; remove hype words and repeated opener labels (e.g., literal Key takeaway: across many H3s).
  • Reduce repeated synthesis stems (e.g., many paragraphs starting with Taken together,...); vary synthesis phrasing and keep it content-bearing.

- Treat repeated "Taken together," as a generator-voice smell. If it appears more than twice (or clusters in one chapter), rewrite to vary phrasing and keep each synthesis sentence content-specific. - Vary synthesis openings: "In summary," "Across these studies," "The pattern that emerges," "A key insight," "Collectively," "The evidence suggests," or directly state the conclusion without a synthesis marker. - Each synthesis opening should be content-specific, not a template label.

Rewrite recipe for subsection openers (paper voice, no new facts):

  • Delete: This subsection surveys/argues... / In this subsection, we...
  • Replace with a compact opener that does 2–3 of these (no labels; vary across subsections):

- Content claim: the subsection-specific tension/trade-off (optionally with 1–2 embedded citations) - Why it matters: link the claim to evaluation/engineering constraints (benchmark/protocol/cost/tool access) - Preview: what you will contrast next and on what lens (A vs B; then evaluation anchors; then limitations)

  • Example skeletons (paraphrase; don’t reuse verbatim):

- Tension-first: A central tension is...;...; we contrast... - Decision-first: For builders, the crux is...;... - Lens-first: Seen through the lens of...,...

Pass 2 — Terminology normalization

Role split:

  • Taxonomist: chooses canonical terms and synonym policy.
  • Integrator: applies consistent replacements across the draft.

Targets:

  • One concept = one name across sections.
  • Headings, tables, and prose use the same canonical terms.

Pass 3 — Redundancy pruning (global repetition)

Role split:

  • Compressor: collapses repeated boilerplate.
  • Narrative keeper: ensures removing repetition does not break the argument chain.

Targets:

  • Cross-section repeated intros/outros are removed.
  • Only subsection-specific content remains inside subsections.

Script

Quick Start

  • python.codex/skills/draft-polisher/scripts/run.py --help
  • python.codex/skills/draft-polisher/scripts/run.py --workspace workspaces/<ws>

All Options

  • --workspace <dir>: workspace root
  • --unit-id <U###>: unit id (optional; for logs)
  • --inputs <semicolon-separated>: override inputs (rare; prefer defaults)
  • --outputs <semicolon-separated>: override outputs (rare; prefer defaults)
  • --checkpoint <C#>: checkpoint id (optional; for logs)

Examples

  • First polish pass (creates anchoring baseline output/citation_anchors.prepolish.jsonl):

- python.codex/skills/draft-polisher/scripts/run.py --workspace workspaces/<ws>

  • Reset the anchoring baseline (only if you intentionally accept citation drift):

- Delete output/citation_anchors.prepolish.jsonl, then rerun the polisher.

Acceptance checklist

  • No TODO/TBD/FIXME/(placeholder).
  • No … or ... truncation.
  • No repeated boilerplate sentence across many subsections.
  • Citation anchoring passes (no cross-subsection drift).
  • Each H3 has at least one cross-paper synthesis paragraph (>=2 citations).

Troubleshooting

Issue: polishing causes citation drift across subsections

Fix:

  • Keep citations inside the same ### subsection; if restructuring is intentional, delete output/citation_anchors.prepolish.jsonl and regenerate a new baseline.

Issue: draft polishing is requested before writing approval

Fix:

  • Record the relevant approval in DECISIONS.md (typically Approve C2) before doing prose-level edits.

平台分布

Claude Code

27.01%
按下载量换算176

Gemini CLI

23.87%
按下载量换算156

Cursor

18.12%
按下载量换算118

Codex

10.81%
按下载量换算71

trae

8.18%
按下载量换算53

OpenCode

3.04%
按下载量换算20

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

继续浏览同类 Skills