Skill: Decide Boundary
"A brief often holds several projects wearing one name."
The Question
Would this piece make sense if the request had never existed?
Most pieces that survive it outlive the request. Some become packages.
The Test
Two halves. Both must pass.
| Ask | Fails when |
|---|---|
| Does it survive alone? | it means nothing without the request that produced it |
| Does it stay correct alone? | standing alone breaks a guarantee it only held in company |
The second gets missed. A review method separated from the thing that supplies its reviewer still runs — and now grades its own work.
The Tells
These surface only in code. The charter gate cannot see them.
| Tell | Reading |
|---|---|
| the same shape written a third time | it wants to be one thing, elsewhere |
| one file, two unrelated reasons to change | two charters sharing a filename |
| a test needing setup from a concern it doesn't test | the boundary already leaks |
Any of these outranks the finding you were about to write. Three findings about symptoms of one mis-sized boundary is three wasted rounds and a missed call.
Elsewhere, Not Alone
| Tell | Move |
|---|---|
| it fires more often than its host | extract upward, into whatever is always on |
| it activates differently — always-on vs deliberately invoked | a different home, not a sub-part |
The Signals
- Needed twice already in the work in front of you.
- Cost asymmetry — extracting now is nearly free; extracting once both callers exist is not.
When It Fires
| Time | Outcome |
|---|---|
| charter | name the pieces; the human chooses the split |
| authoring | stop and say so — cheaper than a judge finding it three rounds later |
| verdict | SPLIT — returns to the charter, not to the author |
Never silently build several things under one name.
Examples
See examples.md.