Engineering Document Summary

Read a technical document and condense it faithfully. Reading is a research act: do not summarize what you have not actually read.

Input Gate

Before searching, name the question, the artifact/scope (or say it is a literature review), the jurisdiction/edition, and the effort budget (user-set or thorough). Ask ONE clarifying question if the ask is too vague, then proceed. See references/input-gate.md.

Workflow

Follow the artifact contract: save summary to outputs/<slug>-summary.md.

1. Read the whole document — not just the abstract or first pages. For a standard, map its scope, normative references, and the sections that govern the question. For a datasheet, read the tables and notes, not just the headline specs.
2. Extract, don't invent — every number, unit, and provision in the summary must come from the document. Preserve:
   • scope and applicability (what it does and does not cover)
   • governing requirements with section numbers
   • key values: limits, factors, properties, tolerances — with units
   • notes, caveats, and exceptions
3. Keep the structure — section references map to the original so a reader can jump to the source.
4. Mark what is missing — if the document is paywalled, partial, or a figure/table could not be read, say so (blocked), and never fill the gap from memory or another source.

Output

A structured summary. For a standards/spec document, prefer this shape:

• What it is and when it applies
• Governing requirements (by section)
• Key values (table with units)
• Exceptions and caveats
• What was not readable (blocked)

Save to outputs/<slug>-summary.md when the user wants an artifact; otherwise answer inline. Always cite the document (standard + edition, URL, or path).

Scope and Boundaries

• This skill produces research — it does NOT produce final designs or construction documents.
• Research-only, not for final engineering sign-off. Licensed engineers must review and approve any design based on this research.