How to Write Claude Project Instructions for AI Marketing Reporting

Why Claude Project Instructions Matter

Project instructions are essentially a persistent prompt that applies across every chat inside a Claude Project. Combined with memory and your connected data, they give Claude the context it needs to understand what it's working with before you ask a reporting question.

This is where context engineering becomes especially important. You're not just writing a better prompt. You're defining the environment Claude will operate inside: its role, the business context, the data taxonomy, the metrics, the rules it should follow, and the type of output you expect.

Define Claude's Role, Expertise, and Business Context

I start by defining who the AI is inside the Project. What is its role? What expertise should it bring to the analysis? What should it focus on, and what should stay outside its lane?

I also give it business context: what the company sells, who the audience is, how the business operates, and what the reporting is ultimately trying to accomplish.

The more relevant context Claude has up front, the less time you spend re-explaining the same fundamentals in individual chats.

Encode Your Marketing Taxonomy and Naming Conventions

Every client and reporting environment has its own taxonomy. Campaign names, funnel stages, products, regions, motions, and other classifications often need to be interpreted according to business-specific rules.

For example, if campaigns need to be categorized into sales-led and product-led motions, I define the logic directly in the Project instructions. Claude can then apply that classification consistently whenever it analyzes the data.

Predefine the Data Flow Claude Should Use

Earlier in the setup, we used the command "list data flows" to find and select the appropriate dataset. Once the Project instructions are in place, you don't need to repeat that process every time.

I specify which data flow belongs to the Project directly in the instructions. Claude then knows which dataset to access whenever a reporting conversation starts.

Define Metric Logic and Reporting Rules

Metric definitions tell Claude what each field means and how it should be interpreted. This becomes especially important when a business uses custom definitions or when similar metrics need to be treated differently.

I also include rules around things like reporting windows, date logic, and other details that are easy for an LLM to interpret inconsistently. For example, you can explicitly define which day a reporting week starts or require Claude to ask for a lookback window rather than choosing one arbitrarily.

Client-specific nuances, outlier conditions, funnel behavior, and other business logic can also live here.

Add Guardrails to Reduce Hallucinations and Goal Drift

Claude is powerful, but without clear boundaries it can make assumptions, drift away from the original task, speculate about causation, or get stuck repeating an unproductive approach.

I use guardrails to define the behavior I want and prevent issues I've seen in practice. These instructions become more specific over time as you learn how the model behaves with a particular dataset or client.

Control Tone, Audience, and Output Formatting

Project instructions can also control how Claude communicates its analysis. I prefer reporting that is factual, straightforward, and concise rather than overly conversational or speculative.

I define who the output is for as well. Analysis I'm using personally may need a different level of detail than a report designed for an executive or client stakeholder.

You can also define how artifacts, bullets, charts, tables, and other reporting outputs should be structured so the presentation stays consistent.

Use Trigger Logic for Repeatable Reporting Workflows

Trigger logic gives you shortcuts for recurring workflows. For example, I can type "weekly performance report" and Claude knows which predefined reporting process or saved artifact I want to run.

As your artifact library becomes more developed, more of the recurring report logic can live inside those saved artifacts while the Project instructions provide the broader context and rules they operate within.

Manage and Version Your Claude Project Instructions

I currently manage my Project instructions in Obsidian using Markdown. That gives me a simple way to maintain versions as the prompt evolves and then copy the latest version back into Claude.

The specific tool matters less than having a versioned source you can update safely. As the instructions become more valuable to the workflow, you don't want to lose track of what changed or overwrite a version that was working well.

Start with a Baseline, Not a Perfect Prompt

The goal isn't to create perfect Project instructions before you ever interact with the data. The goal is to create a strong baseline that gives Claude the correct data source, business context, taxonomy, metrics, and operating rules so you can start working.

In my experience, the first couple of weeks usually surface a few things that need to be refined. After those adjustments, the instructions tend to stabilize and require much less maintenance.

Later in the workflow, meta prompting gives you a structured way to use those real-world interactions to keep improving the instructions instead of trying to anticipate every edge case up front.