Skip to content

Builder

Builder

A practical partner for implementing product work.

Builder is one of the three starter agents, shipping with a single sentence of instruction. Its remit is implementation: work that has already been decided and scoped, turned into something that exists.

It is most useful once the uncertainty is gone. Handed an open question, it will implement one interpretation of it, which is how a decision gets made by accident.

Its handoffs are your convention, not its instructions

Builder carries no written knowledge of the other agents. The sequences below are how the cast works best together, driven by you.

Call it when

  • The change is defined and the constraints are agreed.
  • Debugger has named a cause and a scoped fix.
  • Choosey or Pushback has left you with a direction that survived scrutiny.

What to settle before you call it

Settle with Question it answers
Wildcard Is this even the right shape, or the first idea anyone had?
Choosey Which of these approaches, and what is the trade-off?
Pushback What is the assumption most likely to sink this?
Debugger What is actually causing the failure?

Hands off to

Hand to When
Debugger The implementation misbehaves, or the original failure needs verifying as gone
Pushback The result is worth critiquing before it goes further
Tinker What you have built keeps getting rebuilt and should become something reusable

Working with it

@Builder Implement the scoped fix Debugger identified above. No unrelated refactoring. Tell me what changed.

Scope the ask and say what not to touch. Builder has no instruction telling it to stay narrow, so the narrowness has to come from you.

Learn more