Use Claude to Turn a Launch Brief into a Readiness Checklist

A launch brief often contains enough information to start a conversation but not enough to run a launch. A checklist can expose the gaps before they become last-minute surprises.

This is a worked Claude prompt using a fictional brief and an illustrative result. It is not a recorded Claude run, and it does not claim a launch outcome.

What you will create

You will create a readiness checklist with an evidence field, an owner field, a due date field, and a clear status. Unknown values remain unknown. The checklist is for review, not approval to launch.

Claude Projects let you create a focused workspace with its own chats, knowledge, and project instructions. Claude’s current help also notes that project features and availability can vary as newer versions roll out. This lesson works in a regular Claude chat too, as long as you use only the supplied brief.

Add the fictional brief

Save this as northstar-launch-brief.txt:

Project: Northstar supplier portal pilot
Launch goal: invite five approved suppliers to a two-week pilot.
Target window: the second half of November 2026.
In scope: supplier status page, invitation email, support contact, and pilot feedback form.
Out of scope: changing the order database and changing supplier payment terms.
Known dependency: Operations must confirm which order statuses suppliers may see.
Known risk: the support inbox has no agreed response owner for pilot questions.
Approved facts: Mina owns the project brief. The pilot is not approved to launch yet.
Open items: pilot suppliers, exact launch date, email approver, support owner, feedback questions, and exit criteria.

The file is fictional. Do not add real supplier information or internal credentials.

Build the checklist

1. Open Claude and create a project named Northstar pilot review, or start a new chat if Projects is unavailable to your account.
2. Add the brief as project knowledge or attach it to the chat. Use only this file as the source.
3. Add these project instructions, or paste them before the task:

Use only the supplied launch brief.
Separate confirmed facts, dependencies, risks, and open items.
Never invent an owner, date, supplier, approval, metric, or policy.
Use "unassigned" when the brief names no owner and "not set" when it names no date or measure.
Keep "not approved to launch" as the project status.

4. Paste the task below:

Create a launch readiness checklist from the supplied brief.

Return:
1. A five-line summary of the confirmed scope.
2. A Markdown table with these columns:
   item, evidence from brief, owner, due date, status, approval needed.
3. A separate list of launch blockers.
4. A separate list of questions for the next review.

Use one row per concrete check. Keep the original wording for important constraints.
Mark an item "unknown" when the brief does not provide enough evidence.
Do not recommend launching, assign a person from a job title, or turn a target window into an exact date.

Illustrative result

A sound checklist should include a row for the allowed order statuses, with Operations as the named dependency owner only if the brief explicitly names that owner. It should mark the support owner, email approver, pilot suppliers, exact date, feedback questions, and exit criteria as unknown or unassigned. It should keep the launch status as not approved.

That example tells you what to inspect. It is not a Claude output, benchmark, or launch recommendation.

Acceptance checks

1. The checklist contains the out-of-scope database and payment-term changes as exclusions, not tasks.
2. No exact November launch date appears because the brief supplies only a target window.
3. The support owner and email approver are not invented.
4. Every checklist row points to a phrase in the brief or is marked unknown.
5. The open items remain visible in the review questions.
6. The final status says the pilot is not approved to launch.

Troubleshooting

• Claude fills an empty owner field: repeat the instruction to use unassigned, then compare the row with the source sentence.
• The target window becomes a date: ask Claude to quote the exact source phrase and replace the date with not set.
• Out-of-scope work appears as launch work: add an exclusions section and check it against the brief before sharing the checklist.

TRY / SKIP / USE: TRY this on a short approved brief where a reviewer can check every row. SKIP using the checklist as a launch approval or as a substitute for the responsible owner’s decision. USE it to prepare a focused review meeting.

Sources and next step

• Claude Help: What are projects?
• Claude Help: Get started with Claude Cowork
• Use Claude to turn a process change into a reviewable staff announcement
• Get The Weekly Verdict

Keep the brief and the checklist together. If the source changes, regenerate or review the affected rows instead of silently carrying old assumptions forward.