Skill

Draft the in-scope / out-of-scope / disclaimed boundary

Proposes an explicit boundary statement — what topics, data, and decisions are inside scope, what is out or disclaimed, and what conditions must hold for a reliable output.

In / outBuyer question + observable success outcome → in-scope / out-of-scope / disclaimed boundary statement with prerequisite conditions

You might say…

Having a written boundary meant I stopped fighting scope creep in every kickoff call — I just pointed to the document.

What it does

Given the buyer question and outcome, proposes an explicit boundary statement — what topics, data, and decisions are inside scope, what is out or disclaimed, and what conditions must hold for a reliable output. Used to produce the durable scope reference that disciplines proposals, onboarding, and downstream design.

Trigger: Use after the buyer question and outcome are fixed, to produce the durable scope reference that disciplines proposals, onboarding, and downstream methodology design.

Recognise the problem?

The primitives are the commodity part. The fastest next step is a conversation about composing them into something that works for you.

Start a conversation