enigma-cli 1.16.17 → 1.17.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (29) hide show
  1. package/README.md +10 -14
  2. package/assets/commands/improve.md +2 -0
  3. package/assets/memory/AGENTS.md +2 -0
  4. package/assets/memory/CLAUDE.md +2 -0
  5. package/assets/skills/anti-overengineering-policy/SKILL.md +33 -0
  6. package/assets/skills/anti-overengineering-policy/skill.json +3 -3
  7. package/assets/skills/anti-overengineering-review/skill.json +1 -1
  8. package/assets/skills/backend-policy/skill.json +1 -1
  9. package/assets/skills/ciphera-style-policy/skill.json +1 -1
  10. package/assets/skills/code-review-policy/skill.json +1 -1
  11. package/assets/skills/core-engineering-policy/SKILL.md +2 -0
  12. package/assets/skills/core-engineering-policy/skill.json +3 -3
  13. package/assets/skills/database-expert/skill.json +1 -1
  14. package/assets/skills/debugging-policy/skill.json +1 -1
  15. package/assets/skills/dependency-policy/skill.json +1 -1
  16. package/assets/skills/frontend-design/SKILL.md +1 -1
  17. package/assets/skills/frontend-design/skill.json +3 -3
  18. package/assets/skills/frontend-policy/skill.json +1 -1
  19. package/assets/skills/git-policy/SKILL.md +41 -0
  20. package/assets/skills/git-policy/skill.json +3 -3
  21. package/assets/skills/security-policy/skill.json +1 -1
  22. package/assets/skills/skill-creator/skill.json +1 -1
  23. package/assets/skills/task-completion-policy/skill.json +1 -1
  24. package/assets/skills/technical-writing-policy/SKILL.md +70 -0
  25. package/assets/skills/technical-writing-policy/skill.json +8 -0
  26. package/assets/skills/testing-policy/skill.json +1 -1
  27. package/assets/skills/validation-policy/skill.json +1 -1
  28. package/bin/checksums.json +4 -4
  29. package/package.json +1 -1
package/README.md CHANGED
@@ -8,16 +8,9 @@ committed.
8
8
 
9
9
  ## Install
10
10
 
11
- Recommended - install the `enigma` command globally, then run the interactive hub:
12
-
13
- ```bash
14
- npm install -g enigma-cli@latest # provides the `enigma` command
15
- enigma # interactive hub: pick what to set up
16
- ```
17
-
18
- Or via the install script (clears the npm cache, installs the latest version, then
19
- runs `enigma install` **interactively** so you choose what to set up - handy where npm
20
- `postinstall` scripts are disabled):
11
+ Recommended - run the install script (clears the npm cache, installs the latest
12
+ version, then runs `enigma install` **interactively** so you choose what to set up -
13
+ handy where npm `postinstall` scripts are disabled):
21
14
 
22
15
  ```bash
23
16
  # macOS / Linux
@@ -27,6 +20,13 @@ curl -fsSL https://raw.githubusercontent.com/FJRG2007/enigma/main/scripts/instal
27
20
  irm https://raw.githubusercontent.com/FJRG2007/enigma/main/scripts/install.ps1 | iex
28
21
  ```
29
22
 
23
+ Or install the `enigma` command globally, then run the interactive hub:
24
+
25
+ ```bash
26
+ npm install -g enigma-cli@latest # provides the `enigma` command
27
+ enigma # interactive hub: pick what to set up
28
+ ```
29
+
30
30
  Or one-shot, no global install, no prompts - deploy the skills to every supported
31
31
  agent at user level:
32
32
 
@@ -485,10 +485,6 @@ enigma compress --clear # wipe all dashboard data (stats/his
485
485
  <img src="https://github.com/FJRG2007/enigma/blob/main/docs/images/dashboard.png?raw=true" alt="enigma dashboard" width="100%">
486
486
  <br><sub>Savings view (auto-generated from the current UI; mock data shown).</sub>
487
487
  </p>
488
- <p align="center">
489
- <img src="https://github.com/FJRG2007/enigma/blob/main/docs/images/usage.png?raw=true" alt="enigma Claude usage" width="100%">
490
- <br><sub>Claude usage view: real session/weekly windows, cost, and per-account/model breakdowns.</sub>
491
- </p>
492
488
 
493
489
  `enigma dashboard` (alias `dash`) serves a local, loopback-only browser dashboard
494
490
  of the token savings - totals, **estimated money saved**, average/best per call, a
@@ -40,6 +40,8 @@ Disambiguation: a bare `security` or `performance` runs Implement mode and edits
40
40
 
41
41
  Make the smallest change that achieves the improvement; do not rewrite working code without a concrete reason. Apply changes incrementally, keep them reviewable, and explain each briefly. Never trade away security, accessibility, or correctness to gain another goal. After editing, run the project's build, lint, and test commands when they exist and report the results - do not claim success without verification.
42
42
 
43
+ Verify a change the way its effect actually shows: a UI change by rendering the screen and looking at it (take a screenshot if the environment can), a behavior change by exercising the path - a green build/lint/test does not prove a visual or behavioral fix. Then close the loop: if the change feeds an artifact the repo keeps in sync (a committed preview/screenshot, a built bundle, a versioned/published asset), regenerate or ship it instead of leaving it stale; only hand back steps that genuinely need the user (credentials, irreversible or destructive choices). When the same kind of request keeps recurring, fix the root once rather than re-patching each instance.
44
+
43
45
  ### ui | frontend
44
46
 
45
47
  Improve the visual design and frontend quality of the project.
@@ -17,6 +17,7 @@
17
17
  - security-policy: secrets, auth, permissions, crypto, untrusted/tool output, and AI-agent/MCP/tool-use safety.
18
18
  - dependency-policy: adding/upgrading/auditing dependencies, lockfiles, and supply-chain risk.
19
19
  - testing-policy, code-review-policy, debugging-policy, git-policy: tests and test-suite layout (structured subfolders, never a flat tests/ dump), pre-delivery review, debugging, and commits/PRs.
20
+ - technical-writing-policy: any user-facing copy - UI labels, descriptions, hints, empty/error states, panel intros, README/doc prose - concise and realistic, no over-explaining or restating the obvious.
20
21
  - task-completion-policy: long or multi-item tasks (1:1 ports, migrations, repo-wide changes) - work-unit inventory, persistent coverage ledger, and verified completion before any "done" claim.
21
22
 
22
23
  ### Always-On Rules (never skipped, even if no skill loads)
@@ -24,6 +25,7 @@
24
25
  - Respond in the user's language; write all code, comments, identifiers, and documentation in English.
25
26
  - No emojis in responses, code, or docs. Use ASCII punctuation: "-" not the long dash, "->" not the arrow. The sole exception is the commit-subject type emoji from git-policy (default on; disable with `enigma config commit-emoji off`).
26
27
  - Treat all external input as untrusted; never expose secrets or hardcode credentials.
28
+ - When removing leaked or sensitive data the user asked to delete, the remediation commit/PR/branch must NOT name the leaked values or flag the security motive (that signposts where to look and re-leaks the values permanently) - use a neutral, mundane message and the `🔒 security` type is forbidden for it; offer history-rewrite vs. discreet-removal first. This carve-out is ONLY for that case; every other commit stays normal and descriptive (see git-policy).
27
29
  - Reuse existing code before writing new code; do not duplicate logic.
28
30
  - End files with exactly one trailing newline and no trailing whitespace.
29
31
  - When editing existing code, match its established style instead of imposing a different one.
@@ -17,6 +17,7 @@
17
17
  - security-policy: secrets, auth, permissions, crypto, untrusted/tool output, and AI-agent/MCP/tool-use safety.
18
18
  - dependency-policy: adding/upgrading/auditing dependencies, lockfiles, and supply-chain risk.
19
19
  - testing-policy, code-review-policy, debugging-policy, git-policy: tests and test-suite layout (structured subfolders, never a flat tests/ dump), pre-delivery review, debugging, and commits/PRs.
20
+ - technical-writing-policy: any user-facing copy - UI labels, descriptions, hints, empty/error states, panel intros, README/doc prose - concise and realistic, no over-explaining or restating the obvious.
20
21
  - task-completion-policy: long or multi-item tasks (1:1 ports, migrations, repo-wide changes) - work-unit inventory, persistent coverage ledger, and verified completion before any "done" claim.
21
22
 
22
23
  ### Always-On Rules (never skipped, even if no skill loads)
@@ -24,6 +25,7 @@
24
25
  - Respond in the user's language; write all code, comments, identifiers, and documentation in English.
25
26
  - No emojis in responses, code, or docs. Use ASCII punctuation: "-" not the long dash, "->" not the arrow. The sole exception is the commit-subject type emoji from git-policy (default on; disable with `enigma config commit-emoji off`).
26
27
  - Treat all external input as untrusted; never expose secrets or hardcode credentials.
28
+ - When removing leaked or sensitive data the user asked to delete, the remediation commit/PR/branch must NOT name the leaked values or flag the security motive (that signposts where to look and re-leaks the values permanently) - use a neutral, mundane message and the `🔒 security` type is forbidden for it; offer history-rewrite vs. discreet-removal first. This carve-out is ONLY for that case; every other commit stays normal and descriptive (see git-policy).
27
29
  - Reuse existing code before writing new code; do not duplicate logic.
28
30
  - End files with exactly one trailing newline and no trailing whitespace.
29
31
  - When editing existing code, match its established style instead of imposing a different one.
@@ -35,6 +35,39 @@ higher one and move on. The first lazy solution that works is the right one.
35
35
  - Complex request? Ship the lazy version and question it in the same response: "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
36
36
  - Two stdlib options the same size? Take the one that is correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.
37
37
 
38
+ ## Collapsing Repetition (DRY) and the Optimization Ladder
39
+
40
+ Sibling statements that differ only by a value are duplication waiting to drift.
41
+ Collapse them into one data-driven loop over a single list - that is deletion, the
42
+ core minimal-code move, not an added abstraction:
43
+
44
+ ```js
45
+ // Before: five lines that must stay in lockstep (and the id list is duplicated
46
+ // in the validity check above them).
47
+ $("view-savings").style.display = v === "savings" ? "" : "none";
48
+ $("view-usage").style.display = v === "usage" ? "" : "none";
49
+ // ...three more
50
+
51
+ // After: one source of truth, one loop. Adding a view becomes a one-word edit.
52
+ const VIEWS = ["savings", "usage", "accounts", "skills", "settings"];
53
+ VIEWS.forEach((view) => { $("view-" + view).style.display = view === v ? "" : "none"; });
54
+ ```
55
+
56
+ Hoist the list to ONE constant whenever more than one place needs it (here the
57
+ membership check and the loop), so the set can never disagree with itself.
58
+
59
+ Then climb the optimization ladder only as far as the call frequency earns:
60
+
61
+ 1. Collapse the repetition (above). Always worth it - fewer lines, one source of truth.
62
+ 2. Hoist invariant work out of the hot path: build the constant array/regex once at module
63
+ scope, not on every call.
64
+ 3. Precompute or cache only when the path is genuinely hot - a render loop, per-frame,
65
+ per-item at scale, or a profiler pointing at it. Caching DOM lookups, memoizing, or
66
+ building a lookup map for code that runs on a user action (navigation, a click, a form
67
+ submit) is premature: the saving is unmeasurable and the cache is state you must keep in
68
+ sync. `full` means the shortest correct diff, NOT a speculative cache - stop at the rung
69
+ the frequency justifies, and if you knowingly skip a real optimization, mark it `enigma:`.
70
+
38
71
  ## Marking Deliberate Shortcuts
39
72
 
40
73
  Mark intentional simplifications with an `enigma:` comment so a simple read is
@@ -1,8 +1,8 @@
1
1
  {
2
2
  "name": "anti-overengineering-policy",
3
- "version": "1.1.0",
3
+ "version": "1.2.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Minimal-code discipline - YAGNI ladder, deletion over addition, no unrequested abstractions, and the enigma: shortcut-marking convention; intensity via the minimal-code setting.",
6
- "cliVersion": "1.16.17",
7
- "sha": "3469a7e554b63a5ae3b1a4a127a0765d760649511fa9dfa9cdbcb04b4431fd64"
6
+ "cliVersion": "1.17.0",
7
+ "sha": "b9517e7d520e83a9f881fb1917ca2d4cec4aea4f2c5e753ea02641d9bc06c6b6"
8
8
  }
@@ -3,6 +3,6 @@
3
3
  "version": "1.0.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "On-demand over-engineering review - diff review, whole-repo audit, and enigma: debt-marker ledger (tags delete/stdlib/native/yagni/shrink, line/dep scoring); lists cuts, applies nothing.",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "f742a2be3f328b9ea1ff9a35a449177c2cbec35ad16e46f7054b7a873a2ab017"
8
8
  }
@@ -3,6 +3,6 @@
3
3
  "version": "1.1.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Backend/API architecture: controller-service-repository layering, API and request optimization, server-side caching (Redis), and Zod boundary validation.",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "a46c3cd00aa5f47adb1e7907f1d2bc6f5562f7a272890dee9b1121976ac04ae1"
8
8
  }
@@ -3,6 +3,6 @@
3
3
  "version": "1.1.1",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Ciphera code style conventions (formatting, naming, imports, comments, code-level anti-patterns; TypeScript-first, language-agnostic).",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "74f638aec13e8c93257fe1ad604c28b07e9a7c456796a4ceefcc99217d9e7039"
8
8
  }
@@ -3,6 +3,6 @@
3
3
  "version": "1.0.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Pre-delivery self-review gate, prioritized review dimensions, and change-quality criteria.",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "3d3bbe0602d5bbb4afe37648fe3c2fa39376b1bcbac5d8c441f01fad1e866ed0"
8
8
  }
@@ -40,6 +40,7 @@ description: Highest-authority engineering rules - priority hierarchy, modular a
40
40
  - Before declaring a change done, or when reviewing a diff/PR -> code-review-policy.
41
41
  - Any bug, crash, failing test, or unexpected behavior -> debugging-policy.
42
42
  - Any commit, branch, or pull request -> git-policy.
43
+ - Any user-facing copy (UI labels, descriptions, hints, empty/error states, panel intros, README/doc prose) -> technical-writing-policy.
43
44
  - Any long, multi-item, or porting/migration task (1:1 ports, "migrate all", repo-wide changes, work spanning many files or sessions) -> task-completion-policy.
44
45
  - When a task spans multiple domains, compose the relevant skills instead of re-deriving their rules.
45
46
  - Never duplicate a specialized skill's rules inside another skill; reference it.
@@ -85,6 +86,7 @@ This core policy owns orchestration, architecture, and the global rules. Each co
85
86
  - code-review-policy: self-review before delivery, review dimensions, change-quality gates.
86
87
  - debugging-policy: reproduce-isolate-fix methodology and root-cause discipline.
87
88
  - git-policy: commits, branches, and pull request standards.
89
+ - technical-writing-policy: concise, realistic user-facing copy - UI microcopy, labels, descriptions, hints, empty/error states, panel intros, and README/doc prose that informs without over-explaining, restating the obvious, or leaking implementation detail.
88
90
  - ciphera-style-policy: Ciphera code style conventions - formatting, naming, quotes, string interpolation, length-sorted imports, indentation, comments/JSDoc, and code-level anti-patterns (TypeScript-first, language-agnostic).
89
91
  - anti-overengineering-policy: minimal-code discipline - the YAGNI ladder (stdlib/native/installed-dependency/one-line before custom code), deletion over addition, no unrequested abstractions, the enigma: shortcut-marking convention, and intensity via the minimal-code setting. Owns the detail behind the Anti-Overengineering Rule below.
90
92
  - anti-overengineering-review: on-demand complexity-only review - diff review, whole-repo audit, and the enigma: debt-marker ledger (tags delete/stdlib/native/yagni/shrink, line/dep scoring). Lists cuts, applies nothing; correctness/security/performance stay with code-review-policy.
@@ -1,8 +1,8 @@
1
1
  {
2
2
  "name": "core-engineering-policy",
3
- "version": "1.9.0",
3
+ "version": "1.10.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Core engineering execution policy and harness orchestration (highest-authority rules).",
6
- "cliVersion": "1.16.17",
7
- "sha": "82d246faa4770248a36f143926fbf06bd3ffc082959014184548b57193770fab"
6
+ "cliVersion": "1.17.0",
7
+ "sha": "5e68e2a25c8e3dac6251562062f7fe4c57143baaaee8fd6de83adca9ec24a6e6"
8
8
  }
@@ -3,6 +3,6 @@
3
3
  "version": "1.1.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Senior database architecture policy: query optimization, anti-duplication/normalization, scalability, and RGPD/GDPR encryption.",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "2883bcecb3202683ae6f81b073c3d6a9cec9c55029e011bdd06ba7ac3537297e"
8
8
  }
@@ -3,6 +3,6 @@
3
3
  "version": "1.0.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Reproduce-isolate-fix debugging methodology with root-cause discipline and regression verification.",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "14b0064c8b33a0dc85e51464b05005cf5801c756b1101789a6924b9548420f6b"
8
8
  }
@@ -3,6 +3,6 @@
3
3
  "version": "1.0.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Dependency and supply-chain security: lockfiles and reproducible installs, version pinning, vulnerability auditing, vetting/minimizing packages, vendoring, and SBOM/provenance.",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "6375d835c2aef2c9bd31ce116444dc3d796f510f9970a213aa3ac4696d7e21b9"
8
8
  }
@@ -39,7 +39,7 @@ Try to do a lot of this planning and iteration in your thinking, and only show i
39
39
 
40
40
  ## Restraint and self-critique
41
41
 
42
- Spend your boldness in one place. Let the signature element be the one memorable thing, keep everything around it quiet and disciplined, and cut any decoration that does not serve the brief. Not taking a risk can be a risk itself! Build to a quality floor without announcing it: responsive down to mobile, visible keyboard focus, reduced motion respected. Critique your own work as you build, taking screenshots if your environment supports it – a picture is worth 1000 tokens. Consider Chanel's advice: before leaving the house, take a look in the mirror and remove one accessory. Human creators have memory and always try to do something new, so if you have a space to quickly jot down notes about what you've tried, it can help you in future passes.
42
+ Spend your boldness in one place. Let the signature element be the one memorable thing, keep everything around it quiet and disciplined, and cut any decoration that does not serve the brief. Not taking a risk can be a risk itself! Build to a quality floor without announcing it: responsive down to mobile, visible keyboard focus, reduced motion respected, and native browser chrome themed to the design rather than left as platform defaults. Default scrollbars and unstyled form controls read as templated next to a deliberate design; modern CSS brings them into the system - scrollbars via `scrollbar-width` / `scrollbar-color` (plus `::-webkit-scrollbar` on WebKit), and `<select>` and other form controls via `appearance` and accent/background/border overrides. Theme every scrollable region (code blocks, overflow panes, long lists) and every native control, not just the obvious ones. Check every interactive state for contrast: a hover/focus/active rule must never set text to the colour of its own background - a global `a:hover { color: accent }` will silently make an accent-filled button's label vanish, so hold an explicit on-accent text colour on accent surfaces. A link styled as a button is still an anchor, so it inherits the browser's default underline: a button never carries underlined text unless the design explicitly asks for it, so set `text-decoration: none` on the button class itself rather than relying on a global reset. Reserve underline for inline text links, where it signals "this is a link" inside running copy. For known services use a real icon (an SVG set reused from one place), not a text label, and make sure any logo contrasts with its background - a black mark on a dark UI must be recoloured (e.g. white) or it disappears. Critique your own work as you build, taking screenshots if your environment supports it – a picture is worth 1000 tokens. Consider Chanel's advice: before leaving the house, take a look in the mirror and remove one accessory. Human creators have memory and always try to do something new, so if you have a space to quickly jot down notes about what you've tried, it can help you in future passes.
43
43
 
44
44
  ## More on writing in design
45
45
 
@@ -1,8 +1,8 @@
1
1
  {
2
2
  "name": "frontend-design",
3
- "version": "1.0.0",
3
+ "version": "1.3.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one.",
6
- "cliVersion": "1.16.17",
7
- "sha": "431645565aec8a4ab4cd17247139f78c377a9bcfcfc4ee1d6f252199c332d86f"
6
+ "cliVersion": "1.17.0",
7
+ "sha": "c515f8406368ad3b2a4a8acf979fab34def2a94b1a7a4ffc7d6d47a4ac079ee6"
8
8
  }
@@ -3,6 +3,6 @@
3
3
  "version": "1.3.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Frontend architecture: reusable components, abstraction thresholds, state management, no-op save detection, large-list rendering (infinite scroll/pagination, virtualization, skeletons, progressive loading), and optimistic UI with rollback.",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "26962db5a8b607e95098a6d88977aee59a10bd14e03afe97245f2b013fd21a9a"
8
8
  }
@@ -108,6 +108,47 @@ description: Commit, branch, and pull request standards - conventional commits,
108
108
 
109
109
  ---
110
110
 
111
+ ## Removing Leaked or Sensitive Data (Discreet-Commit Carve-Out)
112
+
113
+ Applies ONLY when remediating sensitive data the user wants removed from a repository - a
114
+ committed secret, credential, private path, internal/customer name, PII value, or an asset
115
+ rendered from one (e.g. a screenshot). For every other commit, including ordinary security
116
+ fixes and hardening, ignore this section and use the normal descriptive conventional-commit
117
+ rules above.
118
+
119
+ When such a removal is requested, FIRST present the remediation choices and let the user
120
+ decide (visibility and irreversibility are their call), then act:
121
+
122
+ 1. Rewrite history (`git filter-repo` / BFG + force-push) - the only option that truly
123
+ removes the data. Warn that it is destructive, rewrites shared history (all later SHAs
124
+ change), needs a force-push (often to a protected branch), and that mirrors, forks,
125
+ CDN/raw caches and archives may still retain copies.
126
+ 2. Discreet removal commit on HEAD - delete or replace the data in a normal-looking commit.
127
+ Non-destructive and low-effort, but the data stays recoverable in older commits and
128
+ caches; it is hidden in plain sight, not erased.
129
+
130
+ Whichever path is chosen, the remediation commit (and any PR) MUST be unremarkable. A
131
+ message that announces the exposure is itself a vulnerability: it points anyone scanning the
132
+ history at exactly which commit to diff and what to look for, and - if it quotes the values -
133
+ re-leaks them permanently into the message. So, in this case only:
134
+
135
+ - Do NOT put leak, secret, credential, exposure, PII, "sensitive", "redact", "scrub" or
136
+ "hidden" in the subject or body, and do NOT use the `🔒 security` type. Frame it as the
137
+ mundane, truthful surface change it also is (a `chore`/`refactor`/`docs`/`build` cleanup,
138
+ a preview refresh, an asset removal) so it blends into the surrounding history.
139
+ - NEVER reproduce the leaked values anywhere - not in the message, branch name, or PR - and
140
+ do not even name which identifiers or paths were removed.
141
+ - Keep it atomic, but if it helps the change not stand out, fold it into a plausible
142
+ neighbouring change rather than letting it sit alone as "the commit that removed something".
143
+ - The message must still be accurate about WHAT changed at the file level (never a bare
144
+ "fix"/"update"); it simply omits WHY.
145
+
146
+ Communicate the security context (what was exposed, that history and caches still hold it,
147
+ and any required credential rotation - a committed secret is burned even after deletion) to
148
+ the user in chat, NOT in the commit, PR title, or branch name.
149
+
150
+ ---
151
+
111
152
  ## Pull Request Engineering Standards
112
153
 
113
154
  ### PR Creation Rules
@@ -1,8 +1,8 @@
1
1
  {
2
2
  "name": "git-policy",
3
- "version": "1.3.0",
3
+ "version": "1.4.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Git & contribution policy (senior engineering standards).",
6
- "cliVersion": "1.16.17",
7
- "sha": "73a978ef11f4def067f9252fc3e2e6aa737a08b6d58ad8a2a45cbcd4b02813f6"
6
+ "cliVersion": "1.17.0",
7
+ "sha": "9298bf572c6186de65bfae5cc008af247731fac3e07d9320ddfc12fe886d6afe"
8
8
  }
@@ -3,6 +3,6 @@
3
3
  "version": "1.0.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Application and AI-agent security: secrets, authn/authz (least privilege), OWASP Top 10, transport/crypto baseline, secure logging, and agent/MCP/tool-use safety.",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "9971e9d9127397d0152e89d24aad3191e2935e55a8483db7fd15f5d4d7a60e7a"
8
8
  }
@@ -3,6 +3,6 @@
3
3
  "version": "1.0.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Create new skills, modify and improve existing skills, and measure skill performance with evals and benchmarks.",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "699586cce82ec0a5458288b598ee7e5ebdddb3dfcf19db354d8bc5e85e47c1c7"
8
8
  }
@@ -3,6 +3,6 @@
3
3
  "version": "1.1.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Exhaustive completion discipline for long/multi-item tasks - inventory, coverage ledger, verified done.",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "6e3facba307eb2b55cefbab2e4b2a346a2b82f93c3ef47e11ebeb78c3c9453a8"
8
8
  }
@@ -0,0 +1,70 @@
1
+ ---
2
+ name: technical-writing-policy
3
+ description: Concise, realistic technical copy - UI microcopy, labels, descriptions, setting hints, empty/error states, and README/doc prose that informs without over-explaining, restating the obvious, or leaking implementation detail. Use whenever writing or reviewing user-facing text: a dashboard/app label or description, a settings hint, a panel intro, a button, a skill/package description, a README section, or any doc copy. Also use when the user complains that descriptions are too long, over-explained, obvious, or "cutre".
4
+ ---
5
+
6
+ # Technical Writing Policy (Concise, Realistic Copy)
7
+
8
+ User-facing text is design material, not decoration. Every word must earn its place.
9
+ Give the reader exactly what they need to act - not less, not more. This policy owns
10
+ descriptive copy: labels, descriptions, hints, empty/error states, panel intros, and
11
+ README/doc prose. Commit/PR prose is owned by git-policy; visual design by frontend-design.
12
+
13
+ ## Core Principle
14
+
15
+ A description says, in plain terms, WHAT a thing is or does and why the reader should
16
+ care - from the reader's side of the screen. It is not a tutorial, not a changelog, not
17
+ a spec, and not a place to show your work.
18
+
19
+ The test for every sentence: **would removing it lose information the reader needs to act
20
+ or decide?** If not, cut it. If you can't remember a button's exact label, it's good
21
+ microcopy - the reader shouldn't have to study it.
22
+
23
+ ## The Cardinal Sins (cut these)
24
+
25
+ 1. **Narrating the obvious.** Do not describe the controls the reader can already see.
26
+ "Edit a skill's content, disable/enable or remove it" next to Edit/Disable/Remove
27
+ buttons tells the reader nothing - they can see the buttons. Describe the *thing*, not
28
+ the toolbar around it.
29
+ 2. **Leaking implementation detail.** The reader does not need the internals. A password
30
+ form does not say "hashed with SHA-256"; a sync feature does not list its diff
31
+ algorithm. Surface mechanism only when the reader must act on it (a security warning, a
32
+ destructive-action caveat, a real constraint they hit).
33
+ 3. **Redundant cross-references and meta-commentary.** "...the same as the terminal UI",
34
+ "as mentioned above", "this section explains..." - filler that orients nothing. State
35
+ the thing directly.
36
+ 4. **Hedging and marketing.** "powerful", "simply", "just", "seamless", "robust", "in
37
+ order to". Plain verbs and concrete nouns instead.
38
+ 5. **Restating the heading.** A panel titled "Accounts" whose intro begins "Manage your
39
+ accounts" wastes the first line. Add information the title does not already carry.
40
+
41
+ ## Rules
42
+
43
+ - Name things by what the reader controls and recognizes, not by how the system is built
44
+ (a person manages *notifications*, not *webhook config*).
45
+ - Be specific over clever: "Resets Monday 11:00" beats "Resets soon".
46
+ - Match length to the slot: a setting hint is one line; a panel/page intro is one sentence
47
+ of orientation plus, only if needed, one of consequence (a caveat, a default, a cost).
48
+ An empty state is one line that invites the next action.
49
+ - Active voice, present tense, sentence case. The control names the exact action ("Save
50
+ changes", not "Submit"); the same verb survives the whole flow (Publish -> "Published").
51
+ - Errors say what went wrong and how to fix it, in the interface's voice - never vague,
52
+ never an apology, never a raw stack trace or internal error to the user.
53
+ - Be realistic, not aspirational: describe what it actually does today, not the roadmap.
54
+ - READMEs: assume a competent reader. Explain what is non-obvious or load-bearing (how to
55
+ run it, the one surprising constraint, why a choice was made) and skip what the audience
56
+ already knows or can infer from the code. Lead with the point; cut the throat-clearing.
57
+
58
+ ## Reviewing existing copy
59
+
60
+ When asked to fix "bad"/over-explained descriptions: read each line and delete what fails
61
+ the test above. Prefer one tight sentence over three padded ones. Keep every load-bearing
62
+ fact (a real constraint, a default, a cost, a security caveat); cut everything that only
63
+ restates the obvious or narrates the UI. Report what you cut and why in one line.
64
+
65
+ ## Boundaries
66
+
67
+ - Respond in the user's language; copy itself is written in the project's language
68
+ (English here) per core-engineering-policy.
69
+ - Commit messages and PR text: git-policy. Visual/typographic design: frontend-design.
70
+ Validation/error-handling logic: validation-policy. This policy governs the words.
@@ -0,0 +1,8 @@
1
+ {
2
+ "name": "technical-writing-policy",
3
+ "version": "1.0.0",
4
+ "provider": "FJRG2007/enigma",
5
+ "description": "Concise, realistic technical copy - UI microcopy, descriptions, hints, empty/error states, and README/doc prose that informs without over-explaining or restating the obvious.",
6
+ "cliVersion": "1.17.0",
7
+ "sha": "647a896d9e6178cd109c475aae91cb98f465c2fae5e4e1eeaab951829832ac4c"
8
+ }
@@ -3,6 +3,6 @@
3
3
  "version": "1.2.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Test strategy, coverage gates, deterministic tests, mocking discipline, regression-first bug fixing, and test-suite organization (layout by type/domain, mirrored paths, file naming, fixture/helper placement).",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "3bdf591057b760f674fb2b1425f63acb426cda2c4f042e1a74c5a5d3807df664"
8
8
  }
@@ -3,6 +3,6 @@
3
3
  "version": "1.0.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Strict frontend + backend schema validation, schema consistency, and safe client-facing error handling.",
6
- "cliVersion": "1.16.17",
6
+ "cliVersion": "1.17.0",
7
7
  "sha": "a33622a2f810ee4cea39824cb1a7ca34b355a917d4224025df50d77dd74f0b3a"
8
8
  }
@@ -1,6 +1,6 @@
1
1
  {
2
- "enigma-darwin-arm64": "937ade3cd10a0005c3c3c159369a548aded0cd0725102f82dcfebafd04678987",
3
- "enigma-linux-arm64": "f9e3859af223004061a45ac46c723fd333e65f7b8d296a1b2d7e0c7733382036",
4
- "enigma-linux-x64": "b3595dc93c44ddff732b970f5a107f2d84079c96a323ebdfaf4176282fdb4034",
5
- "enigma-win32-x64.exe": "297f3edc547ed5fd7a3c1f11696b7d3cf121491a9f118dac22306409a81cf9e3"
2
+ "enigma-darwin-arm64": "22787e34df54fc8de3755378b0f80af4f79f79b4faff52d73b8ce80032de3c03",
3
+ "enigma-linux-arm64": "fb086b31c7d117dd77c190a73747795ccce2b07705452b816522180a8e4d22d0",
4
+ "enigma-linux-x64": "5efd0515524076ee49ccb1f16a9cfc1767738e3ab02bb501922bb446bf2df220",
5
+ "enigma-win32-x64.exe": "a33467de13564b5a9a30ea634a5cf0dc39e9279463c63f3785356096b89c1b50"
6
6
  }
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "enigma-cli",
3
- "version": "1.16.17",
3
+ "version": "1.17.0",
4
4
  "description": "Everything you need to work with a coding agent: install shared policy skills for Claude Code, OpenAI Codex and opencode, and set up portable git security hooks.",
5
5
  "type": "module",
6
6
  "bin": {