Summarize

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.

Workflow

Follow the artifact contract: save summary to outputs/-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.

1. 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

1. Keep the structure — section references map to the original so a reader

can jump to the source.

1. 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/-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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: adeerkhan
• Source: adeerkhan/vitruvius
• License: MIT

Install and usage instructions live in the source repository linked above.