Set up a Claude Project that stays accurate for months, not just this chat

PROJECT KNOWLEDGE SETUP — Q3 Product Launch — Northwind App

This produces two separate deliverables: a knowledge document to upload into this Project's knowledge panel, and a custom-instructions block to paste into the Project's settings. Claude Projects treats these as different mechanisms — knowledge is retrieved content Claude searches over per chat, custom instructions are standing behavioral rules applied to every chat regardless of what gets retrieved — so do not merge them into one file.

PROJECT SCOPE
Coordinating copy, positioning, and internal FAQs for the Northwind app launch on October 14. Done means every asset matches the same three positioning pillars.

AUDIENCE
Marketing team drafting external copy, and support leads writing internal FAQs for the same launch.

KNOWLEDGE DOCUMENT — split into these sections, in order:
1. STANDING FACTS. Only include a fact here if it would still be true in three months. Launch date is October 14, fixed. Product is called "Northwind," never "Northwind App" in customer-facing copy. Pricing is not final and must never appear as a number in any draft. If a fact could plausibly change (a price, a headcount, a deadline), mark it with the date it was last confirmed true, not just the fact itself.
2. TERMINOLOGY. "NW" always means Northwind internally, never spelled out in Slack drafts. Customers are called "members," never "users" — flag any draft that slips into "users." Include the wrong term as explicitly forbidden, not just the right one — a project that only lists the preferred word leaves Claude free to default to a synonym nobody flagged as wrong.
3. WHAT THIS PROJECT IS NOT FOR. State the boundary explicitly — the adjacent topic or request type that should be redirected elsewhere, so a chat that drifts off-scope gets caught rather than confidently answered anyway.

CUSTOM INSTRUCTIONS — separate block, to paste into Project settings, not the knowledge document:
- Default output register: Plain, confident, no exclamation points, short paragraphs over bullet walls.
- Treat the knowledge document as ground truth unless a chat message explicitly says something has changed. When a chat message contradicts a standing fact, say so out loud — name the contradiction and ask which one is current — rather than silently trusting whichever one came later in the conversation.
- Never state a fact from the knowledge document with more confidence than its own staleness marker supports. A fact marked as confirmed two months ago should be flagged as "as of [date], may have changed" when it materially affects the answer, not restated as settled.
- At the end of any chat where a new fact worth keeping came up, name the exact sentence to add to the knowledge document and where it goes, so the correction survives past this one conversation instead of being re-discovered in the next chat that hits the same gap.

STALENESS CHECK
Every two weeks, until launch; monthly after., review the standing facts section against current reality and update the confirmed-true dates, removing or correcting anything that has quietly stopped being accurate.

OUTPUT
Produce the knowledge document first, in full, followed by a clear separator, then the custom instructions block, in full — both ready to paste into their respective places with no further editing.