lisa-parity-code-simplifier

name	lisa-parity-code-simplifier
description	Lisa-native, behavior-preserving…
allowed-tools	["Read","Bash","Grep","Glob","Edit","Write"]
synced-from	code-simplifier@claude-plugins-official@1.0.0

Parity Code Simplifier

Make the recently-changed code simpler and easier to maintain without changing what it does. This is a quality pass: deduplication, reuse, readability, and dead-code removal. It is explicitly not a bug hunt — if you spot a likely defect, note it for a reviewer (or parity-code-review) and leave the behavior intact.

Drift tracking. Pinned to code-simplifier@claude-plugins-official@1.0.0. scripts/plugin-parity-drift.mjs compares this pin against the upstream version in the plugin cache and flags staleness. This is a Lisa-native reimplementation written from scratch — do not port or copy upstream plugin code.

Scope: recently-changed code only

Default to the current diff, not the whole repository. Establish scope first:

git merge-base HEAD origin/main 2>/dev/null && \
  git diff --stat "$(git merge-base HEAD origin/main)"...HEAD
git diff HEAD --stat
git status --short

Simplify the files that changed and the immediate code they touch. Do not embark on a repo-wide refactor unless explicitly asked.

The prime directive: preserve behavior

Every edit must be behavior-preserving. Before changing anything, understand the current contract — inputs, outputs, side effects, error paths, public signatures. After changing it, the observable behavior must be identical. When in doubt, don't — leave a note instead of risking a semantic change.

What to simplify

1. Duplication (DRY) — Collapse copy-pasted blocks into a single function or shared helper. Prefer delegating to an existing canonical implementation over re-deriving logic (see the repo's DRY rule: a function that reproduces a sequence should call the shared generator, not reimplement it).
2. Reuse over reinvention — Search for existing utilities (Grep/Glob) before introducing new code. If the project already has a helper for what the change hand-rolls, use it.
3. Readability — Clearer names; flatten needless nesting with early returns/guard clauses; replace clever one-liners with obvious code; split overly long functions along natural seams.
4. Dead code — Remove unreachable branches, unused variables/imports/exports, and commented-out blocks introduced or exposed by the change.
5. Idiomatic constructs — Prefer immutable transformations (map/filter/reduce) over mutable accumulation where it's clearer; remove redundant intermediate state.

Respect project conventions

This repo enforces specific patterns — honor them so your simplification doesn't trip the linter or hooks:

• Immutability / functional style — avoid let and in-place mutation; prefer const and pure transformations.
• Statement order — do not place expression-statement helper calls before const definitions; inline validation as if guard clauses (exempt from enforce-statement-order).
• eslint-disable directives must include a -- description.
• Barrel-export constraint — if you delete a file referenced by an index.ts, update the barrel in the same change so lint/typecheck stays green.
• Never edit generated plugin artifacts (plugins/lisa, plugins/lisa-*); the source of truth is plugins/src/.

Workflow

1. Read each changed file and enough of its callers to know the contract.
2. Identify simplification opportunities; rank by value-to-risk. Skip anything that risks behavior.
3. Apply edits with Edit/Write, one coherent change at a time.
4. Verify behavior is unchanged — run the project's checks:

   bun run test
   bun run typecheck 2>/dev/null || true
   bun run lint 2>/dev/null || true
   

   If any check fails, fix or revert the offending edit before continuing. Never leave the tree worse than you found it.

Output

Summarize what you changed and why, grouped by file with file:line anchors:

• Simplified — the edits applied (dedup / reuse / readability / dead-code), each with a one-line rationale.
• Left alone — opportunities you deliberately skipped because they risked behavior, with the reason.
• Flagged for review — any suspected bugs noticed in passing (not fixed here — quality pass only).
• Verification — which checks you ran and that they pass.

Rules

• Behavior-preserving only. No bug fixes, no feature changes, no API changes disguised as cleanup.
• Quality only — if the only "simplification" would change behavior, don't make it.
• Tests must stay green. A simplification that breaks a test is a behavior change — revert it.
• If there is nothing worth simplifying, say so clearly rather than churning the code.