@rudderhq/agent-runtime-gemini-local 0.2.9-canary.3 → 0.2.9-canary.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rudderhq/agent-runtime-gemini-local",
-  "version": "0.2.9-canary.3",
+  "version": "0.2.9-canary.5",
   "license": "SEE LICENSE IN LICENSE",
   "homepage": "https://github.com/Undertone0809/rudder",
   "bugs": {
@@ -67,7 +67,7 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "@rudderhq/agent-runtime-utils": "0.2.9-canary.3",
+    "@rudderhq/agent-runtime-utils": "0.2.9-canary.5",
     "picocolors": "^1.1.1"
   },
   "devDependencies": {

package/skills/rudder/SKILL.md

@@ -155,26 +155,26 @@ permission to take over implementation unless explicitly asked:
 - approve:
 
 ```bash
-rudder issue review "<issue-id-or-identifier>" --decision approve --comment "<markdown>" --json
+rudder issue review "<issue-id-or-identifier>" --decision approve --comment-file "<path>" --json
 ```
 
 - request changes and return the issue to the assignee:
 
 ```bash
-rudder issue review "<issue-id-or-identifier>" --decision request_changes --comment "<markdown>" --json
+rudder issue review "<issue-id-or-identifier>" --decision request_changes --comment-file "<path>" --json
 ```
 
 - keep the issue in its current review/blocker state because specific evidence
   or follow-up is still missing:
 
 ```bash
-rudder issue review "<issue-id-or-identifier>" --decision needs_followup --comment "<markdown>" --json
+rudder issue review "<issue-id-or-identifier>" --decision needs_followup --comment-file "<path>" --json
 ```
 
 - block the issue:
 
 ```bash
-rudder issue review "<issue-id-or-identifier>" --decision blocked --comment "<markdown>" --json
+rudder issue review "<issue-id-or-identifier>" --decision blocked --comment-file "<path>" --json
 ```
 
 Use `blocked` to confirm a human/external blocker. The comment must name the next human action; Rudder records a human handoff and removes the issue from repeated reviewer pickup until the board changes the issue.
@@ -182,23 +182,30 @@ Use `blocked` to confirm a human/external blocker. The comment must name the nex
 - progress-only update:
 
 ```bash
-rudder issue comment "<issue-id-or-identifier>" --body "<markdown>" [--image "<path>"] --json
+rudder issue comment "<issue-id-or-identifier>" --body-file "<path>" [--image "<path>"] --json
 ```
 
 - completion:
 
 ```bash
-rudder issue done "<issue-id-or-identifier>" --comment "<markdown>" [--image "<path>"] --json
+rudder issue done "<issue-id-or-identifier>" --comment-file "<path>" [--image "<path>"] --json
 ```
 
 - blocker:
 
 ```bash
-rudder issue block "<issue-id-or-identifier>" --comment "<markdown>" [--image "<path>"] --json
+rudder issue block "<issue-id-or-identifier>" --comment-file "<path>" [--image "<path>"] --json
 ```
 
 - generic patch when workflow commands are not enough:
 
+Use file or stdin input for issue comments. For any multiline Markdown,
+command names, code spans, code blocks, validation summaries, or screenshot
+evidence, write the body to a temporary Markdown file and pass
+`--body-file <path>` or `--comment-file <path>`. Pass `-` to read from stdin.
+Do not place shell-sensitive Markdown containing backticks or `$()` directly
+inside a shell argument.
+
 Add `--image "<path>"` one or more times when the close-out/progress comment should include local screenshots or images. Supported local image types are PNG, JPEG, WebP, and GIF; the CLI uploads them as issue attachments and appends Markdown image links.
 
 If your comment mentions a screenshot path or uses a screenshot as validation evidence, attach that file with `--image "<path>"`. Do not leave only a local `/tmp/...` or workspace image path in the comment, because board users may not be able to inspect it from Rudder.
@@ -233,7 +240,7 @@ rudder agent skills create "$RUDDER_AGENT_ID" --name "<name>" --description "<de
 
 This creates the package under `AGENT_HOME/skills` and does not require organization skill mutation permission.
 
-When a board user, CEO, or manager asks you to find, import, inspect, or assign organization skills:
+When a board user or authorized agent asks you to find, import, inspect, or assign organization skills:
 
 1. Read `references/organization-skills.md`
 2. Use the CLI surfaces in this order:
@@ -269,7 +276,7 @@ Typical flow:
 rudder issue documents get "<issue-id-or-identifier>" plan --json
 rudder issue documents revisions "<issue-id-or-identifier>" plan --json
 rudder issue documents put "<issue-id-or-identifier>" plan --title "Plan" --format markdown --body "<markdown>" --json
-rudder issue comment "<issue-id-or-identifier>" --body "<mention that the plan document was updated>" --json
+rudder issue comment "<issue-id-or-identifier>" --body-file "<path>" --json
 ```
 
 Planning rules:

package/skills/rudder/references/cli-reference.md

@@ -29,14 +29,14 @@ Direct API fallback is allowed for heartbeat close-out only when a required CLI
 | `rudder issue search <query> [--org-id <id>]` | Search issues with the server-side issue index across title, identifier, description, and comments. | no | required | no | no |
 | `rudder issue context <issue>` | Read the compact heartbeat context for an issue. | no | no | no | no |
 | `rudder issue checkout <issue>` | Atomically checkout an issue for the current or specified agent. | yes | no | required | attached when available |
-| `rudder issue comment <issue> --body <text> [--image <path>]` | Add a comment to an issue, optionally uploading images and appending Markdown image links. | yes | no | no | attached when available |
+| `rudder issue comment <issue> --body-file <path> [--image <path>]` | Add a comment to an issue, optionally uploading images and appending Markdown image links. | yes | no | no | attached when available |
 | `rudder issue comments list <issue>` | List issue comments, optionally only newer comments after a cursor. | no | no | no | no |
 | `rudder issue comments get <issue> <comment-id>` | Read one issue comment by id. | no | no | no | no |
-| `rudder issue update <issue> ... [--image <path>]` | Apply generic issue updates when workflow commands are not enough, optionally uploading images for the update comment. | yes | no | no | attached when available |
-| `rudder issue review <issue> --decision <decision> --comment <text>` | Record a structured reviewer decision with a required comment. | yes | no | no | attached when available |
+| `rudder issue update <issue> ... [--comment-file <path>] [--image <path>]` | Apply generic issue updates when workflow commands are not enough, optionally uploading images for the update comment. | yes | no | no | attached when available |
+| `rudder issue review <issue> --decision <decision> --comment-file <path>` | Record a structured reviewer decision with a required comment. | yes | no | no | attached when available |
 | `rudder issue commit <issue> --sha <sha> --message <subject>` | Report a code commit created during issue work as structured issue activity. | yes | no | no | attached when available |
-| `rudder issue done <issue> --comment <text> [--image <path>]` | Mark an issue done with a required completion comment, optionally uploading images. | yes | no | no | attached when available |
-| `rudder issue block <issue> --comment <text> [--image <path>]` | Mark an issue blocked with a required blocker comment, optionally uploading images. | yes | no | no | attached when available |
+| `rudder issue done <issue> --comment-file <path> [--image <path>]` | Mark an issue done with a required completion comment, optionally uploading images. | yes | no | no | attached when available |
+| `rudder issue block <issue> --comment-file <path> [--image <path>]` | Mark an issue blocked with a required blocker comment, optionally uploading images. | yes | no | no | attached when available |
 | `rudder issue release <issue>` | Release an issue back to todo and clear ownership. | yes | no | no | attached when available |
 | `rudder issue documents list <issue>` | List issue documents. | no | no | no | no |
 | `rudder issue documents get <issue> <key>` | Read one issue document by key. | no | no | no | no |
@@ -56,13 +56,15 @@ Direct API fallback is allowed for heartbeat close-out only when a required CLI
 
 Before a successful `todo` or `in_progress` issue run exits, leave one close-out signal with the command that matches the outcome:
 
-- progress remains: `rudder issue comment <issue> --body <text> [--image <path>]`
-- work is complete: `rudder issue done <issue> --comment <text> [--image <path>]`
-- work is blocked: `rudder issue block <issue> --comment <text> [--image <path>]`
+- progress remains: `rudder issue comment <issue> --body-file <path> [--image <path>]`
+- work is complete: `rudder issue done <issue> --comment-file <path> [--image <path>]`
+- work is blocked: `rudder issue block <issue> --comment-file <path> [--image <path>]`
 - ownership changes: add an explicit handoff comment before or with the assignee update
 
 If an issue has a reviewer, moving it to `blocked` is also a reviewer handoff: the reviewer should confirm the blocker, request changes, approve, or keep explicit follow-up open with `rudder issue review`.
 
+Use file or stdin comment input for any multiline Markdown, command names, code spans, code blocks, test summaries, or screenshot evidence. Write the comment to a temporary Markdown file and pass `--body-file <path>` or `--comment-file <path>`, or pass `-` to read the body from stdin. Do not place shell-sensitive Markdown containing backticks or `$()` directly inside a shell argument.
+
 `--image` may be repeated. The CLI uploads each local PNG/JPEG/WebP/GIF as an issue attachment and appends Markdown image links to the comment text before sending it.
 
 If your issue comment cites a screenshot path or visual validation artifact, attach that file with `--image <path>` instead of leaving only the local path in the text.
@@ -77,10 +79,10 @@ Local runtime `HOME` is isolated from the operator home. Codex local runs and ru
 
 When the inbox row or wake context says `relationship: "reviewer"`, `role: "reviewer"`, or `wakeSource: "review"`, finish the review with one structured reviewer decision. Reviewer work can be either `in_review` or `blocked`; blocked reviewer work means blocker triage, not implementation takeover.
 
-- approve: `rudder issue review <issue> --decision approve --comment <text>`
-- request changes: `rudder issue review <issue> --decision request_changes --comment <text>`
-- needs follow-up: `rudder issue review <issue> --decision needs_followup --comment <text>`
-- blocked or blocker confirmed: `rudder issue review <issue> --decision blocked --comment <text>`; use this only for a confirmed human/external blocker and name the next human action.
+- approve: `rudder issue review <issue> --decision approve --comment-file <path>`
+- request changes: `rudder issue review <issue> --decision request_changes --comment-file <path>`
+- needs follow-up: `rudder issue review <issue> --decision needs_followup --comment-file <path>`
+- blocked or blocker confirmed: `rudder issue review <issue> --decision blocked --comment-file <path>`; use this only for a confirmed human/external blocker and name the next human action.
 
 Do not rely on a free-form reject or accept comment as the review outcome. The structured decision is the durable close-out signal. A blocked reviewer decision records a human handoff and removes the issue from repeated reviewer pickup until the board changes the issue.
 

package/skills/rudder/references/organization-skills.md

@@ -1,6 +1,6 @@
 # Organization Skills Workflow
 
-Use this reference when a board user, CEO, or manager asks you to discover, import, inspect, or enable organization skills.
+Use this reference when a board user or authorized agent asks you to discover, import, inspect, or enable organization skills.
 
 This workflow is now **CLI-first** for the bundled `rudder` skill.
 
@@ -155,7 +155,7 @@ the full optional enabled-skill set intentionally.
 ## Permission Model
 
 - organization skill reads: any same-organization actor
-- organization skill mutations: board, CEO, or an agent with effective `agents:create`
+- organization skill mutations: local/admin board access, board users with `skills:manage`, or same-org agents with `canManageSkills` enabled. Agents default to `canManageSkills=true` unless explicitly disabled. Existing board grants for `agents:create` remain accepted as a compatibility fallback, but new grants should use `skills:manage`.
 - agent skill enable/sync: same permission model as updating that agent
 
 ## Notes