TL;DR: A practical workflow of ChatGPT prompts for architects, organised by work stage: briefing, site analysis, precedent, design rationale, planning research, specification, client reports, fees, and consultant coordination. Language work is safe to accelerate. Code compliance, fire, structure and accessibility are not, and this page says exactly where the line sits.
Is this page about buildings or about prompt engineering?
Buildings. If you design them for a living and you want ChatGPT to take work off your evenings, you are in the right place.
The name overlap is our fault. Our company is called Prompt Architects and we make a tool for people writing AI prompts, which has nothing to do with building design. We appear in these searches because of the name, so it is worth saying in the first paragraph rather than wasting ten minutes of yours.
Everything below assumes a practising architect with a live project and a deadline. If you want the image side, massing studies and material boards and competition renders, that is a separate craft and we cover it in AI prompts for architects (building design, not prompt design).
What can ChatGPT actually do in an architectural practice?
It works on language, not on buildings. That single distinction sorts almost every question you will have.
Architecture produces an enormous volume of prose: briefs, appraisals, design statements, stage reports, specifications, fee letters, RFIs, planning covering letters, meeting minutes. Most of it is you converting reasoning you already did into text somebody else can read. That conversion is what a language model is good at, and it is also the part of practice most likely to be happening at 10pm.
What it is not good at is anything with a right answer it cannot derive from the text in front of it. Codes, standards, structural behaviour, fire strategy, accessibility dimensions and site constraints all have right answers, all vary by jurisdiction, and all change. The model answers anyway, in the same fluent register it uses for everything else. There is no visual difference between a sentence it knows and a sentence it invented, which is the whole problem, and why ChatGPT makes things up explains the mechanism.
| Work stage | How far you can go | What stays with you |
|---|---|---|
| Briefing and requirements capture | Structure, summarise and interrogate your own notes | Deciding what the client actually needs |
| Site and context analysis | Organise your findings, generate the questions to ask | Every factual claim about the site |
| Precedent research | Compare and structure sources you supply | Confirming each project exists as described |
| Concept narrative and rationale | Draft and rewrite from your design moves | The design reasoning itself |
| Planning and regulatory research | Turn documents you supply into question lists | The compliance answer, always |
| Specification drafting | Skeletons, consistency checks, plain-language passes | Every performance figure and product decision |
| Client reports and statements | Full drafts from your material | The professional judgement being reported |
| Fee proposals and bids | Structure, scope wording, exclusions | Every number, and the risk position |
| Consultant coordination | Minutes, action logs, RFI wording | What is actually agreed |
The pattern across that table: it can carry the writing when you supply the substance. It cannot supply the substance.
How do you set it up before the first prompt?
Give it your practice context once, in a place it will persist, instead of retyping it into every chat.
ChatGPT's own prompting documentation describes four parts worth including for anything larger than a quick question: Goal (what should it do), Context (what information or sources will help), Output (what format, length and detail you need), and Boundaries (what must stay unchanged, what it should avoid or check with you before acting). Verified at learn.chatgpt.com/docs/prompting, accessed August 27, 2026. That page is explicit that you do not need to fill in every part.
The same documentation covers projects, which keep related chats, uploaded files, sources and shared instructions together, with project instructions applying across the chats inside them (learn.chatgpt.com/docs/projects, accessed August 27, 2026). One project per job, with the brief and the site information loaded in, is the right shape for architectural work.
Prompt 1. The practice context block. What it is for: paste once into project instructions or custom instructions. What to change: everything in brackets.
Context about me and my work, apply to everything in this project:
I am a [registered architect / architectural designer] at a [size]-person practice in
[location]. We work mainly on [sectors]. This project is [project type, storeys,
approximate area, procurement route, current work stage].
How I want you to work:
- Write in [British/American] English, plain professional prose, no marketing tone.
- Use only sources and files I supply in this project. If something is not in them,
say so and stop. Do not fill gaps from general knowledge.
- Never state a building regulation, code clause, standard, fire, structural or
accessibility requirement as fact. Flag it as a question for me instead.
- Where you make an assumption, list it under a heading called ASSUMPTIONS at the end.
- Ask me up to three clarifying questions before any task longer than one page.
That last set of instructions is doing the heavy lifting. The prompting documentation lists boundaries of exactly this kind as worked examples, one of them verbatim: "Use only the supplied sources. Flag missing information instead of guessing." (same page, same access date). It is the difference between a tool that drafts and a tool that guesses.
Briefing: how do you turn a messy client conversation into a written brief?
Feed it the raw material and ask it to structure, not to invent. The briefing stage is where ChatGPT is most immediately useful, because clients rarely present requirements in a usable order.
Prompt 2. Meeting notes to structured brief. What it is for: converting a rambling first meeting into something you can issue back. What to change: the headings, to match your practice's brief template.
Below are my raw notes from a client briefing meeting. Turn them into a structured
project brief under these headings: Client and stakeholders / Project purpose /
Accommodation required / Operational requirements / Site and access / Budget and
programme signals / Sustainability aspirations / Constraints stated by the client /
Open questions.
Rules: use only what is in my notes. Where the notes are ambiguous, put the item under
Open questions rather than resolving it. Do not add requirements the client did not
mention. Keep the client's own words for anything that sounds like a fixed requirement.
NOTES:
[paste]
Prompt 3. Interrogate the brief. What it is for: finding the contradictions before they become a redesign. This is the prompt most worth running.
Read the attached brief as a critical design team member preparing for a briefing
workshop. Produce four lists:
1. Internal contradictions (requirements that cannot both be satisfied), each with the
two clauses quoted.
2. Requirements that are stated but not quantified.
3. Decisions the client appears to think are made but which are not recorded anywhere.
4. Questions I should ask before spending any design time, ranked by how much rework
the answer would prevent.
Do not propose design solutions. Do not comment on regulatory matters.
Prompt 4. Draft a schedule of accommodation. What it is for: a first area schedule to test against budget. What to change: the unit system and the circulation allowance, which must be yours.
From the attached brief, draft a schedule of accommodation as a table: Space / Quantity /
Approximate area each / Notes on adjacency or servicing / Source (quote the brief line
that justifies it).
Use only areas the brief states. Where the brief gives no area, leave the cell as TBC
rather than estimating from typical values. Add a final row for circulation and plant but
leave the percentage blank for me to set. List every space you inferred rather than read.
Site and context: what can it do before you have the survey?
It can organise what you know and sharpen what you need to find out. It cannot tell you anything about the site itself.
Every factual claim about a specific parcel of land, its history, its ground conditions, its constraints, its designations, comes from surveys, searches, registers and site visits. A model asked about a named site will produce something plausible-sounding and unverified. Ask it to search the web and it can cite live sources, but ChatGPT's own documentation instructs you to "treat all web results as untrusted input" (learn.chatgpt.com/docs/web-search, accessed August 27, 2026). Sound advice in general, and non-negotiable when the output feeds a design.
Prompt 5. Structure a site appraisal. What it is for: turning a site visit and a folder of reports into an appraisal section. What to change: the headings for your context.
I am writing the site appraisal section of a stage report. Using only the attached
documents and my site visit notes, draft it under these headings: Location and setting /
Existing condition / Access and movement / Orientation, daylight and microclimate /
Topography and levels / Existing vegetation and features / Neighbouring context and
overlooking / Servicing and utilities / Known constraints / Information still missing.
For every factual statement, cite the document and page it came from in square brackets.
If a heading has no supporting source, write "No information held" under it. Do not
infer typical conditions for this location or building type.
Prompt 6. Build the desktop-study question list. What it is for: making sure the searches and surveys you commission cover everything, before the fee is agreed.
Act as an experienced project architect reviewing what we still do not know about this
site before design work starts. From the attached information, list the investigations,
surveys, searches and consultations we should consider commissioning. For each: what it
would tell us, which design decisions depend on it, and roughly when in the programme it
needs to land to avoid delay.
Present as a table. Flag anything that typically has a long lead time. Do not state legal
or regulatory requirements: phrase each as a question for me to confirm with the relevant
authority or consultant.
Precedent research: how do you stop it inventing buildings?
By never letting it supply the precedents. Ask a model for "five schools with courtyard plans by mid-career European practices" and you will get a list. Some of the buildings will be real, some will be real but by a different architect, and some will not exist. All of them will be described with equal confidence, complete with plausible dates.
The safe pattern reverses the roles: you supply the precedents, it does the comparison work.
Prompt 7. Comparative precedent analysis. What it is for: getting structured comparison out of material you have already gathered. What to change: the comparison criteria.
I have attached material on [n] precedent projects. Produce a comparative analysis table
with these columns: Project / Practice and date / Site condition / Organising diagram /
Circulation strategy / Material approach / What it does that is relevant to my project /
What would not transfer.
Use only the attached material. Where a cell cannot be filled from what I gave you, write
"Not in source". Do not add projects. Do not add facts about these projects from memory,
including dates, areas, awards or client names.
Prompt 8. Precedent search with a verification requirement. What it is for: widening the net, with the fabrication risk made explicit. Use it only with web search on, and check every result.
Search the web for built projects matching: [building type], [approximate scale],
[specific condition you care about, e.g. steeply sloping site, retrofit of a listed
structure, phased occupation during construction].
For each result give: project name, practice, location, completion year, and a link to a
source I can open. Only include projects where you found a source page naming the
practice. Do not include a project you cannot link. At the end, list separately any
project you considered but dropped because you could not verify it.
That last instruction is worth keeping in every research prompt you write. It converts silent invention into a visible list.
Concept narrative: where does ChatGPT genuinely earn its place?
Here. Design rationale is reasoning you have already done, trapped in your head, that has to become prose for a client, a committee, or a submission. Converting it is unglamorous and slow, and it is exactly the job a language model is built for.
Prompt 9. Design moves to rationale narrative. What it is for: a first draft of the rationale in your own logic. What to change: the audience and the length.
I will list the design moves we made and why. Turn them into a design rationale narrative
of about [400] words for [audience: client board / planning officer / competition jury].
Order it so the site and brief drive the moves, not the other way round. Keep my reasoning
intact: do not add justifications I did not give, and do not add sustainability,
community or wellbeing claims I have not made. Plain professional prose, no adjectives
doing work that the reasoning should do.
DESIGN MOVES:
1. [move] because [reason]
2. ...
Prompt 10. Stress-test the rationale. What it is for: hearing the objections before the meeting does. This one earns its place at every design review.
You are a sceptical [planning officer / client finance director / neighbour at a
consultation event] reading the attached design rationale. List the ten objections you
would raise, strongest first, quoting the sentence that provokes each one. For each,
note whether it is a matter of fact, of policy, or of taste.
Do not answer the objections. Do not soften them. Do not assess planning policy or
regulatory compliance: if an objection depends on either, say so and mark it for me to
check with the relevant authority.
Planning and regulations: why is this the most dangerous stage?
Because it is the one where a confident wrong answer looks exactly like a right one, and where being wrong has consequences that a rewrite cannot fix.
Three things make regulatory questions structurally unsafe for a general model. Codes are jurisdiction-specific, so the answer depends on where the building is. They are revised on independent schedules, so the answer depends on when. And they layer guidance over statute, so the answer depends on which document you are actually asking about.
Concretely: the Ministry of Housing, Communities and Local Government publishes the Approved Documents, described on GOV.UK as guidance "on ways to meet the building regulations", a distinction a model is likely to blur. Each carries its own date and its own scope. Approved Document B, "building regulation in England covering fire safety matters within and around buildings", shows as published 7 December 2010 and last updated 11 March 2025. Approved Document A, covering structure in England, shows as published 1 September 2013 with no later revision listed. The collection's update log records Approved Document T for toilet accommodation being added on 15 May 2024: an entire document that had not existed before. All checked on 27 August 2026.
A model trained before those revisions will not know they happened, will not know Approved Document T exists, and will not tell you it does not know. That is not a flaw you can prompt your way around, and it holds in every jurisdiction. The 2010 ADA Standards for Accessible Design are published at ada.gov; whether they apply to your project, and alongside which state and local codes, is not something a chat window can settle.
Prompt 11. Policy document to question list. What it is for: reading a local plan or design guide you have downloaded, and turning it into questions. What to change: the document type.
I have attached [local plan policy extract / design guide / conservation area appraisal]
that I downloaded from [source] on [date]. Using only this document:
1. List every requirement or expectation it places on a proposal like mine
([describe]), quoting the clause or paragraph reference for each.
2. For each, write the question I need to answer about my scheme.
3. Flag any requirement whose wording is ambiguous enough that I should seek
pre-application advice on it.
Do not tell me whether my scheme complies. Do not bring in any other policy, standard or
regulation from your own knowledge, including national ones.
Prompt 12. Regulatory question register. What it is for: one live document tracking who owes you which answer.
Build a regulatory and statutory question register for this project as a table: Question /
Which discipline or authority answers it / Why it matters to the design / Which drawings
or decisions are blocked until it is answered / Status.
Populate it only from the attached project documents and my notes. Where a question is
implied but not recorded, add it with status "Not yet raised". Do not answer any of the
questions yourself.
Prompt 13. Pre-application meeting preparation. What it is for: walking in with the right questions rather than a general chat.
I have a pre-application meeting with [authority] about the attached scheme. Draft an
agenda and a numbered list of specific questions to ask, ordered so that the answers
that most affect the design come first. For each question, note in one line why we are
asking and what we will do differently depending on the answer.
Base the questions only on the attached scheme description and policy extracts. Do not
predict how the authority will respond.
Specification drafting: how far can you let it go?
Far enough to save time on structure and consistency, and no further on content. Every performance figure, product selection, tolerance and standard reference is a decision with liability attached to it.
The productive uses are the boring ones: turning your stated intent into a clause skeleton for you to complete, and checking a document you wrote against itself.
Prompt 14. Performance intent to clause skeleton. What it is for: getting the structure down so you can fill in the substance. What to change: the specification system your practice uses.
I am drafting a performance specification for [element, e.g. the external wall build-up].
My intent is: [describe in plain language].
Produce a clause skeleton with the headings a specification of this element normally
carries, and under each, the questions I need to answer to complete it. Leave every
numeric value, standard reference and product name blank as [TBC by architect].
Do not insert any performance figure, standard number, classification or product. Do not
state what a regulation requires. If a heading is only relevant in some jurisdictions,
mark it as such and let me decide.
Prompt 15. Internal consistency check. What it is for: catching the contradiction between the spec and the drawing schedule before the contractor does.
Compare the attached specification against the attached drawing schedule and finishes
schedule. List every place where they disagree, quoting both sides: different materials
for the same element, elements specified but not drawn, elements drawn but not specified,
inconsistent naming, and conflicting references.
Report only disagreements between the documents I gave you. Do not judge whether either
is correct, adequate, or compliant. Do not propose replacement text.
Client reports and design statements: what is safe to draft?
Anything where you supply the reasoning and it supplies the prose. This category, along with briefing, is where most practices recover the most hours.
Prompt 16. Stage report narrative. What it is for: the report you owe at the end of a work stage. RIBA's own overview describes the Plan of Work as organising briefing, designing, constructing and operating into eight stages (architecture.com, accessed August 27, 2026), and each of those handovers wants a document.
Draft a [work stage] report for the client from the attached material: design summary,
what changed since the last stage and why, decisions taken, decisions still required from
the client, risks and how we are managing them, and what happens in the next stage.
Audience is [describe client's level of construction knowledge]. Around [n] words.
Use only the attached material. Put anything you inferred in a list called INFERRED at
the end. Where the material shows a decision was taken but not by whom, flag it.
Prompt 17. Technical to lay translation. What it is for: the committee paper, the neighbour letter, the client who is not a developer.
Rewrite the attached passage for a reader with no construction background, keeping every
technical fact exactly as stated. Do not simplify a fact into a different fact. Where a
technical term cannot be avoided, define it once in plain words on first use.
Then list separately any sentence in the original that you found ambiguous, because that
usually means it will be misread by the client too.
Fee proposals and bids: can ChatGPT price work?
No. It can write the document around your numbers, which is most of the effort but none of the risk.
Pricing depends on your overheads, your team's actual speed, your risk position and your local market. The model knows none of that. What it is good at is scope wording and, in particular, exclusions, where it will surface the omissions you have stopped noticing because you have written the same letter forty times.
Prompt 18. Fee proposal draft. What it is for: the proposal letter. What to change: everything numeric, which must come from you.
Draft a fee proposal letter to [client] for [project and scope]. I will supply the
figures; leave them as [FEE], [RATE], [PROGRAMME] for me to complete.
Include: understanding of the brief, proposed approach, scope of services by work stage,
what is excluded, what we assume the client provides, what other consultants are needed,
programme dependencies, and terms placeholders.
The exclusions and assumptions sections matter most: be thorough and list anything a
proposal of this type commonly omits. Do not state a fee, a rate, or a duration. Do not
describe our services as covering anything I have not listed.
Prompt 19. Bid answer from your own evidence. What it is for: PQQ and tender narrative questions, drafted from your real project record rather than from thin air.
Answer the attached bid question using only the attached project evidence from our
practice. Maximum [n] words. Structure: direct answer, then the specific evidence, then
the outcome with the figure or fact that proves it.
Use only claims supported by the attached evidence. Do not add accreditations,
certifications, awards, staff numbers or project values. If the evidence does not support
a strong answer, say which evidence I would need to gather instead of writing around it.
Consultant coordination: how do you keep the paper trail straight?
By writing the record immediately, which nobody does, because it takes an hour you do not have. This is the cheapest hour a model can buy back.
Prompt 20. Meeting to actions, RFIs and decisions. What it is for: turning a coordination meeting into three usable outputs.
From the attached meeting notes, produce three separate outputs:
1. Minutes: decisions taken, with who took each.
2. Action list: action, owner, due date, and which drawing or deliverable it affects.
Where an owner or date was not stated, write "Not agreed in meeting".
3. Information requests: each item where somebody needs information from somebody else,
written as a specific question rather than a topic.
Do not resolve disagreements recorded in the notes. Do not assign an owner who was not
named. Quote the note that supports each decision.
Prompt 21. The precise information request. What it is for: replacing the vague chase email that produces another vague answer.
Draft a short email to our [discipline] engineer requesting the information below.
For each item, state exactly what we need, the format we need it in, which design
decision is waiting on it, and the date after which it starts affecting the programme.
Professional and direct, no filler. Do not apologise for asking. Do not suggest what the
answer might be.
ITEMS:
- [item]
How do you verify what it gives you?
With a routine you run every time, not a judgement call you make when something looks odd. Fluent wrong output does not look odd, which is the entire difficulty.
Four steps. Every factual claim gets traced to the document it came from, which is why so many prompts above ask for a citation in square brackets. Anything the model added rather than read gets isolated into an ASSUMPTIONS or INFERRED list, turning invisible invention into a checkable one. Anything touching code, fire, structure, accessibility or planning becomes a question for somebody carrying a professional indemnity policy. And you read it yourself before it leaves the office.
That last step is not a formality. ChatGPT's own prompting documentation puts it plainly: for important work, ask it for a final check, such as flagging information it could not verify, and then "review the result yourself before you use or share it" (learn.chatgpt.com/docs/prompting, accessed August 27, 2026).
What must never be delegated?
The judgement, the sign-off, and anything with a statutory answer. Concretely: compliance determinations of any kind, fire strategy, means of escape, structural adequacy, accessibility standards, whether a design meets planning policy, whether a product is suitable for its application, whether a site constraint applies, and the professional advice you give a client.
The reason is not that the model is bad at prose. It is that it produces the same confident register whether it is summarising your brief or inventing a clause number, and a hallucination in a design statement is embarrassing while a hallucination in a fire strategy is something else entirely. Nothing about a drafting tool changes who is accountable for what gets built.
How do you stop rewriting these prompts every project?
Save them once, with the project-specific parts as variables, and reuse them. The ChatGPT prompts for architects above are deliberately written with bracketed slots for exactly this reason.
The practice-context block from Prompt 1 changes per project. The interrogate-the-brief prompt does not. Neither does the consistency check, the precedent rules, or the verification prompt. Those are permanent assets that get sharper every time you use them, which is the argument for keeping a prompt template library rather than digging through old chats. We wrote up the general case in how to reuse prompts without copy-pasting.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 5.0★ on the Chrome Web Store.
Create An AccountWhere to go next
For the image side, concept visuals, massing and material studies, AI prompts for architects covers it properly. For the technique behind why these prompts are shaped the way they are, prompt engineering for architects works through it as a short course. If your practice has standardised on Gemini instead, architecture prompts for Gemini covers what changes.
The through-line: the model writes, you decide. Architecture carries statutory duties and a regulator that holds you to a standard of competence, and no amount of good prompting moves that boundary. Inside it, there are a lot of evenings to be won back.