Prompt Libraries & Custom Assistants

A prompt that produces a great result is not a lucky accident to be thrown away - it is a small piece of intellectual property you developed. It encodes what you learned about how to frame a task so the AI does it well: the role you assigned, the constraints you set, the format you asked for, the examples you gave. Re-deriving that every time is pure waste.

The first, lowest-effort move is simply to keep the ones that work. A note file, a shared document, a dedicated tool - the medium barely matters. What matters is that when you nail a prompt, you paste it somewhere findable with a one-line label of what it does. Over a few months this becomes a prompt library: a searchable collection of your studio's best-known-good instructions for recurring tasks - drafting a finishes schedule, summarising a code section, writing a client update, generating a moodboard in your house style.

A good library entry is more than the raw text. Note what it is for, which tool it works best in, and what you usually have to swap in (the project name, the room, the climate). That turns a frozen block of text into a template with obvious blanks. The best libraries also record a line or two on why the prompt works - 'assigning the architect role sharpens the spatial suggestions' - because that reasoning is what lets a colleague adapt it rather than just copy it.

There is a compounding effect here that mirrors the last lesson. Each saved prompt is a warm start for a future task. A library of thirty good ones means most of your recurring AI work begins from something already refined - which is both faster and more consistent than everyone improvising in isolation.

Before building anything bespoke, use the setting most assistants already give you: custom instructions (sometimes called a system prompt or personalisation). This is a standing message the AI reads before every conversation - a place to state, once, who you are and how you want it to respond, so you stop repeating it.

For a designer, a few lines go a long way. You might say you are an interior designer working mostly on Indian residential projects, that you want concise answers with concrete examples, that specifications should follow a particular format, and that the assistant should flag uncertainty rather than bluff. From then on, every chat starts already tuned to your context.

Custom instructions (example):
  Role: I am an architect; most projects are small residential
        buildings in hot-dry India.
  Style: Be concise. Give concrete, buildable suggestions. Use
         metric units. Prefer tables for schedules.
  Rigour: Flag anything you are unsure about; never invent a
          code clause, product name or citation.

That last line matters. Custom instructions are also where you install your guardrails - the standing reminders that keep the AI honest about the things this course cares about. It cannot eliminate hallucination, but instructing the model to flag uncertainty and refuse to fabricate references measurably shifts its default behaviour. Think of custom instructions as the base layer under everything else: cheap to set up, and applied automatically to every conversation you have.

The next level up bundles instructions and reference material into a reusable, shareable assistant. The two common forms in 2026 are custom GPTs (in ChatGPT) and Claude Projects (in Claude); Gemini offers 'Gems' in the same spirit. The idea is identical: you create a configured assistant with a fixed set of instructions plus a body of knowledge - files you upload that it can draw on - so it starts every conversation already grounded in your world.

This is where a real studio toolkit takes shape. Imagine a 'Spec Drafter' assistant loaded with your standard specification template, your preferred suppliers and your house wording; a 'Brief Interrogator' primed with the questions your practice always asks a new client; a 'Code Helper' holding the local regulations you refer to constantly. Each one carries your standards so the output arrives closer to house style, needing less correction.

Grounding an assistant in your own documents this way is a light form of retrieval - the assistant answers from the material you gave it rather than only from its general training, which both sharpens relevance and reduces (though never removes) invention. Two honest cautions, though. First, whatever you upload is being sent to a third-party service; never load confidential client data without checking your data terms and consent (Module 9.4). Second, a grounded assistant is still a language model - it can still misread its own reference files, so the human gate does not go away. What you gain is a strong, consistent starting point; what you keep is the duty to check.

To make this concrete, picture three assistants a small practice might build in an afternoon, each solving a real recurring pain and each showing the pattern in action.

The Brief Interrogator. Loaded with the questions your practice always asks a new client - budget bands, site constraints, must-haves, timeline, taste references - and instructed to interview you conversationally and then produce a structured brief. On the next enquiry, a junior runs it, answers the prompts, and hands you a competent first-draft brief in your house format instead of a blank document. You still refine it, but the cold start is gone.

The Spec Drafter. Given your standard specification template, your preferred suppliers and your house wording, and told to turn a plain materials list into a formatted finishes schedule, flagging anything ambiguous rather than inventing it. Because this is high-stakes output, its instructions lean hard on the honesty guardrails - never fabricate a product code or a standard - and you verify every line. What it saves is the formatting drudgery, not the judgement.

The Code Helper. Grounded in the specific local regulations and design standards you refer to constantly, and instructed to answer only from those documents, quote the clause, and say plainly when something is not covered. This is genuinely useful for fast orientation - but it is also where the limits bite hardest, so you treat every answer as a pointer back to the source, never as the authority itself.

Notice the pattern across all three: each carries your standards so output arrives closer to house style, each is scoped to one recurring job, and each keeps a human check calibrated to its stakes - light on the brief, ruthless on the spec and the code. That is a studio toolkit in miniature: a few trusted assistants, each doing one thing well.

A personal collection of prompts helps one person. A shared toolkit - agreed prompts and custom assistants that the whole studio draws on - is what makes AI a practice capability rather than a private trick. The difference is governance, and it is mostly organisational, not technical.

Start small and real. Pick the three or four tasks your studio does most often and most repetitively - drafting finishes schedules, writing client updates, summarising codes, first-pass moodboards - and build one solid, tested prompt or assistant for each. Name them clearly, store them where everyone can reach them, and appoint someone to own each one so it gets refined rather than silently rotting. A living toolkit of five things people trust beats a dumping ground of fifty nobody maintains.

Consistency is a real, underrated benefit here. When everyone drafts specs through the same well-made assistant, the output shares a voice and a structure, which raises the floor of quality and makes reviewing easier. It also lowers the barrier for less confident team members: a junior designer with a good 'Brief Interrogator' produces a competent first pass without years of prompt-craft. (Module 10.2 goes deeper on team workflows and governance.)

Keep three habits and the toolkit stays healthy. Version it - note when a prompt changes and why. Review it - the underlying models update, so retest your key prompts periodically. And guard it - be explicit about what client information may and may not go into shared assistants. A studio toolkit is not a one-time build; it is a small, living asset that quietly compounds every project you run through it.