Luvvv SRC Save Token

SRC 挖洞专用 Token 节省引擎 — 不影响技术精度，只砍废话。

---

用前用后对比

不用（正常模式）

好的，让我分析一下你提供的这些资产。根据之前的扫描结果，
我发现以下几个端点是存在漏洞的。首先，在 /api/ktworking/ 这个路径下，
有 15 个端点没有做鉴权校验。其次，/api/Login/UserLogin 这个接口
接受门店号作为默认密码，可以绕过 Okta SSO 直接登录。
综合来看，我建议你优先提交以下三个漏洞报告……

用之后（/luvvv exploit）

⚡
ktworking/* → 15 endpoints, no auth ← P0
UserLogin → store ID = password, bypass Okta SSO ← P0
出3个P0优先: Kiton读写, testo2o SSRF, chatlabs heapdump

信息量一样，token 省 ~70%。

---

安装

# 已安装到 ~/.claude/skills/luvvv-src-save-token/
# Claude Code 自动发现，无需额外配置

# 验证
ls ~/.claude/skills/luvvv-src-save-token/
# 应看到: SKILL.md  README.md

---

使用

默认关闭。用的时候手动开：

命令	效果	场景
/luvvv recon	极简，表格式	扫 20+ 资产
/luvvv exploit	压缩但保留 POC	深入验证
/luvvv report	完整语言	写报告
/luvvv off	关闭	正常对话

短别名也支持：/luvvv-src-save-token recon

---

⚡ 如何判断是否在压缩模式

开了之后每条回复开头有 ⚡ 标记。没有 ⚡ = 没开或忘了。

⚡                               ← 有这个 = 压缩中
ktworking no auth. 15 endpoints.
UserLogin bypass Okta. P0.

没开时就是正常回复，没有标记。

---

工作原理

输入 token（skill/上下文） → 不受影响，按需加载

输出 token → 压缩:
  砍掉: 冠词、客套、填充词、重复表述
  保留: 代码、POC、URL、CVE、凭证、错误信息 → 原样不动
  省 ~65-75% 输出 token

不丢数据。 curl 命令、HTTP 响应、漏洞 POC、影响评估——全部原样保留。

---

兼容性

配合使用	效果
bounty-hunter	✅ 扫资产时自动压结果
recon	✅ 子域名枚举结果表格式
code-audit	✅ 漏洞描述压缩
任何自定义 skill	✅ 纯输出层，不干涉逻辑

---

⚠️ 已知限制

1. 聊天记录长了可能忘记压缩 — 看 ⚡ 标记判断，忘了就手动 /luvvv recon 重新激活
2. 不能关输入端的 token 消耗 — 只是输出层，skill/reference 加载的 token 不受影响
3. report 模式 = 关闭 — 写报告时和正常模式一模一样，因为影响评估不能压缩

---

作者

@luvvv — SRC 挖洞场景优化

---

反馈

开了 /luvvv recon 试试，看有 ⚡ 没。没有就是 bug，跟我说。