Verify Openspec Docs

作者 fission-ai9111a7654d78無授權條款71K 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫今天更新

Fact-checks OpenSpec user documentation with a fresh-context subagent that re-runs commands and checks claims against source. Manually triggered; not part of the drafting loop. Use when the user asks to verify, fact-check, or accuracy-check a docs page, section, or set of changed claims.

僅含說明Research & Analysis AI & Agents

AI 產生的概覽

透過啟動全新上下文的子代理重新執行指令並核對來源，對已完成的 OpenSpec 文件進行事實查核。

功能: 此技能會對照實際的程式碼倉庫查核已完成的 OpenSpec 使用者文件。它先界定目標頁面、章節或變更主張清單，再為每個單元啟動一個通用子代理，重新執行終端機指令、驗證範例、檢查結構與職責契合度，並標記缺乏依據或誇大其詞的文字。最後產出一份依嚴重程度排序的發現報告，包含引用原文、單行修正建議，以及已驗證內容與其驗證方式的說明。
適用情境: 當使用者明確要求對某個文件頁面、章節或一組變更主張進行驗證、事實查核或準確性檢查時使用。此技能為手動觸發，不屬於撰寫流程，因此除非使用者要求執行驗證，否則不應在撰寫過程中呼叫。
執行需求: 僅包含指令，技能不隨附指令碼。需要存取 OpenSpec 程式碼倉庫，包括文件樹 README、write-openspec-docs 寫作規則與原始碼檔案，並需要能夠啟動子代理、執行唯讀終端機指令以及 openspec validate。

Verify OpenSpec docs

Check finished docs prose against reality. The point of a fresh context is that the reviewer hasn't watched the prose get written, so it can't be talked into the author's assumptions.

This skill runs only when the user asks for it. Drafting is owned by write-openspec-docs; don't invoke this from inside a drafting session unless the user requests a verification pass.

Scope the run

Confirm the target: a page, one ## section, or a list of changed claims. If invoked without a target, ask.
Read the README at the root of the docs tree the target lives in; its invariants and page map are part of what gets checked.
One subagent per unit (one ## section, or the stated claim list). A full page is several subagents, run in parallel.

Spawn the reviewer

General-purpose subagent. Subagents don't inherit skills, so the prompt hands the reviewer everything by path. Fill every placeholder, make every path absolute, and send:

You are reviewing one unit of OpenSpec's user documentation before it reaches the docs owner. Be the two hardest readers it will meet: a skeptical developer reading it cold, and a fact-checker with the repo open.
Repo root: <ABSOLUTE REPO ROOT>. Use absolute paths with every tool.
Read first:1. <DOCS TREE ROOT>/README.md: the page map and standing invariants.2. <ABSOLUTE REPO ROOT>/.agents/skills/write-openspec-docs/writing.md: the house writing rules.3. <PAGE PATH>: review only <the section "<HEADING>" | these changed claims: <LIST>>; read the rest of the page for context.
Then check, in this order:
1. Facts. Every command, flag, path, config key, output block, default, and behavior claim. Re-run the terminal commands shown: read-only commands anywhere, anything that mutates state in a scratch directory or not at all. Commands for the AI chat surface (like /opsx:propose) can't run in a shell; verify their names and behavior against the skill sources this repo ships. Check names against src/ and the CLI's own --help. An output block must match what the command actually prints.2. Examples. Any example spec or change must pass `openspec validate`. Run it when the example exists on disk.3. Structure. Flag anything that re-explains a topic whose canonical home is another page, or breaks a rule the docs tree's README states.4. Job fit. Does the unit serve the page's stated job (the one-line statement under the title, if present)? Does the arriving reader get what they came for quickly?5. Trust and slop. Flag: hype or comfort adjectives (easy, simple, powerful, seamless), claims with no shown evidence, vague generalization where a specific fact belongs, binary contrasts ("not X, it's Y"), colon reveals, importance puffery, summary endings, em dashes, bullet lists that should be prose, and three parallel punchy sentences in a row.
Report findings only, most severe first. For each: quote the line, say what is wrong, and give the fix in one line. For every fact you verified, say how (the command you ran, or the file and line you checked). List any claim you could not verify and why. Do not rewrite the unit. If the unit is clean, say so and list exactly what you verified.

You are reviewing one unit of OpenSpec's user documentation before it reaches the docs owner. Be the two hardest readers it will meet: a skeptical developer reading it cold, and a fact-checker with the repo open.
Repo root: <ABSOLUTE REPO ROOT>. Use absolute paths with every tool.
Read first:1. <DOCS TREE ROOT>/README.md: the page map and standing invariants.2. <ABSOLUTE REPO ROOT>/.agents/skills/write-openspec-docs/writing.md: the house writing rules.3. <PAGE PATH>: review only <the section "<HEADING>" | these changed claims: <LIST>>; read the rest of the page for context.
Then check, in this order:
1. Facts. Every command, flag, path, config key, output block, default, and behavior claim. Re-run the terminal commands shown: read-only commands anywhere, anything that mutates state in a scratch directory or not at all. Commands for the AI chat surface (like /opsx:propose) can't run in a shell; verify their names and behavior against the skill sources this repo ships. Check names against src/ and the CLI's own --help. An output block must match what the command actually prints.2. Examples. Any example spec or change must pass `openspec validate`. Run it when the example exists on disk.3. Structure. Flag anything that re-explains a topic whose canonical home is another page, or breaks a rule the docs tree's README states.4. Job fit. Does the unit serve the page's stated job (the one-line statement under the title, if present)? Does the arriving reader get what they came for quickly?5. Trust and slop. Flag: hype or comfort adjectives (easy, simple, powerful, seamless), claims with no shown evidence, vague generalization where a specific fact belongs, binary contrasts ("not X, it's Y"), colon reveals, importance puffery, summary endings, em dashes, bullet lists that should be prose, and three parallel punchy sentences in a row.
Report findings only, most severe first. For each: quote the line, say what is wrong, and give the fix in one line. For every fact you verified, say how (the command you ran, or the file and line you checked). List any claim you could not verify and why. Do not rewrite the unit. If the unit is clean, say so and list exactly what you verified.

Handle the report

Default is report, not rewrite: show the user the findings ranked most severe first, each with the quoted line and one-line fix, plus what was verified and how, and any claim the reviewer couldn't verify.
Apply fixes only when the user asked for a verify-and-fix run or approves the findings. A verifier can also be wrong: rejections go in the report with your reason, so the user can overrule you.
If an applied fix changed a factual claim, verify again, scoped to the changed claims. Typo and wording fixes don't need a second pass.
Two passes without converging means stop and take it to the user. Don't polish in a loop.

來源與署名

來源：fission-ai/openspec位於.agents/skills/verify-openspec-docs提交9111a76

授權條款：無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架

Verify Openspec Docs

Verify OpenSpec docs

Scope the run

Spawn the reviewer

Handle the report

來源與署名

更多來自 fission-ai/openspec 的技能

Write Openspec Docs

Release Openspec

Draft Openspec Docs

更多Research & Analysis技能

Equity Research

Sector Overview

Idea Generation

Competitive Analysis

Notion Research Documentation

Notion Meeting Intelligence