@nomad-e/bluma-cli 0.1.72 → 0.1.74

package/README.md

@@ -4,6 +4,9 @@
 [![License: Apache 2.0](https://img.shields.io/badge/license-Apache%202.0-blue.svg?style=flat-square)](LICENSE)
 [![Node.js >=20](https://img.shields.io/badge/node-%3E%3D20-brightgreen?style=flat-square)](https://nodejs.org/)
 
+![Factorai.sh Banner](assets/bg.png)
+
+
 **BluMa** is a CLI-based model agent for advanced software engineering workflows. Built with React/Ink 5, it provides an interactive terminal interface for LLM-powered automation, code generation, refactoring, and task execution. Features persistent sessions, contextual reasoning, smart feedback, coordinator mode for worker orchestration, and extensible tools/skills architecture.
 
 > **Credit:** BluMa was conceived and architected by **Alex Fonseca**.

package/dist/config/skills/git-commit/SKILL.md

@@ -5,7 +5,9 @@ description: >
   a commit message, or finalize work. Triggers: "commit", "commit my changes",
   "stage and commit", "save my work", "git commit", "write a commit message",
   "commit this", "amend commit", or any request to record changes in Git
-  history. Do NOT use for pull requests — use git-pr instead.
+  history. Enforces atomic commits per feature or concern: stage with explicit
+  paths or git add -p; never git add ., git add -A, or git add --all. Do NOT
+  use for pull requests — use git-pr instead.
 license: Proprietary. LICENSE.txt has complete terms
 ---
 
@@ -16,6 +18,34 @@ license: Proprietary. LICENSE.txt has complete terms
 > Every commit tells a story. The subject says WHAT, the body says WHY,
 > and the diff shows HOW. Never repeat the diff in the message.
 
+## Staging Discipline (Non-Negotiable)
+
+BluMa must behave like a senior engineer committing: **one commit = one
+coherent unit of work** (typically one feature, one fix, or one concern).
+That requires **surgical staging**, not “stage the whole tree”.
+
+**FORBIDDEN — never run or suggest as the default workflow:**
+
+- `git add .`
+- `git add -A` / `git add --all`
+- Any variant that stages every change in the repo without naming paths
+
+Those commands mix unrelated edits, hide what is being recorded, and
+break atomic history. If the user insists on a blanket add, explain the
+risk once, then still prefer explicit paths or `git add -p`.
+
+**REQUIRED — stage with intent:**
+
+- `git add <path> [<path> ...]` for whole files that belong to *this*
+  commit only
+- `git add -p` / `git add --patch` when only part of a file belongs to
+  this commit (split hunks across commits if needed)
+- `git restore --staged <path>` to unstage mistakes before committing
+
+When several features or concerns are dirty, **commit them in separate
+commits**, each with its own explicit `git add` of the relevant paths —
+never one giant commit because “it was all green in `git status`”.
+
 ## Step 1 — Inspect the Working Tree
 
 Before committing anything, understand the current state:
@@ -31,13 +61,17 @@ Commits below).
 
 ## Step 2 — Stage with Intent
 
-Stage only the files that belong to ONE logical change:
+Stage only the files (or hunks) that belong to **one** logical change —
+aligned with **one** feature, fix, or refactor slice you could review in
+isolation:
 
 ```bash
-git add <file1> <file2>
+git add path/to/file.ts path/to/file.test.ts
+# or, for part of a file:
+git add -p path/to/file.ts
 ```
 
-Use `git add -A` only when ALL changes belong to the same logical unit.
+Do **not** use repository-wide adds (see Staging Discipline above).
 
 Review what is staged:
 
@@ -167,7 +201,13 @@ Confirm the message is well-formed and the watermark is present.
 
 ## Atomic Commits
 
-Each commit MUST represent exactly ONE logical change:
+Each commit MUST represent exactly **one** logical change — the same
+bar a senior would use before pushing: a reviewer can understand the
+**why** from the message and the **what** from the diff without unrelated
+noise.
+
+Organize history **by feature or concern**, not by “everything I touched
+today”:
 
 | Scenario | Commits |
 |----------|---------|
@@ -178,7 +218,8 @@ Each commit MUST represent exactly ONE logical change:
 | New feature + refactored old code to support it | 2 commits: `refactor(...)` first, then `feat(...)` |
 
 When in doubt: if you can describe the commit with "X and Y", it should
-probably be two commits.
+probably be two commits — and each of those commits gets its **own**
+explicit `git add` of only the paths for X or Y.
 
 ## Handling Special Cases
 
@@ -246,7 +287,8 @@ Before finalizing any commit, verify:
 4. Body explains WHY (not WHAT)
 5. Footer references relevant issues
 6. Watermark `Generated-by: BluMa` is the last line
-7. Only related changes are included (atomic)
+7. Only related changes are included (atomic); staging used explicit
+   paths or `-p`, never `git add .` / `git add -A`
 8. No secrets, credentials, or .env files are staged
 
 ## Available References

package/dist/config/skills/git-commit/references/REFERENCE.md

@@ -191,7 +191,7 @@ If a commit fails due to a hook:
 
 1. Read the hook's error output carefully
 2. Fix the issue (formatting, linting, etc.)
-3. Stage the fixes
+3. Stage the fixes with explicit `git add <path>` (never blanket `git add .` / `-A`)
 4. Create a NEW commit (do NOT use --no-verify)
 
 BluMa should NEVER use `--no-verify` to bypass hooks unless the user
@@ -199,6 +199,10 @@ explicitly requests it.
 
 ## Handling Large Changesets
 
+Never use `git add .`, `git add -A`, or `git add --all` to “split later” —
+split **before** staging, with explicit paths or `git add -p` (see the
+main skill: Staging Discipline).
+
 If the staged changes are too large for a single atomic commit:
 
 1. Use `git add -p` guidance (suggest to the user, don't run interactively)