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.
- package/README.md +10 -14
- package/assets/commands/improve.md +2 -0
- package/assets/memory/AGENTS.md +2 -0
- package/assets/memory/CLAUDE.md +2 -0
- package/assets/skills/anti-overengineering-policy/SKILL.md +33 -0
- package/assets/skills/anti-overengineering-policy/skill.json +3 -3
- package/assets/skills/anti-overengineering-review/skill.json +1 -1
- package/assets/skills/backend-policy/skill.json +1 -1
- package/assets/skills/ciphera-style-policy/skill.json +1 -1
- package/assets/skills/code-review-policy/skill.json +1 -1
- package/assets/skills/core-engineering-policy/SKILL.md +2 -0
- package/assets/skills/core-engineering-policy/skill.json +3 -3
- package/assets/skills/database-expert/skill.json +1 -1
- package/assets/skills/debugging-policy/skill.json +1 -1
- package/assets/skills/dependency-policy/skill.json +1 -1
- package/assets/skills/frontend-design/SKILL.md +1 -1
- package/assets/skills/frontend-design/skill.json +3 -3
- package/assets/skills/frontend-policy/skill.json +1 -1
- package/assets/skills/git-policy/SKILL.md +41 -0
- package/assets/skills/git-policy/skill.json +3 -3
- package/assets/skills/security-policy/skill.json +1 -1
- package/assets/skills/skill-creator/skill.json +1 -1
- package/assets/skills/task-completion-policy/skill.json +1 -1
- package/assets/skills/technical-writing-policy/SKILL.md +70 -0
- package/assets/skills/technical-writing-policy/skill.json +8 -0
- package/assets/skills/testing-policy/skill.json +1 -1
- package/assets/skills/validation-policy/skill.json +1 -1
- package/bin/checksums.json +4 -4
- 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
|
|
12
|
-
|
|
13
|
-
|
|
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.
|
package/assets/memory/AGENTS.md
CHANGED
|
@@ -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.
|
package/assets/memory/CLAUDE.md
CHANGED
|
@@ -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.
|
|
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.
|
|
7
|
-
"sha": "
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
7
|
-
"sha": "
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
7
|
-
"sha": "
|
|
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.
|
|
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
|
+
"version": "1.4.0",
|
|
4
4
|
"provider": "FJRG2007/enigma",
|
|
5
5
|
"description": "Git & contribution policy (senior engineering standards).",
|
|
6
|
-
"cliVersion": "1.
|
|
7
|
-
"sha": "
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
6
|
+
"cliVersion": "1.17.0",
|
|
7
7
|
"sha": "a33622a2f810ee4cea39824cb1a7ca34b355a917d4224025df50d77dd74f0b3a"
|
|
8
8
|
}
|
package/bin/checksums.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
|
-
"enigma-darwin-arm64": "
|
|
3
|
-
"enigma-linux-arm64": "
|
|
4
|
-
"enigma-linux-x64": "
|
|
5
|
-
"enigma-win32-x64.exe": "
|
|
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.
|
|
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": {
|