Implement Prompt Reuse Strategies: Caching, Modular Prompts & Skills

CCAR-P Exam Guide — Domain 2: Claude Models, Prompting & Context Engineering

Exam: Claude Certified Architect – Professional Exam Code: CCAR-P Domain 2 Weight: 13%

---

1 What You Need to Know for the Exam

For this objective, think of prompt reuse as three different problems with three different solutions:

Reuse mechanism	Main problem it solves	Think
Prompt caching	Repeated processing of the same large prompt prefix	Performance reuse
Modular prompts/templates	Duplicate, inconsistent prompt logic across applications	Design/code reuse
Skills	Repeated domain procedures/instructions that should be available when needed	Capability/procedure reuse

This distinction is probably the most important concept to remember.

Caching saves repeated computation. Modular prompts save repeated authoring and maintenance. Skills save repeated procedural instruction and context loading.

These techniques can also be used together. They are not mutually exclusive.

---

2 Prompt Caching

2.1 What Prompt Caching Actually Does

Prompt caching allows Claude to reuse a previously processed prompt prefix rather than reprocessing the same large prefix on every request.

Anthropic’s current documentation describes it as caching prompt prefixes so repetitive requests with consistent material can reduce both processing time and input cost.

Consider:

Request 1

[System instructions - 3,000 tokens]
[Company policy - 12,000 tokens]
[Product documentation - 15,000 tokens]
[User question A - 30 tokens]

Then:

Request 2

[Same system instructions]
[Same company policy]
[Same product documentation]
[User question B - 35 tokens]

Without caching, Claude repeatedly processes the entire large input.

With caching:

CACHEABLE STABLE PREFIX
├── System instructions
├── Company policy
└── Product documentation

DYNAMIC CONTENT
└── User question

The stable prefix can be reused.

Exam signal

If the scenario says:

• same
• static
• large
• repeated
• every request
• while cost and latency are concerns

think:

Put static content first → dynamic content later → cache the reusable prefix.

That wording appears almost directly in the official sample item.

---

3 Stable Prefix Is the Key Architectural Concept

Claude’s prompt cache operates over the request prefix in this order:

Tools
  ↓
System
  ↓
Messages

up to the relevant cache breakpoint.

Therefore a well-designed request usually looks conceptually like:

MOST STABLE
│
├── Tool definitions
├── System instructions
├── Policies / reference documents
├── Stable examples
│
├── Cached prefix boundary
│
├── Conversation-specific information
└── Current user request
│
MOST DYNAMIC

The architectural rule is:

Stable before dynamic.

Why?

Because changing something before the cache boundary can invalidate reuse of everything after that point.

---

4 Cache Hits Require Stability

A very exam-relevant detail is that caching is sensitive to changes in the cached prefix. Anthropic states that cache hits require the relevant prompt segments to match exactly. Reordering content, changing an earlier part of the request, or inserting varying data such as timestamps in the stable portion can destroy cache effectiveness.

Poor design

System prompt:
"You are our support assistant.
Current timestamp: 2026-08-17 13:30:42
Follow the company policy below..."

[15,000-token static policy]

Every request changes the timestamp.

Result:

Dynamic timestamp
       ↓
Cache prefix changes
       ↓
Poor cache reuse

Better design

SYSTEM
    Stable instructions
    Stable policies
    Stable examples
          ↓
      CACHE PREFIX

USER / DYNAMIC CONTEXT
    Current timestamp
    Customer details
    Current question

---

5 Prompt Caching Is NOT Response Caching

This is an excellent potential exam trap.

Prompt caching does not mean:

“Claude remembers the previous answer and returns it again.”

It means:

“Claude avoids unnecessarily reprocessing an identical input prefix.”

Anthropic explicitly notes that prompt caching does not change output token generation; Claude still generates the response normally.

Compare

Response cache

Question → lookup previous answer → return same result

Prompt cache

Cached prompt prefix
        +
new user request
        ↓
Claude still generates a new response

---

6 When Prompt Caching Is a Strong Fit

Anthropic currently highlights use cases including repetitive instructions, many examples, large context/background information, extended conversations, and agentic workloads involving repeated model calls.

For CCAR-P, recognize these patterns:

Scenario A — Large policy document

System prompt          2K
Compliance policy     20K
User question         100

Repeated thousands of times.

Answer: caching.

Scenario B — Few-shot classifier

Instructions
+ 25 high-quality examples
+ one new ticket

Examples remain constant.

Answer: caching can materially improve reuse economics.

Scenario C — Agent loop

System + tools + accumulated history
          ↓
Claude
          ↓
Tool
          ↓
Claude
          ↓
Tool
          ↓
Claude

Many repeated API calls reuse large portions of earlier context.

Caching may be valuable.

---

7 When Caching Is NOT the Answer

Caching does not fix every token problem.

Problem: document changes every request

Request A → completely different 30K document
Request B → completely different 30K document

There may be little reusable prefix.

Caching is therefore not the main architectural solution.

Problem: corpus contains millions of documents

Don’t put the whole corpus into a cache.

Use:

Query
 ↓
Retrieval
 ↓
Relevant chunks
 ↓
Claude

That is primarily a RAG problem, not a caching problem.

Problem: recurring instructions are duplicated throughout source code

Caching may lower runtime cost but does nothing to improve maintainability.

Use modular prompts.

Problem: users repeatedly need an entire specialized procedure

A Skill may be the better abstraction.

---

8 Prompt Caching TTL — Know the Concept, Not Just Numbers

Anthropic currently supports standard short-lived caching and an extended cache duration; current documentation describes 5-minute and 1-hour options.

For CCAR-P, however, the more important architectural question is:

Will the same stable prefix be reused often enough while the cache remains useful?

Example:

High reuse

5,000 support questions/hour
same policy prompt

Excellent caching opportunity.

Low reuse

One compliance analysis every two days
same policy

Caching may provide far less benefit.

Don’t blindly select caching just because content is static.

---

9 Modular Prompts

Caching addresses runtime reuse.

Modular prompts address maintainability and consistency.

Instead of building one enormous prompt:

PROMPT =
persona
+ security instructions
+ writing style
+ product rules
+ business rules
+ task instructions
+ output format
+ user question

separate reusable concerns.

Prompt Assembly
│
├── Core system behavior
├── Organization policy module
├── Domain module
├── Task template
├── Output schema
├── Few-shot examples
└── Dynamic request

Think of it as applying ordinary software engineering principles to prompts:

• separation of concerns
• reuse
• composition
• versioning
• testing
• controlled change

The CCAR-P guide positions candidates as experienced architects with a foundation in modular system design, so expect this topic to be tested architecturally rather than as mere text templating.

---

10 Monolithic vs Modular Prompt Design

Monolithic

customer-support-prompt.txt

"You are...
Never...
Always...
The company's refund policy...
Our security rules...
Our email style...
When handling shipping...
When handling refund...
When dealing with fraud...
Examples...
Examples...
Examples..."

Now suppose three applications need the company’s tone rules.

Teams copy/paste the prompt.

Soon:

Application A → Brand rule v4
Application B → Brand rule v3
Application C → Brand rule v2 + local edits

You have prompt drift.

Modular

/shared
    brand-guidelines.md
    security-guidelines.md
    escalation-policy.md

/tasks
    refund-review.md
    order-status.md
    complaint-response.md

/examples
    refund-examples.md

At runtime:

Core prompt
    +
Brand module
    +
Relevant task module
    +
Relevant examples
    +
Dynamic request

Benefits:

• consistent behavior
• easier review
• easier testing
• less duplication
• independent updates
• clearer ownership
• reusable components

---

11 Parameterized Prompt Templates

Another useful reuse pattern is parameterization.

Instead of:

Review invoice 10231 for ACME.
Review invoice 10232 for Globex.
Review invoice 10233 for Contoso.

create a reusable template:

Review invoice {{invoice_id}}.

Customer:
{{customer}}

Invoice:
{{invoice_data}}

Policy:
{{applicable_policy}}

Return:
{{output_schema}}

Separate:

STATIC BEHAVIOR
      +
DYNAMIC VARIABLES

This is useful both for maintainability and caching because a carefully designed prompt can keep the stable components toward the beginning.

---

12 Version Prompts Like Code

The practitioner workbook makes an important architectural point:

prompt changes are behavior changes.

It recommends versioning prompts alongside the code that uses them, testing them against evaluation sets before deployment, keeping prompts/schemas/evaluations aligned, centralizing shared prompts, and considering cache-prefix stability when modifying shared content.

A mature architecture might therefore track:

customer-summary/
├── system-v7.md
├── summary-template-v4.md
├── output-schema-v3.json
└── eval-set-v6.json

A change from:

prompt v6 → prompt v7

should trigger:

Eval
 ↓
Comparison
 ↓
Controlled deployment
 ↓
Monitoring

not simply:

Edit prompt
 ↓
Production

---

13 What Are Claude Skills?

This is likely to be one of the more important CCAR-P distinctions.

Anthropic describes Agent Skills as modular capabilities containing instructions, metadata and optionally resources such as scripts and templates. They provide reusable domain-specific workflows and knowledge, and Claude can load them when they become relevant.

Conceptually:

Skill
├── Metadata
├── Instructions
├── Workflow guidance
├── Templates
├── Reference material
└── Optional scripts/resources

Instead of placing all specialist instructions into every conversation:

GLOBAL PROMPT
+ Excel instructions
+ PDF instructions
+ Proposal instructions
+ Financial modeling rules
+ API conventions
+ ...

Claude can discover the relevant capability:

User asks for financial model
          ↓
Relevant Skill identified
          ↓
Skill instructions loaded
          ↓
Task executed

---

14 Skills and Progressive Disclosure

This is an important architectural advantage.

Anthropic documents a staged loading model for Skills:

Level 1
Metadata
always lightweight / available for discovery

      ↓ if relevant

Level 2
SKILL.md instructions

      ↓ if needed

Additional files/resources

Only lightweight metadata must initially be present; detailed Skill content is loaded as required. This is an example of progressive disclosure, reducing the need to place every specialized instruction into context upfront.

Why architects should care

Imagine 40 specialized procedures, each 2,000 tokens.

Naive approach:

40 × 2,000 = 80,000 tokens

loaded into every request.

But a request may need only:

Expense Report Skill

A Skill-oriented design can avoid blindly injecting all specialized instructions.

This connects directly with another CCAR-P theme:

Context is a managed budget.

---

15 Skill Example

Suppose an organization repeatedly creates architecture decision records.

Instead of prompting every time:

Use our ADR format.
Sections:
Context
Decision
Alternatives
Consequences
Revisit When

Use concise architectural language.
Explain NFR implications...

package the procedure as:

architecture-decision-record/
│
├── SKILL.md
├── ADR-template.md
└── examples/
    ├── cache-decision.md
    └── model-selection.md

Now:

"Create an ADR for using prompt caching
in the support assistant."

can activate the reusable capability.

---

16 Skill Metadata Matters

Skills need to be discoverable.

Anthropic specifically emphasizes that the Skill description should indicate both:

• what the Skill does
• when it should be used

because this metadata helps Claude decide whether to activate it.

Weak description

description: Helps with reports.

Too vague.

Better

description: >
  Creates internal architecture decision records using
  the organization's approved ADR template. Use when a
  user asks to document an architecture decision,
  alternatives, trade-offs, or revisit criteria.

For an exam question involving a Skill that fails to activate reliably, the description/discoverability mechanism may therefore be relevant.

---

17 Keep Skills Focused

Anthropic’s authoring guidance recommends concise, well-structured Skills and warns that once Skill content is loaded, it competes for context with the system prompt, conversation, request, and other information.

Don’t create:

company-everything-skill

containing:

Finance
HR
Security
Architecture
Marketing
Legal
Sales
Engineering
...

Prefer:

expense-analysis
security-review
architecture-review
proposal-writing
incident-analysis

This gives better:

• discovery
• maintainability
• context efficiency
• ownership
• testing

---

18 Prompt vs Template vs Skill

This is a likely exam distinction.

Mechanism	Best suited for
System prompt	Persistent behavior that should apply to the current application
Prompt template	Repeatable prompt structure with variable input
Modular prompt	Reusable behavioral/task components composed programmatically
Skill	Reusable procedure/domain capability Claude can discover and load when relevant
Prompt cache	Runtime reuse of identical/stable prompt prefixes

Example

Suppose an insurance company has:

Requirement 1: Every application must use the same safety policy.

→ Shared system/module.

Requirement 2: Every claim analysis follows the same structure but receives different claim details.

→ Template.

Requirement 3: Claims analysts repeatedly need a sophisticated 20-step claim-review procedure across sessions.

→ Skill.

Requirement 4: Every API request includes the same 25K-token underwriting manual.

→ Prompt caching, possibly together with retrieval depending on use case.

---

19 Caching vs Skills — Very Important

Students often confuse these.

Consider:

“Our developers repeatedly paste a 4,000-token code review procedure into new Claude sessions.”

Two possible thoughts:

Cache it?

Caching solves:

Repeated token processing cost

but not necessarily:

How does everyone consistently obtain and maintain the procedure?

Skill?

Skill solves:

Reusable procedure
+ centralized instructions
+ automatic/on-demand use

The uploaded practice exams strongly favor Skill for this scenario.

Therefore:

Repeated instructions across sessions/team → think Skill.

Repeated identical large prefix across API calls → think caching.

---

20 Modular Prompts vs Skills

Also don’t treat these as identical.

Modular prompt

Application explicitly assembles:

base_prompt
+ fraud_policy
+ review_instructions
+ output_schema

Your application controls composition.

Skill

Claude has access to:

fraud-investigation Skill

and loads its procedure/resources when the task requires it.

Think:

Modules are application-controlled prompt composition.

Skills are reusable capabilities available for contextual activation.

---

21 The Best Architecture Often Uses All Three

A mature enterprise system might look like this:

                         USER REQUEST
                              │
                              ▼
                    APPLICATION / AGENT
                              │
          ┌───────────────────┼─────────────────────┐
          │                   │                     │
          ▼                   ▼                     ▼
   MODULAR PROMPTS      RELEVANT SKILLS       DYNAMIC CONTEXT
          │                   │                     │
   ┌──────┼──────┐            │               Customer data
   │      │      │            │               Retrieved data
 Core   Policy  Task      Procedure/resources      │
   │      │      │            │                     │
   └──────┴──────┴────────────┴─────────────────────┘
                              │
                              ▼
                    PROMPT ASSEMBLY
                              │
               ┌──────────────┴──────────────┐
               │                             │
        Stable reusable prefix          Dynamic tail
               │                             │
               └──────── Prompt Cache ───────┘
                              │
                              ▼
                            CLAUDE

This is the architect-level understanding CCAR-P is likely looking for.

---

22 Decision Framework for the Exam

When you see a reuse question, ask:

Question 1 — Is the problem runtime cost/latency?

If yes:

Is a large prefix repeated?
      ↓ YES
Prompt caching

Question 2 — Is the problem maintainability/duplication?

If yes:

Same prompt components copied across applications?
      ↓ YES
Modular prompt/template

Question 3 — Is the problem a recurring procedure or domain capability?

If yes:

Should Claude reuse specialized instructions/workflows
across tasks or sessions?
      ↓ YES
Skill

Question 4 — Is the issue huge/changing knowledge?

If yes:

RAG / retrieval

not simply caching or Skills.

---

23 A Practical Reuse Hierarchy

A useful CCAR-P mental model:

                     REUSE
                       │
        ┌──────────────┼──────────────┐
        │              │              │
 PERFORMANCE       STRUCTURE       CAPABILITY
    reuse             reuse            reuse
        │              │              │
        ▼              ▼              ▼
 Prompt Cache    Modular Prompt      Skill
        │              │              │
same prefix      same building     same procedure/
reprocessed      blocks/templates  expertise

Memorize this.

---

24 Common Exam Traps

Trap 1 — “Switch to the cheapest model”

Scenario:

Same 20,000-token policy is repeatedly sent and cost is too high.

Wrong reflex:

Use smaller model

This risks quality while ignoring obvious input reuse.

Better:

Preserve required context
+
cache stable prefix

This mirrors the official sample question.

Trap 2 — “Truncate the policy”

That may reduce tokens, but it can remove information required for correct answers.

The better first choice when the content is required and repeated is usually:

Cache it rather than delete it.

Trap 3 — “Put static content after dynamic content”

Poor ordering:

User question
Customer ID
Timestamp
------------------
System policy
Reference documents
Examples

Dynamic fields appear before stable material.

Better:

Tools
System
Stable policies
Stable examples
------------------ cache prefix
Dynamic context
User question

Trap 4 — Confusing caching with memory

Caching

reuse computation

Memory

retain information/state

Caching isn’t cross-session business memory.

Trap 5 — Caching changing knowledge instead of retrieving it

A policy corpus changing continually may need:

RAG

Caching can complement RAG, but does not solve freshness.

Trap 6 — Pasting all Skills into every system prompt

This eliminates an important Skills advantage: load specialized instructions when relevant, rather than consuming all context upfront. Anthropic describes this staged loading explicitly.

Trap 7 — One giant “company Skill”

This creates the Skill equivalent of a monolithic prompt.

Prefer:

Focused
Discoverable
Composable
Testable

Skills.

Trap 8 — Treating prompt reuse as copy/paste

Copy/paste isn’t reuse architecture.

It causes:

duplicate prompts
      ↓
independent edits
      ↓
prompt drift
      ↓
inconsistent behavior
      ↓
difficult evaluation

---

25 Exam-Focused Comparison Table

Scenario	Best answer	Why
Same 20K policy on thousands of requests	Caching	Reduce repeated prefix processing
Same prompt structure with different customer values	Template	Separate stable structure from variables
Same safety instructions required by several assistants	Shared modular prompt	Centralized consistent behavior
Developers repeatedly paste a deployment procedure	Skill	Reusable recurring procedure
Hundreds of domain procedures, only one relevant per request	Skills / progressive loading	Avoid stuffing everything into context
Knowledge base changes every day	Retrieval/RAG	Freshness problem
Need state from previous customer sessions	Memory/store	Persistence problem
Need exact JSON downstream	Structured output/schema, not caching	Output contract problem

---

26 Worked Example — Enterprise Customer Support

Suppose a company operates 100,000 Claude support requests daily.

Each request currently contains:

System instructions             2,000 tokens
Corporate policy               10,000
Brand guidelines                3,000
Refund procedure                4,000
Examples                        5,000
Customer context                  700
Question                           50

Total ≈ 24,750 tokens.

Step 1 — Modularize

Core behavior
Brand guidelines
Safety policy
Task modules
Examples

Now shared components are separately managed and versioned.

Step 2 — Skillify the specialist workflow

Instead of forcing the full refund procedure into every conversation:

refund-processing Skill

can provide the specialized procedure when refund processing is actually relevant.

Step 3 — Cache the stable request prefix

For requests sharing:

core system
brand policy
tool definitions
stable examples

place those before the changing customer context and exploit prompt caching.

The result is not merely a “better prompt.”

It is a prompt reuse architecture.

---

27 Two Recommended Exercises

You asked to replace the site’s build exercise with something more relatable and organized. These two are better aligned with CCAR-P scenario reasoning.

Exercise 1 — Choose the Correct Reuse Strategy

You are architecting an internal HR assistant.

Current design:

5K corporate behavior guidelines
12K HR policy handbook
4K employee-response examples
2K onboarding procedure
employee record
current employee question

The assistant handles 30,000 requests/day.

Additionally, HR specialists manually paste a detailed “new employee onboarding review” procedure whenever that task occurs.

Your task

Classify each component as:

• shared prompt module
• cached prefix
• Skill
• dynamic input
• retrieval candidate

Strong solution

Core behavior guidelines
→ modular shared prompt
→ cacheable if stable

Common stable examples
→ shared examples module
→ cacheable if reused frequently

HR handbook
→ caching if relatively static and repeatedly needed
OR retrieval if large/changing and queries need only portions

Onboarding review procedure
→ Skill

Employee record
→ dynamic context

Current question
→ dynamic user input

The important lesson is that one architecture can use multiple reuse techniques.

Exercise 2 — Find the Cache Killer

Given:

SYSTEM:
Current time: {{NOW}}

You are the ACME support assistant.

Follow ACME Support Policy v7:
[15,000 tokens]

Examples:
[8,000 tokens]

USER:
{{customer_question}}

Requests run thousands of times per hour, but cache-hit rates are poor.

Diagnose it.

The timestamp is included before the otherwise stable content, changing the request prefix every time.

Redesign

SYSTEM:
You are the ACME support assistant.

Policy v7...
Examples...
-------------------
CACHEABLE PREFIX

DYNAMIC MESSAGE:
Current time: {{NOW}}
Customer question: {{customer_question}}

Then ask yourself:

What else could destroy stability?

Possible answers:

• unnecessary request IDs early in the prompt
• changing tool definitions
• reordered examples
• changing policy versions
• personalization before the cache boundary

Anthropic’s cache diagnostics guidance specifically identifies changes such as reordered content or interpolated timestamps as common causes of lost cache reuse.

---

28 Five CCAR-P Style Practice Questions

Question 1 — Prompt Caching

A financial-services assistant receives the same 18,000-token compliance policy and system instructions on every API request. Only the final customer question changes. The compliance content is required in full, and both latency and cost have become concerns.

What should the architect do first?

A. Remove half of the compliance policy to reduce tokens. B. Move the customer question before the policy so Claude sees it first. C. Keep the stable policy and instructions before the changing content and use prompt caching. D. Replace the current Claude model with the least expensive available model.

Correct Answer: C

Prompt caching directly addresses the repeated processing of a large stable prefix while preserving required context. Anthropic recommends caching for repetitive prompts and consistent background context, and the official CCAR-P guide uses essentially this reasoning in its own Domain 2 sample.

Why A is wrong: It sacrifices required information.

Why B is wrong: Dynamic data before stable material works against prefix reuse.

Why D is wrong: It changes model capability rather than addressing the actual inefficiency.

Exam clue

same + large + static + every request + latency/cost

→ Prompt caching

Question 2 — Skills

A platform engineering team has a detailed 4,000-token production-readiness review procedure. Engineers copy the procedure into Claude manually whenever they perform a review. Different engineers now use slightly different versions.

What is the best reuse strategy?

A. Increase the context window. B. Ask each engineer to maintain a personal copy. C. Package the recurring procedure as a reusable Skill. D. Store previous Claude responses in a response cache.

Correct Answer: C

Skills are specifically designed to package reusable domain procedures, instructions and related resources so Claude can use them when relevant.

This exact reasoning is also reinforced by both uploaded practice exams: recurring instructions being manually pasted across sessions are better represented as a modular Skill.

Why A is wrong: More context capacity doesn’t solve reuse or consistency.

Why B is wrong: It increases prompt drift.

Why D is wrong: The team needs reusable instructions, not previously generated answers.

Exam clue

Repeated procedure + across users/sessions + maintainability

→ Skill

Question 3 — Modular Prompts

Three applications use identical security instructions, but each team has copied those instructions into its own application prompt. A security policy update now requires changes across all three applications.

What is the best architectural improvement?

A. Increase the cache TTL. B. Centralize the security instructions as a versioned reusable prompt module composed into each application’s prompt. C. Put the entire security policy into each user message. D. Create a larger context window.

Correct Answer: B

The issue is maintainability and configuration drift, not repeated model computation.

A shared modular prompt gives:

one source
   ↓
versioned change
   ↓
multiple consumers

This aligns with the workbook’s guidance to centralize shared prompts and version prompt artifacts because prompt changes are behavioral changes.

Exam clue

Duplicate prompt logic + consistency + updates

→ Modular prompt

Question 4 — Caching vs RAG

A legal assistant serves answers from 600,000 documents. The corpus changes throughout the day, and most questions require only two or three relevant passages.

Which is the best primary approach?

A. Put all documents into one cached system prompt. B. Use retrieval to select relevant current passages, optionally caching stable instructions separately. C. Convert every document into a Skill. D. Increase cache lifetime until all documents remain available.

Correct Answer: B

This is primarily a knowledge selection and freshness problem.

Use:

Query
 ↓
Retrieve relevant/current evidence
 ↓
Prompt assembly
 ↓
Claude

Caching can still optimize the stable system instructions, but it should not replace retrieval.

A/D confuse repeated prefix computation with corpus management.

C misuses Skills; they are better suited to procedures/domain capabilities than blindly representing a massive changing corpus.

Exam clue

Large + changing corpus + only relevant subset required

→ RAG/retrieval, possibly plus caching

Question 5 — Combined Architecture

A claims-processing assistant has:

1. 3,000 tokens of company-wide behavior rules used on every request.
2. A reusable claims-evaluation prompt structure with several dynamic fields.
3. A specialized fraud-investigation procedure needed for only 5% of cases.
4. Claim-specific customer data.

Which design is best?

A. Put all four components into one giant static system prompt. B. Use caching for everything, including customer data. C. Use a shared/cacheable stable prefix for common rules, a parameterized modular template for claims evaluation, a Skill for fraud investigation, and dynamic context for claim-specific data. D. Implement all four components as Skills.

Correct Answer: C

This is the architect-level response because it matches each problem to its correct mechanism:

Company rules
→ shared module + cache candidate

Claims structure
→ template/module

Fraud procedure
→ Skill

Customer data
→ dynamic context

Skills are intended to compose specialized capabilities and load relevant instructions when needed rather than requiring every specialized workflow upfront.

---

29 What I Would Expect the Real Exam to Test

Based on the official blueprint, official sample question, workbook and the two practice exams, I would prioritize these reasoning patterns:

Very High Probability

1. Stable prefix identification

same large prefix
+
changing short request
=
caching

2. Caching vs removing context

Correct answer usually preserves necessary information rather than truncating it just to save tokens.

3. Skills vs copy/paste

recurring task procedure
+
team/session reuse
=
Skill

4. Caching vs Skills

runtime efficiency → caching
procedural reuse → Skills

5. Reuse architecture rather than one-off prompt tricks

centralize
modularize
version
evaluate
reuse

The official blueprint explicitly tests this as an architecture skill, and the recommended candidate profile emphasizes modular design, system architecture and production operation rather than isolated prompt writing.

---

30 60-Second CCAR-P Revision Sheet

Memorize this before the exam:

PROMPT REUSE
│
├─ Same large static prefix repeatedly?
│      └─ PROMPT CACHING
│
├─ Same prompt structure with changing variables?
│      └─ TEMPLATE
│
├─ Shared instructions used by multiple prompts/apps?
│      └─ MODULAR PROMPT
│
├─ Repeated specialist procedure/workflow?
│      └─ SKILL
│
├─ Huge/changing knowledge corpus?
│      └─ RAG / RETRIEVAL
│
└─ Need state across sessions?
       └─ MEMORY / EXTERNAL STORE

And remember these five exam rules:

1. Stable content before dynamic content when designing cacheable prompts.
2. Caching reuses prompt processing, not model answers.
3. Modular prompts solve maintainability and prompt drift.
4. Skills package reusable procedures/domain capabilities and can load detailed guidance when relevant.
5. Use the mechanisms together when appropriate—a Skill, modular prompt composition and prompt caching solve different architectural problems.

One-line exam mnemonic

Cache the repeated context. Modularize the repeated structure. Skill the repeated procedure. Retrieve the changing knowledge.

That single distinction should eliminate most distractors for this CCAR-P objective.