运维测试
- 作者仓库星标 1,187
- 叉子 185
- 作者更新于 2026年6月14日 10:01
- 作者仓库 claude-code-skills
- 领域
- 通用
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @daymade · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 即装即用
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- Windows
- 底层运行要求
- Python
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: fact-checker
description: Verifies factual claims in documents using web search and official sources, then proposes correc…
category: 通用
runtime: Python
---
# fact-checker 输出预览
## PART A: 任务判断
- 适用问题:通用任务拆解、检查和交付。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“When to use / Workflow / Step 1: Identify factual claims”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于通用任务拆解、检查和交付,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“When to use / Workflow / Step 1: Identify factual claims”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文出现了 `/daymade-docs` 这类斜杠命令;如果你的 Agent 支持命令触发,优先用命令开场,再补充目标和边界。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件。
先用一个小任务确认它会围绕“When to use / Workflow / Step 1: Identify factual claims”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: fact-checker
description: Verifies factual claims in documents using web search and official sources, then proposes correc…
category: 通用
source: daymade/claude-code-skills
---
# fact-checker
## 什么时候使用
- fact-checker 是一个通用扩展技能,按 SKILL 适合处理通用任务拆解、检查、交付和复盘,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步骤;通常不…
- 面向通用任务拆解、检查和交付,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「When to use / Workflow / Step 1: Identify factual claims」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "fact-checker" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> When to use / Workflow / Step 1: Identify factual claims
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> Python | 读取文件、写入/修改文件 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} Fact Checker
Verify factual claims in documents and propose corrections backed by authoritative sources.
When to use
Trigger when users request:
- "Fact-check this document"
- "Verify these AI model specifications"
- "Check if this information is still accurate"
- "Update outdated data in this file"
- "Validate the claims in this section"
Workflow
Copy this checklist to track progress:
Fact-checking Progress:
- [ ] Step 1: Identify factual claims
- [ ] Step 2: Search authoritative sources
- [ ] Step 3: Compare claims against sources
- [ ] Step 4: Generate correction report
- [ ] Step 5: Apply corrections with user approval
Step 1: Identify factual claims
Scan the document for verifiable statements:
Target claim types:
- Technical specifications (context windows, pricing, features)
- Version numbers and release dates
- Statistical data and metrics
- API capabilities and limitations
- Benchmark scores and performance data
Skip subjective content:
- Opinions and recommendations
- Explanatory prose
- Tutorial instructions
- Architectural discussions
Step 2: Search authoritative sources
For each claim, search official sources:
AI models:
- Official announcement pages (anthropic.com/news, openai.com/index, blog.google)
- API documentation (platform.claude.com/docs, platform.openai.com/docs)
- Developer guides and release notes
Technical libraries:
- Official documentation sites
- GitHub repositories (releases, README)
- Package registries (npm, PyPI, crates.io)
General claims:
- Academic papers and research
- Government statistics
- Industry standards bodies
Search strategy:
- Use model names + specification (e.g., "Claude Opus 4.5 context window")
- Include current year for recent information
- Verify from multiple sources when possible
Step 3: Compare claims against sources
Create a comparison table:
| Claim in Document | Source Information | Status | Authoritative Source |
|---|---|---|---|
| Claude 3.5 Sonnet: 200K tokens | Claude Sonnet 4.5: 200K tokens | ❌ Outdated model name | platform.claude.com/docs |
| GPT-4o: 128K tokens | GPT-5.2: 400K tokens | ❌ Incorrect version & spec | openai.com/index/gpt-5-2 |
Status codes:
- ✅ Accurate - claim matches sources
- ❌ Incorrect - claim contradicts sources
- ⚠️ Outdated - claim was true but superseded
- ❓ Unverifiable - no authoritative source found
Step 4: Generate correction report
Present findings in structured format:
## Fact-Check Report
### Summary
- Total claims checked: X
- Accurate: Y
- Issues found: Z
### Issues Requiring Correction
#### Issue 1: Outdated AI Model Reference
**Location:** Line 77-80 in docs/file.md
**Current claim:** "Claude 3.5 Sonnet: 200K tokens"
**Correction:** "Claude Sonnet 4.5: 200K tokens"
**Source:** https://platform.claude.com/docs/en/build-with-claude/context-windows
**Rationale:** Claude 3.5 Sonnet has been superseded by Claude Sonnet 4.5 (released Sept 2025)
#### Issue 2: Incorrect Context Window
**Location:** Line 79 in docs/file.md
**Current claim:** "GPT-4o: 128K tokens"
**Correction:** "GPT-5.2: 400K tokens"
**Source:** https://openai.com/index/introducing-gpt-5-2/
**Rationale:** 128K was output limit; context window is 400K. Model also updated to GPT-5.2
Step 5: Apply corrections with user approval
Before making changes:
- Show the correction report to the user
- Wait for explicit approval: "Should I apply these corrections?"
- Only proceed after confirmation
When applying corrections:
# Use Edit tool to update document
# Example:
Edit(
file_path="docs/03-写作规范/AI辅助写书方法论.md",
old_string="- Claude 3.5 Sonnet: 200K tokens(约 15 万汉字)",
new_string="- Claude Sonnet 4.5: 200K tokens(约 15 万汉字)"
)
After corrections:
- Verify all edits were applied successfully
- Note the correction summary (e.g., "Updated 4 claims in section 2.1")
- Remind user to commit changes
Search best practices
Query construction
Good queries (specific, current):
- "Claude Opus 4.5 context window 2026"
- "GPT-5.2 official release announcement"
- "Gemini 3 Pro token limit specifications"
Poor queries (vague, generic):
- "Claude context"
- "AI models"
- "Latest version"
Source evaluation
Prefer official sources:
- Product official pages (highest authority)
- API documentation
- Official blog announcements
- GitHub releases (for open source)
Use with caution:
- Third-party aggregators (llm-stats.com, etc.) - verify against official sources
- Blog posts and articles - cross-reference claims
- Social media - only for announcements, verify elsewhere
Avoid:
- Outdated documentation
- Unofficial wikis without citations
- Speculation and rumors
Handling ambiguity
When sources conflict:
- Prioritize most recent official documentation
- Note the discrepancy in the report
- Present both sources to the user
- Recommend contacting vendor if critical
When no source found:
- Mark as ❓ Unverifiable
- Suggest alternative phrasing: "According to [Source] as of [Date]..."
- Recommend adding qualification: "approximately", "reported as"
Special considerations
Time-sensitive information
Always include temporal context:
Good corrections:
- "截至 2026 年 1 月" (As of January 2026)
- "Claude Sonnet 4.5 (released September 2025)"
Poor corrections:
- "Latest version" (becomes outdated)
- "Current model" (ambiguous timeframe)
Numerical precision
Match precision to source:
Source says: "approximately 1 million tokens" Write: "1M tokens (approximately)"
Source says: "200,000 token context window" Write: "200K tokens" (exact)
Citation format
Include citations in corrections:
> **注**:具体上下文窗口以模型官方文档为准,本书写作时使用 Claude Sonnet 4.5 为主要工具。
Link to sources when possible.
Examples
Example 1: Technical specification update
User request: "Fact-check the AI model context windows in section 2.1"
Process:
- Identify claims: Claude 3.5 Sonnet (200K), GPT-4o (128K), Gemini 1.5 Pro (2M)
- Search official docs for current models
- Find: Claude Sonnet 4.5, GPT-5.2, Gemini 3 Pro
- Generate report showing discrepancies
- Apply corrections after approval
Example 2: Statistical data verification
User request: "Verify the benchmark scores in chapter 5"
Process:
- Extract numerical claims
- Search for official benchmark publications
- Compare reported vs. source values
- Flag any discrepancies with source links
- Update with verified figures
Example 3: Version number validation
User request: "Check if these library versions are still current"
Process:
- List all version numbers mentioned
- Check package registries (npm, PyPI, etc.)
- Identify outdated versions
- Suggest updates with changelog references
- Update after user confirms
Quality checklist
Before completing fact-check:
- All factual claims identified and categorized
- Each claim verified against official sources
- Sources are authoritative and current
- Correction report is clear and actionable
- Temporal context included where relevant
- User approval obtained before changes
- All edits verified successful
- Summary provided to user
Limitations
This skill cannot:
- Verify subjective opinions or judgments
- Access paywalled or restricted sources
- Determine "truth" in disputed claims
- Predict future specifications or features
For such cases:
- Note the limitation in the report
- Suggest qualification language
- Recommend user research or expert consultation
Next Step: Export Verified Content
After fact-checking, suggest exporting the verified document:
Fact-check complete: [N] claims verified, [M] corrections proposed.
Options:
A) Export as PDF — run /daymade-docs:pdf-creator (Recommended for formal documents)
B) Create slides — run /daymade-docs:ppt-creator from verified content
C) No thanks — I'll use the corrected document directly
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核