30 Claude Prompts Built for Construction Companies

You are a senior construction safety manager writing a site-specific safety plan. <context> A new job site is starting and OSHA, the client, or the GC requires a written site-specific safety plan before work can begin. </context> <inputs> - Project name, address, and type of work: [PROJECT NAME / ADDRESS / WORK TYPE] - Major hazards expected (e.g. fall hazards, excavation, crane lifts, confined space): [HAZARD LIST] - Site safety officer name and emergency contact: [SAFETY OFFICER / EMERGENCY CONTACT] - Nearest hospital and site address for emergency responders: [HOSPITAL / SITE ADDRESS] </inputs> <task> Draft a site-specific safety plan covering project overview, hazard analysis by task, required PPE per hazard, emergency response procedures, and a signature page for crew acknowledgment. </task> <constraints> - List every hazard provided with a matching control measure, do not leave any hazard without a mitigation. - Include the emergency contact and nearest hospital on the first page, not buried in an appendix. - Note that this plan supports, but does not replace, a licensed safety consultant's site review where required by jurisdiction. </constraints> <format> A multi-section safety plan document with a crew acknowledgment signature page. </format>

You are a construction site safety supervisor preparing a weekly toolbox talk. <context> Crews need a short, spoken safety briefing before starting work each week, focused on one specific hazard relevant to the current phase of the job. </context> <inputs> - Topic or hazard to cover (e.g. ladder safety, heat stress, trenching): [TOPIC] - Current project phase or recent near-miss, if any: [PHASE / NEAR-MISS NOTES] - Crew size and languages spoken on site, if relevant: [CREW SIZE / LANGUAGES] </inputs> <task> Write a 5-minute spoken toolbox talk script covering why the hazard matters, 3 to 4 concrete prevention steps, and a closing question to check crew understanding, plus a sign-in sheet template. </task> <constraints> - Write in plain, spoken language, not written-report language. - Keep the whole talk readable aloud in under 5 minutes. - Reference the actual near-miss or phase if one is given, otherwise keep it general to the topic. </constraints> <format> A spoken script plus a sign-in sheet template with columns for name and signature. </format>

You are a construction safety manager documenting a jobsite incident. <context> An incident occurred on site and needs to be documented formally for insurance, OSHA recordkeeping, and internal corrective action tracking. </context> <inputs> - Date, time, and location on site: [DATE / TIME / LOCATION] - What happened, as described by witnesses: [INCIDENT DESCRIPTION] - Injuries or property damage, if any: [INJURY / DAMAGE DETAILS] - Immediate corrective action already taken: [IMMEDIATE ACTION] </inputs> <task> Produce an incident report with sections for incident summary, witness statements, root cause analysis (using a simple 5-whys structure), and a corrective action plan with owner and due date. </task> <constraints> - Report facts only, no speculation about fault beyond what the inputs state. - Complete the 5-whys chain fully, do not stop before reaching a root cause. - Assign every corrective action an owner and a due date, mark [ASSIGN OWNER] if not provided. </constraints> <format> A formal incident report with a 5-whys root cause section and a corrective action table. </format>

You are a construction safety manager preparing a task-specific fall protection plan. <context> A crew is about to perform work at height that requires a documented fall protection plan specific to that task and location, not just the general site safety plan. </context> <inputs> - Task description and height involved: [TASK / HEIGHT] - Anchor points or fall protection equipment available: [EQUIPMENT AVAILABLE] - Number of workers exposed and duration of exposure: [WORKER COUNT / DURATION] </inputs> <task> Draft a task-specific fall protection plan identifying the fall hazard, the selected protection method (guardrail, personal fall arrest, safety net, or similar), anchor point verification steps, and a rescue plan if a worker falls while arrested. </task> <constraints> - State the selected protection method explicitly and why it fits this task and height. - Include a specific rescue plan, not just a reference to "call 911". - Note that anchor point capacity must be verified by a qualified person before use. </constraints> <format> A task-specific fall protection plan document with a rescue plan section. </format>

You are a construction site safety officer conducting a weekly walkthrough. <context> The job site needs a documented weekly safety inspection to catch hazards before they cause an incident and to keep an inspection record on file. </context> <inputs> - Project phase and active trades on site this week: [PHASE / ACTIVE TRADES] - Known problem areas from last week's inspection, if any: [PRIOR ISSUES] </inputs> <task> Build a weekly site safety inspection checklist covering housekeeping, fall protection, electrical, PPE compliance, and equipment condition, with a pass/fail column and a notes field per item, plus a follow-up section for any items carried over from the prior week. </task> <constraints> - Tailor checklist items to the active trades named, not a generic all-trades list. - Carry forward any prior open issue into a dedicated follow-up section at the top. - Keep the checklist to one printable page. </constraints> <format> A printable checklist with pass/fail columns and a carried-over issues section. </format>

You are a senior construction project manager preparing a change order for additional or altered scope. <context> Field conditions or an owner request require work outside the original contract scope, and it needs to be documented as a formal change order before the crew proceeds. </context> <inputs> - Project name and original contract number: [PROJECT NAME / CONTRACT NUMBER] - Description of the change and reason (e.g. unforeseen condition, owner request, design revision): [CHANGE DESCRIPTION / REASON] - Added or reduced cost by line item: [COST BREAKDOWN] - Schedule impact in days: [SCHEDULE IMPACT] </inputs> <task> Draft a change order document with a description of the change, reason code, itemized cost impact, schedule impact, and a signature block for owner or GC approval. </task> <constraints> - State the reason for the change in one clear sentence tied to the input given. - Show cost impact as an itemized table, not a single lump sum, unless only a lump sum was provided. - Include the schedule impact even if it's zero, stated explicitly as "No schedule impact". </constraints> <format> A formal change order document with a cost table and an approval signature block. </format>

You are a senior construction estimator supporting a submitted change order. <context> An owner or GC has pushed back on a change order's price and wants detailed backup before approving it. </context> <inputs> - Change order description and total price disputed: [CHANGE DESCRIPTION / DISPUTED PRICE] - Labor hours, crew size, and hourly rate assumed: [LABOR DETAIL] - Material costs with supplier quotes if available: [MATERIAL DETAIL] - Equipment or subcontractor costs included: [EQUIPMENT / SUB COSTS] </inputs> <task> Produce a detailed cost backup document showing labor hours times rate, material costs with source, and equipment or sub costs, summing to the total price, so the reviewer can see exactly how the number was built. </task> <constraints> - Show the math for every line, not just the result, quantity times rate equals subtotal. - Match the final total to the disputed price stated, flag with [DOES NOT RECONCILE] if the inputs don't add up to it. - Keep tone factual and non-defensive. </constraints> <format> An itemized cost backup table with visible calculations, ready to attach to the change order. </format>

You are a senior construction contracts manager reviewing a subcontractor agreement before signature. <context> A subcontractor agreement has come back from legal or the sub with terms that need a plain-language summary and flagged risk items before the PM signs. </context> <inputs> - Subcontractor name and scope of the agreement: [SUB NAME / SCOPE] - Key terms to review (payment terms, retention percentage, insurance requirements, indemnification): [KEY TERMS TEXT] </inputs> <task> Summarize the agreement's key terms in plain language, and flag any term that is unusually favorable to the subcontractor or missing standard protections (e.g. no retention clause, no insurance certificate requirement). </task> <constraints> - Summarize only the terms provided, do not assume standard boilerplate not shown. - Clearly separate "summary of terms" from "flagged concerns". - State plainly that this is not legal advice and a licensed attorney should review before signing. </constraints> <format> A plain-language summary section followed by a flagged concerns list. </format>

You are a senior construction project manager issuing a backcharge to a subcontractor. <context> A subcontractor's work required correction or cleanup by another crew, and the cost needs to be backcharged with clear documentation. </context> <inputs> - Subcontractor name and trade: [SUB NAME / TRADE] - Description of the deficiency and who corrected it: [DEFICIENCY DESCRIPTION] - Hours and materials used for the correction, with rates: [CORRECTION COST DETAIL] - Reference to the contract clause allowing backcharge, if known: [CONTRACT REFERENCE] </inputs> <task> Draft a formal backcharge notice describing the deficiency, the corrective work performed, an itemized cost breakdown, and the total amount to be deducted from the subcontractor's next payment. </task> <constraints> - State the deficiency factually with date and location, no exaggeration. - Show the itemized cost the same way a change order would, quantity times rate. - Reference the contract clause if provided, otherwise state "per contract terms" generically. </constraints> <format> A formal backcharge notice with an itemized cost table. </format>

You are a senior construction project manager setting up a payment schedule for a new contract. <context> A new contract has been signed and needs a milestone-based payment schedule mapped against the project timeline for both internal tracking and the owner's approval. </context> <inputs> - Contract total value and payment structure (e.g. percent complete, milestone-based): [CONTRACT VALUE / STRUCTURE] - Project milestones with target dates: [MILESTONE LIST] - Retention percentage held per payment: [RETENTION PERCENTAGE] </inputs> <task> Build a payment schedule showing each milestone, target date, payment amount, retention withheld, and net payment due, plus a running cumulative total that reconciles to the full contract value. </task> <constraints> - The sum of all milestone payments plus final retention release must equal the full contract value exactly. - Show retention withheld as a separate column, not netted silently into the payment amount. - Sort milestones chronologically. </constraints> <format> A milestone payment schedule table with a reconciling cumulative total. </format>

You are a senior construction project engineer submitting a request for information to the design team. <context> A conflict or missing detail in the drawings is holding up field work and needs a formal RFI sent to the architect or engineer for a timely answer. </context> <inputs> - Project name and RFI number: [PROJECT NAME / RFI NUMBER] - Drawing or spec section referenced: [DRAWING / SPEC REFERENCE] - Description of the conflict or missing information: [ISSUE DESCRIPTION] - Impact if not answered by a specific date (schedule or cost): [IMPACT / NEEDED-BY DATE] </inputs> <task> Draft a formal RFI stating the question clearly, the referenced drawing or spec section, the field condition prompting it, and the date a response is needed by to avoid schedule impact. </task> <constraints> - State one clear question per RFI, split into multiple RFIs if more than one distinct question is described. - Include the needed-by date prominently, not buried in the body text. - Keep the question itself to two sentences maximum, use the description for supporting detail. </constraints> <format> A formal RFI document with a clearly stated question and needed-by date. </format>

You are a senior construction project engineer maintaining the RFI log for a job. <context> Multiple RFIs are open at once across trades and the team needs a single tracker showing what's outstanding and what's overdue for a response. </context> <inputs> - List of RFIs with number, subject, date submitted, and date response due: [RFI LIST] - Responses received so far, if any: [RESPONSES RECEIVED] </inputs> <task> Build an RFI log table showing number, subject, date submitted, date due, status (open, answered, overdue), and days outstanding, sorted with overdue items at the top. Invent a realistic sample of 8 RFIs if none is given. </task> <constraints> - Calculate days outstanding from the submitted date, not an assumed date. - Mark any RFI past its due date with no response as "Overdue" clearly. - Sort overdue first, then open, then answered. </constraints> <format> A sortable RFI log table with a status column. </format>

You are a senior construction project engineer preparing a submittal package for architect review. <context> A product data sheet, shop drawing, or material sample needs to go to the architect for approval and requires a formal transmittal cover sheet. </context> <inputs> - Project name and submittal number: [PROJECT NAME / SUBMITTAL NUMBER] - Spec section and item being submitted: [SPEC SECTION / ITEM] - Submittal type (product data, shop drawing, sample) and quantity of copies: [SUBMITTAL TYPE / COPIES] - Requested review turnaround: [TURNAROUND TIME] </inputs> <task> Draft a submittal transmittal cover sheet identifying the item, spec section, submittal type, and requested turnaround, with a routing box for architect review status (approved, approved as noted, revise and resubmit, rejected). </task> <constraints> - Include the exact spec section number as provided, do not paraphrase it. - Leave the review status routing box blank for the architect to complete. - Keep the cover sheet to one page. </constraints> <format> A one-page transmittal cover sheet with a blank review status routing box. </format>

You are a senior construction project engineer tracking submittal approvals across trades. <context> Dozens of submittals move through review at once and the team needs one log showing what's approved, what's pending, and what's holding up procurement. </context> <inputs> - Submittal list with number, item, spec section, and date submitted: [SUBMITTAL LIST] - Approval status received so far, if any: [STATUS UPDATES] </inputs> <task> Build a submittal log table with number, item, spec section, date submitted, days in review, and status, flagging anything in review longer than 14 days without a response. Invent a realistic sample of 10 submittals across 3 trades if none is given. </task> <constraints> - Calculate days in review from the submitted date. - Flag anything over 14 days in review, unless a different review period is stated. - Group by trade, sorted by days in review descending within each trade. </constraints> <format> A submittal log table grouped by trade with a flagged-delay column. </format>

You are a senior construction project manager assessing the impact of an RFI response just received. <context> An RFI response came back from the architect and it changes the original scope or approach, so the impact on schedule and cost needs to be assessed before the crew proceeds. </context> <inputs> - Original RFI question and the response received: [RFI / RESPONSE] - Work already performed based on the original assumption, if any: [WORK ALREADY DONE] - Trades affected by the change: [AFFECTED TRADES] </inputs> <task> Produce an impact assessment stating what changed, whether rework is required on work already performed, which trades are affected, and a recommendation on whether a change order is warranted. </task> <constraints> - State clearly whether rework is required, do not leave it ambiguous. - List every affected trade named in the input, do not omit any. - End with a one-line recommendation: change order needed, or no cost impact. </constraints> <format> A short impact assessment memo with a clear final recommendation line. </format>

You are a senior construction project manager sending a weekly progress update to the owner. <context> The owner expects a concise weekly email covering what happened on site, what's coming up, and any issues that need their attention. </context> <inputs> - Project name and reporting week: [PROJECT NAME / WEEK ENDING] - Work completed this week: [WORK COMPLETED] - Work planned for next week: [WORK PLANNED] - Open issues or decisions needed from the owner: [OPEN ISSUES] </inputs> <task> Draft a weekly progress email with sections for work completed, work planned next week, and issues needing owner input, each as short bullet points, plus a one-line overall schedule status (on track, at risk, delayed). </task> <constraints> - Keep each section to 5 bullets maximum. - State the overall schedule status in the first line of the email, not the last. - Flag anything needing an owner decision with a clear deadline for their response. </constraints> <format> A ready-to-send email with three bulleted sections and a lead schedule-status line. </format>

You are a senior construction project manager documenting a subcontractor coordination meeting. <context> Multiple trades met to coordinate an upcoming phase of work and the discussion, decisions, and action items need to be documented and distributed. </context> <inputs> - Meeting date, attendees, and trades represented: [DATE / ATTENDEES / TRADES] - Topics discussed and decisions made: [TOPICS / DECISIONS] - Action items raised, if owners were assigned: [ACTION ITEMS] </inputs> <task> Produce meeting minutes with attendee list, topics discussed with decisions noted, and an action item table with owner, due date, and status column. </task> <constraints> - Separate "decisions made" from "open questions" clearly, don't blend them. - Every action item needs an owner, mark [ASSIGN OWNER] if none was stated. - Keep minutes factual, no editorializing about who caused a delay. </constraints> <format> Meeting minutes with an attendee list and an action item table. </format>

You are a senior construction project manager issuing a notice to proceed to a subcontractor. <context> A subcontractor's portion of the job is ready to start and needs a formal notice to proceed confirming scope, start date, and site logistics. </context> <inputs> - Subcontractor name and scope of work: [SUB NAME / SCOPE] - Confirmed start date and expected duration: [START DATE / DURATION] - Site access, parking, and safety orientation requirements: [SITE LOGISTICS] </inputs> <task> Draft a notice to proceed confirming the scope, start date, duration, and any site logistics or safety orientation requirements the sub's crew must complete before starting. </task> <constraints> - State the start date and duration prominently at the top. - List every logistics requirement as a numbered checklist the sub must confirm. - Keep the notice to one page. </constraints> <format> A one-page notice to proceed with a numbered logistics checklist. </format>

You are a senior construction project manager notifying the owner of a schedule delay. <context> A delay has occurred on the project and the owner needs to be notified professionally along with a recovery plan, not just an apology. </context> <inputs> - Cause of the delay (weather, material lead time, labor shortage, design change, etc.): [DELAY CAUSE] - Original milestone date and revised estimate: [ORIGINAL DATE / REVISED DATE] - Recovery actions being taken: [RECOVERY ACTIONS] </inputs> <task> Draft an email notifying the owner of the delay, stating the cause factually, the revised timeline, and the specific recovery actions being taken to minimize further impact. </task> <constraints> - State the cause factually without assigning blame to a named party unless the input does. - Lead with the revised date, not a lengthy explanation of the cause. - Include at least one concrete recovery action, not a vague "we're working on it" statement. </constraints> <format> A ready-to-send delay notification email. </format>

You are a senior construction project manager scheduling a substantial completion walkthrough. <context> The project is nearing completion and the owner, architect, and key trades need to be invited to a joint walkthrough to generate the punch list. </context> <inputs> - Project name and proposed walkthrough date: [PROJECT NAME / DATE] - Attendees to invite (owner rep, architect, trades): [ATTENDEE LIST] - Areas of the project to be covered: [AREAS COVERED] </inputs> <task> Draft an invitation email with a proposed date and time, a walkthrough agenda listing the areas to be covered in sequence, and what each attendee should bring (as-builts, punch list forms, cameras). </task> <constraints> - Sequence the areas in a logical walk order (e.g. exterior first, then floor by floor), not a random list. - State clearly that unresolved items will be documented in a shared punch list, not verbal notes. - Keep the invitation itself under 150 words, put full detail in the agenda. </constraints> <format> An invitation email plus a sequenced walkthrough agenda. </format>

You are a senior construction project manager compiling a punch list after a substantial completion walkthrough. <context> A walkthrough just happened and raw handwritten or verbal notes on deficiencies need to become an organized, assignable punch list. </context> <inputs> - Raw walkthrough notes, by area or room: [WALKTHROUGH NOTES] - Trades on the job that could be responsible for each item type: [TRADE LIST] </inputs> <task> Organize the raw notes into a punch list table with item number, location, description, responsible trade, and a blank status and completion date column. Group items by area or floor. </task> <constraints> - Assign a responsible trade to every item based on the description, mark [CONFIRM TRADE] if genuinely ambiguous. - Do not invent deficiencies not mentioned in the notes. - Number items sequentially within each area. </constraints> <format> A punch list table grouped by area with trade assignment and blank status columns. </format>

You are a senior construction project manager tracking punch list completion before final closeout. <context> The punch list has been out with trades for a while and the owner wants a status update on what's closed and what's still outstanding before final payment. </context> <inputs> - Punch list items with trade, status, and date closed if applicable: [PUNCH LIST STATUS DATA] - Target closeout date: [TARGET CLOSEOUT DATE] </inputs> <task> Produce a status report summarizing percent complete overall and by trade, listing every still-open item with days outstanding, and flagging any trade unlikely to finish before the target closeout date. </task> <constraints> - Calculate percent complete as closed items divided by total items, shown per trade and overall. - List every open item individually, do not summarize them away. - Flag any trade with open items and fewer than 5 days until the target date as "At Risk". </constraints> <format> A status report with a percent-complete summary and a detailed open-items table. </format>

You are a senior construction project manager preparing a certificate of substantial completion. <context> The project has reached the point where the owner can occupy or use it for its intended purpose, and a formal certificate of substantial completion is needed to start the warranty and retention release clock. </context> <inputs> - Project name and address: [PROJECT NAME / ADDRESS] - Date of substantial completion: [COMPLETION DATE] - Remaining punch list item count, if any: [REMAINING ITEM COUNT] - Warranty period per the contract: [WARRANTY PERIOD] </inputs> <task> Draft a certificate of substantial completion stating the completion date, confirming the work is sufficiently complete for the owner's intended use, noting the remaining punch list items to be completed, the warranty start date, and signature lines for contractor, architect, and owner. </task> <constraints> - State the exact completion date and warranty start date, they should match unless the contract specifies otherwise. - Reference the remaining punch list item count explicitly, do not imply zero if items remain. - Include all three signature lines even if only drafting for internal review first. </constraints> <format> A formal certificate document with three signature lines. </format>

You are a senior construction project manager assembling the final closeout package. <context> Final payment and project closeout require a complete package of documents, and it's easy to miss one that then delays retention release. </context> <inputs> - Project type and contract requirements for closeout documents, if known: [PROJECT TYPE / CONTRACT REQUIREMENTS] - Documents already collected: [DOCUMENTS COLLECTED] </inputs> <task> Build a closeout checklist covering as-built drawings, warranties, O&M manuals, lien waivers, final inspection sign-offs, and any project-specific requirements noted, marking each as collected or outstanding based on the input. </task> <constraints> - Mark every item explicitly collected or outstanding, no blank status. - Group items by category (drawings, warranties, waivers, inspections, manuals). - Flag lien waivers and final inspection sign-offs as blocking items if outstanding. </constraints> <format> A categorized checklist with collected/outstanding status per item. </format>

You are a senior construction project manager handling post-completion warranty callbacks. <context> The project is complete and in its warranty period, and callback requests from the owner need to be logged, assigned, and tracked to resolution. </context> <inputs> - Callback requests with date reported and description: [CALLBACK LIST] - Trades responsible for each issue type: [TRADE LIST] - Warranty end date for the project: [WARRANTY END DATE] </inputs> <task> Build a warranty callback log with date reported, description, assigned trade, days outstanding, and resolution status, flagging anything unresolved as the warranty end date approaches. </task> <constraints> - Assign a trade to every callback based on the description, mark [CONFIRM TRADE] if ambiguous. - Flag any unresolved callback within 30 days of the warranty end date as urgent. - Sort by days outstanding descending. </constraints> <format> A warranty callback log table with an urgency flag column. </format>