Token导航 LogoToken导航TokenDH.com
研究检索操作浏览器github未标认证来源可访问许可证需确认审计通过

safari-explore野生动物园探索

Agent Skill

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

总安装

924

周安装

37

GitHub Stars

4

下载量

299
CodexClaudeCursorGemini CLI

安装说明

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

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 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

简介

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

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词快速定位候选结果。
  • 通过 npx skills add 命令安装,需结合原始 README 核验具体用法。
  • 安装前建议确认权限范围、维护状态及是否触发联网或文件读写操作。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

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.* 🚙

适合场景

01

用户想查找某类 Agent Skill 时

02

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

03

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

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

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

能力 4

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

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

平台分布

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