domains / families / software-engineering / repo-native-refactor

repo-native-refactor

authentic

Review diffs without editing, or perform evidence-based cleanup while preserving authorized behavior, public contracts, and domain ownership.

When to use

• Use when the user asks to review a diff, branch, or PR for correctness, contract breaks, or operational risk.
• Use when the user authorizes bounded cleanup before opening a PR or asks to consolidate duplicated policy with shared ownership.
• Use for repository rehabilitation only when the user explicitly requests work across multiple domains.
• Establish review-only, edit, or combined authority before choosing the operating mode.
• **Correctness and security:** prevent regressions, avoid new security vulnerabilities, handle boundary conditions.
• **Semantic integrity:** preserve existing invariants, state transitions, validation, and error boundaries.
• **Contracts stay as declared:** the rule lives in `references/shared-contracts.md` §1. Preserve the authorized target contract; otherwise keep exact declared types. Internal helpers are fine when exposed contracts stay exact.
• **Repository conformity:** match surrounding naming, domain conventions, and architectural precedents.

When not to use

• Review requires an identifiable comparison base and enough repository evidence to establish contracts and ownership.
• Similar syntax alone does not establish shared policy or justify consolidation.
• The skill cannot establish migration or concurrency safety without relevant requirements and verification; unresolved material uncertainty is a hard stop.
• Local checks and self-review do not establish independent review or universal reliability.
• **Clean greenfield code:** Do not refactor newly written code that is already minimal, idiomatic, and passing all tests.
• **Speculative cleanup:** If you cannot state the domain owner and the concrete maintenance consequence in a single sentence, leave the code unmodified.
• **Risk classification:** When uncertain between risk bands (such as R2 structural vs. R3 semantic), default conservatively to the higher risk band and require explicit justification.

Skill page

Source