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.
When & Why to Use This Skill
The Baseline Restorer is a systematic debugging and code recovery skill designed to break the cycle of failed fix attempts. It enforces a methodical 'reimplement, don't fix' philosophy by reverting software to its last known working state and applying changes incrementally. This approach eliminates technical debt accumulated during frantic troubleshooting and ensures that every modification is verified against a stable baseline, making it essential for complex software engineering and incident resolution.
Use Cases
- Persistent Pipeline Failures: Use when CI/CD builds continue to fail across multiple commits and 'fixing forward' is only introducing new, unrelated errors.
- Complex Logic Regressions: Ideal for situations where a previously functional feature breaks and multiple attempts to patch the logic have resulted in a 'messy' codebase with unclear root causes.
- Infrastructure-as-Code (IaC) Stabilization: Systematically restoring and reimplementing Terraform or configuration scripts when environment states become inconsistent or 'should work but don't'.
- Eliminating Debugging Assumptions: Forcing a verification of the 'last known good' state to determine if a bug is truly new or an overlooked pre-existing environment issue.
| name | baseline-restorer |
|---|---|
| description | Use when multiple fix attempts fail and you need to systematically restore to a working baseline and reimplement instead of fixing broken code. |
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:
- Stop trying to fix forward
- Revert to last known working state
- Understand what worked and why
- Reimplement the needed change ONE step at a time
- 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
Make ONE small change
# Example: Replace sed with awk in ONE function # Don't change 5 things at onceTest locally immediately
./run-generation-script.sh terraform validate # Must pass before committingCommit if working
git add changed-file.sh git commit -m "Replace sed with awk in function X"If it breaks, revert immediately
git reset --hard HEAD~1 # Try different approach or understand why it brokeRepeat 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