DOE Framework — Directive → Orchestration → Execution

Use this skill when the DOE gate (four questions below) returns yes to any. Reference:

foundation/directives/operating-contract.md

,

docs/operating-system-architecture.md

,

routing-index.md

,

foundation/directives/INDEX.md

. Foundation, routing index, and current state are loaded at session start; do not run /prime again in this flow.

---

1. DOE gate (decide before acting)

On each user request, ask yourself (do not ask the user):

Question	Yes to any → DOE required
Is this a repeatable task?
Is this a complex task requiring multiple steps?
Does this request leave the repo and touch a live system?
Does the output need to survive beyond this session?

• No to all four → Handle as direct request (lookup, answer, simple action). May read from hub or data sources. No workspace routing, no directive. Return response. End with END-OF-TASK (§3).
• Yes to any → Surface gate result (§1.1), run grounding check (§1.2), then follow the flow (§2).

1.2 Grounding check (mandatory when DOE is required)

Before acting, invoke the Grounding Check skill (

.claude/skills/grounding-check/SKILL.md

) for every factual claim that touches client data, schemas, or live systems. Pull the source (Airtable, BF-Signal, directive file) — do not recall from memory. Tag each claim

[CANONICAL]

,

[INFERRED]

, or

[OPEN QUESTION]

per the GROUNDING RULES in CLAUDE.md.

1.1 Surface gate result to the user (mandatory)

Before answering or acting, state one short line so the user knows the check ran:

DOE gate: [required | not required] — [brief reason].

Examples:

DOE gate: not required — direct answer, no live systems.

|

DOE gate: required — repeatable task, touches Airtable.

Then proceed.

---

2. End-to-end flow (when DOE is required)

2.1 Roles

• Executor: The micro agent within the selected workspace. Performs scoped work (code, edits, runs) inside that workspace only. Orchestrator invokes it with the contract.
• Verifier: A subagent (e.g. Task tool or separate agent) called to check the executor’s output against directive and skill expectations. Returns pass or fail with details; does not perform the work or write memory.

2.2 Steps

1. Orchestrator classifies request → Route to Business OS Space or Client OS Space per

   routing-index.md

   . Workspace selected.
2. Approved directive exists?
   • If no → Enter DESIGN. Draft directive blueprint + skill outline. Jennifer approval required. Execution blocked until approval.
   • If yes → Continue.
3. Orchestrator reads approved directive + skill; defines scoped execution instructions.
4. Executor (micro agent within workspace) performs work within workspace scope.
5. Verifier (subagent) checks output against directive + skill expectations.
   • If fail: Verifier sends failure details to orchestrator. Orchestrator classifies gap (skill / directive / contract / foundation), patches the correct layer (self-anneal). Resume execution or re-verify until pass — or escalate if correction path not safely inferable.
   • If pass: If directive allows hub write → write to

     hub/

     ; else skip hub update.
6. END-OF-TASK (§3): Output the mandatory close line.

Note: /wrap is user-called only; do not invoke it from this flow.

---

3. Self-annealing and end-of-task

Self-annealing is not optional when the system learns a durable lesson from a repeatable or structural failure. Fix before delivery; report at END-OF-TASK.

3.1 What self-annealing means

Detect problem → fix immediate problem → identify durable lesson → patch correct layer (directive, skill, contract, execution, or foundation) → resume and retest. See

foundation/directives/operating-contract.md

§14.

3.2 When required / not required

Required: repeatable failure; directive omitted a step; wrong script, path, or routing; missing validation; known failure mode; interpretation gap; same mistake could recur. Not required: one-off outages, timeouts, rate limits, transients, user typos, external instability. Patch the correct layer (§14.4); do not rewrite large bodies casually (§14.5).

3.3 Self-annealing is silent

Fix bugs before delivery. Do not announce self-annealing as a failure. Replace

<what>

with a short description of anything you fixed; use N/A only when nothing was fixed (never N/A if you applied a fix). See

foundation/directives/operating-contract.md

§22.2.

3.4 End-of-task (mandatory)

Every task must end with:

END-OF-TASK: Directive [updated/created/N/A]. Self-annealing [applied: <what> / N/A].

Use it to report Directive (updated/created/N/A) and Self-annealing (applied: what changed, or N/A only when nothing was fixed). Applies to both DOE-governed and direct requests.