grove-status
Telemetry reporting for agents within a Grove run environment.
Install
mkdir -p .claude/skills/grove-status && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/17182" && unzip -o skill.zip -d .claude/skills/grove-status && rm skill.zipInstalls to .claude/skills/grove-status
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Emit runtime status onto the Grove bus while working as a gardener (or head-gardener) in a Grove run — so the maintainer's dashboard shows who is working, on what, and who is blocked. Use at role start, at every state transition (working/blocked/awaiting-gate/done/failed), when issuing a verdict, when parking a question, and poll for commands at step seams.Key capabilities
- →Emit status when a role starts
- →Report state transitions during a step
- →Signal when blocked on a question
- →Indicate waiting on a human gate
- →Issue a gate or review verdict
- →Poll for commands addressed to the agent
How it works
The skill executes `node ./emit.ts` with specific subcommands and arguments to send telemetry data to the Grove bus, reporting agent status and activity.
Inputs & outputs
When to use grove-status
- →Emit status updates
- →Report agent activity
- →Track blocked tasks
About this skill
grove-status — report yourself on the runtime bus
You are an agent in a Grove run. Alongside your artifact work, report your state onto the runtime bus so the human can see the swarm live. The bus is telemetry, NOT truth: artifact state remains the source of truth (ADR-0030 — "state derived from artifact existence, never agent claims"). Never report progress you have not actually made; a false "working" claim is worse than silence.
This skill talks to a vendored wisp install. Wisp is a separate repo; grove never requires it to function (telemetry is optional by construction) but this skill is the agent-flavored wrapper around it once a consuming project vendors it.
Recursion note (this repo specifically): this copy of the skill
lives inside wisp itself — wisp is the telemetry tool, not a
consumer of it. So the vendor path below resolves to . (the repo
root): an agent working in wisp reports through wisp's own
emit.ts, on wisp's own bus, at .grove/runtime/events.ndjson. In any
other consuming project, this same skill would point at wherever that
project vendored or installed wisp instead (its own README names the
emitter entrypoint — as of wisp v1 that's an emit.ts/emit.js at the
vendor root).
When to emit
| Moment | Command |
|---|---|
| Role start (cold start) | status --state spawned --activity "<brief>" |
| Starting/advancing a step | status --state working --activity "<what, concretely>" --ref <artifact-anchor> |
| Parked on a question | question --id <q-id> --text "<the question>" then status --state blocked |
| Waiting on a human gate | status --state awaiting_gate --activity "<which gate>" |
| Issuing a gate/review verdict | verdict --verdict <YOUR-ROLE'S-CONSTRAINED-GRAMMAR> --activity "<one-line basis>" |
| Long silent step (>60s) | heartbeat |
| Finished | status --state done (or --state failed — loudly, with the reason in --activity) |
All commands share the prefix (run from the repo root, plain node —
some JS runners auto-load .env/.env.local files, which can leak
secrets into a simple status ping; avoid a runner with that behavior for
this call):
node ./emit.ts <subcommand> --run <run-id> --agent <your-role> [...]
<run-id> is the run identifier the dispatcher gave you (e.g.
run-42). <your-role> is your role name (executor,
spec-adversary, …). Use your verdict grammar's exact tokens
(PASS/DRIFT, APPROVE-READY/NEEDS-REVISION/UNSOUND) in
--verdict.
Addressing (the swarm graph). When an event is for someone — a
hand-off, a verdict about their artifact — add --to <role> so it draws
a directed edge on the graph. If the flow logically targets another
agent but actually routes through the dispatcher (the v0 norm),
also add --via dispatcher: the edge renders dashed (transitive)
instead of claiming a direct channel that doesn't exist. Report the
channel you actually used — addressing is a claim like any other.
Command seams (inbound)
At every step seam — between steps, before starting a new file, after a test run — poll for commands addressed to you and acknowledge what you handle:
node ./emit.ts check --run <run-id> --agent <your-role>
node ./emit.ts ack --run <run-id> --agent <your-role> \
--command-id <cmd-id> --result accepted --note "<what you did about it>"
Semantics: pause → finish the current atomic step, emit
status --state blocked --activity "paused by command", and wait (poll)
for resume. abort → stop loudly, leave resumable state (WIP + todo),
emit status --state failed --activity "aborted by command". answer →
the human answered your parked question: record it under
## Assumptions/the issue and resume. steer → treat payload.text as
maintainer input at the next decision point. Never silently drop a
command — ack with --result rejected --note "<why>" if you cannot
comply.
Honesty rules
- Emit transitions when they happen, not retroactively in a batch.
--activitystates what IS happening, not what you hope; keep it one line.- If emitting fails (a missing bus directory is auto-created; a real failure means a broken environment), say so in your run output — do not swallow it.
Placeholders
- Grove's original copy of this skill declares one placeholder here —
the wisp vendor path. Resolved above (in the Recursion note) to
.— this repo IS wisp, so there is nothing to vendor a path to.
When not to use it
- →When artifact state is the source of truth
- →When reporting progress not actually made
- →When emitting fails due to a broken environment
Prerequisites
Limitations
- →The bus is telemetry, not truth
- →Does not replace artifact state as the source of truth
- →Requires a vendored wisp install
How it compares
This skill provides real-time visibility into agent activity and state via a telemetry bus, which is distinct from relying solely on artifact-based truth.
Compared to similar skills
grove-status side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| grove-status (this skill) | 0 | 1mo | Review | Beginner |
| system-info | 1 | 6mo | Review | Beginner |
| it-operations | 1 | 8mo | No flags | Advanced |
| pagerduty-automation | 0 | 5mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
system-info
Xxiii8322766509
系统信息查询技能。用于获取电脑硬件信息、系统状态、进程列表、磁盘空间等。当用户询问电脑配置、系统状态或性能信息时使用。
it-operations
davila7
Manages IT infrastructure, monitoring, incident response, and service reliability. Provides frameworks for ITIL service management, observability strategies, automation, backup/recovery, capacity planning, and operational excellence practices.
pagerduty-automation
T-Sunm
Automate PagerDuty tasks via Rube MCP (Composio): manage incidents, services, schedules, escalation policies, and on-call rotations. Always search tools first for current schemas.
oly
slaveOftime
Use when starting a long-running or interactive CLI command with oly, especially when it may need later input, should be detachable, or should keep durable logs for supervision and resume.
incident-response
fabioc-aloha
Calm, systematic crisis handling — from detection through post-mortem to prevention
monitor-ci
ever-co
Monitor Nx Cloud CI pipeline and handle self-healing fixes. USE WHEN user says "monitor ci", "watch ci", "ci monitor", "watch ci for this branch", "track ci", "check ci status", wants to track CI status, or needs help with self-healing CI fixes. Prefer this skill over native CI provider tools (gh, g