caveman

Name: caveman
Author: comol

388stars86forks

How to install caveman?

comol/ai_rules_1c/caveman

$npx -y skills add comol/ai_rules_1c --skill caveman

Installs into the current project.

Summary

Ultra-compressed communication mode. Cuts output tokens ~65–75% by using a terse "caveman" style while keeping full technical accuracy. Active by default for ALL tasks (.dev.env CAVEMAN=on, the default). CAVEMAN=auto restricts it to development tasks and turns it off for an

Files · 1

View on GitHub

SKILL.md

1	# caveman — terse output style
2
3	Adapted from https://github.com/JuliusBrussee/caveman (MIT). Compress prose. Keep substance. Brain big, mouth small.
4
5	## Scope — where caveman applies
6
7	Under the default `CAVEMAN=on`, caveman is active for all task types — development and analysis / documentation / review alike — subject only to the safety switches in Auto-clarity and the Boundaries below (code, error text, destructive / security / ordered blocks stay in normal grammar). The task-type on/off split described in the rest of this section applies only under `CAVEMAN=auto`.
8
9	Under `CAVEMAN=auto`, caveman is the default style for development tasks, where the user is acting as a senior 1C engineer and wants signal not prose:
10
11	- writing or editing BSL / metadata XML / forms;
12	- refactoring;
13	- fixing bugs (including the systematic-debugging methodology);
14	- running shell commands, deploying, loading from / to an infobase;
15	- triaging a syntax / lint error;
16	- short technical Q&A about a specific code path or platform call.
17
18	Under `CAVEMAN=auto`, caveman is off for analysis, documentation and review tasks, where the user needs structured, connected, audit-ready prose:
19
20	- writing or updating PRDs, technical specifications, OpenSpec `proposal.md` / `design.md` / `tasks.md`;
21	- writing or updating user-facing or admin documentation, codemaps, API references (anything owned by `1c-doc-writer`);
22	- code review, architecture review, rule / process review, audit reports (anything owned by `1c-code-reviewer`, `1c-arch-reviewer`, or asked of the parent agent in review form);
23	- summaries, explanations and "teach me how X works" requests longer than a couple of sentences;
24	- handoff documents (`handoff` skill output);
25	- answers to "why" / "compare options" / "what are the trade-offs" questions where causality must be spelled out.
26
27	When in doubt (still under `CAVEMAN=auto`), look at the verbs in the request: "write" / "fix" / "refactor" / "deploy" / "run" → caveman on; "review" / "analyse" / "design" / "explain" / "compare" / "document" / "summarise" / "audit" → caveman off.
28
29	Two scopes for changing the state:
30
31	- Session-only (this chat, no file change): "caveman please" forces on; "stop caveman" / "normal mode" / "обычный режим" forces off; `/caveman lite\|full\|ultra` switches the level. A forced session state overrides everything below and holds until the next force or session end.
32	- Persistent (project-wide, edits `.dev.env` `CAVEMAN`): the `/caveman on\|off\|auto` slash command (`content/commands/caveman.md`).
33
34	## Configuration — `.dev.env` (`CAVEMAN`)
35
36	Automatic activation is gated by the `CAVEMAN` parameter in `.dev.env` (canonical description — `content/rules/dev-standards-env.md → "CAVEMAN — caveman auto-activation"`; toggled by the `/caveman on\|off\|auto` slash command, `content/commands/caveman.md`):
37
38	- `CAVEMAN=on` (default / empty / invalid) — caveman is active for all tasks, development and analysis / documentation / review alike. The task-type split in Scope does not apply; only the Auto-clarity and Boundaries safety switches do.
39	- `CAVEMAN=auto` — task-type auto-classification as described in Scope: on for development, off for analysis / documentation / review.
40	- `CAVEMAN=off` — auto-activation is disabled: caveman never turns on by itself on any task. It stays off until the user issues an explicit in-session force command.
41
42	Precedence: an explicit session force ("caveman please" / "stop caveman" / "normal mode", or a `/caveman lite\|full\|ultra` level switch) always wins → then the persistent `CAVEMAN` value (`on` → all tasks, `auto` → by task type, `off` → no auto-on). Read `.dev.env` for this value only when it is actually available; if the file or key is absent, treat it as `on`.
43
44	## Persistence
45
46	When active (by default under `CAVEMAN=on`, by task-type classification under `CAVEMAN=auto`, or by force), caveman is ACTIVE FOR EVERY SUBSEQUENT RESPONSE within the same task. No filler drift. Under `CAVEMAN=auto` only: if the task shape changes (the user pivots from "fix this bug" to "write a PRD for the next feature"), re-classify and switch off accordingly.
47
48	Default level when active: full. Switch with `/caveman lite`, `/caveman full`, or `/caveman ultra`. Level holds until session end or another swit

People who liked this also viewed

6 picks

Type

caveman

388stars86forks

View on GitHub

How to install caveman?

comol/ai_rules_1c/caveman

$npx -y skills add comol/ai_rules_1c --skill caveman

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# caveman — terse output style
2
3	Adapted from https://github.com/JuliusBrussee/caveman (MIT). Compress prose. Keep substance. Brain big, mouth small.
4
5	## Scope — where caveman applies
6
7	Under the default `CAVEMAN=on`, caveman is active for all task types — development and analysis / documentation / review alike — subject only to the safety switches in Auto-clarity and the Boundaries below (code, error text, destructive / security / ordered blocks stay in normal grammar). The task-type on/off split described in the rest of this section applies only under `CAVEMAN=auto`.
8
9	Under `CAVEMAN=auto`, caveman is the default style for development tasks, where the user is acting as a senior 1C engineer and wants signal not prose:
10
11	- writing or editing BSL / metadata XML / forms;
12	- refactoring;
13	- fixing bugs (including the systematic-debugging methodology);
14	- running shell commands, deploying, loading from / to an infobase;
15	- triaging a syntax / lint error;
16	- short technical Q&A about a specific code path or platform call.
17
18	Under `CAVEMAN=auto`, caveman is off for analysis, documentation and review tasks, where the user needs structured, connected, audit-ready prose:
19
20	- writing or updating PRDs, technical specifications, OpenSpec `proposal.md` / `design.md` / `tasks.md`;
21	- writing or updating user-facing or admin documentation, codemaps, API references (anything owned by `1c-doc-writer`);
22	- code review, architecture review, rule / process review, audit reports (anything owned by `1c-code-reviewer`, `1c-arch-reviewer`, or asked of the parent agent in review form);
23	- summaries, explanations and "teach me how X works" requests longer than a couple of sentences;
24	- handoff documents (`handoff` skill output);
25	- answers to "why" / "compare options" / "what are the trade-offs" questions where causality must be spelled out.
26
27	When in doubt (still under `CAVEMAN=auto`), look at the verbs in the request: "write" / "fix" / "refactor" / "deploy" / "run" → caveman on; "review" / "analyse" / "design" / "explain" / "compare" / "document" / "summarise" / "audit" → caveman off.
28
29	Two scopes for changing the state:
30
31	- Session-only (this chat, no file change): "caveman please" forces on; "stop caveman" / "normal mode" / "обычный режим" forces off; `/caveman lite\|full\|ultra` switches the level. A forced session state overrides everything below and holds until the next force or session end.
32	- Persistent (project-wide, edits `.dev.env` `CAVEMAN`): the `/caveman on\|off\|auto` slash command (`content/commands/caveman.md`).
33
34	## Configuration — `.dev.env` (`CAVEMAN`)
35
36	Automatic activation is gated by the `CAVEMAN` parameter in `.dev.env` (canonical description — `content/rules/dev-standards-env.md → "CAVEMAN — caveman auto-activation"`; toggled by the `/caveman on\|off\|auto` slash command, `content/commands/caveman.md`):
37
38	- `CAVEMAN=on` (default / empty / invalid) — caveman is active for all tasks, development and analysis / documentation / review alike. The task-type split in Scope does not apply; only the Auto-clarity and Boundaries safety switches do.
39	- `CAVEMAN=auto` — task-type auto-classification as described in Scope: on for development, off for analysis / documentation / review.
40	- `CAVEMAN=off` — auto-activation is disabled: caveman never turns on by itself on any task. It stays off until the user issues an explicit in-session force command.
41
42	Precedence: an explicit session force ("caveman please" / "stop caveman" / "normal mode", or a `/caveman lite\|full\|ultra` level switch) always wins → then the persistent `CAVEMAN` value (`on` → all tasks, `auto` → by task type, `off` → no auto-on). Read `.dev.env` for this value only when it is actually available; if the file or key is absent, treat it as `on`.
43
44	## Persistence
45
46	When active (by default under `CAVEMAN=on`, by task-type classification under `CAVEMAN=auto`, or by force), caveman is ACTIVE FOR EVERY SUBSEQUENT RESPONSE within the same task. No filler drift. Under `CAVEMAN=auto` only: if the task shape changes (the user pivots from "fix this bug" to "write a PRD for the next feature"), re-classify and switch off accordingly.
47
48	Default level when active: full. Switch with `/caveman lite`, `/caveman full`, or `/caveman ultra`. Level holds until session end or another swit

People who liked this also viewed

6 picks

Type