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.
Use this skill to audit:
- Technical book chapters and tutorials.
- Self-hosting and infrastructure guides.
- Code snippets, shell commands, Docker Compose files, config examples, diagrams, and screenshots.
- Claims that depend on current platform behavior or version-specific documentation.
- Pre-beta or pre-publication technical accuracy.
Reference Routing
| Need |
Read |
| Verification concepts and terminology |
references/core/knowledge.md |
| Audit rules and evidence standards |
references/core/rules.md |
| Example findings and verification tables |
references/core/examples.md |
| Fast verification checklist |
references/core/checklist.md |
| Step-by-step verification pass |
workflows/verify-technical-manuscript.md |
Workflow
1. Define The Verification Scope
Identify what needs verification:
- Commands and code.
- Config files and environment variables.
- Installation and setup steps.
- Screenshots, diagrams, and expected outputs.
- Links and external references.
- Safety, security, privacy, data loss, and cost warnings.
Use a narrow pass when the manuscript is large.
2. Build An Evidence Table
For each technical item, track:
Item | Location | Assumption | Verification method | Result | Fix
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.
Source: hashgraph-online/awesome-codex-plugins → plugins/LVTD-LLC/skills/skills/technical-manuscript-verification/SKILL.md
1---2name: technical-manuscript-verification3description: 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.4---5
6
7# Technical Manuscript Verification
8
9## Core Lens
10
11Technical 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.
12
13Use this skill to audit:
14
15- Technical book chapters and tutorials.
16- Self-hosting and infrastructure guides.
17- Code snippets, shell commands, Docker Compose files, config examples, diagrams, and screenshots.
18- Claims that depend on current platform behavior or version-specific documentation.
19- Pre-beta or pre-publication technical accuracy.
20
21## Reference Routing
22
23| Need | Read |
24|------|------|
25| Verification concepts and terminology | `references/core/knowledge.md` |
26| Audit rules and evidence standards | `references/core/rules.md` |
27| Example findings and verification tables | `references/core/examples.md` |
28| Fast verification checklist | `references/core/checklist.md` |
29| Step-by-step verification pass | `workflows/verify-technical-manuscript.md` |
30
31## Workflow
32
33### 1. Define The Verification Scope
34
35Identify what needs verification:
36
37- Commands and code.
38- Config files and environment variables.
39- Installation and setup steps.
40- Screenshots, diagrams, and expected outputs.
41- Links and external references.
42- Safety, security, privacy, data loss, and cost warnings.
43
44Use a narrow pass when the manuscript is large.
45
46### 2. Build An Evidence Table
47
48For each technical item, track:
49
50```text
51Item | Location | Assumption | Verification method | Result | Fix
52```
53
54Do not rely on plausibility when the item can be checked.
55
56### 3. Verify Against Real Or Simulated Environments
57
58Prefer 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.
59
60### 4. Classify Findings By Reader Risk
61
62Prioritize:
63
64- Data loss, security exposure, privacy harm, or irreversible changes.
65- Commands that fail or produce different output.
66- Missing prerequisites that block readers.
67- Current-info drift from tool or platform changes.
68- Misleading screenshots or diagrams.
69
70### 5. Return Fixes The Author Can Apply
71
72Recommend exact changes:
73
74- Add prerequisite.
75- Change command or config.
76- Add expected output.
77- Add warning, rollback, or troubleshooting note.
78- Move volatile steps to a companion resource.
79- Mark claim for current-doc verification.
80
81## Output Format
82
83When verifying a manuscript, return:
84
851. Verification scope and assumptions.
862. Findings ordered by reader risk.
873. Evidence table with pass/fail/untested status.
884. Exact manuscript fixes.
895. Items requiring current primary-source verification.
906. Suggested beta-reader or expert-review checks.
91
92## Quality Bar
93
94Be 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.
95
96---
97
98**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/LVTD-LLC/skills/skills/technical-manuscript-verification/SKILL.md`
hashgraph-online