PPassTheCertExam

Study guides / CCAO-F / Domain 5

Configuration and Knowledge Management · Lesson 3 of 4

5.3 — Writing Effective Project-Level Instructions

Write Project-level instructions as standing, reusable infrastructure that has to hold up across many future conversations and multiple teammates, not as a one-off prompt for a single task.

A one-off conversational system prompt (see lesson 1.1) only has to work for one conversation, usually for one person, often for one task. A Project's custom instructions are different in kind: they need to hold up across every future conversation anyone on the team starts inside that Project, for tasks that haven't been written yet by people who may never have seen how the Project was originally set up. That's a materially higher bar, and instructions that would be perfectly reasonable as a single conversation's system prompt can be a poor fit as standing Project instructions.

The practical test for Project instructions isn't "does this produce a good result for the task I have right now" — it's "will this still make sense for the next five different requests a teammate sends into this Project next month." Instructions written to the first question tend to bake in details specific to today's task; instructions written to the second stay general enough to keep working as real usage varies.

What Belongs in a Standing Instruction Set

Good Project instructions typically cover a small number of durable things: a role (who Claude is acting as for this Project), a scope (what kinds of requests this Project is for, and what it isn't for), guidance on which knowledge sources to prioritize when the Project has more than one uploaded document or connector (e.g. "treat the uploaded style guide as authoritative over any older guidance a teammate pastes into a message"), and house style or format defaults that should apply by default unless a specific message says otherwise. None of these require knowing what any particular future conversation will ask for — that's exactly what makes them suitable for the Project level instead of a single message.

The Narrow-Instructions Trap

The most common mistake in Project instructions is writing them around the first real task rather than the Project's general purpose. A marketing team setting up a "Newsletter Drafts" Project might write instructions like "Use the Q3 product launch data to draft this month's customer newsletter" — which works perfectly for that one newsletter, and then quietly breaks the moment someone opens the Project next month to draft a completely different newsletter, or asks it to draft social copy instead. The instructions were really a task prompt wearing a Project's clothing. The fix is to separate what's genuinely constant (the role: "you're drafting customer-facing newsletter copy for [Brand]"; the style: "friendly, concise, one clear call to action") from what's specific to one request ("using the Q3 launch data") and leave the task-specific part out of the standing instructions entirely, to be supplied fresh in each conversation's message instead.

Key Concept

Project-level instructions are reusable infrastructure: they should state a role, a scope, which knowledge sources take priority, and format/style defaults — all things that hold true across many different future conversations and multiple teammates. Anything specific to one task belongs in that conversation's message, not in the standing instructions.

Common Exam Distractor

Watch for Project instructions that read like a great one-off prompt for today's specific task — naming a particular dataset, a particular deadline, or a particular one-time request. That specificity is exactly what makes instructions break on the next, slightly different request. The correct fix is generalizing the instructions, not writing an even more detailed version of the same task-specific wording.

Exam traps

Practice question

A marketing team's 'Newsletter Drafts' Project has custom instructions that say: 'Use the Q3 product launch data to draft this month's customer newsletter in a friendly tone with one clear call to action.' The next month, a teammate opens the same Project to draft a completely different newsletter and the instructions no longer fit. What's the best fix?

  • A Rewrite the instructions each month to reference that month's specific data and topic

    This treats the underlying problem — task-specific detail baked into standing instructions — as something to repeat rather than fix, and still requires editing the Project every time a new request comes in.

  • B Separate the durable parts (role: drafting customer-facing newsletter copy for the brand; style: friendly tone, one clear call to action) from the task-specific part (the Q3 launch data), keep only the durable parts in the Project instructions, and supply the specific data fresh in each conversation's message Correct

    This is the correct fix for the narrow-instructions trap: standing instructions should hold a role and style defaults that apply broadly, while task-specific detail belongs in the individual conversation, not baked into the Project's configuration.

  • C Add a sentence to the instructions describing several more possible newsletter topics in addition to the Q3 launch

    Listing more specific topics still leaves the instructions tied to particular tasks rather than generalizing to the Project's actual ongoing purpose; the next unlisted topic will hit the same problem.

  • D Leave the instructions as-is, since the teammate can simply ignore the parts that don't apply

    Leaving mismatched, task-specific instructions in place creates confusion and inconsistent results rather than solving the underlying configuration problem.

Build exercise: Generalize a Task-Specific Instruction Set

Intermediate · 25 minutes

You'll practice:

  1. In claude.ai, create a new Project and write intentionally narrow instructions modeled on one specific task — for example, 'Summarize this week's support ticket data and draft a customer email about the shipping delay.' Send a message requesting something related but genuinely different (e.g. 'draft a customer email about a pricing change instead') and observe the result.

    This reproduces the narrow-instructions trap directly: instructions written around one task tend to produce an odd or mismatched result on a different, but related, request.

    You should see: A response that seems confused about topic, tries to force in the shipping-delay framing where it doesn't belong, or otherwise shows the instructions don't generalize.

    Hints 
    1. Make the first instruction genuinely specific — a real dataset name, a real one-time scenario — not already generic.
    2. Pick a second request that's clearly a different topic but the same general kind of task (still a customer email).
    3. Note specifically which part of the response feels mismatched to the new request.

  2. Rewrite the Project instructions to separate the durable parts (role: 'you draft customer-facing emails for [Company]'; style: 'clear, empathetic, one specific next step for the customer') from the task-specific part, and remove the task-specific part from the instructions entirely.

    This is the actual fix: standing instructions should hold what's constant, not what's specific to the task that happened to be top of mind when the Project was created.

    You should see: Instructions that no longer mention a specific dataset, product, or one-time scenario at all — only role and style.

    Hints 
    1. If you can't remove a detail without the instructions feeling incomplete, that detail probably needs to be supplied in the message instead, not deleted outright.
    2. Keep the rewritten instructions to two or three sentences — durable guidance doesn't need to be long.
    3. Read the new instructions and ask yourself whether they'd still make sense to a teammate who's never seen the Project before.

  3. Resend both the original shipping-delay request and the pricing-change request as two separate messages, each supplying its own specific detail directly in the message, and compare both responses against the mismatched one from step 1.

    This confirms the generalized instructions now hold up across genuinely different requests, which is the actual bar Project instructions need to meet.

    You should see: Two responses that both follow the same consistent role and style, each correctly grounded in the specific detail supplied in its own message, with neither one bleeding into the other's topic.

    Hints 
    1. Supply the specific detail (the dataset, the price change) directly in each message, not by editing the Project instructions again.
    2. If either response still feels off-topic or mismatched, check whether a task-specific detail is still hiding in the instructions.
    3. This is the pattern a real team would reuse indefinitely — one stable instruction set, many different messages.

Sources