Token导航 LogoToken导航TokenDH.com
研究检索权限需确认github未标认证来源可访问clear审计通过

baseline-restorer基线恢复器

Agent Skill

baseline-restorer 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

396

周安装

16

GitHub Stars

142

下载量

124
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:baseline-restorer(基线恢复器)
来源仓库:https://github.com/thebushidocollective/han
仓库路径:skills/baseline-restorer
安装命令:
npx skills add https://github.com/thebushidocollective/han --skill baseline-restorer
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/thebushidocollective/han --skill baseline-restorer

简介

用于查找、检索和筛选相关信息。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词、任务场景或来源线索快速定位候选结果时使用。
  • 可结合来源仓库、安装命令和原始 README 继续核验具体用法。
  • 安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。
  • baseline-restorer 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

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

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

28.28%
按下载量换算35

Codex

23.7%
按下载量换算29

OpenCode

17.25%
按下载量换算21

Antigravity

13.01%
按下载量换算16

windsurf

8.43%
按下载量换算10

Gemini CLI

3.52%
按下载量换算4

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

权限需确认

当前来源未能明确判断权限范围,默认进入异常复核队列。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

来源信息

继续浏览同类 Skills