Native Tools First

Deliver the single requested outcome with the smallest justified integration of proven capabilities. “Native first” is an evidence check, not a command to make every solution small: substantial custom code is correct when current acceptance criteria and verified tool gaps require it.

Establish the boundary

Before coding:

1. Restate the outcome in one concrete, observable sentence. Treat current-ticket acceptance criteria as the definition of done.
2. Inventory relevant libraries, CLIs, platform features, standards, existing workflows, and repository utilities. Assign each responsibility to its natural owner. Inspect repository configuration and locked or installed versions before proposing replacements.
3. When native capability is uncertain or version-sensitive, check authoritative documentation for the version in use. Separate verified behavior from inference; do not design around remembered limitations.
4. Identify the smallest missing integration or glue. Explain why configuration, composition, or an existing extension point cannot supply it.
5. Separate current acceptance criteria from useful future concerns. Make the latter explicit non-goals or follow-up candidates instead of building for them now.
6. State authorization boundaries. This skill changes the technical approach, not permission: it does not authorize deployments, external writes, messages, purchases, destructive actions, or broader repository changes.
7. Forecast likely files, new dependencies, and rough change size. Use this as a drift tripwire, not a quota or a target.

When the approach involves meaningful judgment, present a compact scope gate before implementation: