Verify technical nonfiction manuscripts for runnable accuracy, including commands, configuration, code snippets, links, version drift, screenshots, prerequisites, security warnings, expected outputs, and reproducibility.
Use when auditing self-hosting, DevOps, programming, infrastructure, data, security, or software tutorial drafts before beta reading, publication, or release.
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
Files included with this skill beyond the listing page.
skill mdSKILL.md3,779 B
docsSUMMARY.md420 B
History
First seen on skills.sh
First recorded snapshot · 61 installs
SKILL.md
Technical Manuscript Verification
Core Lens
Technical nonfiction must work in the reader's environment, not just in the author's memory. Verification checks whether commands run, configs are coherent, screenshots match text, links still resolve, safety boundaries are clear, and the reader has enough context to recover from failure.
Do not rely on plausibility when the item can be checked.
3. Verify Against Real Or Simulated Environments
Prefer running commands, linting configs, checking links, rendering examples, or consulting primary documentation. When execution is unsafe or impractical, state the assumption and the evidence still needed.
4. Classify Findings By Reader Risk
Prioritize:
Data loss, security exposure, privacy harm, or irreversible changes.
Commands that fail or produce different output.
Missing prerequisites that block readers.
Current-info drift from tool or platform changes.
Misleading screenshots or diagrams.
5. Return Fixes The Author Can Apply
Recommend exact changes:
Add prerequisite.
Change command or config.
Add expected output.
Add warning, rollback, or troubleshooting note.
Move volatile steps to a companion resource.
Mark claim for current-doc verification.
Output Format
When verifying a manuscript, return:
Verification scope and assumptions.
Findings ordered by reader risk.
Evidence table with pass/fail/untested status.
Exact manuscript fixes.
Items requiring current primary-source verification.
Suggested beta-reader or expert-review checks.
Quality Bar
Be concrete and evidence-driven. Distinguish "verified," "likely," "untested," and "unsafe to test here." Never imply that a technical instruction works unless it was actually checked or the limitation is clearly stated.