@laitszkin/apollo-toolkit 3.12.0 → 3.13.0

package/iterative-code-quality/references/job-selection.md

@@ -1,78 +0,0 @@
-# Job Selection Guide
-
-## Purpose
-
-Help the agent choose the next execution direction after each full-codebase re-scan.
-
-These are job-selection rules for Step 2 of the main skill loop. They are not workflow steps.
-
-The goal is not to force one permanent order. The goal is to choose the next job that most safely improves the selected module or module cluster and unlocks later work.
-
-Before choosing, the agent should first scan the selected module through every available job lens. Job selection happens after that scan; it is not a substitute for that scan.
-
-## Available jobs
-
-- naming cleanup
-- function simplification / extraction
-- module-boundary cleanup
-- logging alignment
-- test addition
-- staged unlock work
-
-## Choose `naming cleanup` when
-
-- confusing names are the main thing blocking understanding,
-- flags, units, lifecycle states, or ownership terms are misleading,
-- better naming would clearly reduce the risk of a later deeper refactor.
-
-## Choose `function simplification / extraction` when
-
-- duplicated logic exists across multiple call sites,
-- one function mixes too many concerns,
-- control flow is currently the main complexity bottleneck,
-- extracting a helper would make the next test or split easier.
-
-## Choose `module-boundary cleanup` when
-
-- one file or module clearly has multiple reasons to change,
-- local responsibilities are already visible enough to separate,
-- a safe split would reduce repeated touching of unrelated concerns.
-
-## Choose `logging alignment` when
-
-- stale or missing diagnostics are the main blocker to safe validation,
-- later refactors would be safer if branch decisions and outcomes were easier to observe,
-- observability drift is currently hiding the real ownership model.
-
-## Choose `test addition` when
-
-- the target area is high-risk and weakly guarded,
-- desired cleanup is blocked mainly by missing behavior locks,
-- coupling spans multiple modules and needs characterization before change,
-- regression risk is too high to justify deeper refactors without stronger coverage.
-
-## Choose `staged unlock work` when
-
-- the file feels too central or too coupled for direct cleanup,
-- no safe full refactor exists yet, but a preparatory step does,
-- you can reduce risk through naming, seam extraction, type extraction, side-effect isolation, or caller grouping,
-- the best next move is to make a future refactor cheaper rather than solve the whole area now.
-
-## Tie-breakers
-
-If multiple jobs are plausible, prefer the one that:
-
-1. increases safety for the next iteration,
-2. reduces cognitive load fastest,
-3. removes the strongest blocker to a deeper future refactor,
-4. helps an unvisited module reach deep-read coverage,
-5. matches the agent's self-assessed ability to understand, execute, and repair the change under current evidence,
-6. preserves behavior with the clearest available guardrails.
-
-## Hard rule
-
-If a high-risk area lacks enough guardrails, `test addition` or another guardrail-building job should usually win before a deeper structural refactor.
-
-If the area is difficult but the agent can explain the behavior, affected contracts, rollback path, and available tests clearly, do not downgrade confidence just because the refactor is non-trivial. Strong guardrails mean accidental breakage should be repaired by returning the test suite to green, not avoided by leaving an actionable quality issue in place.
-
-If any in-scope module remains unvisited, choose jobs that help the next easiest useful unvisited module become deeply read, improved, or validated-clear before spending another round on already-familiar areas.

package/iterative-code-quality/references/logging-alignment.md

@@ -1,67 +0,0 @@
-# Logging Alignment And Missing Observability
-
-## Purpose
-
-Keep logs and diagnostics synchronized with the real code path while preserving behavior.
-
-## Stale log signals
-
-Update logs when they:
-
-- mention retired owners, lifecycle stages, resource names, or field names,
-- describe a branch that no longer matches the condition,
-- use generic text like `failed` without the operation or reason,
-- report aggregate success without identifiers that let operators reconcile details,
-- keep compatibility-era names after code has moved to a new canonical model,
-- conflict with structured field names or metrics in the same path.
-
-## Missing log criteria
-
-Add logs only where they answer a concrete debugging question.
-
-High-value locations:
-
-- workflow start and final outcome for long-running jobs,
-- branch selection or skipped work with reason code,
-- validation rejection with safe context,
-- external dependency outcome including status class, retry count, request id, and latency when available,
-- persistence side effect or emitted command,
-- rollback, compensation, idempotency, duplicate, or replay decisions.
-
-Low-value locations:
-
-- every line of a tight loop,
-- logs that only restate the function name,
-- dumping raw payloads,
-- duplicating an exception already logged with equal context,
-- noisy success logs in hot paths without operational value.
-
-## Structured field rules
-
-- Reuse the project's existing logger, field naming, metric naming, and trace conventions.
-- Prefer stable identifiers, counts, reason codes, status classes, and lifecycle stages.
-- Keep field names aligned with canonical owners, not stale compatibility projections.
-- Do not log secrets, tokens, private keys, passwords, raw personal data, or full sensitive payloads.
-- Avoid high-cardinality values unless they are necessary identifiers already used by the project.
-
-## Behavior-neutral updates
-
-Logging changes must not:
-
-- alter retry, error, persistence, or branch behavior,
-- swallow exceptions,
-- add blocking network calls,
-- create expensive serialization in hot paths,
-- change public output unless logs are the product output.
-
-## Tests
-
-Add or update tests when:
-
-- the project already captures logs in tests,
-- branch-specific reason codes matter,
-- stale field names were renamed,
-- extracted helpers need observability contracts,
-- aggregate and detail telemetry must stay reconcilable.
-
-Assert stable fields and event names, not timestamps or full formatted strings.

package/iterative-code-quality/references/module-boundaries.md

@@ -1,83 +0,0 @@
-# Module Boundary And Single Responsibility Refactoring
-
-## When to split a module
-
-Split only when the module has multiple independent reasons to change, such as:
-
-- domain rules mixed with IO, formatting, CLI parsing, or external service calls,
-- unrelated workflows sharing one file because of history, not ownership,
-- test setup forced to instantiate unrelated dependencies,
-- large files where local changes frequently touch distant concepts,
-- circular or awkward imports caused by unclear ownership,
-- logging, validation, persistence, and presentation all living in one function or class.
-
-## Before splitting
-
-Define:
-
-- the current module's actual responsibilities,
-- the target responsibility of each new module,
-- which module owns the canonical business rule,
-- which interfaces must remain stable,
-- which tests prove behavior did not change.
-
-## Macro architecture boundary
-
-For this skill, `macro architecture` means the whole system's runtime shape and operating model, such as:
-
-- major subsystems and their top-level responsibilities,
-- deployment/runtime boundaries,
-- persistence model and data ownership model,
-- inter-service or inter-process boundaries,
-- the overall execution logic by which the system operates end to end.
-
-The following do **not** count as macro-architecture changes by themselves:
-
-- moving logic between ordinary internal modules,
-- extracting helpers,
-- splitting a mixed-responsibility file into narrower local modules,
-- clarifying call boundaries inside one subsystem,
-- replacing duplicated local control flow with a shared internal abstraction.
-
-Treat those changes as ordinary refactoring work unless they also alter the top-level system model above.
-
-Large coupled or central files should therefore be treated as decomposition problems, not as automatic macro-architecture blockers. If the top-level system model remains intact, prefer staged internal cleanup over stopping.
-
-## Safe split patterns
-
-- Move pure domain logic into a domain-owned helper module.
-- Move external adapter code into an integration or infrastructure-adjacent module if the repository already uses that boundary.
-- Move formatting/reporting away from computation.
-- Move test helpers into existing test utility locations rather than production modules.
-- Keep orchestration modules thin: validate inputs, call owners, handle outcomes.
-
-## Interface design
-
-Use narrow interfaces:
-
-- pass only data the callee needs,
-- return explicit result objects or existing domain types,
-- avoid leaking framework/request/database objects into pure domain modules,
-- preserve existing error taxonomy,
-- keep naming aligned with current project vocabulary.
-
-## Anti-patterns
-
-Avoid:
-
-- creating a generic `utils` dumping ground,
-- moving code only to reduce file length,
-- adding new layers that duplicate existing architecture,
-- introducing dependency injection frameworks or service locators without explicit approval,
-- splitting tightly coupled state machines before defining the state owner,
-- changing public boundaries during a cleanup pass.
-
-## Validation checklist
-
-After a split:
-
-- imports remain acyclic or no worse than before,
-- public entrypoints still call the same behavior,
-- tests cover moved logic and orchestration glue,
-- logs still carry the same correlation identifiers,
-- docs or `AGENTS.md/CLAUDE.md` are updated only if the visible architecture or command surface changed.

package/iterative-code-quality/references/module-coverage.md

@@ -1,126 +0,0 @@
-# Module Coverage And Deep-Read Iterations
-
-## Purpose
-
-Prevent the agent from repeatedly improving only familiar or easy files while untouched modules remain unexamined.
-
-Use this reference in Step 1 to build the module inventory and in Step 2 to choose which module or module cluster receives the next deep-read iteration.
-
-Deep-read here does not mean generic reading. It means scanning the module through each available job lens so the agent can identify whether naming cleanup, simplification, module-boundary cleanup, logging alignment, test addition, or staged unlock work is justified.
-
-## Module inventory
-
-List every meaningful in-scope module before completion. A module may be:
-
-- a package, app, service, route group, command group, worker, or library,
-- a domain folder with a clear responsibility,
-- a runtime entrypoint plus its owned helpers,
-- a testable subsystem with stable callers and contracts.
-
-Record each module with:
-
-- module name and path roots,
-- primary responsibility,
-- entrypoints and public interfaces,
-- key callers and callees,
-- tests and guardrails,
-- logging or telemetry surfaces,
-- risk level and estimated ease,
-- current coverage status.
-
-Exclude generated, vendored, lock, build-output, snapshot, fixture-only, or explicitly out-of-scope areas only with evidence.
-
-## Coverage ledger statuses
-
-Use simple statuses so stopping conditions are auditable:
-
-- `unvisited`: inventoried but not deeply read yet.
-- `deep-read`: callers, callees, tests, logs, contracts, core files, and all available job lenses were inspected with enough context to judge quality.
-- `refactored`: at least one behavior-neutral improvement landed for this module.
-- `validated-clear`: deep read found no actionable in-scope quality issue worth changing now.
-- `deferred`: an issue exists but is blocked, unsafe, speculative, approval-dependent, or requires macro-architecture/product scope.
-- `excluded`: not human-maintained source or outside the user's requested scope.
-
-Completion is not allowed while any in-scope module remains `unvisited`.
-
-## Easy-first module ordering
-
-Start with the easiest useful modules when that reduces risk:
-
-- small surface area,
-- clear ownership,
-- local tests or cheap guardrails,
-- limited side effects,
-- low public API or persistence risk,
-- likely to clarify names, tests, boundaries, or seams used by harder modules.
-
-Do not confuse easy-first with low-value churn. The chosen module should either resolve real quality issues or create context/guardrails that make later modules safer.
-
-If multiple modules are equally easy, prefer the one that unlocks harder modules by improving shared naming, helpers, tests, logging, or dependency seams.
-
-## Deep-read requirements
-
-A module iteration is not deep-read until the agent inspects:
-
-- module entrypoints and public interfaces,
-- internal core files and responsibility boundaries,
-- key callers and downstream callees,
-- tests, fixtures, mocks, and validation commands,
-- logs, metrics, tracing, and error messages,
-- configuration, persistence, and external-service contracts when relevant,
-- known TODOs, comments, or docs that describe current behavior.
-
-It also must inspect the module through each available job lens:
-
-- `naming cleanup`: are names hiding ownership, units, state, lifecycle, or intent?
-- `function simplification / extraction`: are there duplicated flows, hard-coded orchestration paths, or overly mixed functions?
-- `module-boundary cleanup`: are responsibilities mixed in ways that can be split safely?
-- `logging alignment`: are logs stale, misleading, or missing at important branch/outcome points?
-- `test addition`: are important behaviors, edges, or invariants weakly guarded?
-- `staged unlock work`: if the module is too coupled for direct cleanup, what is the next smaller unlock step?
-
-Do not mark a module `validated-clear` from a shallow file skim.
-Do not mark a module `validated-clear` until every available job lens has been checked and classified as one of: actionable now, unlock-first, deferred, excluded, or no meaningful issue found.
-
-## Choosing the next module
-
-After every iteration:
-
-1. Re-scan the module ledger.
-2. Prefer an `unvisited` module unless a just-touched module must be stabilized before moving on.
-3. Choose the easiest useful `unvisited` module that can be deeply read and improved or validated now.
-4. Scan that module through every available job lens before deciding what "this round" means.
-5. If the next unvisited module is high-risk and under-guarded, choose guardrail-building jobs first.
-6. If the next unvisited module is too coupled for direct cleanup, choose staged unlock work rather than skipping it.
-7. Return to the full-codebase scan after validation and update the ledger.
-
-Revisiting a familiar module is valid only when:
-
-- it blocks safe deep reading of an unvisited module,
-- a previous refactor created follow-up drift that must be stabilized,
-- validation exposed a real defect or stale contract,
-- cross-module cleanup requires touching it together with the next module.
-
-## Module cluster iterations
-
-One iteration may cover a small cluster of modules when they share one boundary or invariant, such as:
-
-- a command and its parser,
-- a route and its service,
-- a domain module and its test helpers,
-- an integration wrapper and its local fake.
-
-Keep clusters bounded. Do not use clustering to claim full-repository coverage without deep context.
-
-## Stage-gate questions
-
-At the end of each iteration, answer:
-
-- Which module or module cluster was deeply read?
-- Which job lenses were checked, and which jobs were selected and why?
-- What quality issue was fixed, or why is the module validated-clear?
-- Which guardrails prove behavior was preserved?
-- Which modules remain `unvisited`?
-- Which module is the next easiest useful target?
-
-If any in-scope module remains `unvisited`, the correct action is to return to Step 1, not to finish.

package/iterative-code-quality/references/naming-and-simplification.md

@@ -1,73 +0,0 @@
-# Naming And Function Simplification
-
-## Naming improvements
-
-Rename only when the current name creates real ambiguity.
-
-Good rename reasons:
-
-- hides domain role, unit, quantity, ownership, or lifecycle stage,
-- uses stale terminology after a refactor,
-- collides with another concept in the same scope,
-- makes boolean, enum, or state-transition meaning unclear,
-- forces readers to inspect implementation before understanding intent.
-
-Avoid renaming when:
-
-- the name is already clear in local context,
-- the change is pure personal preference,
-- the name is part of a stable external API, database schema, event contract, or migration-sensitive field,
-- the rename would create broad churn without reducing ambiguity.
-
-## Naming patterns
-
-- Prefer domain nouns over implementation nouns: `selectedAccount` over `item`.
-- Include units for quantities: `timeoutMs`, `amountCents`, `windowDays`.
-- Use booleans that read as predicates: `isEligible`, `hasPendingRetry`, `shouldPersist`.
-- Name collections by contents: `pendingInvoices`, not `list`.
-- Name state transitions by lifecycle: `markSettlementComplete`, not `updateStatus`.
-- Keep test data names meaningful: `expiredSubscription`, `duplicateEvent`, `unauthorizedActor`.
-
-## Function simplification signals
-
-Simplify functions that contain:
-
-- repeated guard clauses or duplicated validation,
-- mixed parsing, validation, orchestration, persistence, and formatting,
-- nested branches that hide the main path,
-- temporary variables whose names encode implementation steps rather than domain state,
-- hard-coded workflow steps repeated in multiple callers,
-- comments explaining what code structure should make obvious.
-
-## Safe simplification moves
-
-- Extract pure transformations and validations into small helpers.
-- Replace repeated literal mappings with a named table or function.
-- Flatten nested conditionals with explicit guard clauses when it clarifies failure paths.
-- Centralize one business rule behind one function when multiple callers duplicate it.
-- Split orchestration from local computation when tests need a deterministic unit.
-- Delete dead compatibility paths only when reachability evidence and tests support deletion.
-
-## Extraction rules
-
-Create a reusable helper only when at least one condition is true:
-
-- two or more call sites duplicate the same rule,
-- the extracted logic has a clear domain name and stable contract,
-- the helper makes a high-value invariant testable,
-- the helper isolates an external dependency contract or side-effect boundary,
-- the current function has multiple reasons to change.
-
-Keep extracted helpers close to the owner module unless the repository already has a shared utility location for that domain.
-
-## Behavior preservation checklist
-
-Before and after simplification, verify:
-
-- inputs, outputs, exceptions, side effects, and ordering are unchanged,
-- persisted data and emitted events keep the same contract,
-- public API and CLI behavior remain stable,
-- log fields remain compatible unless stale names were intentionally corrected,
-- existing tests still pass and new tests cover extracted rules.
-
-If these checks can be enforced by existing or newly added tests, do not treat subjective confidence alone as a reason to avoid the simplification.

package/iterative-code-quality/references/repository-scan.md

@@ -1,65 +0,0 @@
-# Repository Scan And Backlog Selection
-
-## Purpose
-
-Build a factual map before changing code, then choose the highest-value quality improvements while tracking module-by-module job-oriented deep-read coverage.
-
-## Required scan
-
-- Read `AGENTS.md/CLAUDE.md`, `README*`, project docs, manifests, task runners, CI configs, and test setup.
-- List entrypoints: CLI commands, servers, workers, jobs, frontend routes, scripts, libraries, or public packages.
-- Identify core domain modules, external integrations, persistence boundaries, logging utilities, and test helpers.
-- Create a module inventory and coverage ledger using `references/module-coverage.md`.
-- For each module, scan through the available job lenses instead of treating scan as generic code reading.
-- Inspect current git state before editing so unrelated user changes are not overwritten.
-- Identify generated, vendored, lock, snapshot, build-output, and fixture files; exclude them from refactoring unless they are human-maintained source.
-
-## Code quality backlog signals
-
-Prioritize files or functions with:
-
-- high fan-in or many call sites,
-- critical business rules or money/security/data-integrity decisions,
-- duplicated condition trees, conversions, validation, or external-call choreography,
-- unclear naming around ownership, units, state, or lifecycle,
-- large functions that mix parsing, validation, orchestration, side effects, and formatting,
-- log messages that describe old concepts or omit branch/failure context,
-- low or missing tests around meaningful invariants and edge cases.
-
-## Evidence to capture
-
-For each candidate record:
-
-- file path and symbol name,
-- owning module or module cluster,
-- job lens that exposed the issue,
-- observed quality problem,
-- why it matters to maintainability or correctness confidence,
-- expected behavior-neutral change,
-- tests or validations needed to prove safety,
-- reason to defer if the candidate requires product or architecture approval.
-
-## Exclusion rules
-
-Do not refactor:
-
-- third-party, generated, or compiled artifacts,
-- snapshots where churn would hide signal,
-- code the user marked as actively edited elsewhere,
-- public schema/API names that require migration planning,
-- areas that cannot be validated and are not causing a clear quality risk.
-
-## Backlog scoring
-
-Prefer a small set of high-confidence improvements over an exhaustive sweep.
-
-Score each candidate by:
-
-1. **Impact**: criticality, call frequency, future change risk.
-2. **Confidence**: evidence that the change is behavior-neutral.
-3. **Validation**: ability to test or otherwise prove equivalence.
-4. **Blast radius**: number of modules, public contracts, and migrations affected.
-
-Start with high-impact, high-confidence, low-blast-radius items. Escalate broad changes only when smaller passes cannot resolve the root problem.
-
-Do not finish from backlog scoring alone. Completion also requires the module coverage ledger to show that every in-scope module has been deeply read and either improved, validated-clear, deferred, or excluded with evidence.

package/iterative-code-quality/references/testing-strategy.md

@@ -1,95 +0,0 @@
-# Risk-Based Testing Strategy
-
-## Principle
-
-Choose tests from the risk inventory, not from a generic coverage target.
-
-For every non-trivial pass, ask what could regress silently if the cleanup were wrong.
-
-Use the resulting guardrails aggressively: when tests or equivalent verification can prove behavior preservation, they should unlock bolder refactors rather than merely justify small cosmetic edits.
-
-Confidence decisions must include the agent's own ability to understand and complete the refactor, not only the apparent difficulty of the code. Strong tests, characterization coverage, narrow rollback points, and clear validation commands are objective support: if the refactor breaks behavior, the agent should use the failing guardrails to repair the true owner and return the suite to green instead of treating the task as impossible.
-
-Do not require pre-existing tests before every refactor. Instead:
-
-- if existing guardrails are already sufficient, proceed;
-- if the area is high-risk and guardrails are weak, add the smallest high-value tests first and treat that as progress toward the refactor.
-
-The intended end state is not merely "some tests passed for touched files". The refactor is complete only when the relevant guarded test surface for the repository remains green after the cleanup.
-
-## Unit tests
-
-Use for:
-
-- extracted helpers,
-- renamed or simplified business rules,
-- validation and rejection logic,
-- branch-specific errors and side effects,
-- formatting or parsing boundaries.
-
-Good oracles:
-
-- exact return values,
-- exact domain state transitions,
-- exact error class or reason code,
-- emitted side effect or explicit lack of side effect.
-
-For high-risk legacy code with weak coverage, characterization-style unit tests are often the first unlock step even before the larger cleanup happens.
-
-## Property-based tests
-
-Use when logic has invariants or broad input space:
-
-- serialization or parsing round trips,
-- sorting, grouping, deduplication, aggregation,
-- authorization or eligibility predicates,
-- idempotency, retry, replay, and state-machine transitions,
-- generated mocked external-service states.
-
-Record `N/A` only with a concrete reason, such as "no generated input space; pass only renamed local variables."
-
-## Integration tests
-
-Use when the risk spans modules:
-
-- orchestration calling extracted domain helpers,
-- persistence plus domain transition,
-- API/CLI handler plus service layer,
-- logging contract across a real execution path,
-- adapter behavior with mocked external services.
-
-For external services, prefer mocks, fakes, local emulators, or recorded stable fixtures unless the real contract is explicitly under test.
-
-When risk comes from multi-module coupling rather than one local function, integration coverage is often the best guardrail to add before refactoring.
-
-## E2E tests
-
-Use only when:
-
-- the project already has reliable E2E infrastructure,
-- the path is user-critical,
-- required external services are stable, controlled, or safely mocked,
-- the same confidence cannot be gained from faster integration tests.
-
-If E2E is unreliable or too costly, add stronger integration coverage and state the reason.
-
-## Edge and adversarial coverage
-
-Consider:
-
-- null, empty, malformed, duplicate, oversized, and boundary inputs,
-- unauthorized actors and invalid transitions,
-- stale, duplicate, out-of-order, or replayed events,
-- dependency timeout, 429/500, partial response, and inconsistent response,
-- partial write, rollback, compensation, and idempotency behavior,
-- concurrency or shared-state contamination when the code is stateful.
-
-## Test hygiene
-
-- Keep tests deterministic and close to the behavior owner.
-- Prefer table-driven cases for many similar business permutations.
-- Preserve failing seeds or examples from property-based tests.
-- Do not weaken existing tests to fit the refactor.
-- If old tests asserted implementation details, rewrite them around stable behavior while preserving the business invariant.
-- Once stable guardrails exist, do not refuse a maintainability-improving refactor purely because confidence feels lower than ideal; combine self-assessed ability with the objective safety net and let the guardrails decide.
-- If stable guardrails do not yet exist for a high-risk area, create them as the next execution direction instead of treating the refactor as blocked forever.

package/merge-conflict-resolver/SKILL.md

@@ -1,46 +0,0 @@
----
-name: merge-conflict-resolver
-description: Resolve git merge conflicts using deterministic rules that preserve correct functionality. Use when branch consolidation encounters merge conflicts and needs automated resolution guidance that reads both parent versions and applies scenario-specific strategies.
----
-
-# Merge Conflict Resolver
-
-## Dependencies
-
-- Required: none.
-- Conditional: **`commit-and-push`** when the user expects the resolved tree to be **committed** or **pushed**—**MUST** run that skill for the submission leg instead of bare `git commit` / ad-hoc push when readiness gates apply.
-- Optional: none.
-- Fallback: If a **gated** submission was requested but **`commit-and-push`** is unavailable, **MUST** stop and report.
-
-## Standards
-
-- Evidence: Read both parent versions from conflict markers before resolving.
-- Execution: Read conflicts → apply scenario rules → verify with tests → recommit via **`commit-and-push`** when persisting to git.
-- Quality: Prefer preserving functionality over keeping either branch's exact changes.
-- Output: Return resolved files with passing verification.
-
-## Workflow
-
-### 1) Read conflict markers
-
-- Read both parent versions from conflict markers before editing.
-- Never use `-X ours`/`-X theirs` as the default strategy; only for narrowly justified conflicts after reading the actual content.
-
-### 2) Apply scenario rules
-
-| Scenario | Resolution |
-|----------|-----------|
-| Same line, both branches changed behavior | Read both code paths and compose merged logic preserving the verified invariant |
-| Same line, bug fix vs refactor | Keep the bug fix, reapply compatible refactor structure |
-| File deleted in one, modified in other | Keep version supported by current references/tests; delete only if proven correct |
-| Both modified same file differently | Preserve both when compatible; manually compose overlapping changes |
-| Test files conflict | Preserve both coverages unless one assertion is obsolete |
-| Config file (non-overlapping keys) | Keep both values |
-| package.json dependency | Keep higher version if compatible |
-| Same function added differently | Keep both; rename if needed |
-
-### 3) Verify after resolution
-
-- `git add <resolved-files>`
-- Run targeted tests or build checks for changed files.
-- If verification fails, resolve differently before committing.

package/merge-conflict-resolver/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "merge-conflict-resolver"
-  short_description: "Resolve git merge conflicts with deterministic, evidence-based rules"
-  default_prompt: >-
-    Use $merge-conflict-resolver to read both sides of conflict markers, apply scenario-specific resolution rules that preserve intended behavior, verify with the project’s tests or checks, and when the user needs persistence, hand off to $commit-and-push instead of ad-hoc git commands.