Model-Mediated Development

Overview

Model decides. Code provides inputs and executes. This skill is a thinking lens that applies DURING other workflows, not a replacement for them.

Core question throughout: "What decisions exist, and who should make each?"

Integration with Development Workflows

This skill runs ALONGSIDE other skills:

Works with both Claude Code (superpowers) and Codex (bootstrappers).

During Design/Brainstorming

When designing any system that might involve model calls, explore:

Suggest possibilities:

• •"This could be model-mediated - the model could decide X based on Y"
• •"What if we gave the model tools for Z and let it figure out timing?"
• •"Here's a tool interface that would give the model control..."

Ask yourself and the user:

• •"What decisions exist in this system?"
• •"For each decision: should it be user-controlled, model-controlled, or hardcoded?"
• •"This could go either way - do you want explicit control or model judgment?"

Surface considerations:

• •"If the model decides this, here's what it would need..."
• •"If we hardcode this, we lose flexibility for..."
• •"This feels like a decision - should we discuss who makes it?"

Not everything needs model-mediation. A CLI that takes explicit user input and calls an API is a dumb pipe. That's fine. The question is whether there are DECISIONS being made, and if so, by whom.

During Planning

When writing implementation plans, distinguish:

Dumb pipes (code):

• •Fetch data, transform formats, call APIs
• •Execute tool calls from model
• •Provide factual inputs (time, state, history)
• •Health checks, audit trails

Decision layers (model):

• •What action to take
• •When to take it
• •What context to request
• •How to interpret ambiguous intent

The plan should make clear: "Component X is a pipe - TDD applies. Component Y is a decision layer - model controls via tools."

During Implementation (TDD)

TDD applies to pipes. Write tests for:

• •Data fetching works correctly
• •Tool execution is reliable
• •Inputs are gathered accurately
• •Error handling is robust

But continuously ask:

• •"Am I about to write an IF that decides behavior? Stop - that's model logic."
• •"Am I pre-gathering context? Should model request this instead?"
• •"Am I adding a threshold/rule? Why isn't the model deciding this?"

When uncertain, surface it:

• •"This looks like it could be model-controlled. Thoughts?"
• •"I'm tempted to add a safety check here - but that's compensating for the model. Should we improve the prompt instead?"
• •"This pattern looks like [anti-pattern] - intentional?"

During Verification

Before claiming complete:

• • All IF statements are execution flow, not decision logic
• • Model receives tools, not pre-gathered context dumps
• • Tool calls execute without filtering/modification
• • No fallback logic compensating for model behavior
• • Adding new behavior requires only prompt changes

Surface anything suspicious:

• •"I notice we added X - this looks like a heuristic"
• •"This threshold wasn't in the plan - should we discuss?"
• •"The model's decisions are being filtered here - intentional?"

The Right Pattern

async execute(workItem, context) {
  // === CODE: Factual inputs ===
  const inputs = {
    currentTime: new Date().toISOString(),
    lastRunTime: await getLastRunTime(),
  };

  // === CODE: Available tools ===
  const tools = [
    { name: 'get_context', description: '...' },
    { name: 'create_work_item', description: '...' },
  ];

  // === MODEL: Reasons and decides ===
  const result = await model.run({
    system: buildPrompt(inputs), // Adversarial prompts included
    tools,
  });

  // === CODE: Execute exactly what model decided ===
  for (const toolCall of result.tool_calls) {
    await executeToolCall(toolCall); // No filtering!
  }
}

Multi-Turn Model Reasoning

Don't dump context. Let model request what it needs:

Turn 1: Minimal seed
  Model: "What do I need to know?"
  → calls get_context(source: 'conversations')

Turn 2: Has some data, needs more
  Model: "Is he busy today?"
  → calls get_context(source: 'calendar')

Turn 3: Enough to decide
  Model: "I'll wait until after his meeting"
  → calls schedule_next(when: '11am')

Adversarial Prompts for Runtime Models

Build into system prompts:

• •"What makes sense here?"
• •"What information would help me assess this?"
• •"What should I NOT do in this setting?"
• •"What would [persona] do? What would [user] want?"
• •"What if action 1 vs action 2?"
• •"Review what you need, request it, then decide."

Anti-Patterns to Surface

When you see these, ask about them:

When Model-Mediation Doesn't Apply

Not everything needs it:

• •Pure pipes: User provides explicit input → API call → output
• •Deterministic transforms: Data in → format change → data out
• •User-controlled flows: User explicitly decides each step

The question isn't "does this call a model?" but "are there decisions being made, and should a model make them?"

Collaborative Mode

This skill is about ongoing dialogue, not checkpoints:

• •Propose architectures and tool designs
• •Question yourself when writing code that decides
• •Ask the user when you're uncertain
• •Surface anti-patterns as they emerge
• •Suggest model-mediated alternatives

Don't wait until verification to catch problems. Think about decision ownership continuously.

The Bottom Line

Every decision needs an owner: user, model, or code.

• •User: Explicit control, deterministic
• •Model: Judgment, context-dependent, flexible
• •Code: Never for judgment calls - only execution

When in doubt, ask: "Is this a judgment call?" If yes, model decides.

Reference

For detailed methodology, see:

• •docs/design/13-model-mediated-methodology.md (assistant-system)
• •Anthropic SDK documentation for tool-based patterns