skills.rest
codybrom
codybromCOMMUNITY
Explore all skills by this author →
WebsiteGitHub

code-evolution

Evaluate code changes for design quality and technical debt.

11|Updated Feb 25, 2026
Search Tags:#code quality#code review#pull request#refactoring#software design#technical debt
One-click install
npx skills add https://github.com/codybrom/clairvoyance --skill code-evolution-codybrom
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-evolution
Source: https://github.com/codybrom/clairvoyance/tree/main/skills/code-evolution
Command: npx skills add https://github.com/codybrom/clairvoyance --skill code-evolution-codybrom

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps identify when changes to existing code preserve good design or introduce technical debt, duplication, special cases, and bolted-on behavior.

Core Features & Use Cases

  • Designed-In Change Review: Compare modifications against how the system would have been structured if the new requirement were considered from the beginning.
  • Technical Debt Detection: Identify incremental complexity, duplicated logic, unnecessary dependencies, parameters, flags, and stale comments.
  • PR and Refactoring Guidance: Review diffs, recently modified files, or modules and recommend focused restructuring that improves design within the current scope.

Quick Start

Ask the code-evolution skill to review the current pull request and identify changes that increase technical debt or look bolted on.

Frequently Asked Questions about code-evolution

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a pull request for technical debt and bad design?▼

Reviewing a pull request for technical debt involves evaluating code changes to determine whether they preserve software design quality or introduce incremental complexity, duplication, and bolted-on behavior, ensuring modifications feel designed-in rather than patched.

What is designed-in code change versus a patched-on modification?▼

A designed-in code change matches how the system would have been structured if the new requirement were considered from the beginning, whereas a patched-on modification degrades software design by introducing special cases, stale comments, and unnecessary dependencies.

How do I detect duplicated logic and unnecessary flags during refactoring?▼

Detecting duplicated logic and unnecessary flags during refactoring requires examining target code for incremental complexity, unnecessary parameters, and stale comments, then recommending focused restructuring that improves software design within the current scope.

Can I use automated code review to identify stale comments and complexity?▼

Automated code review can identify stale comments and complexity by evaluating code changes against good software design principles, detecting incremental complexity, unnecessary dependencies, and duplicated logic to guide focused refactoring decisions.

When should I refactor code to reduce technical debt instead of patching it?▼

You should refactor code to reduce technical debt when changes introduce bolted-on behavior, unnecessary parameters, or duplicated logic, ensuring modifications feel designed-in and preserve overall software design quality rather than degrading it.

Related Skills

Explore More Software Engineering Skills→
tobihagemanntobihagemann
399

simplify-code

Review git diffs with four agents and apply code fixes.

Community
Advanced
ccakmak60ccakmak60
1

receiving-code-review

Restate ambiguous code-review feedback and verify it against the codebase before implementing changes.

Community
Advanced
CaptainPhantasyCaptainPhantasy

dry-logic-unifier

Identify duplicated logic patterns and extract them into shared utility packages.

Community
Intermediate
DaBigHomieDaBigHomie
1

scrutinize

Review codebases for logic errors, security vulnerabilities, and edge cases.

Community
Advanced