This one is for the daily Breeze users, the team leads, and anyone who has written a genuinely brilliant prompt, watched it produce something great, and then never managed to find it again three weeks later.
What: Using Breeze Assistant to design a Breeze project, a shared AI workspace that carries your instructions, your knowledge and your context into every chat inside it, so a great prompt stops being a thing one person got lucky with once and becomes a reliable expert the whole team can open and use. The clever part is that you use Breeze to design the project itself.
Prompt of the week:
Somewhere in your team's chat history is a genuinely brilliant prompt. Someone spent twenty minutes crafting it, it produced something excellent, everyone was impressed for an afternoon, and then it scrolled quietly out of view and was never seen again. Next week someone rewrites a rougher version from memory, gets a rougher result, and without anyone quite noticing, the quality of your team's AI output becomes a lottery: dependent on who happened to ask, and how well they happened to remember how to ask.
This is the exact problem Breeze projects were built to solve, and it is the most significant recent change to how Breeze works. A project is a shared workspace that applies one fixed set of instructions and one body of knowledge to every conversation held inside it. You set it up once, and from then on anyone who opens the project gets an assistant that already knows its job, already has your brand and your documents in front of it, and already replies in the format you want, with no prompt typed at all. As of July 2026 projects replaced custom assistants entirely, and were rebuilt to take direct file uploads, mentions of CRM records, and team permissions, so this is the surface worth learning now.
Here is the catch that trips almost everyone up, though: a vague brief produces a vague project, every time. Create an empty project, paste in something vague like “help with marketing”, and you get a slightly worse version of the generic chatbot you were trying to escape. The gap between a project that behaves like a seasoned expert and one that produces bland filler comes down to two things, the precision of its instructions and the quality of the knowledge you attach, and those are design decisions most people have never been shown how to make.
So this week's prompt does something a little different. It uses Breeze to design a Breeze project. You describe the recurring job you want handled, and Breeze produces the complete specification: the exact instructions to paste, the precise documents and CRM context to attach, the tools to switch on and the ones to leave off, who should have access, and a starter prompt to run inside it. It is the highest-leverage move available in the new Breeze, turning a one-off prompt into a permanent, shared capability, and building it afterwards takes about five minutes.
Prompt structure
Paste this into Breeze Assistant and make sure CRM data access is enabled in your AI settings so Breeze can see your properties, objects, and the shape of your data as it designs the project:
Role: You are a HubSpot Breeze architect who designs Breeze
projects. You know a project is a reusable AI workspace that applies
shared instructions, knowledge and context to every chat held inside
it, and that a project is only as strong as its instruction layer and
the knowledge it is given. You design projects that behave like a
reliable expert, not a generic chatbot wearing a company logo.
Task: Help me design a Breeze project for a recurring job my team
does. Produce the complete specification: the instruction block to
paste, the knowledge and context to attach, the tools to enable, the
access model, and a starter saved prompt to run inside it. Make it
precise enough that anyone on the team gets consistent, expert output
without writing a prompt of their own.
Context:
- Company: [COMPANY NAME]
- Industry: [INDUSTRY]
- HubSpot tier: [Marketing / Sales / Service / Content Hub edition]
- The recurring job this project should do:
[describe it plainly, e.g. "prepare renewal briefs for account
managers", "write on-brand campaign copy", "triage inbound
support tickets", "research and qualify inbound leads"]
- Who will use it: [the team or roles, and their confidence level]
- What a great output looks like: [what the ideal result contains]
- The knowledge and data it should draw on: [brand documents,
product docs, a knowledge vault, specific CRM objects, lists]
- What it must never do or get wrong: [the expensive mistakes]
Design the following:
1. THE JOB, SHARPENED
- Restate the recurring job as a single, clear purpose
- Define the one output the project produces
- State what is in scope and, just as important, what is out of
scope, so the project stays focused
2. INSTRUCTION BLOCK (the heart of the project)
Write the actual instructions to paste, copy-ready, not advice
about writing them. Include:
- A role that sets the expertise and the voice
- The task, stated as one clear job
- The rules and constraints (tone, length, what to avoid)
- The exact output format the project should return every time
- A guardrail: it must answer from the attached knowledge, and
write "SIGNAL MISSING" rather than invent anything it cannot find
3. KNOWLEDGE & CONTEXT TO ATTACH
Specify exactly what to give it, and how:
- Which documents or files to upload as persistent knowledge
- Which knowledge vault to attach, if one fits
- Which CRM objects, records or lists to bring in as context
- For each item, say whether it is persistent (attached once) or
per-chat (mentioned when needed), and why
4. TOOLS
- Which tools to switch on (browse the web, write to the CRM)
- Which to deliberately leave off, and why. Enable only what the
job genuinely needs
5. ACCESS
- Who should be able to use the project
- Whether it writes to the CRM at all, and the governance that
implies
6. STARTER SAVED PROMPT
- One ready-to-run prompt to save inside the project, so the team
runs the job in a single click
Constraints:
- Write the instruction block as real, copy-ready text, not as tips
about how to write instructions
- Ground the project in attached knowledge and CRM context, never in
the model's general training. Recommend the specific documents and
data to give it
- Apply least privilege: enable only the tools and write-access the
job actually requires, and say plainly why each is needed
- Build in the gap-flagging guardrail. A project that invents facts
it runs hundreds of times is worse than no project
- If a detail you need to design the project well is not clear from
the context, state: "SIGNAL MISSING: [what needs checking manually]"
- Design for consistency across the team and reuse over months, not
for a single impressive run
Output format:
### I. PROJECT SUMMARY
{Name, a one-line purpose, who it is for, and a readiness verdict:
READY TO BUILD / NEEDS DECISIONS FIRST}
### II. INSTRUCTION BLOCK (paste this into the project)
{The copy-ready instructions, exactly as they should appear}
### III. KNOWLEDGE & CONTEXT TO ATTACH
| Item | Type (file / vault / CRM object / list) | Persistent or per-chat | Why |
### IV. TOOLS & ACCESS
| Setting | On or Off | Why |
### V. STARTER SAVED PROMPT
{The ready-to-run prompt for the team to use}
Why this prompt works, and how to adapt it
Most advice about Breeze projects tells you that they exist and that you should ground them in your data. Both true, and neither much use when you are staring at an empty project wondering what to type into it. The real gap is the how, and specifically the instruction layer, the few hundred words that decide whether your project behaves like a seasoned expert or a generic chatbot wearing your logo. This prompt closes that gap by writing those words for you, grounded in your actual context, so you leave with a project you can paste and use rather than a principle you nodded along to.
A few things to note about how it is constructed:
It writes the instructions, not advice about instructions. The whole point of the design is that it hands you the actual, copy-ready instruction block, the real text that goes into the project, rather than a lecture on the principles of good instructions. That is the difference between reading about project design and simply having a project. Everything else in the specification supports that one deliverable.
The instruction block is the whole ballgame. Every chat inside a project inherits its instructions, so a few hundred well-chosen words get reused hundreds of times, for better or worse. That is why the design spends most of its effort there, on the role, the task, the rules, the output format and the guardrail. Get that layer right and the project is reliable by default; get it vague and no amount of attached knowledge will save it.
It insists on real knowledge, not the model's memory. A project running on the model's general training is just a chatbot with extra steps. The design forces you to attach the specific documents, vaults and CRM context the job needs, because that grounding is the entire reason the output ends up being about your business rather than about businesses in general. This is the single biggest lever on quality, and the one most people skip.
Least privilege is a feature, not a limitation. A project that can write to your CRM is genuinely powerful, and genuinely worth governing, so the design recommends switching off any tool or write-access the job does not strictly need. A project that only reads is a safe thing to hand a whole team; one that can act on your records deserves the same scrutiny you would give any integration. Turning things off on purpose is good design, not caution for its own sake.
A starter saved prompt is what drives adoption. A well-built project that nobody knows how to invoke gets used twice and forgotten. Pairing it with a saved prompt means a teammate with no interest in prompting at all can open the project, click once, and get the expert output, which is the only version of “the team uses AI” that actually happens in practice.
“SIGNAL MISSING” matters more here than anywhere. The stakes are higher than in a normal prompt, because a project runs its brief over and over: a wrong assumption baked into it does not misfire once, it misfires every single time it runs. So where designing the project would mean guessing at your context, which documents you actually trust, which of your team's mistakes are the costly ones, the flag stops and asks rather than quietly building you a confident expert in the wrong subject.
Adapting it for your portal:
Building a content project? If the job is on-brand writing, add: “This project writes on-brand marketing content. Attach our brand voice, tone guide and product fact sheet, instruct it to treat those as the source of truth, and have it write SIGNAL MISSING rather than invent a product detail.” The specification will lean the whole design on your brand documents.
Building a sales-prep project? If it briefs reps for calls, add: “This project prepares account managers for calls. Design it to read the company and deal records I mention, summarise the relationship, and surface risks and next steps, and tell me exactly which CRM objects to give it access to.” The output will centre on CRM context rather than uploaded files.
Building a support or triage project? If it drafts replies, add: “This project drafts support responses. Ground it in our knowledge base and help documentation as a knowledge vault, instruct it to answer only from that material, and have it escalate anything it cannot find rather than guessing.” The design will make the knowledge vault the spine of the project.
Worried about it acting on your CRM? If write-access makes you nervous, add: “We want maximum caution. Recommend a read-only design wherever the job allows, list exactly which write actions, if any, are genuinely required, and tell me the human checkpoint before anything is written back.” The design will default to safety and justify every exception.
Rolling it out to a big team? If adoption is the goal, add: “This will be used by a large team of mixed confidence. Keep the instructions robust to vague questions, and give me three starter saved prompts covering the most common versions of the job, so nobody has to think about prompting.” You get a project designed for the least confident person who will open it.
Want a quarterly cadence? Save the output and re-run it 90 days later with: “Compare against the output from [DATE]. Based on how the team has actually used this project, tell me which instructions to tighten, which knowledge to add or retire, and whether the access model still fits.” That keeps the project sharp as the work around it changes.
Beyond the prompt:
The specification is the plan. Building the project from it takes about five minutes, and there is a sensible order to doing it well.
Start with the instruction block. Create the project from the folder icon in the Assistant sidebar, and paste the instructions in first. This is the brain of the thing, and it is worth reading twice before you go further, because every conversation the project ever holds will inherit it word for word.
Attach the knowledge before you invite anyone. Upload the documents and add the CRM context the design calls for. A project without its knowledge is just an instruction sheet, and it will answer from the model's general training rather than your business, which is precisely the generic output you were trying to leave behind.
Set the tools and access deliberately. Switch on only what the job needs, leave write-access off unless it is genuinely required, and decide who can open it. A project that can act on your CRM deserves the same care as any integration you would connect, so make those choices on purpose rather than by default.
Then test it, and hand it over with a saved prompt. Run it a few times yourself on real examples, tighten the instruction wherever it drifts, then save a starter prompt inside it and point the team at it. That saved prompt is the small thing that turns “we have a project” into “the team actually uses the project”.
The teams that get the most from AI this year will not be the ones with the single cleverest prompt-writer. They will be the ones who took their best thinking, wrote it down once, and handed it to everyone. A project is how you stop being brilliant in private and start being reliable in public.
