/context-engineer

name: context-engineer
description: The concierge proxy — turn a vague user script ("I need the agent to help me do X") into a context contract, route it to the right skills/workflows, add backpressure (tests/evals/reviews/approvals), execute, and report. Use when a request is multi-step, durable, or human-in-the-loop and you'd otherwise hand-roll the orchestration; skip it for a single prompt → single answer.

Context Engineer

`context-engineer` is an archived Smithers **concierge** example: a proxy agent turning a half-formed request into an executable, durable, observable run. Not installed by `init`: copy `examples/init-pack/context-engineer.tsx` and its dependency closure into a project, or ask the seeded `create-workflow` to build an equivalent.

The job

The user says *"I need the agent to help me do X."* They needn't know what "context engineering" is. Convert that script into five things:

1. **a context contract**: goal, non-goals, assumptions, inputs (+ sources), constraints, risks, desired artifacts, success criteria; 2. **a route**: the smallest sufficient path (one task, a set of skills, or a durable sub-workflow); 3. **a backpressure plan**: every success criterion mapped to a verification gate (schema / test / eval / review / approval / trace); 4. **executed artifacts**: work done (or dispatched), looped until gates pass; 5. **a report**: a self-contained HTML slideshow of what happened.

The layered model

Model an agent as a control system: **prompt** (instructions, examples, output format) → **context** (info/tools/memory/schema entering each step) → **harness** (runtime, tools, permissions, retries, fresh-context loops) → **workflow** (graph, parallelism, review loops, approvals, resumability) → **backpressure** (every desired behavior gets a gate). The proxy layer is the differentiator: the user owns only the prompt's intent (business/domain questions); **Smithers owns the outer four layers** (all agent-engineering ones): context in the workflow graph + memory, harness in `agents.ts`/sandboxes/`repoCommands`, workflow in the runtime, backpressure in the gate matrix, all filled by `context-engineer`.

The operating loop

This mirrors the workflow's `<Sequence>`: classify → inventory → grill → route → backpressure → approve → execute → report.

• **Intake & classify** (`classify-script`): read the script, name the modes

touched (research / planning / implementation / debug / report), and decide `durable`: real workflow, or one task?

• **Build a context inventory** (`inventory-context`): scan the repo, available

tools/commands, `.smithers/skills`, and memory to draft the contract, filling gaps with explicit `assumptions` and listing what's `missingInputs`.

• **Grill, only to reduce risk** (`context-engineer:grill`, the `<GrillMe>`

component): ask **one question at a time** with a **recommended answer + reason**, stopping once ambiguity no longer changes the plan. **Never ask what's discoverable** from repo/docs/tools/memory: auto-answer yourself. Every ambiguity resolves to *assumption | question | deferred decision*.

• **Maintain a visible contract**: the shared artifact, kept current so the

human can read goal/non-goals/criteria anytime.

• **Backpressure** (`build-backpressure`): turn each success criterion into ≥1

gate with a `verificationMethod` (`schema` | `unit_test` | `integration_test` | `eval` | `review` | `approval` | `trace` | `manual_check`) and a `gateType` (`blocking` | `warning` | `informational`). The contract isn't "ready" until every blocking criterion names a verification method.

• **Approve** (`approve-contract`): a durable `<Approval>` gate so a human signs

off on contract, route, and gates before side effects.

• **Execute** (`execute:loop`, a `<Ralph>`): run or dispatch the routed work,

looping until the gates pass; on repeated failure, revise context or harness, not just the prompt.

• **Report** (`report`): emit the HTML slideshow from run state.

How to run it

# Launch the concierge on a vague script. --review true (default) inserts the
# approval gate; --review false runs straight through.
bunx smthrs workflow run context-engineer \
  --prompt "I need the agent to help me harden our rate limiting and prove it works"

# Watch it
bunx smthrs ps                       # active / paused / recent runs
bunx smthrs logs <run-id> -f         # follow the event stream
bunx smthrs inspect <run-id>         # full run state (contract, route, gates)
bunx smthrs why <run-id>             # why is it paused?

# Clear the design-approval gate once you've read the contract
bunx smthrs approve <run-id> --node approve-contract --by <name>
bunx smthrs deny <run-id> --node approve-contract   # send it back

# Bail out
bunx smthrs cancel <run-id>

The run **pauses durably** at `approve-contract` (a suspended run is a row, not a process, so it costs nothing while waiting), then proceeds to execute and report.

**Cheaper / adjacent paths:**

• **`route-task`**: the degenerate concierge for "just run one task": it

classifies a script, then runs it as a single task or recommends the right durable workflow, for work that's clearly one-shot (a single task is a first-class outcome, not a routing failure).

• **`create-workflow`** / **`create-skill`**: authoring, not execution. Dispatch

these when the route is "we need a new durable workflow / a new reusable skill" to build it (clarify → provision → design → approve → scaffold → verify → document), then run the result.

When to use vs. skip

• **Single prompt → single answer, or a one-off edit:** skip the concierge

and answer directly: the overhead buys nothing.

• **Clearly one task:** use **`route-task`** (above).
• **Multi-step, needs ordering / crash-recovery / a human gate / loop-until-true,

or the user wants work to keep going while away:** use **`context-engineer`**, where a contract + route + backpressure + durable executio