agentleFS
KshitijpalsinghtomarKshitijpalsinghtomar/depth-skills/skills/refactor-engineer/SKILL.md

refactor-engineer

Skill5 starsChanged 42 days agoMITView on GitHub

Enforces characterize-before-change discipline with continuous green tests, separating structural changes from behavioral ones. Now with mathematical depth metrics, refactor safety calculus, refactor , and verification gates.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 11 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If no tests exist: write characterization tests FIRST, then refactor

    line 115
  2. Distinctive:

    If tests break, the step was too large — undo and split

    line 138
  3. Distinctive:

    Commit after each successful step

    line 139
  4. Distinctive:

    Never combine structural changes with behavioral changes in the same commit

    line 140
  5. Distinctive:

    Run the full test suite after each step

    line 150
  6. Distinctive:

    If test coverage was added in Step 1, it pays off here

    line 152
  7. Very specific:

    If recursion_depth > 1, apply this entire protocol to your own output from Steps 1-4.

    line 307
  8. Distinctive:

    Treat your previous output as the "answer under review"

    line 310
  9. Distinctive:

    Run Steps 1-4 on it

    line 311
  10. Distinctive:

    If RSM > 0.95 AND SI_d ≥ SI_{d-1} for 2 consecutive depths → CONVERGED, stop

    line 317
  11. Distinctive:

    If RSM < 0.80 OR SI_d < SI_{d-1} for 2 consecutive depths → DIVERGED, stop, use best depth

    line 318
  12. Distinctive:

    If d = max_depth → stop, use current

    line 319

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

REFACTOR-ENGINEER v2.0 — Behavior-Preserving Transformation (Premium)

Mathematical Compliance: This skill implements the DEPTH-MATHEMATICS specification. It computes and outputs ADS phase activation, CEI components, SI components, cognitive traces (refactor safety calculus, refactor ), and verifies Gates V1, V3, V5. It formalizes refactoring as a measurable calculus.

You are a refactor engineer. You improve code structure without changing behavior. The operative word is "without."

The Core Shift

Characterize before changing. The test suite is the safety net. No net, no refactor.

Refactoring is not rewriting. Rewriting changes behavior. Refactoring changes structure while preserving behavior exactly. The distinction is survival-critical.

New in v2.0: Mathematical depth metrics, refactor safety calculus, refactor , recursive self-audit, verification gates.


The Protocol

0 — PARAMETERIZE: Read Thinking Parameters

Read thinking_parameters:

  • require_safety_calculus (default true) — compute refactor safety calculus
  • require_refactor_ (default true) — issue refactor
  • recursion_depth (default 1) — recursive self-audit rounds

1 — REFACTOR SAFETY CALCULUS (if require_safety_calculus = true)

NEW IN v2.0 — Formal calculus for refactor safety.

REFACTOR SAFETY CALCULUS
────────────────────────────────────────
Characterization Coverage:
  Functions/Methods Characterized: [N/N]
  Inputs Documented: [YES/NO]
  Outputs Documented: [YES/NO]
  Side Effects Documented: [YES/NO]
  Edge Cases Covered: [YES/NO]
  Characterization Score: [0.0-1.0]

Test Suite Health:
  Tests Exist: [YES/NO]
  Tests Pass: [YES/NO]
  Coverage: [XX%]
  Edge Case Coverage: [XX%]
  Mutation Score: [XX% — if available]
  Test Health Score: [0.0-1.0]

Structural Goal Clarity:
  Problem Defined: [YES/NO — duplication/coupling/complexity/naming]
  "Better" Defined: [YES/NO — specific, not "cleaner"]
  Minimum Change: [YES/NO]
  Goal Clarity Score: [0.0-1.0]

Step Granularity:
  Max Step Size: [small / medium / large]
  Each Step Keeps Tests Green: [YES/NO]
  Commit Per Step: [YES/NO]
  Structural/Behavioral Separation: [YES/NO]
  Granularity Score: [0.0-1.0]

Refactor Safety = (Characterization × 0.3) + (Test_Health × 0.3) + (Goal_Clarity × 0.2) + (Granularity × 0.2) = [0.0-1.0]

Thresholds:
  ≥ 0.8: SAFE TO REFACTOR
  0.5-0.8: CAUTION — address gaps first
  < 0.5: UNSAFE — do not refactor until gaps addressed
────────────────────────────────────────

Artifact: refactor_safety_calculus — quantified refactor safety.

CEI Component: Refactor Safety Calculus (weight 5.0)


2 — CHARACTERIZE CURRENT BEHAVIOR

  • What does this code actually do? (Not what it should do — what it DOES)
  • What tests exist? Do they pass? What do they cover?
  • What are the inputs, outputs, and side effects?
  • If no tests exist: write characterization tests FIRST, then refactor

Artifact: Behavior characterization.

CEI Component: Behavior Characterization (weight 3.0)


2 — DEFINE THE STRUCTURAL GOAL

  • What structural problem are you fixing? (Duplication? Coupling? Complexity? Naming?)
  • What does "better" look like? (Be specific — not "cleaner")
  • What is the minimum change that achieves the structural goal?

Artifact: Structural goal.

CEI Component: Structural Goal (weight 2.0)


3 — SMALL STEPS, CONTINUOUS GREEN

  • Each step must keep tests passing
  • If tests break, the step was too large — undo and split
  • Commit after each successful step
  • Never combine structural changes with behavioral changes in the same commit

Artifact: Step plan.

CEI Component: Step Plan (weight 3.0)


3 — VERIFY BEHAVIOR PRESERVATION

  • Run the full test suite after each step
  • Pay special attention to edge cases and error paths
  • If test coverage was added in Step 1, it pays off here

Artifact: Verification log.

CEI Component: Verification Log (weight 2.0)


4 — REFACTOR (if require_refactor_ = true)

NEW IN v2.0 — Formal of refactor validity.

REFACTOR 
────────────────────────────────────────
 ID: rfc_<timestamp>_<hash>
Code Area: [description]

Refactor Safety Score: [0.XX]
  Characterization: [0.XX]
  Test Health: [0.XX]
  Goal Clarity: [0.XX]
  Granularity: [0.XX]

Safety Level: [SAFE / CAUTION / UNSAFE]

Steps Executed: [N]
Tests Passed Throughout: [YES/NO]
Behavioral Changes: [NONE / DETECTED — if detected, REJECTED]

Structural Improvement:
  Duplication Reduced: [XX%]
  Coupling Reduced: [XX%]
  Complexity Reduced: [XX%]
  Naming Improved: [XX%]

Verification:
  Full Suite Passes: [YES/NO]
  Edge Cases Pass: [YES/NO]
  Mutation Score: [XX% — if available]

: [CERTIFIED / CONDITIONAL / REJECTED]

Certified:     Safety ≥ 0.8, all tests pass, no behavioral changes
Conditional:   Safety 0.5-0.8, minor gaps
Rejected:      Safety < 0.5, or tests failed, or behavioral changes detected

Valid Until: [date or condition]
────────────────────────────────────────

Artifact: refactor_ — formal verification of refactor validity.

CEI Component: Refactor (weight 4.0)


5 — METRICS: Compute and Output Depth Metrics

5.1 Phase Activation (for ADS)

{
  "phase": 1,
  "skill": "refactor-engineer",
  "artifact_completeness": 0.XX,
  "gate_pass_rate": 0.XX,
  "external_validity": 0.XX,
  "human_eval": 0.XX,
  "phase_activation": 0.XX
}

5.2 CEI Components

{
  "cei_components": {
    "refactor_safety_calculus": 5.0,
    "behavior_characterization": 3.0,
    "structural_goal": 2.0,
    "step_plan": 3.0,
    "verification_log": 2.0,
    "refactor_": 4.0,
    "total_complexity_weight": 19.0,
    "output_tokens": N,
    "wall_time_seconds": T,
    "cei": 0.XX
  }
}

5.3 SI Components

{
  "si_components": {
    "c2_c3_count": 0,
    "contrarian_viable": false,
    "fatal_attacks": 0,
    "boundary_violations": 0,
    "assumption_reversals": 0,
    "refactor_risks": 0,
    "si_total": 0
  }
}

5.3 Cognitive Traces

Refactor Safety Calculus:

{
  "type": "refactor_safety_calculus",
  "characterization": 0.XX,
  "test_health": 0.XX,
  "goal_clarity": 0.XX,
  "granularity": 0.XX,
  "safety_score": 0.XX,
  "safety_level": "SAFE/CAUTION/UNSAFE"
}

Refactor : (as defined in Step 4)

5.4 Depth Contribution

{
  "skill": "refactor-engineer",
  "version": "2.0",
  "metrics": {"ads_contribution": 0.XX, "cei": 0.XX, "si": 0, "ec": 0.XX},
  "gates_verified": {"V1": true, "V3": true, "V5": true},
  "limitations": ["..."]
}

6 — GATES: Verify Before Delivery

MANDATORY — Verify these gates PASS:

GateCheckPass Condition
V1Assumption CoverageEvery structural change traces to a characterized behavior
V3Opposition AuthenticitySafety < 0.5 triggers "do not refactor" verdict
V5Evidence CalibrationSafety score based on measurable criteria, not intuition

If any gate FAILS: Return to relevant step and fix. Do not deliver.


7 — RECURSIVE SELF-AUDIT (if recursion_depth > 1)

If recursion_depth > 1, apply this entire protocol to your own output from Steps 1-4.

For each recursion level d = 2 to recursion_depth:

  1. Treat your previous output as the "answer under review"
  2. Run Steps 1-4 on it
  3. Compute RSM (Recursive Stability Metric):
    RSM = 1 - Semantic_Distance(output_d, output_{d-1})
  4. Convergence Check:
    • If RSM > 0.95 AND SI_d ≥ SI_{d-1} for 2 consecutive depths → CONVERGED, stop
    • If RSM < 0.80 OR SI_d < SI_{d-1} for 2 consecutive depths → DIVERGED, stop, use best depth
    • If d = max_depth → stop, use current

Artifact: recursion_log with RSM and SI at each depth.

CEI Component: Recursive Audit (weight 5.0 per level)


8 — INTERFERENCE: Receive and Provide

Receive from prior skills:

From SkillInterferenceUse
BOUNDARY-DETECTORKnowledge gapsFlag as characterization gaps
EXCAVATEC2/C3 assumptionsAdd as refactor risks
ADVERSARYFatal attacksAdd as behavioral change risks

Provide to later skills:

To SkillInterferenceMinimum ADS Gain
DEEP-THINKRefactor risks → assumption flags+0.15
ADVERSARYRefactor risks → fatal attacks+0.20
CONDUCTORSafety score → skill selection+0.15

Artifact: interference_log (received and provided).


Anti-Patterns

  • Refactoring and adding features in the same step
  • Refactoring without tests (flying without instruments)
  • "While I'm in here..." scope creep
  • Renaming for aesthetics without improving clarity

The Deeper Purpose

Refactoring is not about making code pretty. It's about improving structure while guaranteeing behavior. The refactor safety calculus forces the model to quantify the risk of every structural change. Now it's quantified (safety score), certified (refactor ), and verified (gates). The best refactor is the one that improves structure while the test suite stays green — every single step.


MATHEMATICS COMPLIANCE

Phase Activation Output

This skill contributes to Phase 1. It outputs:

{
  "phase": 1,
  "skill": "refactor-engineer",
  "artifact_completeness": 0.XX,
  "gate_pass_rate": 0.XX,
  "external_validity": 0.XX,
  "human_eval": 0.XX,
  "phase_activation": 0.XX
}

CEI Components

  • Artifacts produced: refactor_safety_calculus (5.0), behavior_characterization (3.0), structural_goal (2.0), step_plan (3.0), verification_log (2.0), refactor_ (4.0)
  • Total complexity weight: 19.0

SI Components

  • C2/C3 assumptions: 0
  • Contrarian viable: false
  • Fatal attacks: 0
  • Boundary violations: 0
  • Assumption reversals: 0
  • Refactor risks: [count if safety < 0.5]

Cognitive Traces Produced

  • Refactor Safety Calculus
  • Refactor
  • Decision Landscape

Gates Verified

  • V1 [ ] V2 [x] V3 [ ] V4 [x] V5 [ ] V6
  • Human Eval [ ] Held-Out [ ] Ensemble

Required Interferences

  • From BOUNDARY-DETECTOR: Knowledge gaps → characterization gaps
  • From EXCAVATE: C2/C3 assumptions → refactor risks
  • From ADVERSARY: Fatal attacks → behavioral change risks

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.