Skip to content
baseline-restorer logo

Baseline Restorer

baseline-restorer

Use when multiple fix attempts fail and you need to systematically restore to a working baseline and reimplement instead of fixing broken code.

TheBushidoCollective/han0installs199stars

SKILL.md

Full skill instructions

Baseline Restorer

Enforces methodical problem-solving by reverting to last known working state and reimplementing step-by-step instead of trying to fix accumulated broken changes.

Core Philosophy

Reimplement, don't fix the mess

When something breaks after multiple failed fix attempts:

  1. Stop trying to fix forward
  2. Revert to last known working state
  3. Understand what worked and why
  4. Reimplement the needed change ONE step at a time
  5. Verify each step before proceeding

When to Use This Skill

Trigger conditions

  • 2+ failed fix attempts for the same issue
  • "This should work but doesn't" situations
  • Pipeline failures persisting across multiple commits
  • User says "the old version worked fine"
  • Complex accumulated changes with unclear impact

Red flags requiring this skill

  • Making assumptions about root cause without verification
  • Blaming "pre-existing issues"
  • Adding more changes to fix previous changes
  • Not testing locally before committing

Systematic Process

Phase 1: Identify Working Baseline

# Find last known working state
git log --oneline -20
git show origin/​beta:path/​to/​file.sh  # Check beta/​main branch
git diff origin/​beta -- path/​to/​file.sh  # What changed?

# Verify baseline works
git stash
git checkout origin/​beta -- path/​to/​file.sh
# Test it - does it work?

Questions to answer

  • What was the last commit where this worked?
  • What branch has a working version? (beta, main, prod)
  • What specific files/​scripts were working?

Phase 2: Compare Current vs Baseline

# Get exact differences
git diff baseline..current -- path/​to/​file.sh

# Understand each change
# For EACH diff hunk, ask:
# - Why was this changed?
# - What problem was it trying to solve?
# - Did it actually solve that problem?

Document findings

  • List every change made
  • Note which changes were necessary
  • Note which changes broke things
  • Identify assumptions that were wrong

Phase 3: Revert to Baseline

# Hard revert to working state
git checkout origin/​beta -- path/​to/​file.sh
git add path/​to/​file.sh
git commit -m "Revert to working baseline from beta"

# Verify baseline works
./​test-locally.sh
# Must pass before proceeding

Critical: Don't proceed until baseline is verified working.

Phase 4: Reimplement ONE Change at a Time

For each needed change

  1. Make ONE small change

    # Example: Replace sed with awk in ONE function
    # Don't change 5 things at once
    
  2. Test locally immediately

    ./​run-generation-script.sh
    terraform validate
    # Must pass before committing
    
  3. Commit if working

    git add changed-file.sh
    git commit -m "Replace sed with awk in function X"
    
  4. If it breaks, revert immediately

    git reset --hard HEAD~1
    # Try different approach or understand why it broke
    
  5. Repeat for next change

Phase 5: Verify Complete Solution

# Run full test suite
make test
terraform validate

# Compare with original broken state
# Did we achieve the goal without breaking things?

# Push only after local verification
git push

Verification Checklist

Before committing ANY change:

  • Tested locally and passes
  • Compared output with baseline (no unexpected differences)
  • Understood why this change is needed
  • Change is minimal and focused
  • Can explain what would break if this change was wrong

Anti-Patterns to Avoid

DON'T

  • ❌ "Let me try one more fix" (revert instead)
  • ❌ "This is probably a pre-existing issue" (verify with baseline)
  • ❌ "The logic should work" (test it, don't assume)
  • ❌ Change 5 things and hope one fixes it
  • ❌ Commit without local verification
  • ❌ Blame the user's code/​environment

DO

  • ✅ "Let me check what worked in beta"
  • ✅ "Reverting to baseline first"
  • ✅ "Testing this one change locally"
  • ✅ Make ONE change, verify, commit
  • ✅ Test before every commit
  • ✅ Take responsibility for breakage

Examples

Example 1: Terraform Generation Scripts

Broken approach (Example 1)

# Made 10 changes trying to "optimize" variable filtering
# Each fix broke something new
# Spent day+ debugging

Baseline approach (Example 1)

# Check beta branch - does it work?
git show origin/​beta:terraform/​build-module.sh > /​tmp/​beta-version.sh
bash /​tmp/​beta-version.sh  # Verify it works

# Revert to beta version
git checkout origin/​beta -- terraform/​build-module.sh

# Now reimplement ONLY what's needed (e.g., sed→awk for portability)
# One function at a time, test each change

Example 2: Pipeline Failures

Broken approach (Example 2)

# Assume it's a CI environment issue
# Try 5 different "fixes" based on guesses
# Each creates new errors

Baseline approach (Example 2)

# Find last passing pipeline
git log --oneline | head -20
# Check what changed since then
git diff <last-passing-commit>

# Revert suspicious changes
# Test locally before pushing

Commands

# Find working baseline
git log --oneline --all | grep "known working feature"
git show origin/​beta:path/​to/​file

# Compare with baseline
git diff origin/​beta -- path/​to/​file
git diff <working-commit> -- path/​to/​file

# Revert to baseline
git checkout origin/​beta -- path/​to/​file
git checkout <working-commit> -- path/​to/​file

# Test locally
terraform validate
mix test
yarn test

# Verify no changes after running script
git diff  # Should be empty if script is idempotent

Remember

  • Reimplement, don't fix - Start from working state
  • One change at a time - Test each change immediately
  • Local verification first - Never commit untested changes
  • Baseline is truth - If baseline works, your changes broke it
  • Stop digging - After 2 failed fixes, revert and rethink
  • Question assumptions - Verify, don't assume
  • Take responsibility - Your changes, your bugs

More skills from TheBushidoCollective

typescript-utility-types logo
TheBushidoCollective/han

typescript-utility-types

Use when typeScript utility types, mapped types, and advanced type manipulation. Use when creating flexible, type-safe TypeScript code.

199 0
View
shell-portability logo
TheBushidoCollective/han

shell-portability

Use when writing shell scripts that need to run across different systems, shells, or environments. Covers POSIX compatibility and platform differences.

199 0
View
tailwind-performance logo
TheBushidoCollective/han

tailwind-performance

Use when optimizing Tailwind CSS for production, reducing bundle size, and improving performance. Covers PurgeCSS, JIT mode, and build optimization.

199 0
View
figma-generate-component logo
TheBushidoCollective/han

figma-generate-component

Generate production-ready code from a Figma component or frame using the Figma MCP server

199 0
View
dialyzer-integration logo
TheBushidoCollective/han

dialyzer-integration

Use when integrating Dialyzer into development workflows and CI/CD pipelines for Erlang/Elixir projects.

199 0
View
rubocop-configuration logo
TheBushidoCollective/han

rubocop-configuration

Use when ruboCop configuration including YAML config, departments, inheritance, and customization.

199 0
View
elixir-otp-patterns logo
TheBushidoCollective/han

elixir-otp-patterns

Use when Elixir OTP patterns including GenServer, Supervisor, Agent, and Task. Use when building concurrent, fault-tolerant Elixir applications.

199 0
View
ameba-custom-rules logo
TheBushidoCollective/han

ameba-custom-rules

Use when creating custom Ameba rules for Crystal code analysis including rule development, AST traversal, issue reporting, and rule testing.

199 0
View
Swift Optionals Patterns logo
TheBushidoCollective/han

Swift Optionals Patterns

Use when swift's optional handling patterns including optional binding, chaining, nil coalescing, and modern approaches to safely working with optional values while avoiding common pitfalls and force unwrapping.

199 0
View
code-annotation-patterns logo
TheBushidoCollective/han

code-annotation-patterns

Use when annotating code with structured metadata, tags, and markers for AI-assisted development workflows. Covers annotation formats, semantic tags, and integration with development tools.

199 0
View
Scala Collections logo
TheBushidoCollective/han

Scala Collections

Use when scala collections including immutable/mutable variants, List, Vector, Set, Map operations, collection transformations, lazy evaluation with views, parallel collections, and custom collection builders for efficient data processing.

199 0
View
reactflow-custom-nodes logo
TheBushidoCollective/han

reactflow-custom-nodes

Use when creating custom React Flow nodes, edges, and handles. Covers custom node components, resizable nodes, toolbars, and advanced customization.

199 0
View

Popular AI tools

Kaiber logo
Video

Kaiber

Generate, edit, and beat-sync AI video with leading models in one workspace.

Paid
View
Vimcal logo
Productivity

Vimcal

The world's fastest calendar for remote work

Free
View

Transform Your Design with AI Designer by ImgCreator.ai

Freemium
View
Akool AI logo
Content & writing

Akool AI

Revolutionizing Video Production with AI-Powered Creativity

Paid
View

Extend an image past the frame and let AI fill the new aspect ratio.

Freemium
View
StarByFace logo
Security

StarByFace

Discover your celebrity doppelgänger with StarByFace!

Free
View
C

ChainClarity explains 700+ crypto whitepapers in plain English, with layered summaries, comparisons, research tools, alerts, and a $4.99 Pro plan.

Freemium
View
Opus Clip logo
Coding & apps

Opus Clip

Opus.ai: Revolutionize Your Web Experience

Free
View