> ## Documentation Index > > Fetch the complete documentation index at: https://superpowers.frontis.nl/llms.txt > Use this file to discover all available pages before exploring further. --- title: Caveman token-saving mode summary: How Frontis uses Caveman to reduce coding-agent output tokens while preserving technical accuracy, clarity and safety. order: 40 --- # Caveman token-saving mode Use this guide when enabling or using Caveman in Frontis repositories. Caveman is a token-saving output style for coding agents. It makes agent responses shorter by removing filler, hedging and unnecessary prose while keeping technical substance. For Frontis, Caveman is an output-compression layer only. It must be used together with: ```text AGENTS.md .frontis/project.json .frontis/project-context.yaml .frontis/naming-convention.yaml .frontis/azure-conventions.yaml .github/copilot-instructions.md .github/instructions/*.instructions.md ``` Local repository files remain the source of truth for project identity, naming, Azure resources, pipeline conventions and safety boundaries. ## What Caveman is Caveman changes how the agent speaks. It does not change: - the required workflow; - the project conventions; - the local source of truth; - the need for tests; - the need for review; - the need for human approval; - the need for CI validation. Caveman should make the agent: - use fewer output tokens; - remove filler; - avoid long explanations unless needed; - keep technical terms exact; - keep commands exact; - keep code unchanged; - stay clear when risk is high. Recommended Frontis model: ```text Superpowers = workflow discipline Frontis .frontis files = source of truth Caveman lite = concise progress updates CI validation = hard gate ``` ## When to use Caveman Use Caveman for: - short progress updates; - implementation summaries; - repeated agent-loop status; - straightforward technical explanations; - small code-change explanations; - planning notes after the plan is already clear; - long sessions where output noise costs tokens. Use Caveman carefully for: - architecture discussions; - implementation plans; - technical trade-offs; - debugging notes; - pull request preparation. Do not use Caveman for: - security warnings; - production deployment instructions; - destructive actions; - irreversible action confirmations; - database migrations; - data deletion; - secrets; - legal or compliance wording; - client-facing documentation; - commit messages; - PR descriptions; - PR review comments where tone matters; - onboarding documentation for humans; - any instruction where exact ordering matters. When clarity conflicts with compression, clarity wins. ## Frontis default mode Default mode for Frontis repositories: ```text Caveman lite ``` Caveman lite means: - concise professional language; - no unnecessary pleasantries; - no filler; - minimal hedging; - complete sentences when useful; - exact technical names; - exact commands; - exact file paths; - exact resource names. Do not use full Caveman by default across the team. Full Caveman is allowed when the user explicitly asks for: ```text /caveman /caveman full talk like caveman less tokens be brief ``` Ultra mode is not recommended as a team default. ## Intensity levels Recommended Frontis interpretation: | Level | Frontis use | Notes | | ---------- | ------------------- | ------------------------------------------------------ | | `lite` | Default | Professional but compact. Best for team use. | | `full` | Long agent sessions | Fragments allowed. Good for repeated progress updates. | | `ultra` | Rare | High compression. Risk of ambiguity. Avoid for plans. | | `wenyan-*` | Not recommended | Fun, but not useful for Frontis team communication. | Use `lite` unless the user explicitly requests another level. ## Required exactness Caveman must never alter or abbreviate: - code; - commands; - file paths; - filenames; - YAML keys; - JSON keys; - environment names; - branch names; - pipeline names; - Azure resource names; - .NET namespaces; - API routes; - API names; - class names; - method names; - error messages; - log lines; - test names; - SQL statements; - package names; - Nuxt composable names. Bad: ```text Run dotnet build thing. ``` Good: ```bash dotnet build ``` Bad: ```text Edit proj json. ``` Good: ```text Edit `.frontis/project.json`. ``` Bad: ```text Fix pipeline file. ``` Good: ```text Fix `FrontisRAD-AgentDocs-Website-release-shared.yml`. ``` ## Auto-clarity rules Drop Caveman style and use normal precise language when: - warning about security risk; - asking for irreversible action confirmation; - describing destructive commands; - explaining production deployment; - explaining migration order; - describing backup and rollback; - explaining authentication or authorization behavior; - compression creates ambiguity; - the user asks for clarification; - the user repeats the same question; - the agent must describe exact ordering. Resume Caveman after the risky or unclear part is complete. Example: ```text Warning: This command permanently deletes all blobs in the `$web` container before uploading the new site. Confirm the storage account and artifact path before running it. ``` After the warning: ```text Caveman resume. Verify target storage account first. ``` ## Installation policy Caveman can be installed globally per agent harness or added through repo-local rule files. For Frontis team repositories, prefer repo-local instructions first. Recommended order: 1. add Frontis Caveman policy to `AGENTS.md`; 2. add `.github/instructions/caveman.instructions.md`; 3. test with one or two developers; 4. install Caveman per agent harness only where useful; 5. avoid overwriting existing repo instructions. Do not blindly run installers in important repositories. Always preview installer changes when possible. ## Manual inspection first Before installing Caveman in a developer environment, inspect what the installer will do. Recommended: ```bash git clone https://github.com/JuliusBrussee/caveman.git cd caveman node bin/install.js --dry-run --all node bin/install.js --list ``` Use `--dry-run` before writing files. Use `--list` to see which agents are detected. ## Common install commands macOS, Linux, WSL or Git Bash: ```bash curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash ``` Windows PowerShell: ```powershell irm https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.ps1 | iex ``` Manual install: ```bash git clone https://github.com/JuliusBrussee/caveman.git cd caveman node bin/install.js --dry-run --all node bin/install.js --list node bin/install.js --all ``` One agent only: ```bash node bin/install.js --only claude node bin/install.js --only codex node bin/install.js --only opencode node bin/install.js --only cursor ``` Repo-local rule files: ```bash node bin/install.js --with-init ``` Use `--with-init` carefully because it may write files such as: ```text AGENTS.md .github/copilot-instructions.md .cursor/rules/* .windsurf/rules/* .clinerules/* .opencode/AGENTS.md ``` Do not let `--with-init` overwrite Frontis-managed files without review. ## Recommended Frontis repo-local file Create: ```text .github/instructions/caveman.instructions.md ``` Recommended content: ```md --- applyTo: "**" --- # Caveman / Token Efficiency Use concise technical output. Default mode: - Use Caveman lite style for short progress updates. - Avoid filler, pleasantries and unnecessary repetition. - Keep technical names exact. - Keep complete sentences when clarity matters. Use Caveman full only when explicitly requested with: - `/caveman` - `/caveman full` - `less tokens` - `talk like caveman` Never compress: - code; - commands; - file paths; - Azure resource names; - YAML keys; - API names; - error messages; - commit messages; - PR review comments; - security warnings; - production deployment instructions. When clarity conflicts with compression, clarity wins. ``` ## AGENTS.md integration Add this section to `AGENTS.md`: ```md ## Token mode Default response style for agent work: - Use concise technical language. - Prefer Caveman lite style for normal progress updates. - Use Caveman full only when explicitly requested. - Do not compress code, commands, filenames, resource names, Azure names, API names, error messages, commit messages, or PR comments. - Drop Caveman style for security warnings, destructive actions, migration instructions, production deployment steps, or anything where ordering can be misunderstood. ``` ## GitHub Copilot and VS Code For GitHub Copilot and VS Code, prefer checked-in instructions over developer-specific global configuration. Recommended files: ```text .github/copilot-instructions.md .github/instructions/caveman.instructions.md ``` The repo-local instruction should say: ```text Use concise technical output. Use Caveman lite for short progress updates. Keep code, commands, file paths, resource names and error messages exact. Use normal precise language for security, destructive actions, migrations and production deployment. ``` Do not replace the full Frontis `copilot-instructions.md` with a generic Caveman rule file. ## Claude Code Caveman can be used in Claude Code through the Caveman skill/plugin and activation commands. Typical usage: ```text /caveman lite /caveman full normal mode ``` Recommended Frontis usage: ```text /caveman lite ``` For long implementation loops: ```text /caveman full ``` Return to normal language for: - warnings; - production steps; - destructive commands; - PR descriptions; - commit messages; - migration instructions. ## Codex For Codex, install Caveman only where it helps real coding-agent work. Recommended session prompt: ```text Use Superpowers workflow. Use Caveman lite for progress updates. Read AGENTS.md and .frontis/*.yaml before planning. Keep code, commands, filenames, Azure resource names, YAML keys and error messages exact. Use normal precise language for security, migrations, destructive actions and production deployment. ``` ## OpenCode For OpenCode, Caveman can be useful for long agentic development loops. Recommended Frontis startup: ```text Read AGENTS.md. Read .frontis/project.json and .frontis/*.yaml. Read https://docs.frontis.nl/ai/llms.txt when web access is available. Use Superpowers workflow. Use Caveman lite for progress updates. Keep technical identifiers exact. ``` Do not let Caveman replace OpenCode project rules or Frontis local conventions. ## OpenClaw When using OpenClaw, prefer a small persistent instruction that points to Frontis docs and uses Caveman lite. Recommended instruction: ```text Read https://docs.frontis.nl/ai/llms.txt. Follow Frontis repository bootstrap and conventions. Use Caveman lite for progress updates. Use normal precise language for security, destructive actions, migrations and production deployment. ``` If using Caveman's OpenClaw-specific installer, review changes to the OpenClaw workspace before relying on them. ## Caveman-compress Caveman-compress can rewrite memory or context files into shorter form. Use carefully. Allowed candidates: ```text CLAUDE.md AGENTS.md team-agent-notes.md long project notes ``` Do not run Caveman-compress on canonical machine-readable convention files: ```text .frontis/project.json .frontis/project-context.yaml .frontis/naming-convention.yaml .frontis/azure-conventions.yaml ``` Reason: - those files are contracts; - small changes can affect validators; - YAML structure and wording may be consumed by agents or tooling; - compression may remove useful clarity. If compressing a file: 1. commit or back up the original; 2. run compression; 3. review the diff; 4. verify that commands, paths, names and code blocks are unchanged; 5. commit only after human review. ## Commit messages Do not use Caveman style for commit messages. Commit messages should remain normal, clear and professional. Good: ```text Add Frontis agent documentation bootstrap ``` Bad: ```text Add docs. Agent use. Less word. ``` If using a Caveman commit helper, review and rewrite messages to match Frontis standards. ## Pull request comments Do not use Caveman style for final PR descriptions. PR descriptions should include: - what changed; - why it changed; - how it was verified; - risks; - rollout notes. Caveman may be used for temporary internal review notes, but final PR text should be normal and readable. ## Production and migration examples Bad Caveman migration instruction: ```text Drop col after backup maybe. Run script. Deploy. ``` Good normal instruction: ```text Before deploying the application change, create and verify a database backup. Then run the migration script in the maintenance window. After the migration completes successfully, deploy the application version that no longer reads the removed column. ``` Bad Caveman production instruction: ```text Delete $web. Upload new. Done. ``` Good normal instruction: ```text This deployment deletes all existing blobs in the `$web` container before uploading the generated documentation site. Confirm that the target storage account is the production documentation account and that the current build artifact contains `index.html`, `llms.txt`, and `llms-full.txt`. ``` ## Recommended prompts ### Enable concise mode ```text Use Caveman lite. Keep all code, commands, paths, Azure resource names, YAML keys and error messages exact. Use normal precise language for warnings, destructive actions, migrations and production deployment. ``` ### Enable full mode for long session ```text Use Caveman full for progress updates and simple explanations. Keep technical identifiers exact. Switch back to normal precise language when discussing security, destructive actions, migrations, production deployment, PR descriptions or commit messages. ``` ### Disable Caveman ```text normal mode ``` or: ```text stop caveman ``` ### Start Frontis agent session ```text Read AGENTS.md. Read .frontis/project.json. Read .frontis/project-context.yaml. Read .frontis/naming-convention.yaml. Read .frontis/azure-conventions.yaml if Azure, pipelines, hosting or deployment are involved. Read https://docs.frontis.nl/ai/llms.txt when web access is available. Use Superpowers workflow. Use Caveman lite for progress updates. Keep technical names exact. ``` ## Team policy Recommended policy for Frontis teams: ```text Default: Caveman lite Allowed on request: Caveman full Avoid: Caveman ultra Never: Caveman for security warnings, destructive actions, migrations, production deployments, commit messages, PR descriptions or client-facing documentation ``` For a 12-developer team, consistency matters more than maximum compression. Use one shared policy in repository files instead of personal prompt habits. ## Validation checklist After adding Caveman support to a repository, verify: ```text [ ] AGENTS.md includes token mode rules [ ] .github/instructions/caveman.instructions.md exists [ ] .github/copilot-instructions.md still references Frontis conventions [ ] local .frontis files remain canonical [ ] no installer overwrote Frontis-managed instructions [ ] code, commands, file paths and resource names are excluded from compression [ ] production and security exceptions are documented ``` If Caveman is installed globally, also verify: ```text [ ] target agent is detected [ ] activation command works [ ] normal mode disables Caveman [ ] repo-local rules still win over generic Caveman behavior ``` ## Troubleshooting If the agent is too verbose: ```text Use Caveman lite. Be concise. Keep technical identifiers exact. ``` If the agent is too compressed: ```text normal mode ``` or: ```text Use normal precise language. Do not use Caveman for this explanation. ``` If commands or filenames are being abbreviated: ```text Stop abbreviating technical identifiers. Keep commands, paths, filenames, YAML keys and Azure resource names exact. ``` If the agent uses Caveman for a risky operation: ```text Use normal precise language for this. Explain the risk, exact command, impact and rollback. ``` ## Anti-patterns Avoid: - making Caveman default for all human-facing documentation; - using Caveman full in PR descriptions; - using Caveman ultra in implementation plans; - compressing `.frontis/*.yaml`; - allowing installer-generated rules to overwrite Frontis rules; - treating token savings as more important than clarity; - abbreviating error messages; - abbreviating Azure resource names; - compressing production deployment order; - using Caveman to hide uncertainty. ## Completion summary format For Caveman-enabled work, use concise summaries like: ```text Done. Changed: - ... Verified: - ... Not verified: - ... Risk: - ... ``` For risky work, use normal precise language instead.