Scoped Instructions

Scoped instructions are the first control lever that changes the body of skill.md. They give framework-enforced branching by stripping non-matching paragraphs from the LLM’s prompt. The LLM can’t follow the wrong branch because it isn’t in context.

The problem

The Card Replace skill has reason-based routing: different handling for stolen vs. damaged vs. lost cards. With pure prose the LLM sometimes picks the wrong path, skips straight to locking, or blends the stolen and lost workflows.

The fix: `if:` markers

Declare a categorical memory entry in memory.yml
Put an if: marker on the line above each branch paragraph
Once the entry is set, the framework strips the non-matching paragraphs

skills/card_replace/skill.md

---
name: Card Replace
description: Replace a credit card -- lost, stolen, damaged, or not received
requires: "session.project.authenticated"

tool_constraints:
  - lock_card:
      requires: "session.project.selected_card_id"
---

Help the customer replace a credit card.

Check whether their account is eligible for replacement. If they have multiple
cards, ask which one. Ask why they need a replacement: the valid reasons are
lost, stolen, damaged, or not received.

if: session.card_replace.replacement_reason == 'damaged'
Ask who needs a replacement: just the customer's card, an authorized user's
card, or both.

if: session.card_replace.replacement_reason == 'stolen'
Tell the customer the card will be locked for their protection. Confirm, then
lock the card.

if: session.card_replace.replacement_reason == 'lost' or session.card_replace.replacement_reason == 'not_received'
Present any recent transactions and ask if they all look familiar. Then explain
that the card will be unusable until the replacement arrives, ask for
confirmation, and lock it if they agree.

Once the reason is handled, check digital-wallet eligibility. If eligible and
not already provisioned, offer Apple Pay, Google Pay, or Samsung Pay.

Ask their shipping preference (rush or standard), confirm the order, and process
the replacement.

skills/card_replace/memory.yml

schema:
  public:
    replacement_reason:
      type: categorical
      enum_values: [lost, stolen, damaged, not_received]
      llm_settable: true
      description: Why the card is being replaced.

One `if:` per case

Each marker stands on its own, so every branch reads as its own if:. To cover “everything other than X”, write the complement:

if: not session.card_replace.replacement_reason == 'stolen'
Explain the standard replacement timeline.

When a section genuinely needs exclusive either/or branching, reach for an ordered block and its next: branches, where else: provides the fallback.

How it works at runtime

The LLM reads all instructions (every paragraph is visible while the entry is unset) and gathers information conversationally
The user says “it was stolen”
The LLM records replacement_reason = "stolen" via set_fields
On the next prompt build, the damaged and lost/not_received paragraphs are gone
The LLM continues with only the stolen path plus every unmarked paragraph

Scoping is re-evaluated on every prompt build, so a corrected value re-scopes the branch on the next turn.

Boundary rule

An if: marker scopes only the paragraph immediately following it, up to the next blank line. Paragraphs without a marker are always visible. There are no end markers. The marker goes on the first line of the paragraph, with the text it scopes directly beneath it.

What `rasa train` checks

if: conditions are verified before packaging, so branching mistakes surface at build time:

Code	Meaning
`calm_v2.validation.prose.empty_if_condition`	An `if:` marker with no expression
`calm_v2.validation.prose.invalid_if_expression`	An expression the parser does not accept
`calm_v2.validation.prose.unknown_memory_key`	A key this skill cannot read at runtime

The last one is the useful one. It catches a mistyped entry name, a reference missing its namespace, or a reference to another skill’s private field.

The progressive story

The frontmatter is unchanged from the previous page. The only additions are if: markers in the body and a categorical entry in memory.yml. Zero ordered blocks, and a framework-enforced guarantee.

Getting Started

Building Skills

Progressive Control

Orchestration

More

Scoped Instructions

The problem

The fix: `if:` markers

One `if:` per case

How it works at runtime

Boundary rule

What `rasa train` checks

The progressive story

​The problem

​The fix: if: markers

​One if: per case

​How it works at runtime

​Boundary rule

​What rasa train checks

​The progressive story

The problem

The fix: `if:` markers

One `if:` per case

How it works at runtime

Boundary rule

What `rasa train` checks

The progressive story