Token导航 LogoToken导航

Agent Skill · 研究检索

lift(lift 搜索)

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

lift 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证信息还不明确,第三方扫描有提醒项,按安装量在研究检索类的 73,675 个 Skill 里排第 53,604。

总安装 528周安装 22GitHub Stars 53下载 176核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

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

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

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/tkersey/dotfiles --skill lift

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

lift 用于查找、检索和筛选相关信息。适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词快速定位候选结果。通过 npx skills add 命令从指定仓库安装,需确认权限和维护状态。使用前建议核验是否会触发联网、命令执行或文件读写操作。

lift 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/lift

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/tkersey/dotfiles --skill lift;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

lift 怎么安装?

在终端执行 npx skills add https://github.com/tkersey/dotfiles --skill lift。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

lift 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

lift 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

lift 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

lift 用的人多吗?

公开数据是累计安装 528 次,近一周安装 22 次,下载 176 次,GitHub 53 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

lift 安全吗?

第三方扫描有提醒项,说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
lift

lift 搜索 · 本页

52853需要联网未明确有提醒

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Lift

Intent

Deliver aggressive, measurement-driven performance improvements (latency/throughput/memory/GC/tail) with correctness preserved and regressions guarded.

Zig CLI Iteration Repos

When iterating on the Zig-backed bench_stats/perf_report helper CLI path, use these two repos:

  • skills-zig (/Users/tk/workspace/tk/skills-zig): source for bench_stats and perf_report, build/test wiring, and release tags.
  • homebrew-tap (/Users/tk/workspace/tk/homebrew-tap): Homebrew formula updates/checksum bumps for released lift binaries.

Double Diamond fit

Lift lives in Define -> Deliver:

  • Define: write a performance contract and pick a proof workload.
  • Deliver: measure baseline, profile, run tight experiments, then ship with a guard.

Hard Rules

  • Measure before and after every optimization (numbers + environment + command).
  • Optimize the bottleneck, not the loudest hunch (profile/trace/counters required).
  • Avoid micro-optimizations until algorithmic wins are exhausted.
  • Keep correctness and safety invariants intact.
  • Require a correctness signal before and after; never accept a perf win with failing correctness.
  • Do not change semantics without explicit user approval.
  • If you cannot run a proof workload, label the output UNMEASURED and provide exact benchmark/profiling commands; treat all optimization ideas as hypotheses.
  • Stop and ask before raising resource/cost ceilings (CPU cores, memory footprint, I/O bytes, external calls), unless explicitly requested.
  • Stop when ROI is negative or risk exceeds benefit.
  • For Lift-owned CLIs, use Zig binaries only (bench_stats, perf_report) and prove compatibility via marker checks before use.
  • After any Zig CLI contract change, update docs and release/tap propagation in the same pass so install guidance matches runtime behavior.
  • When running $lift on $lift with $ms, require a runnable proof bundle before done: Zig marker checks plus one sample invocation per CLI.

Default policy (non-interactive)

Goal: stay autonomous without inventing SLOs.

Mode selection (measured vs unmeasured)

If you can run a proof workload, operate in measured mode. Otherwise operate in unmeasured mode.

  • Measured: run baseline + variant on the same workload; include numbers, bottleneck evidence, and a correctness signal.
  • Unmeasured: start with UNMEASURED: <why>; do not claim wins; provide the exact commands you would run to produce baseline/after + profiling evidence.

Contract derivation

If the user did not provide a numeric target:

  • Define the contract as: "Improve on vs baseline; report delta; do not regress."
  • Do not invent SLO numbers; treat the goal as "maximize improvement within constraints".

Metric defaults (pick one):

  • Request-like: latency p95 (also report p50/p99).
  • Batch/offline: throughput (also report CPU% and memory).
  • Memory issues: peak RSS + alloc rate / GC pause (also report latency).

Workload selection (proof signal)

Pick the first runnable, representative workload you can find:

  1. User-provided repro/command.
  2. Existing repo benchmark/harness (README, scripts, Makefile/justfile/taskfile).
  3. A minimal harness around the hot path (microbench) plus a correctness signal.

Stop and ask only if you cannot find or create any runnable proof workload without product ambiguity.

Experiment hygiene

  • Change one variable at a time; keep diffs small and reversible.
  • Reject wins smaller than the noise floor; re-run when variance is high.
  • Track second-order regressions (memory, tail latency, CPU) even if the primary metric improves.

Workflow (Opinionated)

  1. Preflight

- Capture environment (hardware/OS/runtime flags). - Pick a correctness signal and a performance workload; run each once to verify they work.

  1. Performance contract

- Metric + percentile + workload + environment + constraints.

  1. Baseline

- Warm up; collect enough samples for stable percentiles (keep raw samples when possible).

  1. Locate the bottleneck

- Profile/trace; classify bound (CPU/memory/I/O/lock/tail).

  1. Choose the highest-leverage lever

- Follow the optimization ladder: delete work -> algorithm -> data/layout -> concurrency -> I/O -> micro-arch -> runtime/compiler.

  1. Run tight experiments (loop)

- Hypothesis -> patch -> measure -> accept/reject -> record.

  1. Ship with guards

- Add/extend a benchmark, budget, or alert; document trade-offs.

  1. Report

- Present baseline vs variant and the evidence trail.

  1. CLI proof (Zig only)

- Lock Zig behavior and capture proof (<tool> --help marker check plus one sample run). - Keep install/run guidance in sync with the released lift binary behavior before shipping.

Decision Gates

  • If the baseline is noisy or unstable, fix measurement first.
  • If the complexity class dominates, change the algorithm first.
  • If tail latency dominates, treat variance reduction as the primary goal.
  • If I/O dominates, reduce bytes, syscalls, or round trips before CPU tuning.
  • If the only remaining wins require higher resource/cost ceilings, surface the trade-off and ask.
  • Stop when ROI is negative or risk exceeds benefit.

Deliverable format (chat)

If unmeasured, prefix the response with UNMEASURED: <reason> and fill sections with a concrete measurement plan (no claimed deltas).

Output exactly these sections (short, numbers-first):

Performance contract

  • Metric + percentile:
  • Workload command:
  • Dataset:
  • Environment:
  • Constraints:

Baseline

  • Samples + warmup:
  • Results (min/p50/p95/p99/max):
  • Notes on variance/noise (or estimated noise floor):

Bottleneck evidence

  • Tool + key finding:
  • Hot paths / contention points:
  • Bound classification:

Experiments

  • <1-3 entries> Hypothesis -> change -> measurement delta -> decision

Result

  • Variant results (min/p50/p95/p99/max):
  • Delta vs baseline:
  • Confidence (noise/variance):
  • Trade-offs / regressions checked:

Regression guard

  • Benchmark/budget added:
  • Threshold (if any):

Validation

  • Correctness command(s) -> pass/fail
  • Performance command(s) -> numbers

Residual risks / next steps

- lift_compliance: mode=<measured|unmeasured>; workload=<yes|no>; baseline=<yes|no>; after=<yes|no>; correctness=<yes|no>; bottleneck_evidence=<yes|no>

Core References (Load on Demand)

  • Read references/playbook.md for the master flow and optimization ladder.
  • Read references/measurement.md for benchmarking and statistical rigor.
  • Read references/profiling-tools.md for a profiler/tool matrix and evidence artifacts.
  • Read references/algorithms-and-data-structures.md for algorithmic levers.
  • Read references/systems-and-architecture.md for CPU, memory, and OS tactics.
  • Read references/latency-throughput-tail.md for queueing and tail behavior.
  • Read references/optimization-tactics.md for a tactical catalog by layer.
  • Read references/checklists.md for fast triage and validation checklists.
  • Read references/anti-patterns.md to avoid common traps.

Scripts

  • Prefer this brew-aware launcher pattern for Lift CLIs (Zig-only, fail-closed):
run_lift_tool() {
  local subcommand="${1:-}"
  if [ -z "$subcommand" ]; then
    echo "usage: run_lift_tool <bench-stats|perf-report> [args...]" >&2
    return 2
  fi
  shift || true

  local bin=""
  local marker=""
  case "$subcommand" in
    bench-stats)
      bin="bench_stats"
      marker="bench_stats.zig"
      ;;
    perf-report)
      bin="perf_report"
      marker="perf_report.zig"
      ;;
    *)
      echo "unknown lift subcommand: $subcommand" >&2
      return 2
      ;;
  esac

  install_lift_direct() {
    local repo="${SKILLS_ZIG_REPO:-$HOME/workspace/tk/skills-zig}"
    if ! command -v zig >/dev/null 2>&1; then
      echo "zig not found. Install Zig from https://ziglang.org/download/ and retry." >&2
      return 1
    fi
    if [ ! -d "$repo" ]; then
      echo "skills-zig repo not found at $repo." >&2
      echo "clone it with: git clone https://github.com/tkersey/skills-zig \"$repo\"" >&2
      return 1
    fi
    if ! (cd "$repo" && zig build -Doptimize=ReleaseSafe); then
      echo "direct Zig build failed in $repo." >&2
      return 1
    fi
    if [ ! -x "$repo/zig-out/bin/$bin" ]; then
      echo "direct Zig build did not produce $repo/zig-out/bin/$bin." >&2
      return 1
    fi
    mkdir -p "$HOME/.local/bin"
    install -m 0755 "$repo/zig-out/bin/$bin" "$HOME/.local/bin/$bin"
  }

  local os="$(uname -s)"
  if command -v "$bin" >/dev/null 2>&1 && "$bin" --help 2>&1 | grep -q "$marker"; then
    "$bin" "$@"
    return
  fi

  if [ "$os" = "Darwin" ]; then
    if ! command -v brew >/dev/null 2>&1; then
      echo "homebrew is required on macOS: https://brew.sh/" >&2
      return 1
    fi
    if ! brew install tkersey/tap/lift; then
      echo "brew install tkersey/tap/lift failed." >&2
      return 1
    fi
  elif ! (command -v "$bin" >/dev/null 2>&1 && "$bin" --help 2>&1 | grep -q "$marker"); then
    if ! install_lift_direct; then
      return 1
    fi
  fi

  if command -v "$bin" >/dev/null 2>&1 && "$bin" --help 2>&1 | grep -q "$marker"; then
    "$bin" "$@"
    return
  fi
  echo "missing compatible $bin binary after install attempt." >&2
  if [ "$os" = "Darwin" ]; then
    echo "expected install path: brew install tkersey/tap/lift" >&2
  else
    echo "expected direct path: SKILLS_ZIG_REPO=<skills-zig-path> zig build -Doptimize=ReleaseSafe" >&2
  fi
  return 1
}

run_lift_tool bench-stats --input samples.txt --unit ms
run_lift_tool perf-report --title "Perf pass" --owner "team" --system "service" --output /tmp/perf-report.md
  • Direct Zig CLI commands:

- bench_stats --input samples.txt --unit ms - perf_report --title "Perf pass" --owner "team" --system "service" --output /tmp/perf-report.md

  • Zig proof snippet:

- command -v bench_stats && bench_stats --help 2>&1 | grep -q bench_stats.zig - command -v perf_report && perf_report --help 2>&1 | grep -q perf_report.zig

  • Sample invocation proof snippet:

- bench_stats --input samples.txt --unit ms - perf_report --title "Perf pass" --owner "team" --system "service" --output /tmp/perf-report.md

Assets

  • Use assets/perf-report-template.md as a ready-to-edit report.
  • Use assets/experiment-log-template.md to track experiments and results.

Output Expectations

  • Deliver a baseline, bottleneck evidence, hypothesis, experiment plan, and measured result.
  • Provide a minimal diff that preserves correctness and includes a regression guard.
  • Explain trade-offs in plain language and record the measured delta.

平台分布

Codex

39.26%
按下载量换算69

Claude

27.61%
按下载量换算49

Cursor

17.29%
按下载量换算30

Gemini CLI

8.79%
按下载量换算15

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills