本文へ移動
cccskills
無料GitHub で公開

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.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md6.1 KB
  • references/worked-example.md5.1 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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

SpaceActivity supportedArea (m²)OccupancyKey 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"

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.

日本語の概要は準備中です。原文の説明を表示しています。

mohitagw15856/pm-claude-skills1,4412026年10月13日 更新

Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.

日本語の概要は準備中です。原文の説明を表示しています。

mohitagw15856/pm-claude-skills1,4412026年10月13日 更新

Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.

日本語の概要は準備中です。原文の説明を表示しています。

mohitagw15856/pm-claude-skills1,4412026年10月13日 更新

Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.

日本語の概要は準備中です。原文の説明を表示しています。

mohitagw15856/pm-claude-skills1,4412026年10月13日 更新

Build or tailor an academic CV for faculty, postdoc, research or fellowship applications: publications, grants, teaching, supervision and service in the order the field expects, with consistent citations. Use when asked to write my academic CV, update my CV for a lectureship, tenure-track or postdoc application, format my publications list, or adapt my academic CV for an industry research role. Produces the full academic CV, a field-appropriate section order, a clean publications list in one citation style, and a two-page summary version when asked.

日本語の概要は準備中です。原文の説明を表示しています。

mohitagw15856/pm-claude-skills1,4412026年10月13日 更新

Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.

日本語の概要は準備中です。原文の説明を表示しています。

mohitagw15856/pm-claude-skills1,4412026年10月13日 更新

mohitagw15856 のスキルをすべて見る

このスキルの問題を報告する