菜单
Explain Caveman token-stats support in Pi. Upstream Caveman stats are powered by Claude Code hooks and session logs; this Pi package does not fake token savings. Triggers on /skill:caveman-stats or "caveman stats".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | caveman-stats |
| description | Explain Caveman token-stats support in Pi. Upstream Caveman stats are powered by Claude Code hooks and session logs; this Pi package does not fake token savings. Triggers on /skill:caveman-stats or "caveman stats". |
Report stats support honestly. Do not estimate token savings.
Upstream Caveman computes stats through Claude Code hook files:
hooks/caveman-stats.jshooks/caveman-mode-tracker.jsThis Pi package has Pi-native mode hooks, but they only activate/track Caveman mode. They do not install Claude Code hooks, read Claude Code logs, provide statusline stats, mutate non-Pi agent config, or expose measured token savings. Real Caveman token stats remain unavailable unless Pi exposes a reliable token/session-log API.
When invoked, say:
Caveman stats unavailable in Pi package.
Pi-native hooks track mode only; no measured token stats API yet.
Upstream stats need Claude Code hooks/session logs.
No fake estimate.
If Pi later exposes a reliable token/session log API, use that source only. Never infer savings from response length or claim exact percentages for current session without measured data.
Reviews implementation architecture with firm, evidence-based judgment: separation of concerns, maintainability, ownership, dependency direction, stability/change boundaries, validation, persistence/state ownership, runtime coordination, Conway fit, evolution strategy, and refactoring discipline. Use when asked for architecture review of module/package boundaries, cross-capability dependencies, shared code, abstraction drift, validation placement, service boundaries, strangler work, branch-by-abstraction changes, or refactoring claims.
Reviews data movement and structural resource costs: filtering, pagination, streaming, materialization, copying/cloning, allocation, serialization/parsing, batching, N+1 I/O, backpressure, lock contention, and APIs that force callers to pay unnecessary costs. Use when asked for data-flow or performance review of data-heavy paths, persistence/search/streaming APIs, parsers, async workflows, hot paths, batch jobs, CLI pipelines, or hidden memory/throughput risks.
Review delivered code, CI, config, and generated assets. Use when explicit implementation review is requested; OpenSpec artifacts are optional context.
Reviews implementation security by tracing assets, actors, attacker-controlled input, trust boundaries, enforcement points, and sinks across auth, authorization, injection, command/path/URL handling, deserialization, secrets, logs, resource exhaustion, races, supply-chain, and crypto surfaces. Use when asked for security review of external inputs, auth flows, APIs, CLI commands, file/network/subprocess access, stored payloads, dependency scripts, tenant isolation, privilege boundaries, or security-sensitive assumptions.
Reviews implementation test quality by judging whether tests prove required behavior, invariants, failure modes, and realistic regressions across the relevant codebase. Use when asked for test review of meaningful coverage, public APIs, CLIs, generated outputs, validators, parsers, persistence, mocks, snapshots, property tests, fuzzing, or regression gaps.
Cavekit bug-to-spec protocol. Use on test failures, user bug reports, post-mortems, or /ck:check violations to trace root cause and decide what §B and §V updates should be made through cavekit-spec.