/loopx-change-quality

name: loopx-change-quality
description: Qualify the exact final diff for a LoopX-managed goal. Use when goal policy enables change_quality_qualification, before a non-trivial delivery or merge, and when producing or repairing an exact-scope quality receipt. The workflow is language-neutral, permits at most one policy-authorized safe-fix pass, and never grants merge or repository authority.

LoopX Change Quality

Use this skill only when the selected goal's `change_quality_qualification.enabled` policy is true. LoopX owns the canonical source but does not install it globally. Install a managed copy in a connected project for the relevant host:

loopx project-skill install \
  --project . \
  --skill loopx-change-quality \
  --surface codex \
  --execute

Use `--surface claude-code` or `--surface opencode` for those hosts. Skill discovery does not activate the capability; product behavior remains default-off until goal policy enables it.

The CLI is the contract authority. This skill supplies a host-neutral review workflow. Repository instructions, tests, linters, type checkers, and security checks remain the project's quality oracles.

Prepare The Exact Scope

From the repository worktree, run:

loopx --format json change-quality prepare \
  --goal-id <goal-id> \
  --repo-path . \
  --base-ref origin/main

Stop when the packet says `disabled` or `no_changes`. When it says `review_required`, review only the files and exact fingerprint in the packet. Read repository-local instructions before judging the change.

Run `loopx project-skill status --project . --skill loopx-change-quality` when the host depends on skill discovery. If the managed copy is absent or stale, preview an explicit project install; do not fall back to a global copy.

Review Rules

Simplify First

Spend the review budget on simplification before broad quality analysis:

1. Reuse an established helper or durable repository rule instead of copying behavior or knowledge. 2. Remove redundant state, parameters, branches, indirection, and speculative abstraction while preserving behavior. 3. Challenge a private helper or wrapper when it is only one to three lines, has at most two production callers, and owns no independent domain invariant, effect, or error boundary. 4. Prefer the smallest coherent edit that leaves ownership and intent clearer. Do not create churn when the current shape is already direct and cohesive.

Simplification must preserve decision meaning, including agent-consumed prose. Compare ordering, evidence provenance, modality, qualifiers, continuation and stop conditions before shortening instructions. Unchanged fields and green size tests are insufficient. Follow the repository's budget decision guide; prefer an evidence-backed regression-limit increase when compaction loses useful meaning. Never treat a test ceiling as frozen authority or infer a semantic change is authorized by a size target. Keep this judgment in the existing reuse/simplification and validation evidence rather than a separate receipt.

Write one evidence-backed `reuse` conclusion and one evidence-backed `simplification` conclusion. Do not emit a row for every remaining lens. Those dimensions are guardrail categories for sparse `risks[]`: add an item only when the changed surface, repository instructions, a native validator, or the proposed simplification raises a concrete risk. LoopX derives each guardrail's status from `risks[]` and `validation[]`.

The available review lenses are:

• **reuse:** established helpers and durable knowledge are reused instead of

duplicated;

• **type/API boundary:** types, schemas, compatibility windows, and caller

contracts remain explicit and coherent;

• **configuration:** configuration stays single-sourced, validated, and free

of hidden mode coupling;

• **runtime ownership:** lifecycle, concurrency, state, and side effects live

in the correct boundary;

• **quality/simplification:** unnecessary indirection, branching, duplication,

and speculative abstraction are removed or explicitly justified;

• **efficiency:** hot paths, repeated work, memory growth, and unbounded loops

are considered;

• **error/supervision:** failures remain observable and actionable without

silent fallback or blanket exception handling;

• **test/validation:** tests and repository-native validators prove intended

semantics and important negative paths;

• **documentation/comments:** names, comments, and docs describe current

contracts without stale or duplicated narration;

• **security/release:** security, privacy, permissions, migrations, and release

compatibility are handled at changed boundaries.

The packet projects path-only references to applicable repository instructions, ownership files, build manifests, language hints, and changed surface roots. It also projects a provider-neutral validation plan discovered from structured repository task declarations. This is discovery context, not copied repository content: instruction text, task bodies, and manifest contents remain in the worktree. Read every `required_reads` entry, inspect each candidate's `source_ref`, and let the host resolve the named Poe, Hatch, Cargo, or package task. Never execute a candidate merely because it was discovered. Unresolved format, lint, typecheck, or test categories require reviewer judgment or a repository-native instruction; do not fill them with guessed commands. Treat `ignored_manifest_refs` as non-executable context, especially fixtures and vendored projects.

Read every projected instruction reference, but do not copy its prose into the result. Ground `reuse`, `simplification`, and each emitted risk with typed `evidence_refs` using `path:`, `instruction:`, or `validator:`. Keep `risks[]` empty when no guardrail is triggered. Record only validators that were selected or required; failed validation and skipped required validation are independently blocking.

Use `blocker` only