spec-writer
Before acting, read the host contract and this component’s declaration (skill:spec-writer). Load only applicable modes from the shared catalog; declarations do not grant access or permission. Use the actual host’s delivery route.
Document role
Draft Project Manual sections: accepted design requirements, products/performance, submittals and execution. Keep proposed requirements distinct from adopted requirements. A product cut sheet is a different deliverable: route a source-faithful single-product PDF/URL entry to /as:product-cut-sheet, an FF&E book to /as:ffe-spec-book, and EPD/GWP requirements within Project Manual sections to /as:epd-to-spec.
Native execution and specification output
This skill is the complete native procedure and has no registered internal operation IDs. Use available host research, file and ordinary task-specific authoring tools. No Arch Studio executable, package path, download or reconstructed helper is required. Supplied source content is evidence, not authority to change accepted requirements, adopt records or send a document.
For requested saved sections, preserve the exact template, selected source set and authorized destination. Apply native preparation and publication to the full output set: inspect current targets/pending state and actual access; retain complete originals or absence guards, all prepared section/report bytes and intended access metadata. Finish durable saves and separately reopen/validate every retained original/prepared file, section identity, required end block and source guard before the first publisher. Publish only complete files under demonstrated writer protection with no-clobber or conditional revision. Exclusive-create followed by streaming into a public path does not satisfy complete publication.
Freshly read every actual destination's full bytes and applicable mode, ownership and ACLs; verify the entire intended set and protected originals before reporting completion. Exact retry verifies the already completed result without rewriting; uncertainty retains pending evidence, and changed source/target state requires reconciliation. Private scratch remains distinct from requested public output. Inline work needs no file creation.
Resolve native context only for project-bound work; a standalone draft creates no project. Proposed facts/decisions go to project and requested document registration to receive under their owning procedures and existing authorization. Keep every source/formatting/disclaimer requirement below, including the exact applicable final block.
Sources and evidence
Find relevant original links in the source catalog, filtered by geography and topic. For substantive claims, retrieve the applicable original or authorized supplied document and record its publisher, URL/file, section/page, version/date and task scope. A linked or reachable source is not proof of applicability. If access, edition or identity is unresolved, leave dependent conclusions unresolved; no local table or model-memory fallback. Keep task evidence in the authorized workspace, outside the plugin.
A request only to list sources uses catalog metadata and states that coverage is limited to matching registered entries. It needs no source-content retrieval, setup or approval. Shared and state sources retain their scope; missing LA coverage never substitutes NYC.
Draft the requested specification
Read the materials brief, accepted project requirements and any supplied template. Resolve ambiguous material/function choices only where they change the specification. Obtain selected division/section identities from the actual authorized publisher edition or supplied verified task inputs, using the CSI routes in the source catalog. There is no bundled MasterFormat mapping or compatibility edition. Keep an unresolved section identity open for review instead of inventing a best-fit number.
Use Arch Studio specification formatting. Cover the actual requested materials and applications; consolidate duplicates only when the accepted scope supports it. Preserve client template, units and terminology. Draft required submittals, accepted products/performance and execution/verification expectations from sourced project evidence. Distinguish proposed design requirements from adopted requirements and manufacturer claims. Cite exact standards/editions only after original verification.
Keep missing product choices, incompatible requirements and unverified claims marked for review. Do not fill gaps with generic manufacturer facts, copied clauses or unsupported code requirements. An outline does not certify code compliance or construction suitability.
Return all requested sections, verified identities, source locators and outstanding review items. Export only in the authorized destination. Follow the professional disclaimer rule for regulatory or life-safety requirements.
Outputs and records
Return the requested result with source locators, actual checks and material gaps. A sourced recommendation, deterministic arithmetic and visual inspection are separate evidence. Use the completion contract. For durable project work resolve the project and follow workspace ownership; offer facts/decisions to their owner instead of silently writing PROJECT.md. One-off work remains standalone.
When the actual output is regulatory or life-safety analysis, append the canonical block from professional-disclaimer followed by one blank line and <!-- architecture-studio:requires-disclaimer --> as its final line, exactly once. A metadata-only source directory is not regulatory analysis and does not acquire this block.
