Workspace refactoring

Skill meyverick/agy-skills/skills/workspace-refactoring

A collection of elite, modular, and validated AI agent skills and system rules for Google Antigravity.

Install

npx -y skills add meyverick/agy-skills --skill workspace-refactoring

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Conducts autonomous, full-workspace structural refactoring. Use when auditing architecture, combating technical debt, or enforcing SOLID principles globally.

SKILL.md

2.7 KB, as published. Nobody here has run it

Workspace Refactoring

This skill guides the agent through an autonomous architectural audit and execution of structural refactoring. It enforces code quality improvements without altering the overarching business logic behavior.

When to Use

Use when paying down technical debt.
Use when auditing the codebase against SOLID, DRY, and KISS principles.
Use when migrating legacy file structures to Domain-Driven Design (DDD) module layouts.
NOT for adding net-new business features.

Core Process

Phase 1: Architectural Audit

Examine the workspace to identify violations of the Foundational Pillars.

SRP Violations: Look for "God classes" or files exceeding 500 lines.
Demeter Violations: Look for deeply chained method calls (a.b().c().d()).
DRY Violations: Look for copy-pasted configuration logic.

Phase 2: Define Refactoring Scope

Refactoring must be bounded.

Target a specific module or specific principle (e.g., "Extracting data access logic from the UI layer").
Do not attempt to rewrite the entire application in one pass.

Phase 3: The Boy Scout Execution

"Leave the code better than you found it."

Apply incremental changes.
If applying Dependency Inversion, define the Interface first, then implement it.
Ensure strict test coverage exists before modifying the core logic.

Phase 4: Validation

Refactoring alters structure, not behavior.

Ensure the test suite passes perfectly after the changes.

Common Rationalizations

Rationalization	Reality
"I'll just rewrite this whole file from scratch, it's easier."	Rewrites introduce massive regressions. Refactoring is defined by incremental, behavior-preserving modifications.
"I don't have tests, but I'm sure this refactor is safe."	Refactoring without a test harness is just guessing. Write the tests first.
"It works, so I shouldn't touch it."	Code rots. Continuous application of the Boy Scout Rule is required to maintain velocity.

Red Flags

Refactoring PRs that also sneak in new features.
Massive single commits deleting and adding thousands of lines without tests.
"Refactoring" that actually changes the system's observable outputs or API schema unexpectedly.

Verification

Before finalizing the refactoring session, verify:

The architectural change aligns with SOLID or DDD principles.
Existing functionality remains entirely unchanged (100% test pass rate).
Code complexity metrics (e.g., line count, cyclomatic complexity) have demonstrably decreased.

Gives 1 of the 12 instructions most refactoring skills give

Counted across 521 of the 525 authors here whose files we hold, read 2026-08-06

run tests after each changehere, and in 59 of 521, across 56 files
write tests before refactoringin 27 of 521, across 24 files
preserve external behaviorin 26 of 521, across 22 files
remove dead codein 25 of 521, across 24 files
make small incremental changesin 20 of 521, across 17 files
break the implementation into tiny commitsin 18 of 521, across 5 files
ask the user about alternative optionsin 17 of 521, across 4 files
create a GitHub issue with the planin 17 of 521, across 4 files
explore the repository to verify assertionsin 17 of 521, across 4 files
interview the user about the refactorin 16 of 521, across 3 files
check the codebase for test coveragein 16 of 521, across 3 files
refactor one thing at a timein 16 of 521, across 12 files

Said here and by no other author read

examine workspace for architectural violations
apply incremental behavior-preserving changes
ensure strict test coverage exists before modifying
reduce code complexity metrics

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.