重要前提
安装AI Skills的关键前提是:必须科学上网,且开启TUN模式,这一点至关重要,直接决定安装能否顺利完成,在此郑重提醒三遍:科学上网,科学上网,科学上网。查看完整安装教程 →
npx skills add https://github.com/autumnsgrove/groveengine --skill fox-optimize狐狸不会笨拙地穿过森林。它以迅捷精准的方式移动,在树木间寻找最快的路径。当某些东西拖慢狩猎时,狐狸会立刻察觉。它悄悄接近问题,将其隔离,然后出击。狐狸经过后,森林的流动会更加顺畅。
/fox-optimize 或提及 fox/performance搭配使用: bloodhound-scout 来查找慢速代码路径
STALK → PINPOINT → STREAMLINE → CATCH → CELEBRATE
↓ ↲ ↲ ↓ ↓
Watch for Find the Optimize Capture Enjoy the
Slowness Bottleneck Hot Paths Gains Win
狐狸悄无声息地潜行,观察着移动过于缓慢的东西...
在动手做任何事之前,建立基准指标。
加载 以获取 Lighthouse 命令、打包分析设置、数据库查询分析、DevTools 指南和性能目标值
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
references/measurement-tools.md脚本: 运行 scripts/measure-bundle.sh 以捕获所有应用的基准打包大小。优化后再次运行,以获得自动的前后对比。
参考: 加载 references/performance-toolkit.md 以获取 Grove 特定的测量命令 —— 跨所有 3 个数据库的 D1 查询分析、KV 缓存模式、Workers 特定的并行化,以及性能报告模板
输出: 定义基准指标和目标
耳朵竖起。狐狸精确地定位了猎物藏身之处...
用证据找到具体的瓶颈。
80/20 法则:在 SSR 应用中,首先检查 TTFB —— 如果服务器慢,任何客户端优化都无济于事。然后检查图片、索引、缓存和 JS 打包体积。
参考: 加载 references/optimization-patterns.md 以获取诊断决策树 —— 它将症状映射到可能的原因
输出: 用证据识别出的具体瓶颈
狐狸在灌木丛中找到最快的路径...
应用有针对性的优化 —— 修复瓶颈,而不是其他所有东西。
参考: 加载 references/optimization-patterns.md 以获取所有优化模式的完整代码示例:图片、代码分割、N+1 修复、并行查询、KV 缓存、记忆化、虚拟滚动、动画性能和内存泄漏修复
输出: 应用了优化,且范围变更最小
狐狸猛地咬合 —— 速度已被捕获...
强制要求:验证优化没有破坏任何功能:
pnpm install
gw ci --affected --fail-fast --diagnose
如果验证失败:狐狸行动太快,破坏了某些东西。阅读诊断信息,修复回归问题,重新运行验证。没有正确性的速度毫无价值。
一旦 CI 通过,测量改进:
lighthouse https://yoursite.com
npm run build && npm run analyze
为报告记录前后对比。
输出: 经过验证的、有记录的收益
狐狸欢快地叫着,狩猎完成...
报告胜利并防止回归。
输出: 报告已交付,监控已就位
| 阶段 | 参考 | 加载时机 |
|---|---|---|
| STALK | references/measurement-tools.md | 始终(优化前必须测量) |
| STALK | references/performance-toolkit.md | Grove 特定:D1 分析、KV 缓存、打包跟踪 |
| STALK | scripts/measure-bundle.sh | 运行以获取自动化的打包大小基准和对比 |
| PINPOINT | references/optimization-patterns.md | 使用决策树识别原因 |
| STREAMLINE | references/optimization-patterns.md | 应用正确的修复模式 |
| STREAMLINE | references/performance-toolkit.md | Grove 特定:Workers 并行化、缓存头 |
| CELEBRATE | references/performance-toolkit.md | 使用性能报告模板 |
狐狸行动迅速。不要在微优化上花费数周时间。先找到大的收益点。
瞄准实际的瓶颈。先分析,再优化。不要猜测。
快但坏了毫无价值。每次优化后验证功能。
使用狩猎隐喻:
狐狸不会:
用户: "仪表板加载很慢"
狐狸流程:
| 症状 | 可能原因 | 快速修复 |
|---|---|---|
| 高 TTFB (>500ms) | hooks/middleware 中的顺序等待 | 使用 Promise.all 或 promise hoisting 进行并行化 |
| 访客也慢 | SSR 页面没有边缘缓存 | 添加 Cache-Control + CDN-Cache-Control 头 |
| 仅登录时慢 | 为认证/功能进行的额外查询 | 为匿名访客跳过不必要的工作 |
| 首次请求非常慢 | DO/Worker 冷启动 | 添加 keepalive 定时任务,配置的 KV 后备方案 |
| 初始加载慢 | JS 打包体积大 | 代码分割,摇树优化 |
| 图片慢 | 未优化的格式 | WebP/AVIF,懒加载 |
| 滚动卡顿 | 布局抖动 | 使用 transform,避免布局更改 |
| API 慢 | 缺少数据库索引 | 添加索引,实现缓存 |
| 内存增长 | 监听器泄漏 | 在 onDestroy 中正确清理 |
| 交互慢 | 阻塞主线程 | 将工作移至 web workers |
迅捷的狐狸将缓慢的森林抛在身后。 🦊
每周安装量
48
仓库
GitHub 星标
2
首次出现
2026年2月5日
安全审计
安装于
opencode48
gemini-cli48
codex48
github-copilot47
amp47
cline47
The fox doesn't lumber through the forest. It moves with swift precision, finding the fastest paths between trees. When something slows the hunt, the fox notices immediately. It stalks the problem, isolates it, and strikes. The forest flows better after the fox passes through.
/fox-optimize or mentions fox/performancePair with: bloodhound-scout to find slow code paths
STALK → PINPOINT → STREAMLINE → CATCH → CELEBRATE
↓ ↲ ↲ ↓ ↓
Watch for Find the Optimize Capture Enjoy the
Slowness Bottleneck Hot Paths Gains Win
The fox pads silently, watching for what moves too slowly...
Establish baseline metrics before touching anything.
Reference: Load references/measurement-tools.md for Lighthouse commands, bundle analysis setup, database query profiling, DevTools guide, and performance target values
Script: Run scripts/measure-bundle.sh to capture baseline bundle sizes across all apps. Run again after optimization to get automatic before/after comparison.
Reference: Load references/performance-toolkit.md for Grove-specific measurement commands — D1 query profiling across all 3 databases, KV caching patterns, Workers-specific parallelization, and the performance report template
Output: Baseline metrics and target goals defined
Ears perk. The fox isolates exactly where the prey hides...
Find the specific bottleneck with evidence.
The 80/20 rule: In SSR apps, check TTFB first — if the server is slow, no client-side optimization will help. Then check images, indexes, caching, and JS bundle size.
Reference: Load references/optimization-patterns.md for the diagnosis decision tree — it maps symptoms to likely causes
Output: Specific bottleneck identified with evidence
The fox finds the fastest path through the thicket...
Apply targeted optimizations — fix the bottleneck, not everything else.
Reference: Load references/optimization-patterns.md for complete code examples for all optimization patterns: images, code splitting, N+1 fixes, parallel queries, KV caching, memoization, virtual scrolling, animation performance, and memory leak fixes
Output: Optimizations applied with minimal scope changes
The fox snaps its jaws — speed captured...
MANDATORY: Verify the optimization didn't break anything:
pnpm install
gw ci --affected --fail-fast --diagnose
If verification fails: the fox moved too fast and broke something. Read the diagnostics, fix the regression, re-run verification. Speed without correctness is worthless.
Once CI passes, measure the improvement:
lighthouse https://yoursite.com
npm run build && npm run analyze
Document before/after for the report.
Output: Documented gains with verification
The fox yips with joy, the hunt complete...
Report the win and prevent regression.
Output: Report delivered, monitoring in place
| Phase | Reference | Load When |
|---|---|---|
| STALK | references/measurement-tools.md | Always (must measure before optimizing) |
| STALK | references/performance-toolkit.md | Grove-specific: D1 profiling, KV caching, bundle tracking |
| STALK | scripts/measure-bundle.sh | Run for automated bundle size baseline and comparison |
| PINPOINT | references/optimization-patterns.md | Use the decision tree to identify the cause |
| STREAMLINE | references/optimization-patterns.md |
The fox moves fast. Don't spend weeks on micro-optimizations. Find the big wins first.
Target the actual bottleneck. Profile first, optimize second. Don't guess.
Fast but broken is worthless. Verify functionality after each optimization.
Use hunting metaphors:
The fox does NOT:
User: "The dashboard is slow to load"
Fox flow:
🦊 STALK — "Measure: FCP 3.2s, LCP 5.1s. Target: FCP < 1.8s"
🦊 PINPOINT — "Lighthouse: render-blocking JS, unoptimized images, no caching. Database: N+1 queries for widget data."
🦊 STREAMLINE — "Defer non-critical JS, convert images to WebP, add DB indexes, implement KV caching"
🦊 CATCH — "FCP: 3.2s → 1.4s. LCP: 5.1s → 2.2s. Tests pass."
🦊 CELEBRATE — "Performance budget added to CI, RUM monitoring enabled"
| Symptom | Likely Cause | Quick Fix |
|---|---|---|
| High TTFB (>500ms) | Sequential awaits in hooks/middleware | Parallelize with Promise.all or promise hoisting |
| Slow for guests too | No edge caching on SSR pages | Add Cache-Control + CDN-Cache-Control headers |
| Slow only when logged in | Extra queries for auth/features | Skip unnecessary work for anonymous visitors |
| First request very slow | DO/Worker cold starts | Add keepalive crons, KV fallback for config |
| Slow initial load | Large JS bundle | Code splitting, tree shaking |
| Images slow | Unoptimized formats | WebP/AVIF, lazy loading |
| Janky scrolling | Layout thrashing | Use transform, avoid layout changes |
| API slow | Missing DB indexes | Add indexes, implement caching |
| Memory growing |
The swift fox leaves the slow forest behind. 🦊
Weekly Installs
48
Repository
GitHub Stars
2
First Seen
Feb 5, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
opencode48
gemini-cli48
codex48
github-copilot47
amp47
cline47
Azure 升级评估与自动化工具 - 轻松迁移 Functions 计划、托管层级和 SKU
118,400 周安装
| Apply the right fix pattern |
| STREAMLINE | references/performance-toolkit.md | Grove-specific: Workers parallelization, cache headers |
| CELEBRATE | references/performance-toolkit.md | Use the performance report template |
| Leaking listeners |
| Proper cleanup in onDestroy |
| Slow interactions | Blocking main thread | Move work to web workers |