| name | prog-review |
| description | First-principles review — question requirements, delete unnecessary parts, simplify, optimize with evidence, automate last. Use for code review, refactor, performance, or architecture. |
| execution | direct |
Programming Refactor Review
Apply this order unless the user asks for a narrow task:
- Question the requirement — identify the real need. Flag vague, inherited, untested, or likely obsolete requirements.
- Delete before improving — look for features, branches, abstractions, passes, dependencies, or process steps to remove.
- Simplify what remains — reduce state, control flow, duplication, indirection, and conceptual load.
- Speed it up with evidence — profiling, better algorithms, better data structures, fewer I/O passes, concurrency — only after steps 1–3.
- Automate stable parts — tests, linters, CI, benchmarks — only for workflows that survived the earlier steps.
Response Pattern
For substantial reviews:
- Verdict: delete / simplify / optimize / automate — one line.
- Question requirements: assumptions to challenge; questions that affect the solution.
- Delete candidates: what can likely be removed and why; include a safety check (call-site search, test to run, log to inspect).
- Simplify next: refactor ideas that reduce states, branches, representations, or passes.
- Optimize only after that: evidence needed, profiling plan, algorithmic changes.
- Automate last: tests, CI, benchmarks, or deployment automation.
- Suggested next patch: specific code or steps when enough context is available.
For small snippets or quick questions, compress to the few sections that matter most.
Triage
Classify before answering:
- Feature request — challenge need and scope before design.
- Bug report — preserve reproducibility before deleting code.
- Refactor request — deletion and simplification before rewriting.
- Performance request — propose profiling before optimization.
- Automation request — check stability and necessity before automating.
Heuristics
Requirement questions to ask or infer
- What exact input/output contract must be preserved?
- Which callers depend on this behavior?
- What happens if the feature, parameter, or branch is removed?
- Is the requirement based on measured need, old compatibility, speculation, or convenience?
Delete candidates (prioritize)
- Dead code, unused flags, unused configuration.
- Duplicated logic and parallel implementations.
- Abstractions with one implementation and no extension pressure.
- Compatibility hacks without a current supported consumer.
- Defensive branches that hide invalid states instead of preventing them.
- Dense materialization, intermediate files, repeated parsing, extra passes.
Simplification targets
- Smaller functions with explicit contracts.
- Fewer mutable shared states.
- Data structures that match the problem directly.
- One source of truth for derived values.
- Plain control flow over clever abstractions.
For bioinformatics/data pipelines: unnecessary dense arrays, redundant coordinate conversions, repeated BAM/FASTA parsing, avoidable decompression, repeated scans, accidental O(n²).
Optimization hierarchy
- Remove the work.
- Reduce input size or number of passes.
- Choose a better algorithm.
- Choose a better data representation.
- Reduce allocation/copying/I/O.
- Add parallelism or native extensions.
- Micro-optimize syntax or hot loops.
Use measured language: "likely," "profile to confirm," "this is a bottleneck if…"
Automation fit
Automate when: workflow is repeated, output is well-defined, failure can be detected, process is stable.
Do not automate: workarounds, unclear processes, designs still being questioned.
Review Checklist
Requirement quality: testable? describes outcome not implementation? edge cases defined? backward compat truly required? evidence users need this?
Deletion safety: before recommending deletion, identify one validation method — search call sites, check telemetry/logs, run test suite, add a temporary deprecation path, compare output on fixtures, run before/after benchmarks.
Simplification quality: good when it reduces at least one of — states, branches, representations of the same concept, passes over data, configuration combinations, ways an invariant can be violated.
Optimization evidence: benchmark plans should include realistic input sizes, warm-up rules, memory as well as runtime, correctness comparison against baseline, worst-case and typical-case inputs, clear success threshold.
Output Style
Be direct. Show the highest-leverage deletion or simplification first. Provide concrete patches or pseudocode when feasible. Distinguish correctness issues, maintainability issues, performance risks, and automation opportunities.
The five steps are a strict ordering discipline, not motivational advice.
