@globant/coda-darwin-x64 1.2.0 → 1.4.0

package/assets/skills/init-rules/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: init-rules
+description: Interactively bootstrap a project's permission rules (allow/ask/deny) and permission mode, and optionally enable the LLM safety-check layer. Use when the user wants to set up, configure, initialize, or scaffold permissions/authorization rules for a repo, e.g. "/init-rules", "set up my permissions", "configure allow/deny rules for this project".
+---
+
+# init-rules — bootstrap permission rules for a project
+
+Your job is to help the user set up their CODA permission **rules** (`allow` / `ask` / `deny`) and **permission mode**, and optionally the **LLM safety-check** layer, based on how the project actually works.
+
+You change **rules and the permission mode** by calling the built-in **`propose_policy`** tool — the sanctioned, approval-gated path for those. For settings that `propose_policy` does not cover (such as the `llmSafetyCheck` block), you may edit `config.json` directly with the `write`/`edit` tools: that write is a control-plane authoring write, so it is **allowed but always requires the user to approve the HITL prompt** first (it is not silently applied, and the user must consent to each such edit).
+
+## Mode assumption — clarify up front
+
+This skill assumes the session is running in **auto mode** (unattended/hands-off autonomy). State this to the user before you start, e.g.:
+
+> "This assumes you're running in **auto** permission mode (Ctrl+P cycles modes). In auto, only your explicit `ask`/`deny` rules and the catastrophic floor still stop the agent, so the rules we set here are what keeps risky commands in check. Let's configure them."
+
+If the user is not in auto mode, still proceed — the rules are valid in any mode — but note that in `default`/`read-only` mode many commands already require approval, so `deny`/`ask` rules matter most.
+
+## Interactive vs. headless
+
+- **Interactive:** follow every step, using `ask_user` to confirm choices.
+- **Headless / batch** (`ask_user` unavailable): explore the repo and pick sensible defaults — a `default`-leaning, restrictive rule set (deny destructive commands, allow the project's read/test/build commands). Note that `propose_policy` **widenings are auto-refused headlessly**, so only `deny` rules (tightenings) will actually apply; report the `allow`/mode suggestions to the user for them to apply interactively later.
+
+---
+
+## Step 1 — Explore the project
+
+Understand what commands this project legitimately runs so your rules fit reality. Do NOT skip this.
+
+- Read every `AGENTS.md` (root and per-package) — they usually list the exact build/test/lint commands. Also read `README.md`, `CONTRIBUTING.md`.
+- Inspect `package.json` scripts / `Makefile` / `justfile` / `pyproject.toml` / `Cargo.toml` / CI workflow files (`.github/workflows/*`) for the real commands.
+- Note the package manager (pnpm/npm/yarn/bun/pip/cargo/go) and the common verbs: test, lint, type-check, build, format.
+
+Summarize back to the user the commands you found (e.g. `pnpm test`, `pnpm lint`, `pnpm type-check`, `bun test`) so they can confirm which should be auto-allowed.
+
+Search in the ~/.coda/coda.db database for bash commands to get a sense of the commands the system has already executed, if the user has some existing history.
+
+---
+
+## Step 2 — Choose how permissive the rules should be
+
+Ask the user which posture they want. Use `ask_user`:
+
+> "How strict should the rules be?"
+> - **Permissive** — auto-allow the project's routine commands (test/lint/build/format, common git reads); deny only clearly destructive ones.
+> - **Restrictive** — allow only a short, explicit allowlist; `ask` before anything not on it; deny a broad set of destructive/network commands.
+> - **Balanced** — allow the confirmed dev commands, `ask` for git-writes and network/publish, deny destructive ones.
+
+Then, using what you found in Step 1, propose the concrete rule set and confirm the risky ones with `ask_user` before writing. Typical shapes (adapt to the actual project):
+
+- **Allow** (permissive/balanced): `Bash(pnpm test:*)`, `Bash(pnpm lint:*)`, `Bash(pnpm type-check)`, `Bash(git status)`, `Bash(git log:*)`, `Bash(git diff:*)`.
+- **Ask** (guardrails on state-changing / outbound actions): `Bash(git push:*)`, `Bash(git commit:*)`, `Bash(npm publish:*)`, `Bash(curl:*)`.
+- **Deny** (destructive / dangerous): `Bash(rm:*)`, `Bash(git reset --hard:*)`, `Bash(chmod:*)` — deny whatever the user does not want the agent doing unattended.
+
+Rule syntax reminders (this is exactly what `propose_policy` writes):
+- `Bash(npm:*)` = any command starting with `npm`; `Bash(git push origin main)` = exact match; `Bash(*)` = any bash command (**too permissive — don't recommend it**, see below); bare `Bash` = the whole tool.
+- File tools take globs: `Read(//etc/passwd)` (double slash = absolute), `Edit(src/**)`, `Write(package.json)`.
+- MCP: `mcp__filesystem` (whole server) or `mcp__filesystem__read_file` (one tool).
+- Effects: `allow` (no prompt), `ask` (always prompt, even in auto), `deny` (always block).
+
+Precedence is **deny-first**: `deny` > `ask` > `allow` > mode. Nothing overrides a `deny`, and nothing overrides the catastrophic floor (`rm -rf /`, `sudo`, private-key/credential reads, writes to secret files like `.env` / `.secrets`, etc. — never relaxable, so don't bother proposing rules for those). Note that editing `config.json`, `mcp.json`, or `agents.md` is *not* on that floor: it is allowed as an approval-gated authoring write (see Step 5).
+
+### Command-scoped allow rules
+
+IMPORTANT: Do not recommend `Bash(*)` as it won't allow cases that are related to package managers, etc. 
+Bash(*) doesn't allow every bash command, it isn't the most permissive rule possible. 
+Each command is broken down and evaluated independently. 
+
+Recommendation: **allow one command family at a time** with `Bash(<tool>:*)`. Each such rule auto-allows only that executable and its arguments, so the agent can run the tool freely while everything else still falls back to `ask`/`deny`/mode.
+
+- If a user needs to run **all `pnpm` commands**, the ideal rule is `Bash(pnpm:*)` — not `Bash(*)`.
+- Same idea per tool: `Bash(bun:*)` for all `bun` commands, `Bash(cargo:*)` for all `cargo` commands, and so on.
+
+Build the allow list from the tools the project actually uses (from Step 1). A palette of common command-scoped rules to draw from:
+
+```jsonc
+// ❌ do NOT recommend this:
+"Bash(*)",
+
+// ✅ Recommended: scope to one command family each.
+// Package managers / runtimes:
+"Bash(bun:*)", "Bash(bunx:*)", "Bash(pnpm:*)", "Bash(pnx:*)",
+"Bash(npm:*)", "Bash(npx:*)", "Bash(node:*)",
+"Bash(python3:*)", "Bash(python:*)", "Bash(uv:*)", "Bash(uvx:*)",
+// Lint / format / build / type-check / test:
+"Bash(biome:*)", "Bash(tsc:*)", "Bash(vitest:*)", "Bash(jest:*)",
+"Bash(eslint:*)", "Bash(prettier:*)",
+// Build / task runners:
+"Bash(make:*)", "Bash(cargo:*)", "Bash(go:*)", "Bash(just:*)", "Bash(task:*)",
+// Version control:
+"Bash(git:*)", "Bash(gh:*)",
+// Shell builtins / environment:
+"Bash(cd:*)", "Bash(set:*)", "Bash(export:*)", "Bash(source:*)",
+"Bash(pwd:*)", "Bash(which:*)", "Bash(command:*)", "Bash(timeout:*)",
+"Bash(env:*)", "Bash(bash:*)", "Bash(sh:*)", "Bash(zsh:*)",
+// Read-only file / text inspection:
+"Bash(ls:*)", "Bash(cat:*)", "Bash(head:*)", "Bash(tail:*)", "Bash(wc:*)",
+"Bash(grep:*)", "Bash(rg:*)", "Bash(find:*)", "Bash(sed:*)", "Bash(awk:*)",
+"Bash(sort:*)", "Bash(uniq:*)", "Bash(comm:*)", "Bash(tr:*)", "Bash(cut:*)",
+"Bash(diff:*)", "Bash(echo:*)", "Bash(printf:*)", "Bash(base64:*)",
+"Bash(test:*)", "Bash(jq:*)",
+// Filesystem-mutating — riskier, usually `ask`/`deny`, not blanket `allow`:
+"Bash(mkdir:*)", "Bash(rm:*)", "Bash(cp:*)", "Bash(mv:*)",
+"Bash(touch:*)", "Bash(chmod:*)",
+// Misc tools:
+"Bash(sqlite3:*)", "Bash(ffmpeg:*)", "Bash(ffprobe:*)", "Bash(open:*)"
+```
+
+Caveats to relay when proposing these:
+- These are all **fairly permissive** examples; if the user wants this you should add one rule for each command the user has in their history of commands executed.
+- The filesystem-mutating (`rm`, `mv`, `cp`, `chmod`, …) and network (`curl`, `wget`) families change state or reach outbound — prefer `ask` (or `deny` for the destructive ones) over a blanket `allow`, and confirm each with `ask_user` first.
+- You can scope tighter than a whole tool: `Bash(pnpm test:*)` allows only `pnpm test …`, `Bash(git log:*)` only `git log …`. Prefer the narrowest rule that still lets the project's real commands run.
+
+---
+
+## Step 3 — Choose the target scope: project or global
+
+Ask the user with `ask_user`:
+
+> "Where should these rules live?"
+> - **Project** — written to `<repo>/.coda/config.json`; applies only to this repository (and is shareable with teammates if committed).
+> - **Global** — written to `~/.coda/config.json`; applies to every CODA session you run.
+
+Map their choice to the `scope` argument (`"project"` or `"global"`) you pass to `propose_policy`.
+
+> Note: a **project** scope can only make the permission mode *more* restrictive than global/managed policy, never more permissive. A project-scoped request to *raise* the mode is refused. Raising autonomy must be global.
+
+---
+
+## Step 4 — Apply the rules with `propose_policy`
+
+For each rule the user confirmed, call `propose_policy` once:
+
+- Add a rule: `op: "add-rule"`, `rule: "<rule string>"`, `effect: "allow" | "ask" | "deny"`, `scope: "<from Step 3>"`.
+- Change the mode (if needed): `op: "set-mode"`, `mode: "read-only" | "default" | "auto"`, `scope`.
+- Remove a stale rule: `op: "remove-rule"` with the same `rule` + `effect`.
+
+Expect these behaviors and relay them:
+- **Tightenings apply on their own** — adding a `deny` (or lowering the mode) removes capability, so it applies without an approval prompt.
+- **Widenings always ask first** — any `allow`/`ask` rule, removing a rule, or raising the mode prompts the user for approval before it is written, in *every* mode (auto included). Walk the user through approving each one.
+- A `gated`/`rejected` result means the change hit the floor, managed policy, or a project-can't-widen limit — report it plainly and move on; don't retry the same thing.
+
+Do them in a sensible order (deny rules first, then ask, then allow, then any mode change) and tell the user what each proposal will do before firing it.
+
+---
+
+## Step 5 — Optionally enable the LLM safety-check layer
+
+Ask the user with `ask_user`:
+
+> "Do you want an **LLM safety check** on commands the agent would otherwise run? When enabled, a classifier model reviews commands and can flag/deny risky ones as an extra layer on top of your rules."
+
+This layer is configured under `permissions.llmSafetyCheck` in `config.json`. `propose_policy` does not cover this block, so **edit `config.json` directly** — the same config file they chose in Step 3 (`<repo>/.coda/config.json` for project, `~/.coda/config.json` for global) — merging the block into the existing `permissions` object. Read the file first (create it if absent), then apply the change with `edit`/`write`.
+
+This is a control-plane authoring write, so CODA will show a **mandatory approval prompt** describing the effect before anything is saved. Tell the user to expect and approve it; if they decline, the block is not written. If you cannot get approval (e.g. headless), fall back to giving them the JSON snippet to paste in by hand.
+
+The block to add:
+
+```jsonc
+{
+  "permissions": {
+    "llmSafetyCheck": {
+      "enabled": true,
+      // Optional: an explicit model list REPLACES the built-in default.
+      // Omit this key to use the shipped default classifier models.
+      // If you want to use another model, just modify the list. 
+      "models": ["openai/gpt-5.4", "openai/gpt-5.4", "anthropic/claude-sonnet-4-6", "anthropic/claude-haiku-4-5"],
+      // Optional: after this many auto-approvals in an interactive session,
+      // a one-time nudge suggests adding an explicit allow rule. Default: 10.
+      "nudgeThreshold": 10
+    }
+  }
+}
+```
+
+Notes to give the user:
+- It is **default-off**; an absent block leaves it inert. Set `enabled: true` to turn it on.
+- If `enabled: true` but `models` is an empty list `[]`, the check is inert (a startup warning fires). Omit `models` to use the built-in default, or list at least one model.
+- `nudgeThreshold` must be an integer ≥ 1.
+- If they picked **project** scope in Step 3, this belongs in the project config; if **global**, in `~/.coda/config.json`. Since it rides the global→project cascade, a project block overrides the global one.
+
+---
+
+## Step 6 — Wrap up: tell the user to restart
+
+After applying rules and (optionally) writing the safety-check block, finish with a short summary of what was set, then clearly instruct the user:
+
+> **Restart CODA for these changes to take full effect** — especially the `llmSafetyCheck` block written to `config.json`, which is only read at startup.
+
+Keep the final message concise: list the rules added (grouped by allow/ask/deny), the scope, the mode (if changed), whether the safety check was configured, and the restart reminder.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@globant/coda-darwin-x64",
-  "version": "1.2.0",
+  "version": "1.4.0",
   "description": "Coda CLI native binary (darwin-x64)",
   "os": [
     "darwin"