Editorial review pendingon version support under review
Action boundary
Before you act
- Expected result
- A one-page decision record names the smallest viable surface and rejects at least one broader alternative.
- Failure mode
- The design grants network, filesystem, browser, or write authority that the stated outcome does not require.
- Rollback
- Do not install or connect the extension; retain only the decision record and revisit the lower-authority option.
Decide before you install
Start with the job, not the integration. Write one sentence in this form: “Given bounded input, produce bounded output by reading named source, with no side effects.” If you cannot write that sentence, you do not yet have an implementation target.
Use this decision order:
- Skill — choose a reusable, local operating procedure when the work is primarily instructions and approved existing tools. It should narrow an agent’s choices, not secretly add authority.
- Native tool — choose a built-in capability when the action and policy are already part of the runtime and the input/output can be constrained.
- MCP server — choose a separately versioned external capability only when an existing tool cannot provide the needed integration. It must have an identifiable maintainer, explicit transport/configuration, permissions, and a removal path.
- Browser workflow — choose this last, when the target has no safe API and a human user interface is the actual target. Treat every page change, session, and confirmation as volatile.
A browser flow is not a shortcut around an unavailable or restricted API. If it needs a personal profile, hidden state, CAPTCHA bypass, or an irreversible click to “work,” stop and redesign.
Lab — authority gradient
For a proposed “weekly public release research” capability, make four cards: skill, tool, MCP, browser. On each card record: data read, data written, credentials, network destination, human confirmation, test target, owner, and remove/revoke action. Cross out every card whose authority exceeds the job.
A defensible answer normally begins as a read-only skill using an approved retrieval tool. An MCP server is justified only if it supplies a capability the existing tool cannot. Browser automation is justified only for a disposable public fixture in this lesson.
Checkpoint
Which design is safest for “summarise three approved public release notes and return their URLs”?
A. Browser automation logged into a maintainer account
B. A read-only skill with a URL allowlist and structured result schema
C. An MCP server that can write issues and read mail
D. A tool with unrestricted shell access
Answer: B. It has the smallest authority and an auditable source boundary. The other options introduce credentials or writes without a stated need.
Evidence to keep
Save the rejected alternatives beside the selected design. A reviewer should be able to see why a broader permission request was declined, not merely that the final choice happened to be narrow.
Lesson checkpoint
Ready to move on?
Mark this lesson complete when you can apply its outcome without relying on the examples above.