Architectural programme brief
Turn a client's wishes into an architectural brief that can actually be designed against — the accommodation schedule, the adjacencies, the budget reality, and the constraints named before they become change orders.
How to use it
Claude Code
- Run the line below. It pulls the whole folder into
~/.claude/skills/architectural-programme-brief. - Describe your job in plain words. Claude Code follows the skill from there.
npx degit mohitagw15856/pm-claude-skills/skills/architectural-programme-brief#main ~/.claude/skills/architectural-programme-briefFor one project only, change the path to .claude/skills/architectural-programme-brief.
Claude (web or desktop app)
- On this page open ⋯ → Download .md.
- Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
- Pick the file and Save. Claude shows the name and description and runs a security scan.
- Check the skill is switched on.
- Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
- ChatGPT: make a Project and paste it into Instructions.
- Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
- Check which app you pasted it into — the steps above name the right one.
- Some skills need the paid tier of Claude or ChatGPT.
Paste into Claude, ChatGPT or Cursor.
Source of Architectural programme brief
Show the full text91 lines
| name | description |
|---|---|
| architectural-programme-brief | Turn a client's wishes into an architectural brief that can actually be designed against — the accommodation schedule, the adjacencies, the budget reality, and the constraints named before they become change orders. Use when asked to write an architectural brief, prepare a project brief for a building, run a client briefing, or capture requirements for a new build or refurbishment. Produces the accommodation schedule with areas, the adjacency and circulation requirements, the site and statutory constraints, the budget and programme reality check, and the explicit exclusions. |
Architectural Programme Brief
Clients brief in rooms and adjectives; buildings are designed from areas, adjacencies and constraints. The gap between the two is where scope creep lives. This converts the conversation into a schedule you can design against, tests the budget against the areas before anyone draws anything, and writes down what the project is not — the single most valuable page in any brief.
What This Skill Produces
- An accommodation schedule — every space with its area, occupancy, and the activity it must support
- Adjacency and circulation requirements — what must be near what, what must never be, and the routes between
- Site and statutory constraints — planning context, access, orientation, services, and known designations
- Performance requirements — servicing, acoustics, daylight, accessibility, and environmental targets, stated as requirements rather than aspirations
- The budget and programme reality check — the area total against the budget at a realistic rate, before design begins
- Explicit exclusions — what this project is not doing, agreed and written down
Required Inputs
Ask for these if not provided:
- The client and the driver — who they are, and what problem the building is supposed to solve
- The activities — what will actually happen in the building, by whom, and when
- The site — location, area, existing structures, access, orientation, and any known designations or constraints
- The budget and programme — the number they have and the date they need it, however soft
- The fixed points — anything already decided, promised, or non-negotiable
Framework: Activities Before Rooms, Areas Before Budget
- Brief the activity, not the room. 'A place for forty people to eat that empties in twenty minutes' designs better than 'a canteen'. Rooms are a solution; activities are the requirement.
- Put an area against everything. An unpriced schedule is a wish list. Areas are what make the budget conversation possible.
- Test the budget early and bluntly. Total area at a realistic rate per square metre, against the stated budget. If it does not work, say so in the brief rather than discovering it at tender.
- Map adjacencies as a matrix. Must-be-near, must-not-be-near, and the routes people take between them. This is where the plan actually comes from.
- Name constraints before they become surprises. Planning context, rights of light, access, ground conditions, services capacity, listed status.
- Write the exclusions down and get them agreed. The scope you did not include is only excluded if it is on paper.
Deeper Material
references/worked-example.md— a community hall whose budget is £461k short of its own accommodation schedule, found before anyone drew a line. Read it when the shape of a good output is unclear, or to calibrate how specific the entries should be.
Output Format
Project brief: [project] · [client] · [date] · rev [n]
Project driver: [the problem the building solves, in one paragraph]
Accommodation schedule
| Space | Activity supported | Area (m²) | Occupancy | Key requirements |
|---|---|---|---|---|
| Net area: [x] m² · Gross (at [n]% circulation/plant): [y] m² |
Adjacencies: must be adjacent [pairs] · must be separated [pairs] · key routes [list]
Site & statutory: [location, area, access, orientation, existing structures, designations, planning context, known constraints]
Performance: accessibility [standard] · environmental target [standard/rating] · acoustics [where it matters] · daylight [requirement] · servicing strategy [outline]
Budget check: [y] m² × [rate]/m² = [construction cost estimate] vs stated budget [amount] → [aligned / gap of [amount]] If there is a gap: [the options — reduce area, change specification, phase, or increase budget]
Programme: [key dates, and whether they are achievable against a realistic consent and construction period]
Explicitly excluded: [what this project does not include — agreed with client on [date]]
Assumptions: [what has been assumed pending information, and what would change if wrong]
Quality Checks
- Every space is justified by an activity, not just named
- Areas are stated and totalled, gross as well as net
- The budget is tested against the area before design begins
- Adjacencies are recorded as requirements, not left to the plan
- Statutory and site constraints are named rather than assumed away
- Exclusions are written down and agreed
- Assumptions are flagged with what changes if they turn out wrong
Anti-Patterns
- Briefing in room names. Locks in a solution before the requirement is understood.
- A schedule with no areas. Guarantees the budget conversation happens after the design.
- Deferring the budget test. The gap does not shrink by being discovered later; it just costs more to fix.
- Aspirations written as requirements. 'Sustainable' is not a requirement; a target rating is.
- No exclusions page. Every undocumented exclusion becomes a variation.
- Accepting a programme without testing it. Consent periods are not negotiable by optimism.
Example Trigger Phrases
- "Write an architectural brief for a new community building"
- "Help me capture what the client actually needs"
- "Turn these client notes into a project brief"
- "Does this budget work for the accommodation they are asking for?"
- "Write a brief for a house extension"
| 1 | |
| 2 | name architectural-programme-brief |
| 3 | description "Turn a client's wishes into an architectural brief that can actually be designed against — the accommodation schedule, the adjacencies, the budget reality, and the constraints named before they become change orders. Use when asked to write an architectural brief, prepare a project brief for a building, run a client briefing, or capture requirements for a new build or refurbishment. Produces the accommodation schedule with areas, the adjacency and circulation requirements, the site and statutory constraints, the budget and programme reality check, and the explicit exclusions." |
| 4 | |
| 5 | |
| 6 | # Architectural Programme Brief |
| 7 | |
| 8 | Clients brief in rooms and adjectives; buildings are designed from areas, adjacencies and constraints. The gap between the two is where scope creep lives. This converts the conversation into a schedule you can design against, tests the budget against the areas before anyone draws anything, and writes down what the project is not — the single most valuable page in any brief. |
| 9 | |
| 10 | ## What This Skill Produces |
| 11 | |
| 12 | **An accommodation schedule** — every space with its area, occupancy, and the activity it must support |
| 13 | **Adjacency and circulation requirements** — what must be near what, what must never be, and the routes between |
| 14 | **Site and statutory constraints** — planning context, access, orientation, services, and known designations |
| 15 | **Performance requirements** — servicing, acoustics, daylight, accessibility, and environmental targets, stated as requirements rather than aspirations |
| 16 | **The budget and programme reality check** — the area total against the budget at a realistic rate, before design begins |
| 17 | **Explicit exclusions** — what this project is not doing, agreed and written down |
| 18 | |
| 19 | ## Required Inputs |
| 20 | |
| 21 | Ask for these if not provided: |
| 22 | **The client and the driver** — who they are, and what problem the building is supposed to solve |
| 23 | **The activities** — what will actually happen in the building, by whom, and when |
| 24 | **The site** — location, area, existing structures, access, orientation, and any known designations or constraints |
| 25 | **The budget and programme** — the number they have and the date they need it, however soft |
| 26 | **The fixed points** — anything already decided, promised, or non-negotiable |
| 27 | |
| 28 | ## Framework: Activities Before Rooms, Areas Before Budget |
| 29 | |
| 30 | **Brief the activity, not the room.** 'A place for forty people to eat that empties in twenty minutes' designs better than 'a canteen'. Rooms are a solution; activities are the requirement. |
| 31 | **Put an area against everything.** An unpriced schedule is a wish list. Areas are what make the budget conversation possible. |
| 32 | **Test the budget early and bluntly.** Total area at a realistic rate per square metre, against the stated budget. If it does not work, say so in the brief rather than discovering it at tender. |
| 33 | **Map adjacencies as a matrix.** Must-be-near, must-not-be-near, and the routes people take between them. This is where the plan actually comes from. |
| 34 | **Name constraints before they become surprises.** Planning context, rights of light, access, ground conditions, services capacity, listed status. |
| 35 | **Write the exclusions down and get them agreed.** The scope you did not include is only excluded if it is on paper. |
| 36 | |
| 37 | ## Deeper Material |
| 38 | |
| 39 | **[`references/worked-example.md`]** — a community hall whose budget is £461k short of its own accommodation schedule, found before anyone drew a line. Read it when the shape of a good output is unclear, or to calibrate how specific the entries should be. |
| 40 | |
| 41 | ## Output Format |
| 42 | |
| 43 | ### Project brief: [project] · [client] · [date] · rev [n] |
| 44 | |
| 45 | **Project driver:** [the problem the building solves, in one paragraph] |
| 46 | |
| 47 | **Accommodation schedule** |
| 48 | | Space | Activity supported | Area (m²) | Occupancy | Key requirements | |
| 49 | |---|---|---|---|---| |
| 50 | | | | | | | |
| 51 | **Net area:** [x] m² · **Gross (at [n]% circulation/plant):** [y] m² |
| 52 | |
| 53 | **Adjacencies:** must be adjacent [pairs] · must be separated [pairs] · key routes [list] |
| 54 | |
| 55 | **Site & statutory:** [location, area, access, orientation, existing structures, designations, planning context, known constraints] |
| 56 | |
| 57 | **Performance:** accessibility [standard] · environmental target [standard/rating] · acoustics [where it matters] · daylight [requirement] · servicing strategy [outline] |
| 58 | |
| 59 | **Budget check:** [y] m² × [rate]/m² = **[construction cost estimate]** vs stated budget **[amount]** → [aligned / gap of [amount]] |
| 60 | **If there is a gap:** [the options — reduce area, change specification, phase, or increase budget] |
| 61 | |
| 62 | **Programme:** [key dates, and whether they are achievable against a realistic consent and construction period] |
| 63 | |
| 64 | **Explicitly excluded:** [what this project does not include — agreed with client on [date]] |
| 65 | |
| 66 | **Assumptions:** [what has been assumed pending information, and what would change if wrong] |
| 67 | |
| 68 | ## Quality Checks |
| 69 | [ ] Every space is justified by an activity, not just named |
| 70 | [ ] Areas are stated and totalled, gross as well as net |
| 71 | [ ] The budget is tested against the area before design begins |
| 72 | [ ] Adjacencies are recorded as requirements, not left to the plan |
| 73 | [ ] Statutory and site constraints are named rather than assumed away |
| 74 | [ ] Exclusions are written down and agreed |
| 75 | [ ] Assumptions are flagged with what changes if they turn out wrong |
| 76 | |
| 77 | ## Anti-Patterns |
| 78 | **Briefing in room names.** Locks in a solution before the requirement is understood. |
| 79 | **A schedule with no areas.** Guarantees the budget conversation happens after the design. |
| 80 | **Deferring the budget test.** The gap does not shrink by being discovered later; it just costs more to fix. |
| 81 | **Aspirations written as requirements.** 'Sustainable' is not a requirement; a target rating is. |
| 82 | **No exclusions page.** Every undocumented exclusion becomes a variation. |
| 83 | **Accepting a programme without testing it.** Consent periods are not negotiable by optimism. |
| 84 | |
| 85 | ## Example Trigger Phrases |
| 86 | "Write an architectural brief for a new community building" |
| 87 | "Help me capture what the client actually needs" |
| 88 | "Turn these client notes into a project brief" |
| 89 | "Does this budget work for the accommodation they are asking for?" |
| 90 | "Write a brief for a house extension" |
| 91 |
Discussion
Browse more free Claude skills or everything in Finance.


