claude-caliper

Use when the user wants to view, change, or reset their persistent preferences, or when triggered by "/caliper-settings", "my settings", "change defaults".

Use when asked to audit a codebase, find DRY/YAGNI/complexity issues repo-wide, or perform periodic code quality review

Use when a design doc has been written and before draft-plan is dispatched

Use when creating features, building components, adding functionality, or modifying behavior - before any creative or implementation work begins

Use when you have a spec or requirements for a multi-step task, before touching code

Use when implementing a small or medium change directly in the current session, without a multi-task plan — via design's fast-path routing, or direct invocation ("/implement", "just implement this", "quick fix").

Use when a multi-task implementation is complete and ready for holistic review before merging, or asked to review the current branch/diff as a whole

Use when executing implementation plans with independent tasks in the current session

Use when a plan has been written and before execution begins

Use when a PR has review feedback to address, needs review, or when triggered by "/pr-review", "address review feedback", "review feedback ready".

Queue commands to fire automatically at a future time — by default right after the current Claude 5-hour usage window resets (so the work runs on the fresh quota in this same session), or at a time the user names. Use when the user runs `/queue <commands>`, `/queue <when> <commands>`, says "queue this for the next window", "run this after my limit resets", "defer this to the next 5-hour block", "run this in 2 hours", "do this at 3pm", or "10am tomorrow run X".

Work a task autonomously and continuously, checking usage-window consumption (the 5-hour block by default, or the 7-day/weekly cap with `--window 7d`) at each checkpoint, and stop when usage hits a threshold (default 99%) instead of getting rate-limited mid-action. Use when the user runs `/usage-guard <task>`, `/usage-guard --queue <task>`, `/usage-guard --window 7d <task>`, says "keep going until I'm almost out of usage", "grind on this until the 5-hour limit", "use up my block on this", "stop when I'm near my weekly/7-day limit", or "work until 99% then stop / then queue the rest".

Use when asked to audit unit tests, check test quality/health, find flaky or weak tests, or review the test suite for smells — repo-wide or on changed tests

Use when a reviewed PR is ready to merge, or when triggered by "/pr-merge", "merge the PR", "merge it".

Use when work is complete and ready to create a PR for review. Triggers include "/pr-create", "create a PR", "commit and push", "open a PR".

Use when evaluating skill output quality, comparing skill versions, running behavioral evals, benchmarking a skill, or when triggered by /skill-eval