All skills
lexler avatar

/refactoring-team

@628d2e9
by Lada Kesselerlexler/skill-factory238 stars
61

Iterative code refactoring through progressive lenses via a worker-reviewer agent team.

Use this Skill: https://skilld.dev/gh/lexler/skill-factory/refactoring-team

This session only. Nothing lands on disk.

referenceslenses04-abstraction-consistency.md

≈559 tokens on demand. Your agent reads this file only when SKILL.md points to it.

Lens: Abstraction Consistency

Functions that mix orchestration with detail, and modules solving the same kind of problem at different levels of design maturity.

The Question

Are similar problems solved at the same level of abstraction — within functions and across the codebase?

How to Spot

  • Inline detail surrounded by named operations: the squint test fails — one block looks denser or more mechanical than the lines around it
  • Sibling functions with different approaches: functions solving the same kind of problem, but one follows a clean pattern while the other hand-rolls the logic
  • Design maturity mismatch across modules: one module has clear separation of concerns while another doing the same kind of work is a flat script with everything inlined
  • Same interface tested differently: one test suite passes arguments while another patches globals to exercise the same behavior

Process

Start within functions. Blur your eyes and scan: if all lines look similar in density, the function is at one level. If a block looks denser or more mechanical, that's a level break — detail that should be behind a name.

Then zoom out. Find modules that solve the same kind of problem. Do they show the same design shape? When one has named concepts and clear boundaries while its sibling is a monolithic script, the design understanding hasn't propagated. Inconsistency breeds more inconsistency — quality erodes toward the worst example.

Trade-off

Not every extraction improves things. If the extracted function's name restates its one-line body, the extraction adds interface complexity without hiding meaningful work. A 30-line function at one consistent level is better than five shallow wrappers. And cross-file consistency only applies between modules solving the same kind of problem — domain code and glue code legitimately differ in shape.

Go Deeper

Where do sibling functions that should follow the same pattern use different approaches — recursion vs iteration, named steps vs inline logic? Where has one module matured in design while its peer remains a first draft? Where do tests reveal the inconsistency — the same interface exercised through fundamentally different mechanisms?

Source: SKILL.md on GitHub

No alerts6d3 checks · Risk SAFE
  • Gen Agent Trust Hub6d

    The skill facilitates an automated, iterative refactoring workflow using a worker-reviewer agent team. It processes local source code and executes user-provided test commands to verify changes. The skill operates using local scripts and standard development tools without any detected malicious behaviors or obfuscation.

  • Socket6d

    No alerts

  • Snyk6d

    Risk: LOW · No issues

Signed by skilld at 628d2e9. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub last month.

Steadyupdated 7 months ago
disable-model-invocation
true
argument-hint
[target-path]
Other metadata
hooks
{
  "TeammateIdle": [
    {
      "hooks": [
        {
          "type": "command",
          "command": "${CLAUDE_SKILL_DIR}/references/guard-idle-worker.sh"
        }
      ]
    }
  ]
}

README badge

README badge for lexler/skill-factory/refactoring-team