A Higher Order Prompt wraps a base command with verified domain expertise loaded into the same context window — so /plan runs with the architecture already in its head, not after.

Pattern

Higher Order Prompt

The shape

Expert surface → expertise layer → base command.

1. Surfaceuser entry

# experts:adw:plan

$USER_REQUEST

"add a retry step

to the webhook ADW"

→

wraps

2. Layerone context pass

1load expertise.yaml

2 name critical files

3read the actual files

4 verify claims vs code

5 drop unverified

6 delegate

→

delegates

3. Baseunchanged

# /plan

plan(

$USER_REQUEST

)

sees: request +

verified expertise

in one window

The expertise is a context layer — not a parallel planner, not a report to merge. The base command runs with it already present.

The three steps

Load. Verify. Delegate. In that order.

01

Load the mental model

Read expertise.yaml in full, before any task-specific work. Domain knowledge is not an afterthought — it enters the context window first.

Mental Model

02

Verify against code

For each critical file the expertise names, read the actual file. Confirm structures still exist; drop stale claims. Expertise goes stale; the filesystem doesn't.

Live check

03

Call the base command

Invoke /plan with the user's original request. The base command is unchanged — what changed is the context it sees.

Unchanged base

Skip verification and the HOP trusts an expertise file that's three commits behind reality — and bakes the staleness into the plan.

Why embedding fails

Expertise inlined into commands drifts. One externalized source does not.

Domain knowledge embedded per commandN copies to update

plan.mdembeds ADW schema inline

build.mdembeds ADW schema inline

fix.mdembeds ADW schema (stale)

ADW schema gains a retry step field.

Three independent edits. Miss one and that surface silently plans against a fictional schema. Drift is guaranteed by the first human mistake.

HOP loads one expertise file1 source of truth

expertise.yamlADW schema lives here

plan.md→ loads expertise.yaml

build.md→ loads expertise.yaml

fix.md→ loads expertise.yaml

ADW schema gains a retry step field.

Edit one file. Every expert surface sees the update on next invocation. Verification step catches any claim the file got wrong.

Why it's not a sub-agent

A context layer, not a parallel report.

Parallel expert agent

user request

↓ spawn expert agent

expert report

↓ merge two inputs

/plan must reconcile

Two inputs, two windows. The base command re-interprets the expert's report against the task — fragmented context, reconciliation cost, room for disagreement.

Higher Order Prompt

user request

↓ load + verify in-line

request_+ verified expertise__+ live critical files_

↓ same window

/plan sees unified world

One context pass. The base command sees expertise + task as a single pre-enriched world. Nothing to reconcile — the world is already coherent when /plan boots.

A report is data to merge. A context layer is a world to inhabit. HOP builds the world, then lets the base command live in it.

When to reach for it

Use it when the base command keeps guessing at your domain.

REACH FOR HOP

• Base command's plans miss architectural decisions it couldn't infer from the task description
• Multiple command surfaces (plan + build + fix) share the same domain knowledge
• Expertise file exists and can be verified against live files at invocation

DON'T BOTHER

• Task is domain-agnostic — base command's default context suffices
• No verifiable critical files yet — expertise would be unchecked claims
• Only one surface needs the knowledge — just embed it there and move on

HOP is a wrapper, not a frame. Reach for it when the same expertise serves multiple surfaces — otherwise inline is cheaper and drift isn't a risk.

The discipline

Enrich the context, don't rewrite the command.

The base command stays unchanged — what changes is what it can see when it runs. Verified expertise enters the same window as the request, so planning happens with domain awareness baked in, not bolted on.