Skip to content

Operator Techniques

Sanjeev Azad edited this page May 29, 2026 · 2 revisions

Operator Techniques

Status: Complete · The tactical how. These are the repeatable moves a Conductor uses inside the lifecycle.

Principles tell you what to aim for; techniques are the muscle memory. Each below has a when, a how, and the failure it prevents.


Context techniques

1 · Context priming

When: Before every Generate phase. How: Load the agent with exactly three things — the relevant specs/<slice>.md, the files in that bounded context, and .cursorrules. Nothing else. Prevents: Hallucination and scope creep from a polluted context window. The model is precise on what it can fully hold; vague on what it half‑sees.

2 · Bounded‑context isolation

When: Any multi‑file change. How: Keep the agent inside one features/<slice>/ folder. If it needs another context's data, expose a narrow contract instead of letting it read across the boundary. Prevents: Accidental coupling and the "spaghetti" that destroys AI readability.

3 · Context‑window hygiene

When: Long sessions; when answers start drifting. How: Start a fresh context rather than fighting a stale one. Summarize decisions into the spec, then reload. Treat the context window as scratch space, the spec as memory. Prevents: "Context rot" — the slow degradation where the model contradicts earlier turns.


Generation techniques

4 · Vertical‑slice generation

When: Any new feature. How: Ask for schema + API + state + UI in one cycle, driven by one spec, so the layers align by construction. Prevents: Integration drift between layers built at different times.

5 · Progressive disclosure (skeleton → fill)

When: Medium/High entropy work. How: Generate the structure first (file layout, types, function signatures, empty tests), review it, then fill implementations. Catch architectural mistakes before they're buried in detail. Prevents: Reviewing 800 lines when the shape was wrong on line 10.

6 · Spec‑first debugging

When: Every bug. How: Don't ask "fix this code." Ask "does the spec describe the correct behaviour?" If no, fix the spec; if yes, regenerate the slice from it. Prevents: Patches that fix the symptom, drift the code from the spec, and recur.


Verification techniques

7 · Fresh‑context adversarial review (the Guardian move)

When: Every Guard phase. How: Open a separate, clean context with no memory of how the code was written, and instruct it to break the slice — hostile inputs, edge cases the spec missed, concurrency. The writer must never be the sole judge. Prevents: Self‑review rationalizing away its own bugs.

8 · "Refute, don't confirm"

When: Verifying any non‑trivial claim or fix. How: Prompt the verifier to assume the code is wrong and find why, defaulting to "broken" when uncertain — not "looks good to me." Prevents: Plausible‑but‑wrong output sailing through a confirmatory check.

9 · Perspective‑diverse review

When: High‑blast‑radius changes (auth, money, data). How: Run multiple independent passes, each with a different lens — correctness, security, does‑it‑reproduce, performance — rather than the same check repeated. Prevents: A single blind spot passing every (identical) reviewer.

10 · Diff‑driven review

When: Every Review phase. How: Review the diff, not the whole file. Ask specifically: did the agent change anything the spec didn't ask for? Unrequested scope is a red flag. Prevents: Silent scope creep and unrelated "helpful" edits.


Prompting patterns

11 · Intent → Constraints → Acceptance

Structure generation prompts in three parts: what to build (intent), boundaries it must respect (constraints, from .cursorrules + spec), and how you'll judge it (acceptance criteria). The acceptance criteria double as the Guardian's test list.

12 · Name the entropy, set the ceremony

Open a task by stating its Context Entropy. "This is a 13" tells you to stop and spec; "this is a 2" tells you to just do it. The label calibrates your own effort.

13 · Guardrail prompts (.cursorrules)

Encode non‑negotiables once — file‑size limits, "spec is source of truth," "never cross bounded contexts," "no secrets in code" — so you don't re‑type them every prompt. See Agent Setup & Configuration.


Orchestration patterns

14 · One persona, one job

Don't ask the Engineer to also QA its own work. Route UI to the Visualizer, logic to the Engineer, breakage to the Guardian — even if it's the same underlying model wearing different hats in different sessions. Separation of concerns is the point.

15 · Human gate on irreversibles

Auth, payments, data deletion, schema drops, and external sends never auto‑apply. The agent proposes; you decide. Automate the reversible; gate the irreversible.


Reality check. Techniques are tools, not rituals. A 1‑line typo fix doesn't need progressive disclosure and a three‑lens adversarial review — that's ceremony theatre. Scale the technique stack to the entropy and blast radius. The two that never switch off: fresh‑context verification for anything non‑trivial, and the human gate on irreversibles.


See also: Best Practices (the durable habits) · Agent Setup & Configuration (where guardrails live) · The End‑to‑End Lifecycle.

Clone this wiki locally