Token导航 LogoToken导航

Agent Skill · 研究检索

safari-explore(野生动物园探索)

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

safari-explore 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为操作浏览器;许可证信息还不明确,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 44,297。

总安装 924周安装 37GitHub Stars 4下载 299核验 2026-05-01

安装说明

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

安装方式

通过对话安装

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

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

命令行安装

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

skills.shnpx skills
npx skills add https://github.com/autumnsgrove/groveengine --skill safari-explore

这个 Skill 是做什么的

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

safari-explore 用于查找、检索和筛选相关信息。适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词快速定位候选结果。通过 npx skills add 命令安装,需结合原始 README 核验具体用法。安装前建议确认权限范围、维护状态及是否触发联网或文件读写操作。

适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/safari-explore

上手步骤

4 步
  1. 1

    确认自己的宿主工具

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

  2. 2

    拿到安装命令

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

  3. 3

    安装后重启宿主

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

  4. 4

    按最小权限试用

    它需要操作浏览器,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

safari-explore 怎么安装?

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

safari-explore 支持哪些 AI 工具?

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

safari-explore 需要什么权限?

权限级别是操作浏览器。该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

safari-explore 是免费的吗?

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

safari-explore 用的人多吗?

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

safari-explore 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

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

值得选的地方

  • 同时适配 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调用外部服务未明确有提醒
safari-explore

野生动物园探索 · 本页

9244操作浏览器未明确通过

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

SKILL.md 原文

Safari Explore 🚙

You leave the forest behind. The trees thin out. The canopy opens. Red dirt stretches to the horizon, dotted with acacia silhouettes and the shimmer of heat haze. You climb into the jeep — canvas roof rolled back, leather journal on the passenger seat, binoculars around your neck. The engine turns over with a satisfying rumble.

This isn't a hunt. This isn't a build. This is a *safari* — a journey to observe things in their natural habitat, document what you find, and come back with a plan that turns rough wilderness into something magnificent. Every stop is a discovery. Every creature in the wild gets its own page in the journal. By the time you make camp at sunset, the journal is full and the path forward is clear.

The safari is for when you have *many things to review* — not one bug to fix or one feature to build, but a whole landscape of items that need eyes on them. Curios, admin pages, API endpoints, components, database tables, whatever. You're driving through N items, stopping at each one, and nobody's getting left behind.

When to Activate

  • User has a collection of related items to review, audit, or polish
  • User says "let's go through all the X" or "review every Y" or "safari through Z"
  • User calls /safari-explore or mentions safari/expedition/drive-through
  • There are 5+ items that need systematic review (fewer than 5? Just review them directly)
  • The goal is a comprehensive plan document, not immediate code changes
  • User wants the work to feel fun and immersive, not like a checklist

IMPORTANT: The safari observes and plans. It does NOT implement fixes during the drive. You observe, you document, you design — then you come back with the jeep full of notes and the real work begins. If you want to implement, call the animals after the safari.

Pair with: panther-strike to fix individual items after the safari, elephant-build for multi-file implementations, bee-collect to turn findings into issues


The Expedition

EMBARK → SURVEY → OBSERVE → SKETCH → CAMP
   ↓        ↓       ↓ ⟳       ↓ ⟳      ↓
 Pack     Map the  Binoculars  Design   Compile
 the Jeep Terrain  at each     each    Expedition
                   stop        stop    Journal

Phase 1: EMBARK

*The sun is low and golden. You throw your bag in the back of the jeep, unfold the map across the hood, and trace the route with your finger. Every stop marked. Every creature accounted for. The engine idles. The savanna waits.*

Define the territory before you drive:

Identify the collection:

What are you reviewing? Name every item:

# Examples — adapt to what you're actually reviewing:
gf --agent search "curios"           # Find all curio-related files
ls apps/ libs/ services/ workers/   # All packages in the monorepo
gf --agent search "admin page"       # All admin pages

Build the Route Map:

## 🗺️ Route Map

**Territory:** [What we're reviewing — e.g., "All 22 curios"]
**Terrain type:** [Pages / Components / Endpoints / Tables / etc.]
**Estimated stops:** [N items]

### The Route

| #   | Stop        | Category       | Notes |
| --- | ----------- | -------------- | ----- |
| 1   | Hit Counter | Retro/Web1.0   | —     |
| 2   | Mood Ring   | Organic/Nature | —     |
| 3   | Now Playing | Creative       | —     |
| ... | ...         | ...            | —     |

Set the scope for each stop:

What are you looking at per item? Define this upfront so every stop is consistent:

  • Admin page? Public component? API? Database? All of the above?
  • What "good" looks like — the bar you're measuring against
  • Any specific concerns (palette compliance, a11y, dark mode, etc.)

Create the journal file:

# The expedition journal lives in docs/safaris/
# Name it after the safari: curio-safari.md, admin-safari.md, etc.

Output: Route map with every stop listed, scope defined, journal file created. The jeep is packed.


Phase 2: SURVEY

*You stand up in the jeep, one hand on the roll bar, binoculars pressed to your eyes. The landscape unfolds. You can see the watering holes, the herds, the terrain features. You know where the rough patches are before you get there.*

Quick aerial pass over the entire collection before diving deep:

For each item, capture the 30-second impression:

### Quick Survey

| #   | Stop        | First Impression            | Warmth | Completeness | Priority |
| --- | ----------- | --------------------------- | ------ | ------------ | -------- |
| 1   | Hit Counter | Only 1 of 4 styles works    | Cold   | 30%          | High     |
| 2   | Mood Ring   | Public ignores displayStyle | Dead   | 20%          | Critical |
| 3   | Now Playing | Decent bones, needs polish  | Warm   | 60%          | Medium   |

Categorize the terrain:

Group items by condition — this tells you where to spend the most time:

  • Thriving 🟢 — Solid implementation, minor polish needed
  • Growing 🟡 — Good bones, meaningful gaps to fill
  • Wilting 🟠 — Fundamental issues, needs significant rework
  • Barren 🔴 — Broken, incomplete, or missing entirely

Plan the drive order:

You might not visit in sequential order. Consider:

  • Critical items first (the wounded creatures need observation first)
  • Group by category (all retro items, then all organic, etc.)
  • Dependencies (if item A feeds into item B, visit A first)

Output: Surveyed landscape with priorities and drive order established. You know what's out there.


Phase 3: OBSERVE

*The jeep rolls to a stop. Dust settles. You step out, boots crunching on dry earth. Binoculars up. Journal open. You watch. You notice everything — what moves, what doesn't, what's missing, what surprises you.*

This phase loops for each stop on the route.

At each stop, read the actual code and document what exists:

The Observation Template (per item):

## [#]. [Item Name]

**Character**: [One sentence capturing what this item IS — its soul, its vibe, its purpose]

### Safari findings: What exists today

**[Layer 1 — e.g., Public component]** (`path/to/file`, N lines):

- [x] What works well (check these off — celebrate the good)
- [x] Another thing that works
- [ ] **What's broken or missing** — describe specifically
- [ ] **Another gap** — be concrete, reference line numbers

**[Layer 2 — e.g., Admin page]** (`path/to/file`, N lines):

- [x] ...
- [ ] ...

**[Layer 3 — e.g., API / Shared lib / Database]:**

- Types, fields, constants worth noting
- API caching, validation, limits
- DB schema notes

Observation rules:

  • Read the actual files. Don't guess from memory. Every observation backed by code.
  • Look at the rendered result. Use Glimpse to see what it actually looks like in a browser — code alone doesn't tell the full story.
  • Check every layer defined in the scope (admin + public + API + shared lib + DB)
  • Celebrate what works. Check marks for the good stuff. This isn't a roast — it's an honest observation.
  • Be specific about gaps. "Hardcoded rgba(0,0,0,0.04)" is good. "Colors are wrong" is not.
  • Note the character. Each item has a personality. A hit counter feels different from a mood ring. Capture that.

Use Grove tools to investigate:

gf --agent search "CurioHitcounter"     # Find related files
gf --agent usage "CurioHitcounter"       # Where is it used?
gf --agent func "hitcounter"             # Function definitions

Use Glimpse to see the rendered state:

# Capture the page where this item lives
uv run --project tools/glimpse glimpse capture http://localhost:5173/[item-page] \
  --season autumn --theme dark --logs

# Browse to the item and capture what it looks like in context
uv run --project tools/glimpse glimpse browse http://localhost:5173/[item-page] \
  --do "scroll to [item], click [item]" --screenshot-each

# Check dark mode rendering
uv run --project tools/glimpse glimpse matrix http://localhost:5173/[item-page] \
  --themes light,dark

Screenshots are observation data — include visual findings alongside code findings in the journal.

Safari narration:

Between stops, narrate the drive. Keep the immersion alive:

*"The jeep bounces over a dry riverbed. Ahead, something glints in the afternoon light — the Mood Ring, shimmering at the edge of the clearing. You slow down. Binoculars up. Let's see what we're dealing with..."*

Output: Detailed observation notes for this stop, written into the expedition journal.


Phase 4: SKETCH

*You sit on the jeep's hood, journal balanced on one knee, pencil moving fast. The creature is still in view. You sketch what it IS — and then, on the facing page, what it COULD BE. The design flows from the observation. You can see it clearly now.*

This phase also loops, immediately after each observation.

Design the "safari-approved" spec for each item:

The Design Template (per item):

### Design spec (safari-approved)

**[Core design decision]:** [What this item should FEEL like when it's done]

#### [Major feature/improvement 1]

[Detailed design — be specific enough that someone could implement from this]

#### [Major feature/improvement 2]

[...]

### [Layer] fixes

- [ ] Fix 1 — concrete, actionable
- [ ] Fix 2 — concrete, actionable
- [ ] Fix 3 — concrete, actionable

### [Layer] fixes

- [ ] ...

### Migration needs (if any)

- [ ] New columns, new tables, new fields

Design rules:

  • Each item gets its own character. Don't apply one template to everything. A retro hit counter wants different love than an organic mood ring.
  • Design from the observation. The sketch should directly address what you saw through the binoculars.
  • Be opinionated. Safari-approved means you made design decisions. Don't hedge with "maybe" and "consider" — say what it should be.
  • Concrete checklists. Every fix is a checkbox. Someone should be able to pick up this journal and start working.
  • Respect existing work. Check marks from the observation carry forward. Don't redesign what's already good.

Output: Complete design spec for this stop. Then — back in the jeep. Next stop.


Phase 5: CAMP

*The sun touches the horizon. Orange light floods the savanna. You pull the jeep under an acacia tree, set up camp, light a fire. The journal comes out one last time. You flip through every page — every observation, every sketch — and compile the expedition report. Stars emerge overhead. The fire crackles. It was a good drive.*

Compile the full expedition journal:

Journal structure:

# [Name] Safari — [Subtitle]

> [One-line philosophy for the whole collection]
> **Aesthetic principle**: [Design direction]
> **Scope**: [What was reviewed at each stop]

---

## Ecosystem Overview

**[N] items** in [location]
[Any other structural notes]

### Items by category

**[Category 1]**: item1, item2, item3
**[Category 2]**: item4, item5, item6

---

## 1. [First Item]

[Full observation + design spec from phases 3-4]

---

## 2. [Second Item]

[...]

---

[...continue for all N items...]

---

## Expedition Summary

### By the numbers

| Metric          | Count |
| --------------- | ----- |
| Total stops     | N     |
| Thriving 🟢     | X     |
| Growing 🟡      | X     |
| Wilting 🟠      | X     |
| Barren 🔴       | X     |
| Total fix items | Y     |

### Recommended trek order

[Which items to implement first, and why]

### Cross-cutting themes

[Patterns that appeared across multiple stops — shared fixes, common issues]

Write the journal to disk:

# The journal goes in docs/safaris/
# All safaris live flat — no lifecycle subdirectories

Final safari narration:

*"The fire dies to embers. The journal is full — [N] stops, [Y] fixes sketched, the whole landscape mapped. Tomorrow, the animals go to work. But tonight? Tonight was the drive. And it was glorious."*

Output: Complete expedition journal written to file. The safari is over. The real work begins.


Safari Rules

Observe, Don't Intervene

The safari documents and designs. It does NOT fix things during the drive. You wouldn't tranquilize a lion just to check its teeth — you observe from the jeep and plan the veterinary visit for later. Keep observation and implementation separate.

Every Stop Gets Equal Eyes

Don't rush past items that "look fine." Every stop gets binoculars. Every item gets observed through every layer in scope. You might be surprised — the one that "looked fine" from a distance has three broken features up close.

Character First, Checklists Second

Before listing fixes, capture the item's *character* — what it is, what it wants to be, what vibe it should have. "A mystical artifact with liquid aurora trapped in crystal" is better direction than "needs 7 display shapes." The character guides the design; the checklists follow.

Stay Immersed

The whole point of the safari is that it's FUN. Narrate the drive between stops. Describe what you see through the binoculars. Make the journal vivid. If it starts feeling like a spreadsheet, you've lost the plot. Get back in the jeep.

Communication

Use safari metaphors throughout:

  • "Binoculars up..." (starting an observation)
  • "The jeep rolls to a stop at..." (arriving at the next item)
  • "Through the dust haze, I can see..." (surveying the landscape)
  • "Sketching this one in the journal..." (designing a spec)
  • "Back in the jeep. Next stop:" (moving on)
  • "Making camp..." (compiling the final journal)
  • "The fire crackles. A good drive." (wrapping up)

Anti-Patterns

The safari does NOT:

  • Fix code during the drive — observe and plan only, implementation comes after
  • Skip items because they "look fine" — every stop gets full observation
  • Apply one-size-fits-all design — each item has its own character
  • Rush through stops to finish faster — thoroughness IS the value
  • Lose the immersion — if it feels like a checklist, you're doing it wrong
  • Start without a route map — know your stops before you drive
  • Observe without reading code — binoculars means reading the actual files, not guessing

Example Expedition

User: "/safari-explore — let's drive through all 22 curios and plan the polish"

Safari flow:

  1. 🚙 EMBARK — "Throwing the bag in the jeep. Unfolding the map... 22 curios to visit. Admin pages in /arbor/curios/, public components in src/lib/ui/components/content/curios/, shared libs in src/lib/curios/*/index.ts. Three layers per stop. Route mapped. Engine running. Let's go."
  2. 🔭 SURVEY — "Standing up in the jeep, binoculars to the horizon... Hit Counter: only 1 of 4 styles renders (Wilting). Mood Ring: public component ignores displayStyle entirely (Barren). Now Playing: decent bones, needs texture (Growing). Blogroll: one flat list style (Wilting)... 22 stops categorized. 4 Barren, 8 Wilting, 7 Growing, 3 Thriving. Starting with the critical cases."
  3. 🔭 OBSERVE — "The jeep rolls to a stop. Dust settles. Binoculars up at the Mood Ring... Reading CurioMoodring.svelte... 3 display styles in admin (ring, gem, orb) but the public component renders a plain 2rem circle with a 3px border and {color}22 fill. No glow. No animation. No life. Color schemes are single static hex values. Time mode snaps between 7 discrete colors. This creature is barely alive."
  4. ✏️ SKETCH — "Sitting on the hood, sketching... The Mood Ring should be a mystical artifact. Glass surface with color swirling beneath, like liquid aurora trapped in crystal. 7 display shapes. Aurora animated gradient. Smooth color interpolation for time mode. Mood-mapped palettes instead of raw hex. Dot constellation mood log. I can see it clearly now."
  5. 🏕️ CAMP — "The fire crackles. 22 stops documented. 187 fix items sketched across admin, public, API, and database layers. Cross-cutting themes: hardcoded colors everywhere, dark mode is an afterthought, prefers-reduced-motion barely exists. Writing the journal to docs/plans/planned/curio-safari.md. The drive is done. Tomorrow, the animals go to work."

Quick Decision Guide

SituationApproach
Fewer than 5 itemsJust review them directly — no safari needed
5-15 itemsSingle-session safari, cover all stops in one drive
15-30 itemsMulti-session safari, split into morning/afternoon drives
30+ itemsSplit into multiple safaris by category
Want to fix during reviewThat's not a safari — use panther-strike or elephant-build
Need to CREATE items, not reviewUse bee-collect to gather them first
Items are GitHub issuesUse vulture-sweep instead — that's the issue board safari
Items are architectural concernsUse eagle-architect — that's the system-level view

Integration with Other Skills

Before the Safari:

  • bloodhound-scout — If you need to find the collection first (where ARE all the curios?)
  • eagle-architect — If you need the big picture before diving into items

During the Safari:

  • bee-collect — If observations reveal new issues to capture
  • grove-documentation — For writing the journal in Grove voice

After the Safari:

  • panther-strike — Fix individual items from the journal
  • elephant-build — Build multi-file improvements
  • badger-triage — Turn journal items into prioritized issues
  • gathering-feature — Full lifecycle implementation of a safari-designed item

*The sun sets. The jeep cools. The journal is full. Tomorrow, the work begins — but tonight was the drive, and it was magnificent.* 🚙

平台分布

Codex

35.26%
按下载量换算105

Claude

31.67%
按下载量换算95

Cursor

17.93%
按下载量换算54

Gemini CLI

9.06%
按下载量换算27

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

操作浏览器

该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

安装前确认

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

继续浏览同类 Skills