Use Claude Projects to Prepare a Client Kickoff Brief from Approved Notes

A client kickoff brief should make the first meeting easier. It should not quietly turn a rough note into a promise.

This guide uses a Claude Project to organize approved notes into a kickoff brief, an agenda, and an open-questions list. The input and output are fictional. The workflow is documentation-based and illustrative, not a recorded Claude run or a personal test by Cihan.

What you need

A Claude account with Projects available. Anthropic says Projects are self-contained workspaces with chat histories and knowledge bases. You can add documents and project instructions.
Three approved or fictional source files.
A person who owns the client relationship and can approve scope, dates, and commitments.

Read What are projects? from Anthropic before following interface labels. Claude is changing the Projects experience in stages, so your screen may differ.

1. Prepare the complete fictional input

Create these files:

client-notes.md

Client: Northstar Bikes
Project: Customer support knowledge base refresh
Known goal: reduce repeated questions in the support inbox
Known materials: current help articles, five anonymized support questions
Requested first meeting: review the current article set and agree on a short pilot
Missing: pilot date, final approver, success measure, and list of systems in scope

constraints.md

Do not promise a launch date.
Do not change support content during discovery.
Customer data must stay anonymized.
The client will decide which systems are in scope.

questions.md

What does the client want to approve in the first meeting?
Who can approve the pilot scope?
Which support questions are safe to use as examples?
What evidence would show that the pilot is useful?

The missing details are intentional. Keep them missing until the owner answers them.

2. Create the Project and add the files

In Claude, open Projects and create a project called Northstar kickoff practice. Add the three files to the project’s knowledge area. Then add these project instructions:

Use only the files in this project as source material.
Never invent a client commitment, owner, date, system, metric, or approval.
Mark missing details as OPEN QUESTION.
Keep constraints separate from goals.
For every statement in the kickoff brief, show the source file and section.
Do not send messages, edit files, or change the project plan.

If your account shows a different Projects layout, use the current Anthropic help page for the matching action. Do not assume that a button exists because another account has it.

3. Request the kickoff pack

Start a chat inside the Project and paste this prompt:

Create a reviewable client kickoff pack from the project files.

Return four sections:
1. A short project summary with only supported facts.
2. A 45-minute meeting agenda with a purpose for each item.
3. A decision and open-questions table with question, why it matters,
   suggested owner role, and status.
4. A source map for every summary statement and proposed agenda item.

Rules:
- Do not invent a date, deadline, approver, system, success metric,
  deliverable, or client commitment.
- Keep the pilot as a proposed topic, not an approved plan.
- Keep all customer examples anonymized.
- Label any recommendation as RECOMMENDATION, not FACT.
- If the files disagree or are silent, write CONFLICT or OPEN QUESTION.
- Do not send or publish anything.

4. Apply the acceptance check

The pack passes this review when:

The summary names Northstar Bikes, the knowledge base refresh, and the support-inbox goal without adding a result.
The agenda includes review of the current articles and a pilot discussion.
Pilot date, final approver, success measure, and systems in scope remain open questions.
Every factual statement points to one of the three files.
Recommendations are visibly different from facts.
No customer identity or raw customer data appears.

An illustrative row might look like this:

Question	Why it matters	Suggested owner role	Status
Who approves the pilot scope?	The meeting cannot close scope without a decision owner.	Client project owner	OPEN QUESTION

That row is a planning aid. It is not evidence that the client has chosen an owner.

5. Prepare the human handoff

Ask Claude for a final one-page handoff that contains only unresolved questions and the source line behind each one. Review it against the files before sharing it with the client team.

Keep the source files beside the brief. When a note changes, update the source first and regenerate the draft. Otherwise, an old brief can quietly become the team’s unofficial memory.

Troubleshooting

Claude adds a date or named person: repeat the rule that missing details must stay OPEN QUESTION, then compare every new detail with the source map.
The project ignores one file: confirm that the file appears in the project knowledge area and ask Claude to identify the file it used for one specific statement.
A recommendation looks like an approved decision: require separate FACT, RECOMMENDATION, and OPEN QUESTION labels.
The output is too broad: limit the brief to the three files and the requested first meeting. Do not add general client strategy.

TRY / SKIP / USE: TRY this with fictional or approved notes. SKIP confidential client data until your organisation approves the tool and handling rules. USE the brief only after the relationship owner checks the source map and open questions.

Sources and next step

The result is a reviewable draft, not a client commitment.