Vanilla First

Find the smallest supported path that meets the user's outcome. Check the tool's existing capabilities and architecture before proposing custom code, while keeping operator authority distinct from another project's ownership.

Use this skill when a non-trivial implementation or architecture proposal could duplicate an existing tool capability, cross an owner boundary, depend on a specific version, or require a new integration. Keep the check brief when the fit is obvious. For a small, documented, reversible fix in an authorized repository, do the fix without a full ownership exercise.

1. Fix the requested outcome and owner

Capture the behavior the user needs, the material constraints, the exact product/repository/version when known, and who owns each affected boundary. Separate the user problem from a proposed implementation.

Use the existing issue or project record when it helps track non-trivial work; do not create one just to satisfy this skill. An ownership map is useful when several products, teams, or repositories are involved:

behavior_or_contract: <needed behavior>
product_and_repository_owner: <who owns each affected surface>
maintainer_surface: <canonical issue, documentation, maintainer statement, or unknown>
state: <documented | owner_approved | proposal | investigation | unresolved>