ownership-driven-ai-customization-architecture: Skill for Claude Code

ODA Copilot Customization

Use this skill to keep a repository's Copilot customization healthy, current, and professionally reasoned.

The goal is not merely to remove the nearest inconsistency. The goal is a healthy customization map that respects local repository rules, ODA, the latest official Copilot docs, and the repository's desired level of control without overengineering.

Requested Outcome And Scope

Let the user's request define what this pass is for.

Requested outcomes:

• surface in-scope problems, drift, or worthwhile improvements
• think through a specific problem or decision before changing anything
• resolve the requested scope and any follow-through needed to keep the result coherent

Scope:

• keep the scope as narrow as the request honestly allows
• expand scope only when a real dependency, coupled issue, or verification need would make the narrower pass misleading, incomplete, or unsafe

Let the request shape the work:

• Stay in analysis when the user wants understanding, evaluation, or discussion.
• Make changes only within the requested scope and what directly depends on it.
• For broad requests, organize the work and the output in the clearest way for that request.

Treat each use of this skill as one pass. Surface what remains directly instead of managing further passes inside the skill.

This skill must be resilient to change. The platform, its documentation, its support boundaries, and the best implementation path can all change over time. Do not overfit the review to the current wording of a page, the current product menu, or the current shape of the platform. Use stable architectural principles to drive the review, then verify what the current platform can and cannot do in practice.

Required Sources

1. ODA sources:
   • use the current upstream ODA repository directly as the authoritative source
   • repository: https://github.com/HenriqueCotta/ownership-driven-ai-customization-architecture
   • do not rely on local mirrors, archived copies, MVP snapshots, or deleted experiments as an authority for ODA
   • if the upstream ODA repository cannot be checked, treat the review as verification-blocked instead of pretending the architecture review is current
2. Official GitHub Copilot docs:
   • discover the currently relevant official docs and official change surfaces that may affect the healthiest design at review time
   • do not assume today's doc taxonomy, feature names, or mechanism list will remain stable
   • when behavior, availability, or implementation priority may have changed recently, also check the latest official product-update, release-note, changelog, or equivalent official change surface that clarifies the current behavior
   • do not treat one static docs page as sufficient proof of the current best implementation path if newer official material indicates the platform behavior changed
   • stop broadening the search once the remaining uncertainty would no longer change the decision
3. Local repository sources of truth, bridges, mirrors, and safeguards:
   • the current customization source of truth
   • any compatibility bridge
   • maintainer-facing mirrors of customization behavior
   • automated safeguards that validate or protect the customization map