architectural-programme-brief

name	architectural-programme-brief
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.
homepage	https://mohitagw15856.github.io/pm-claude-skills/skill/architectural-programme-brief.html
metadata	{"openclaw":{"emoji":"🧠"}}

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

1. 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.
2. Put an area against everything. An unpriced schedule is a wish list. Areas are what make the budget conversation possible.
3. 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.
4. 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.
5. Name constraints before they become surprises. Planning context, rights of light, access, ground conditions, services capacity, listed status.
6. 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"