If you work in architecture, engineering, or construction, the documentation layer surrounding a project is relentless. The specification section that has to be complete before the CD set goes out. The RFI response that needs to be issued by end of day. The submittal log that has grown to 200 line items and every cover letter needs individual review commentary. The owner status letter that is somehow due at the same time as the design team meeting minutes. For experienced architects and AEC project managers, none of this is new — but none of it has gotten faster, either.
Claude AI handles the language, structure, and formatting of that documentation layer. It does not replace the licensed professional who reviews, stamps, and issues the document. That distinction is load-bearing, and this post maintains it throughout. Two adjacent posts on this blog cover related ground: Claude AI for technical writers owns user documentation, API docs, and product documentation; Claude AI for project management owns general project management workflows, timelines, and cross-functional coordination. This post — post #70 in the series — owns the AEC-specific deliverable lane: CSI MasterFormat specification sections, RFI response drafts, submittal cover letters, project narratives, construction meeting minutes, and formal owner correspondence. That is a distinct workflow from general project management, and a distinct audience from technical documentation.
This post targets architects, project architects, design architects, specification writers, construction administrators, and AEC project managers. It covers what Claude can do for your documentation workflow and what it cannot do — and those limits matter as much as the use cases.
What Claude Cannot Do for AEC Work
Read this section before using any prompt in this post. These are hard limits, not disclaimers.
- No access to Revit, AutoCAD, SketchUp, Rhino, ArchiCAD, Vectorworks, or any design or modeling software: Claude is a language model. It cannot open, read, modify, or generate files in any design, drafting, or BIM platform. There is no integration and no way to connect it to your model.
- No access to Procore, Autodesk Construction Cloud, PlanGrid, Bluebeam, e-Builder, or any construction management platform: Claude cannot pull RFI logs, submittal registers, schedule data, or any live project data from any construction management system. Everything it works with must be pasted directly into the prompt.
- No real-time project schedule or budget data: Claude has no access to your project schedule, cost tracking, or budget status. Any schedule or cost references in a response are based entirely on what you provide.
- No building code compliance checking: Claude can help draft language that references IBC, ADA, NFPA, local codes, and zoning requirements, but it cannot check compliance, certify conformance, or substitute for a licensed professional's code review. It may get code citations wrong. Verify every code reference independently.
- No CSI MasterFormat or SectionFormat database access: Claude knows the CSI 3-part format and general structure. It does not have access to proprietary master specification libraries (Arcom, Spectext, or firm-owned masters). Output is a structured draft — not a pulled master section.
- Cannot generate shop drawings, submittals, or construction documents: Claude produces text. It cannot generate drawings, details, schedules, or any graphic construction document.
- No RFI tracking or formal document control: Claude does not maintain a live RFI log, submittal register, or any formal document control function. It drafts individual documents — it does not manage the project record.
- No guarantee of accuracy on material specs, product data, or manufacturer information: Claude may hallucinate product names, performance values, or standards references. Every material specification, product data reference, and standards citation must be verified against current manufacturer data sheets and published standards before inclusion in any project document.
What Claude does for AEC professionals: drafts the language, structure, and formatting of technical documents. The content verification, code compliance review, licensed professional sign-off, and formal issuance are yours.
6 Use Cases for Claude AI in AEC Work
1. CSI-Format Specification Section Drafting
Writing a specification section from scratch — even with a master spec library — requires organizing technical requirements, referencing the right standards, and maintaining 3-part CSI structure throughout. For project-specific sections, modified proprietary content, or performance spec sections that don't map cleanly to a master, the drafting time adds up fast. Claude takes your technical inputs and produces a complete 3-part section with placeholder brackets wherever product-specific, proprietary, or project-specific content needs to go.
Draft a complete CSI 3-part specification section using the information below.
Structure the output strictly in CSI MasterFormat 3-part format:
PART 1 — GENERAL
1.01 Summary (scope, work included, related sections)
1.02 References (list all standards — mark each [VERIFY CURRENCY])
1.03 Submittals (product data, shop drawings, samples, certificates)
1.04 Quality Assurance (qualifications, mockups if applicable)
1.05 Delivery, Storage, and Handling
1.06 Warranty
PART 2 — PRODUCTS
2.01 Manufacturers ([INSERT ACCEPTABLE MANUFACTURERS — DO NOT FABRICATE])
2.02 Materials (technical description with performance requirements)
2.03 Accessories and components
2.04 Mixes or fabrication (if applicable)
PART 3 — EXECUTION
3.01 Examination (pre-installation conditions and inspection)
3.02 Preparation
3.03 Installation (step-by-step, referencing standards)
3.04 Field Quality Control (testing, inspection, tolerances)
3.05 Cleaning and Protection
Use [INSERT PRODUCT DATA] wherever proprietary product information is required.
Use [PROJECT-SPECIFIC REQUIREMENT] wherever the spec needs project customization.
Flag every standards reference as [VERIFY CURRENT EDITION].
Section number: [e.g., 07 92 00]
Section title: [e.g., Joint Sealants]
Material or system: [describe what is being specified]
Key performance requirements: [list critical performance criteria]
Relevant standards: [list ASTM, ANSI, or other standards you want referenced —
Claude will flag all citations for verification]
Project tier: [commercial / institutional / residential / mixed-use]
Special conditions: [any project-specific requirements, exposure conditions,
sustainability requirements, or deviations from standard practice]
[VERIFY ALL CODE AND STANDARDS REFERENCES BEFORE INCLUDING IN PROJECT DOCUMENTS]
[DO NOT ISSUE FOR CONSTRUCTION WITHOUT SPEC WRITER REVIEW]
[ALL PRODUCT NAMES AND PERFORMANCE DATA MUST BE VERIFIED AGAINST
CURRENT MANUFACTURER DATA SHEETS]
The output gives you a fully structured section with clear brackets where the spec writer must insert verified product data and project-specific requirements. It is a working draft, not a finished spec — treat it as a first pass for the specification writer's review, not as a deliverable ready for the CD set.
2. RFI Response Drafting
A well-drafted RFI response is specific, traceable to the contract documents, and unambiguous about direction. Writing one under CA time pressure — referencing the right drawing and spec section, restating the question accurately, providing a clear resolution, and noting any cost or schedule impact — takes longer than it should when you are managing 40 open RFIs at once. Claude takes your intended resolution and produces a complete, formally structured RFI response ready for project architect review.
Draft a formal RFI response in standard construction administration format
using the information below.
Structure the response with the following sections:
PROJECT HEADER: Project name, project number, architect name, date of response
RFI NUMBER AND DATE: [RFI number] | Date Received: [date] | Date of Response: [today]
SUBJECT: one-line description of the RFI subject
RFI QUESTION (RESTATED): restate the contractor's question verbatim or near-verbatim
RESPONSE: narrative response — clear, specific, professionally written
REFERENCE DOCUMENTS: list applicable drawing sheets and specification sections
DIRECTION / RESOLUTION: explicit statement of required contractor action
COST AND SCHEDULE IMPACT: [PENDING OWNER REVIEW — DO NOT STATE IMPACT
WITHOUT AUTHORIZATION] or specific notation if provided
ATTACHMENTS: list any sketches, details, or supplemental instructions
RFI Number: [number]
Date received: [date]
Contractor's question: [paste the RFI question as written]
Relevant drawing or spec section: [sheet number / spec section]
Your intended resolution: [describe how you want to resolve this —
Claude will draft the formal response language around your direction]
Cost or schedule impact: [none / pending review / [your description]]
Any supplemental information to reference: [optional]
[REVIEW WITH PROJECT ARCHITECT BEFORE ISSUING]
[COST AND SCHEDULE IMPACTS REQUIRE OWNER AUTHORIZATION BEFORE RESPONSE]
[DO NOT ISSUE WITHOUT CONSTRUCTION ADMINISTRATOR SIGNATURE]
The direction you provide is the substance of the response. Claude provides the formal structure, professional language, and complete formatting — including the reference document list, explicit contractor direction, and appropriate impact notation. Every RFI response goes through the project architect before issuance. That requirement does not change because a draft was faster to produce.
3. Submittal Cover Letter and Review Commentary
Submittal review commentary has to be specific enough to be actionable and formally structured enough to be legally defensible. Generic disposition stamps without explanation leave the contractor without clear direction and expose the firm to claims. Writing individualized review commentary for 15 submittals in a single review cycle is a documentation problem more than a technical one. Claude takes your notes and disposition decision and drafts a complete, professionally formatted submittal transmittal with itemized commentary.
Draft a complete submittal review transmittal letter with professional
review commentary using the information below.
Structure the output as follows:
PROJECT HEADER: project name, project number, date, transmittal number
TO: [Contractor name and contact]
FROM: [Architect / CA name and firm]
RE: Submittal [number] — [spec section and title]
DISPOSITION: [state clearly: APPROVED / APPROVED AS NOTED /
REVISE AND RESUBMIT / REJECTED]
REVIEW COMMENTARY: itemized, numbered list of notes — each specific,
referencing contract document section where applicable
DEVIATIONS FROM CONTRACT DOCUMENTS: explicit list of any departures
from the drawings and specifications, with required contractor action
CONTRACTOR NEXT STEPS: clear statement of what the contractor must do next
RESUBMITTAL REQUIREMENTS: [if applicable — what must be included
in the next submittal]
Submittal number: [number]
Spec section: [number and title]
Submitting contractor: [name]
What is being reviewed: [description of the submittal content]
Disposition: [Approved / Approved as Noted / Revise and Resubmit / Rejected]
Your review notes and deviations: [paste your notes — Claude will draft
the formal commentary around your technical observations]
Contract document references: [drawing sheets and spec sections that apply]
[VERIFY DISPOSITION AGAINST CONTRACT DOCUMENTS BEFORE ISSUING]
[DO NOT ISSUE WITHOUT PROJECT ARCHITECT REVIEW]
[STAMP AND SIGN PER FIRM PROTOCOL BEFORE RETURNING TO CONTRACTOR]
The disposition is yours. The technical notes are yours. Claude structures them into formal, professionally written commentary that is specific, traceable, and formatted consistently across the entire submittal log. Consistency in submittal commentary is a CA quality issue — using a structured prompt for every review letter helps maintain it.
4. Project Narrative and Design Intent Statement
A project narrative written well positions the design for the audience reading it — an owner, a permit reviewer, an award jury, or a design development presentation attendee. The same project requires a different narrative length, register, and emphasis depending on where it is in the process. Writing three versions of the same narrative — short for a cover sheet, medium for a presentation, long for a design development owner report — from scratch at every milestone is time that could go to the design itself. Claude generates all three versions in one prompt.
Write a project narrative and design intent statement for the project described below.
Generate three versions at different lengths:
VERSION 1 — SHORT (approximately 150 words):
Use: permit application cover sheet, project directory, or drawing title sheet
Tone: clear, factual, professional — no jargon
Focus: project type, program, site, and primary design response
VERSION 2 — MEDIUM (approximately 350 words):
Use: design presentation, award submission, client milestone presentation
Tone: architectural — engaging, specific about design moves, avoids clichés
Focus: design concept / parti, key design decisions, relationship to site and program,
client goals, any sustainability or performance targets
VERSION 3 — LONG (approximately 600 words):
Use: design development narrative, owner project report,
design review board submission
Tone: comprehensive and authoritative — covers program, concept,
materials strategy, sustainability approach, community context
Focus: full story from program through design resolution, with measurable
outcomes noted as [INSERT SPECIFIC METRIC] wherever data will be added
Use [INSERT CLIENT NAME] wherever the client name should appear.
Use [INSERT SPECIFIC METRIC] wherever a specific measurement, area, cost,
or performance number should be inserted.
Use [INSERT LOCATION] wherever a specific site address or city should appear.
Project type: [e.g., mixed-use residential / K-12 school / community health center]
Program summary: [key spaces and areas — brief description]
Site context: [urban / suburban / rural; notable site conditions or constraints]
Design concept / parti: [your core design idea — one or two sentences]
Key design moves: [2–4 specific design decisions that define the project]
Client goals: [what the client has stated as priorities]
Sustainability targets: [LEED / WELL / Passive House / net zero / none — specify]
[REVIEW FOR ACCURACY BEFORE SUBMITTING TO OWNER OR AUTHORITY HAVING JURISDICTION]
[PERSONALIZE WITH PROJECT-SPECIFIC DETAILS BEFORE USING]
The three output versions give you a complete milestone set — from permit to presentation to owner report — all from a single prompt run. The [INSERT SPECIFIC METRIC] placeholders are intentional: Claude will not fabricate square footage, construction cost, energy use intensity, or any specific quantitative claim. Those numbers come from your project data.
5. Construction Meeting Minutes
Meeting minutes in AEC are not a courtesy — they are a project record. Decisions made verbally at the OAC table need to be captured, distributed, and acknowledged within 48 hours. Action items need owners and due dates. Disputed items need flagging. Writing complete, formatted minutes while managing a full CA project load is a documentation overhead problem. Claude takes your notes from the meeting and produces complete, formatted minutes ready for review and circulation.
Write complete, formatted construction meeting minutes from the notes below.
Structure the output with the following sections:
MEETING HEADER
Project name and number
Meeting type: [OAC / Design Team / Subcontractor Coordination / Other]
Date, time, and location
Next meeting: [date and time if known]
ATTENDANCE LOG
Attendees: [name, firm, role — one per line]
Distribution list: [same as attendees plus any absent parties]
AGENDA ITEMS (numbered)
For each item: topic heading, summary of discussion,
decisions (call out clearly as DECISION: [text]),
any outstanding questions or items requiring follow-up
ACTION ITEMS TABLE
| # | Action Item | Responsible Party | Due Date | Status |
List all action items from the meeting
NEXT MEETING
Date, time, location, agenda items to carry forward
Meeting type: [OAC / design team / subcontractor coordination]
Date: [date]
Attendees: [name, firm, role for each person]
Agenda items discussed: [paste your meeting notes — bullet points are fine,
Claude will expand into full summaries]
Decisions made: [list clearly — Claude will call each out as DECISION:]
Action items: [item, person responsible, due date for each]
Next meeting: [date and time if known]
[CIRCULATE FOR REVIEW AND COMMENT WITHIN 24–48 HOURS OF THE MEETING]
[NOTE ANY DISPUTED ITEMS IN A SEPARATE SECTION BEFORE DISTRIBUTING]
[ACTION ITEMS MUST BE CONFIRMED WITH RESPONSIBLE PARTIES BEFORE DISTRIBUTION]
The action item table format matters: who owns each item, when it is due, and current status. When these are formatted consistently across every meeting in the construction phase, tracking open items becomes a documentation function rather than a memory exercise. Use this prompt for every meeting type — OAC, design team, coordination — adjusting the agenda items section to reflect the meeting content.
6. Client and Owner Correspondence
Formal correspondence to owners follows a different register than internal project communication. Status updates, design issue notifications, change order proposal letters, project close-out transmittals, and post-occupancy follow-ups all require professional tone, clear organization, and appropriate urgency calibration for the specific situation. Writing a complete set of template letters for a project — one for each correspondence type you will need across the project lifecycle — in a single prompt session is a setup task that pays dividends through the entire project.
Write a complete set of 5 owner correspondence templates for the project described below.
Each letter should be in formal architectural business letter format:
Firm letterhead placeholder, date, owner name and address, RE: line, salutation,
body paragraphs, professional close, signature block placeholder.
Generate all 5 in a single output, clearly labeled:
LETTER 1 — MONTHLY PROJECT STATUS UPDATE
Tone: informative and professional
Content: project phase, work completed this period, work planned next period,
current issues requiring owner awareness, any items requiring owner decision
(flagged clearly), next milestone and date
LETTER 2 — DESIGN ISSUE NOTIFICATION (OWNER DECISION REQUIRED)
Tone: direct and clear — conveys urgency without alarm
Content: description of the design issue, why a decision is required, 2–3 options
presented neutrally with pros/cons, decision deadline, consequences
of delayed decision on schedule
LETTER 3 — CHANGE ORDER PROPOSAL COVER LETTER
Tone: formal and factual
Content: change order number, brief description of scope change,
basis for change (owner-directed / unforeseen condition / code requirement),
cost and schedule impact summary, request for owner authorization,
authorization deadline relative to construction schedule
LETTER 4 — PROJECT CLOSE-OUT TRANSMITTAL
Tone: formal and complete
Content: confirmation of substantial completion, list of close-out documents
transmitted (operations and maintenance manuals, warranties, as-built drawings,
training documentation, final lien waivers — listed as [INSERT ITEM]),
punchlist status, final payment application reference, next steps
LETTER 5 — POST-OCCUPANCY FOLLOW-UP AND LESSONS LEARNED REQUEST
Tone: professional and collegial — relationship-focused
Content: congratulations on occupancy, request for post-occupancy feedback
(building performance, design satisfaction, operational issues),
offer of continued support, invitation to connect for future work
Use [INSERT CLIENT NAME] throughout.
Use [INSERT PROJECT NAME] throughout.
Use [INSERT SPECIFIC DATE / AMOUNT / ITEM] wherever project-specific
data must be filled in.
Project type: [describe briefly]
Project phase at time of writing: [varies by letter — Claude will calibrate]
Firm name: [INSERT FIRM NAME]
[PERSONALIZE EACH LETTER BEFORE SENDING]
[CHANGE ORDER LETTERS REQUIRE PRINCIPAL REVIEW BEFORE ISSUANCE]
[DO NOT SEND DESIGN ISSUE NOTIFICATIONS WITHOUT CONFIRMING
DECISION DEADLINE WITH PROJECT SCHEDULE]
[CLOSE-OUT TRANSMITTAL MUST LIST ACTUAL DOCUMENTS BEING TRANSMITTED]
All five letters come back in a single output — complete templates with appropriate tone and urgency calibration for each situation. Save them into your firm's project folder at project start. The change order cover letter and design issue notification are the two that require the most careful review before sending: the first involves money, the second involves owner decisions that affect schedule. Both flags above are non-negotiable.
Why Claude Over ChatGPT for AEC Work
For AEC professionals specifically, four things make Claude the more useful tool.
One Project per active project. Claude Projects let you build a persistent context for each active project — paste in the program summary, the relevant spec divisions, your running RFI log, and the project narrative at the start of the construction phase. That context persists across the entire CA phase, not just a single session. When you draft an RFI response three months into construction, Claude still has the project context. ChatGPT's memory features do not replicate the explicit, file-organized project context that Claude Projects provide.
Context window handles a full spec division. A full specification division — all sections in Division 07, for example — fits in Claude's context window in a single session. You can paste the relevant spec sections, ask for a gap analysis, draft a new section, and cross-reference all in one conversation. That is not possible with tools that limit session length or context.
Structured output discipline. CSI 3-part format, RFI response headers, action item tables, formal business letter structure — Claude maintains format discipline across a long output. The output is ready to paste into your firm's templates and word processor, not a paragraph dump that needs reformatting.
Conservative on fabricated citations. This matters in AEC. Claude is more conservative than ChatGPT when it comes to inventing ASTM standard numbers, product data, manufacturer specifications, and code citations. ChatGPT has a documented tendency to fabricate specific standards references that sound plausible but do not exist — a significant liability risk in construction documents. Claude still requires verification of every citation, but it is less likely to generate confident-sounding invented references. The [VERIFY] flags in every prompt above are not optional — they apply regardless of which tool you use.
For a broader comparison of the two tools, see Claude vs. ChatGPT: Which AI is Better for Work.
4 Practical Tips for AEC Professionals
1. One Project per active project — not per client. Set up a Claude Project for each active project at the start of construction administration. Paste in the project summary, the spec table of contents, your RFI log structure, and the project narrative. Keep it updated as the project progresses. This gives you persistent context across the entire CA phase — specs, RFIs, meeting minutes, and owner correspondence all in one place. If you run a small firm or sole practice and want tips on using Claude for business operations, Claude AI for small business owners covers that layer.
2. Always paste the relevant spec section or drawing note before drafting an RFI response. Claude cannot look up your project documents. If you want it to reference Section 07 92 00 in an RFI response, paste the relevant portion of the spec section into the prompt. The quality of the RFI response is directly proportional to the document context you provide. "Draft an RFI response about joint sealants" produces a generic result. "Here is Section 07 92 00, Paragraph 2.01 — now draft an RFI response to this specific contractor question about acceptable manufacturers" produces a response you can actually use.
3. Use the project narrative prompt before every milestone presentation. SD, DD, CD, permit submission, award submission — each requires a narrative at the right length and register for that audience. Running the project narrative prompt before each milestone takes 20 minutes and produces a first draft that covers the full scope. The medium-length version covers most presentation needs. The long version covers owner reports and design review board submissions. Start from Claude's draft, not from a blank page.
4. Every spec section and RFI response output is a first draft for a licensed professional. This is the most important tip and it applies to every use case in this post. Nothing Claude produces goes to a contractor, an owner, or a permitting authority without review and sign-off by a licensed architect or professional engineer. Claude handles the documentation labor. The licensed professional provides the professional judgment, code compliance review, and liability. That division of labor is what makes the tool useful — and what makes it safe to use. For more on building advanced prompting habits that transfer across professional work, see Claude AI prompts that will change how you work. For the engineering side of AEC, Claude AI for software engineers covers the technical documentation workflows that structural and MEP engineers will find most relevant.
Ready to cut your spec writing and RFI time in half? The Complete Claude Playbook ($27) has the full prompt library, workflow templates, and advanced techniques for professional work like this — instant PDF download.