james-s-tayler-skills

Lazy Developer

Autonomously optimize every aspect of your codebase with a single command /lazy-developer or completely trash it and protect yourself from the coming AI job losses with /job-security

Introduction

Automate yourself out of a job by using Claude Code to perform multiple rounds of autoresearch in a Ralph Wiggum Loop using the GOAL.md pattern against a prioritized set of goals. First make the code safe to work with by increasing test coverage, then make it fast to work with by reducing build and test times, then make it nice to work with by improving code quality, then make it performant. All while you sleep. Because that's just where we're at on the timeline...

Too lazy to install this yourself?

It's hard work being a code monkey. Have Claude do it:

Hey Claude, what's happening?
If I could get you to go ahead and take a look at https://github.com/james-s-tayler/lazy-developer
and use it to automate myself out of a job? That'd be great. 

Installation

Add this marketplace to Claude Code:

/plugin marketplace add james-s-tayler/lazy-developer

Then install individual skills:

/plugin install <skill-name>@james-s-tayler-lazy-developer

Available Skills

autoresearch

Set up autonomous goal-driven optimization on any repo. Based on the GOAL.md pattern.

/plugin install autoresearch@james-s-tayler-lazy-developer

What it does:

1. Reads the GOAL.md spec and examples from jmilinovich/goal-md
2. Scans your project to understand what "better" means
3. Asks you what metric to optimize, the direction (minimize/maximize/target), and your constraints
4. Writes a complete GOAL.md with a runnable fitness function and scoring script
5. Asks clarifying questions about unstated constraints
6. Starts an autonomous improvement loop — measure, diagnose, act, verify, commit or revert, log, repeat

Usage:

/autoresearch

lazy-developer

Orchestrates autoresearch across a configurable sequence of optimization goals. You choose the phase priority and execution mode, and it handles the rest — writing GOAL.md files, running improvement loops, and tracking state across phases.

/plugin install lazy-developer@james-s-tayler-lazy-developer

What it does:

1. Configuration — Asks you five questions before starting:
   • Phase order — Safety First (coverage first), Speed First (build/test speed first), Clean Code First (complexity first), or Custom
   • Execution mode — Standalone (runs everything in one session) or Ralph Mode (generates artifacts for ralph to drive each phase as a separate AI instance)
   • Stopping strategy — Diminishing returns (keep going until progress stalls) or Default targets met
   • Dependency optimization — optionally vendor and optimize direct dependencies, keeping changes only if main repo metrics improve
   • Intensity — Any change is ok (quick win), Moderate (balanced), or Aggressive (maximum extraction)
2. Discovery — Scans the target codebase to understand its structure, tools, test framework, build system, and all measurable metrics
3. Sequential optimization — Works through goals in the chosen order:
   • Test Coverage — maximize coverage to make the codebase safer to modify (locks production code)
   • Test Speed — minimize test execution time for cheaper iteration cycles (locks production code)
   • Build Speed — minimize build time for faster feedback loops (locks test files)
   • Cyclomatic Complexity — reduce complexity for maintainability (locks test files)
   • Lines of Code — reduce total LOC by removing dead, duplicated, and verbose code (locks test files)
   • Performance — optimize benchmark results (locks test files)
   • Discovered metrics — any additional project-specific metrics found during discovery
4. Per-goal orchestration — for each goal, automatically writes a GOAL.md with fitness function, runs the autoresearch improvement loop until stopping conditions are met, records results, and advances to the next goal
5. State persistence — tracks progress in LAZY-DEV-STATE.md so it can resume if interrupted
6. Recursively improve dependencies (experimental) - after optimization completes, optionally proceed to vendor in direct dependencies and run autoresearch against them to see if doing so improves the current repo. I'm too lazy to actually test this mode myself. YMMV, wildly.