mcpField
D
document-refinement

document-refinement

github.com/majesticlabs-dev文档处理5067 次安装7 周前更新
代码仓库

关于 document-refinement

面向工程师的结构化文档审查技能，用于交接前检查脑暴内容、计划或 PRD。它按清晰度、完整性、具体程度、范围约束和意图一致性评分，并区分小问题与阻塞项。

主要功能

  1. 01按类型分类文档
  2. 02按五项标准评分
  3. 03检查必需章节和模糊措辞
  4. 04自动修正小问题并标出阻塞项
  5. 05最多进行两轮审查

适用场景

  1. 01在交接实施前检查计划
  2. 02审查 PRD 是否缺少细节
  3. 03将脑暴笔记整理为可交付文档
  4. 04区分可处理的缺口与风格偏好

安装

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

$npx skills add https://github.com/majesticlabs-dev/majestic-marketplace --skill document-refinement

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

附带文件references/document-type-requirements.mdreferences/vague-language-patterns.md

详细介绍

文档完善

通过结构化审查回答：“这份文档是否清晰，已准备好进入下一阶段？”

受众： 在交接前审查头脑风暴产出、计划或 PRD 的工程师。 目标： 尽早发现含糊之处和缺漏。自动修复小问题，并标记实质性问题。

评估标准

每项评分为 1–5：

标准1（不合格）3（可接受）5（优秀）
清晰度措辞含糊，术语未定义大体清晰，存在少量歧义每条陈述都明确具体，可直接执行
完整性缺少必需章节包含所有章节，但部分内容单薄所有章节内容充实，没有缺漏
具体性“妥善处理错误”包含一些具体细节明确定义具体行为、数值和边界
YAGNI功能纯属臆测、过度设计存在轻微范围蔓延每个条目都有明确需求作为依据
用户意图忠实度偏离原始请求大体符合预期准确体现用户的要求

审查流程

DOCUMENT = read target document
DOC_TYPE = classify(DOCUMENT) → brainstorm | plan | prd | other
REQUIREMENTS = load references/document-type-requirements.md[DOC_TYPE]
VAGUE_PATTERNS = load references/vague-language-patterns.md

Step 1: Structural Check
  For each REQUIRED_SECTION in REQUIREMENTS[DOC_TYPE].sections:
    If REQUIRED_SECTION missing from DOCUMENT:
      findings.blocking.append({type: "missing_section", section: REQUIRED_SECTION})

Step 2: Vagueness Scan
  For each LINE in DOCUMENT:
    If LINE matches VAGUE_PATTERNS.qualifier_words OR VAGUE_PATTERNS.hedge_phrases:
      If context is risk-identification OR explicit-deferral:
        skip (acceptable vagueness)
      Else if fix is obvious (simple word replacement):
        auto_fixes.append({line: LINE, fix: replacement})
      Else:
        findings.blocking.append({type: "vague_language", line: LINE, suggestion: "specify X"})

Step 3: Criteria Scoring
  For each CRITERION in [Clarity, Completeness, Specificity, YAGNI, User Intent Fidelity]:
    score[CRITERION] = assess(DOCUMENT, CRITERION) → 1-5
    If score[CRITERION] < 3:
      findings.blocking.append({type: "low_score", criterion: CRITERION, details: "..."})

Step 4: Categorize Findings
  blocking = findings where score < 3 OR missing required sections
  polish = findings where score 3-4 (improvable but not blocking)

输出格式

## Document Refinement Report

**Document:** [filename or title]
**Type:** [brainstorm | plan | prd]
**Verdict:** READY | NEEDS REVISION

### Scores
| Criterion | Score | Notes |
|-----------|-------|-------|
| Clarity | X/5 | ... |
| Completeness | X/5 | ... |
| Specificity | X/5 | ... |
| YAGNI | X/5 | ... |
| User Intent Fidelity | X/5 | ... |

### Auto-Fixed (applied)
- [Line X]: "should handle" → "returns 422 with error message"

### Blocking Issues
1. [Issue]: [What's wrong] → [What to specify]

### Polish Suggestions
- [Improvement that would raise score but isn't blocking]

迭代规则

MAX_ROUNDS = 2

If VERDICT == "NEEDS REVISION":
  Apply auto-fixes directly to document
  Present blocking issues to user
  User addresses blocking issues
  Re-run assessment (round 2)

If round 2 still has blocking issues:
  Present remaining issues
  Ask user: "Ship as-is or address remaining items?"
  Do NOT run round 3 (diminishing returns)

反模式

反模式错误原因应采取的做法
审查实现代码此技能面向文档，而非代码使用 code-review 或 plan-review
逐行评分过度分析会拖慢进度重点评估章节层面的内容
因风格偏好而阻塞“我会换种说法”不属于缺漏仅在信息缺失或存在歧义时阻塞
审查时扩大范围“你还应该添加 X”仅指出文档类型要求中缺失的内容
要求满分所有标准均为 3/5 即可继续仅在评分低于 3 时阻塞

评论

支持 Markdown