Boundary design
11 problem-shaped skills backed by 97 sourced reasoning patterns — Curie to Toulmin, as Claude Code agents. Every claim cites its source; a pre-commit gate blocks unsourced constants. Install the gates alone in 30s (zetetic-gates). The only agent system where "I don't know" is a feature.
npx -y skills add cdeust/zetetic-team-subagents --skill boundary-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Draw the line where it costs least. Use for build-vs-buy calls, "where does this module/team/service boundary belong?", APIs and abstractions forcing users into implementation vocabulary, tools that should augment rather than automate, hardcoded decisions that belong at runtime, or information nobody can find.
SKILL.md
3.0 KB, as published. Nobody here has run it
Boundary Design
Problem shape: something must be split, wrapped, or interfaced — a system into modules, a workflow between human and tool, a product between build and buy — and the current boundary leaks implementation detail, transaction cost, or cognitive load across it.
Relevant geniuses
| Agent | Use when |
|---|---|
| coase | build vs buy; team/service boundary placement — compare transaction costs across the boundary, not ideology |
| hopper | users forced to think in implementation vocabulary — build the translator; debugging under-invested; a tool defended out of familiarity |
| engelbart | "automate this" proposed where augmenting the person is the real win; the team doesn't use its own tool; design for expert ceiling, not just novice floor |
| kay | decisions hardcoded that could bind late; tight coupling via direct calls; users need to modify the system at runtime |
| alexander | decompose by misfit; the design needs a generative sequence of patterns rather than a top-down blueprint |
| simon | the system should be nearly decomposable — strong interactions inside modules, weak between; hierarchy as the default shape |
| liskov | the boundary is an interface — write the behavioral contract so implementations are substitutable |
| ranganathan | information exists but nobody can find it — faceted classification and findability laws |
Invocation
- Pick the best-fit agent above. If two or more fit, run
tools/genius-invoker.sh route "<problem>"and take the top ranked match. - Load it:
tools/genius-invoker.sh invoke <agent> "<problem>", then readagents/genius/<agent>.mdin full. - Apply the agent's
<workflow>step by step and answer in its<output-format>. Every proposed boundary states what crosses it, what it hides, and what it costs (Clean Architecture layer rules apply, §2.2). - Typical chain: coase places the boundary → simon shapes the decomposition →
liskov contracts the interface. Run via
tools/genius-invoker.sh compose coase liskov -- "<problem>". - If no shape above matches, use a standard team agent instead.
Refuse when
- The boundary is being drawn to match an org chart against the dependency evidence — surface the conflict instead of ratifying it.
- Fewer than three concrete uses exist for a proposed abstraction (coding-standards §3.3: premature abstraction is worse than duplication).