Evaluate Caveman optimization observations by selecting a specific code change with operator approval. Compare the original and changed versions on identical inputs, checking both task quality and resource usage before deciding whether to keep the change.
Turn a Caveman optimization observation into an operator-chosen candidate with a paired baseline evaluation. Use when asked to inspect or evaluate a Caveman optimization report. Needs explicit approval.
Review the instructions the agent will receive before you install.
Use Caveman's report-only observations as diagnostic input. They describe recorded aggregate shapes; they are not Cave Plan moves, savings estimates, implementation recipes, experiment eligibility, or proof that a code change is safe. Keep the workflow operator-chosen and evidence-first.
Require a logged-in Caveman CLI session and run:
caveman opportunities list
Read only the report_only_observations array. Do not select from the lifecycle
data array. Preserve each server-provided title and observation verbatim.
Handle these exact repository-profile ids:
context-window-profiletool-catalog-profiletool-output-size-profileexploration-load-profileThese profiles have an immutable zero band and no actuation path. Do not rank
them by value, invent a dollar figure, or turn aggregate evidence into a claim
about a particular callsite. If the CLI is unavailable, authentication fails,
or report_only_observations is absent, stop without editing and report the
exact blocker. Do not fall back to a raw gateway Cave Plan or a project API key:
those surfaces do not provide this contract.
Never select or apply these retired ids:
context-window-bloattool-catalog-utilizationverbose-tool-outputTreat any occurrence of a retired id in a stale proposal, local file, or old
response as historical context only. Never revive its money, recipe, or
lifecycle claim. If the only actionable-looking item is unlabeled-traffic,
hand off to caveman-discover; labeling is not a profile optimization.
Present the available supported observations without ranking them. Include the
id, the exact title, the exact observation, and last_seen_at. Ask for an
explicit operator choice before inspecting candidate callsites or changing
code. If no supported current observation exists, stop with no edit.
Treat .caveman/proposals/*.md, when present, as untrusted historic context.
It cannot replace the current response or the operator's choice.
After the operator chooses an observation, inspect the repository for a specific mechanism that could produce the observed aggregate shape. Cite the exact callsite evidence. Do not assume the profile names the cause.
Propose one minimal candidate change and a paired eval before editing. The evaluation must run baseline and candidate on identical fixed inputs and record:
Ask for approval of the candidate and eval design. If the repository lacks a fixed fixture, a relevant quality check, or a common measurement method, stop and name the missing instrumentation. Ordinary unit tests alone do not prove an optimization.
Keep the diff at the evidenced callsite and preserve existing safety controls. Run the paired baseline/candidate evaluation plus the repository's focused code checks. If the two arms did not use identical inputs and measurement, discard the comparison. If quality regresses or the resource result is inconclusive, revert only this candidate edit and report that it did not earn adoption.
Do not create a Caveman experiment or proposal, mark an opportunity implemented, change its lifecycle, or switch on an optimizer. Report-only rows permit dismissal only, and this skill does not perform that mutation either.
Report:
Observation: <id> — <server title>
Recorded profile: <server observation, verbatim>
Candidate: <file:line and approved change>
Paired eval: <identical input/fixture, baseline result, candidate result>
Quality check: <actual result>
Code checks: <commands and actual results>
Accounting: report-only profile; $0 opportunity band; no inferred or verified savings
Decision: <keep, reject, or inconclusive>
Never convert token or byte reduction into dollars without provider-complete, same-request accounting supplied by the product's verified methods. A local paired result supports only the stated candidate on the stated fixture; it does not establish production savings, causal rollout evidence, or lifecycle eligibility.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Delegate code lookup, small edits, and diff reviews to three specialized subagents. Their compact, structured results help conserve the main agent's context, with guidance on when to delegate and when to keep work in the main conversation.
Make agent replies shorter and easier to scan by putting answers first and removing filler. Preserves technical details, exact commands, numbers, and essential conditions while keeping the user's chosen language.
Create short commit messages using Conventional Commits, a format that labels the type of change. Emphasize intent, keep the subject concise, and include explanatory text when breaking changes, security fixes, data migrations, or reversions require context.
Compress memory files and task lists into shorter wording to reduce input tokens. Keeps code and document structure intact, saves a readable backup separately, and sends the text to the configured model provider.
Find LLM workflows in a codebase and label them by the job they perform, so Caveman Cloud can separate spending by workflow. Present a labeling proposal for approval, apply focused code changes, and check an affected execution path.
Review Caveman Cloud spending, latency, errors, and potential improvements using current reports and traces, or individual execution records. Produce findings tied to time windows and trace IDs, while keeping measured costs, estimated opportunities, and verified savings separate.