| name | build-client-brief |
| description | Turn accepted consulting or agency work into one reliable engagement brief covering scope, stakeholders, milestones, evidence standards, communication, systems, risks, and client-data restrictions. Use after a proposal, statement of work, or internal mandate has been accepted and delivery needs a clear starting point. |
Start a Client Engagement
Start delivery from what was actually accepted. Create one practical brief that the people doing the
work can trust, without reopening the proposal or copying another client's setup.
1. Confirm the engagement
Identify the client or internal stakeholder, accepted piece of work, delivery team, current phase,
and intended home for the brief. Confirm that the work has been accepted. If the user is still
defining the commercial offer, use strawberry/consulting/create-a-client-proposal first.
Follow an existing kickoff or engagement method when the user has one. Establish who should be able
to see the brief and whether it is an internal working document or something the client will also
receive.
2. Assemble the accepted context
Use the approved proposal, statement of work, RFP response, kickoff material, discovery records,
email threads, meeting notes, delivery plans, and relevant files already available in Strawberry.
Work across visible tabs, logged-in sites, files, meetings, and connected apps when they materially
improve the brief. Keep important sources easy to inspect.
Keep every client's facts, files, commercial terms, access, learned context, and artifacts separate.
Do not import another client's delivery assumptions, examples, or restrictions. Ask only about gaps
or conflicts that could change the work.
3. Build the working brief
Capture the information the team needs to deliver:
- the business context, decision, intended outcomes, scope, deliverables, and exclusions;
- stakeholders, decision owners, reviewers, responsibilities, and client dependencies;
- milestones, timing, acceptance points, and known resourcing constraints;
- evidence standards, definitions, approved sources, and how claims or calculations will be checked;
- communication cadence, meeting rhythm, status format, and escalation path;
- systems, files, source locations, access boundaries, and the intended home for new work;
- client-data, confidentiality, legal, privacy, brand, and retention restrictions;
- assumptions, open questions, risks, and changes that would require the scope to be revisited.
Distinguish accepted facts from working interpretations and unresolved questions. Link decisions to
their sources when the team may need to verify them later.
4. Resolve the important gaps
Compare the sources and surface contradictions, unclear ownership, missing access, unsupported
success measures, or delivery expectations that do not match the accepted scope. Recommend an
answer when the record supports one, and identify the person who must decide when it does not.
Do not invent acceptance criteria, client permissions, authority, dates, outcomes, or system access.
Do not quietly turn a kickoff decision into a commercial commitment.
5. Review the handoff
Present a concise brief and a short list of unresolved decisions. Check it with the people who own
delivery before using it as the basis for research, meetings, artifacts, status updates, or system
changes.
Approval of the brief confirms the working context only. Client delivery, sharing, task assignment,
CRM or project changes, sending, publishing, and legal acceptance remain separate actions. Establish
the audience, access model, and destination before recommending any sharing path.
6. Put the brief to work
Use the accepted brief to route the engagement without duplicating specialist workflows:
strawberry/research-analysis/map-a-market for landscapes and categories;strawberry/research-analysis/extract-web-data for repeated structured research at scale;strawberry/consulting/turn-client-research-into-recommendations when evidence needs to become a
client decision;strawberry/operations/prepare-for-meetings and
strawberry/operations/debrief-a-meeting for the general meeting loop;strawberry/operations/prepare-a-status-update for source-backed engagement updates.
Update the brief when accepted scope, owners, access, evidence standards, or restrictions change.
Do not record proposed changes as agreed facts.
7. Preserve the reusable method
After the engagement setup works, offer to save the accepted structure, source checklist, evidence
standards, communication choices, and review behavior as a custom skill. A boutique team can share
that sanitized method after client-specific facts and access are removed and the audience and
destination are agreed.
Engagement setup is normally event-driven, so do not create a Routine by default. A draft-first
Routine may refresh the brief or prepare a status view only when the sources, owner, cadence,
destination, approval behavior, and stop conditions are stable.
Suggested outcome
Create one concise, source-linked engagement brief that gives the delivery team a trustworthy view
of the accepted work, its boundaries, the evidence expected, and the decisions still open.
