How to Build a Reusable Project Brief for Claude

The quality of a recurring Claude workflow depends less on a clever opening prompt than on a stable, well-maintained project brief. The brief defines what the work is for, what evidence is authoritative, which constraints cannot be negotiated, and what a finished deliverable looks like.

A good brief is not a document dump. It is a compact operating agreement between the human team and the model.

The Core Brief

Use the following structure as a starting point:

PROJECT
Name:
Owner:
Business outcome:
Current phase:

AUDIENCE
Primary reader or user:
What they already know:
What decision or action should follow:

SCOPE
Included:
Excluded:
Dependencies:
Deadline and milestones:

SOURCE POLICY
Authoritative sources:
Allowed secondary sources:
Freshness requirement:
Sources that must not be used:

DELIVERABLE
Format and approximate length:
Required sections:
Tone and terminology:
Examples to follow:

QUALITY BAR
Facts that require citations:
Checks or tests to run:
Reviewers and approval owner:
Definition of done:

CONSTRAINTS
Privacy and confidentiality:
Legal or brand requirements:
Technical limitations:
Known risks and unresolved questions:

Fill the fields with observable requirements. “Make it engaging” is difficult to test. “Open with the user's operational problem, avoid promotional adjectives, and keep paragraphs under 120 words” is easier to evaluate.

Distinguish Durable Context From Task Context

Durable context changes infrequently: audience definitions, brand terminology, architecture decisions, source policy, and approval rules. Task context changes with each deliverable: the current question, new source files, deadline, and requested format.

Keep these layers separate. If temporary instructions are copied into the permanent brief, the project accumulates contradictions. If durable policies must be repeated in every prompt, reviewers will eventually omit one.

At the start of a task, use a short invocation:

Use the project brief as the governing context.
Task: Draft the launch risk assessment for Release 2.4.
New evidence: incident-summary.pdf and rollout-metrics.csv.
Deliverable: one-page decision memo plus a risk table.
Before drafting, list any conflict between the new evidence and the brief.

Design an Evidence Hierarchy

When project files disagree, Claude needs a precedence rule. Define one explicitly, such as:

1. approved policy and signed decisions;
2. current product or technical specifications;
3. measured data with a documented collection method;
4. working drafts and meeting notes;
5. external commentary.

Require the model to flag conflicts rather than silently choosing the more convenient source. Add owners and dates to important documents. A file named final-v7-new.pdf is not a reliable governance system.

Include Good and Bad Examples

One approved example can communicate structure and tone more precisely than a page of adjectives. Annotate why the example is good: clear recommendation, source-linked claims, direct language, or a specific level of detail. If recurring mistakes are costly, include a short negative example and explain the defect.

Do not ask Claude to imitate a living writer or reproduce copyrighted text. Define the observable qualities the project needs instead.

Add Acceptance Tests

For analytical work, acceptance tests might require every number to include a source and period, totals to reconcile, and assumptions to appear in a separate table. For software documentation, require commands to be tested, version prerequisites to be stated, and links to resolve. For marketing copy, require approved product names, evidence for comparative claims, and a legal review flag for regulated statements.

Ask Claude to return a preflight checklist before drafting and a self-review after drafting. The self-review is not final quality assurance, but it catches missing sections and obvious instruction conflicts.

Keep the Brief Small and Current

Review the brief on a regular cadence. Remove obsolete requirements, archive superseded examples, and record material changes in a brief change log. When an instruction changes, identify which active deliverables need to be revised.

A useful maintenance rule is that every permanent paragraph must answer one of four questions: What outcome matters? What evidence is trusted? What constraints apply? How will the result be accepted? Background material that answers none of these belongs in a linked reference, not the core brief.

Example: Editorial Research Project

An editorial team's outcome might be “publish practical AI guides that a professional can reproduce.” Its source policy could require first-party documentation for product features, direct links for current claims, and explicit labeling of inference. The deliverable standard might specify an audience, tested workflow, limitations section, and final verification checklist. The approval owner remains the editor, even when Claude produces the first draft.

Governance Still Belongs to People

The project owner decides which instructions are authoritative, who can access source material, and when a deliverable is ready. Claude can point out ambiguity, but it cannot resolve organizational ownership on its own. Record consequential decisions outside the chat so they survive personnel, tool, and model changes.

A strong project brief reduces repeated explanation while making the work more auditable. Its purpose is not to maximize context. Its purpose is to supply the smallest body of reliable context needed for consistently good decisions.