@rudderhq/agent-runtime-gemini-local 0.2.0-canary.13 → 0.2.0-canary.15

package/package.json

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

package/skills/rudder/SKILL.md

@@ -91,11 +91,12 @@ rudder agent inbox --json
 Inbox rows include a `relationship` field:
 
 - `assignee`: execution work you own
-- `reviewer`: review work where the issue is in `in_review`
+- `reviewer`: review or blocker-triage work where the issue is in `in_review`
+  or `blocked`
 
 Prioritize active close-out work first: reviewer rows with `status:
-"in_review"`, then assignee `in_progress`, then assignee `todo`. Skip
-`blocked` unless you can actually unblock it.
+`"in_review"` or `"blocked"`, then assignee `in_progress`, then assignee
+`todo`. Skip assignee-only `blocked` work unless you can actually unblock it.
 
 If `RUDDER_TASK_ID` is set and the task is assigned to you or names you as
 reviewer, prioritize it first.
@@ -141,11 +142,13 @@ rudder issue comments list "<issue-id-or-identifier>" --after "<last-comment-id>
 
 **Step 8 — Communicate outcome.**
 
-Before exiting an active `todo` or `in_progress` issue run, leave exactly one clear close-out signal. Use a progress comment if work remains, `issue done` if complete, `issue block` if blocked, or an explicit handoff comment when ownership changes. Rudder may wake you again with `RUDDER_WAKE_REASON=issue_passive_followup` when a successful run exits without that signal.
+Before exiting an active `todo` or `in_progress` issue run, leave exactly one clear close-out signal. Use a progress comment if work remains, `issue done` if complete, `issue block` if blocked, or an explicit handoff comment when ownership changes. If the issue has a reviewer, `issue block` is also a reviewer handoff: write the blocker clearly enough for the reviewer to decide next steps. Rudder may wake you again with `RUDDER_WAKE_REASON=issue_passive_followup` when a successful run exits without that signal.
 
 Before exiting a reviewer run or an inbox row with `relationship: "reviewer"`,
 leave exactly one structured reviewer decision. Do not rely on free-form
-comments such as "reject" or "accepted" as the durable outcome:
+comments such as "reject" or "accepted" as the durable outcome. Reviewer rows
+may be `in_review` or `blocked`; blocked reviewer work is blocker triage, not
+permission to take over implementation unless explicitly asked:
 
 - approve:
 
@@ -159,8 +162,8 @@ rudder issue review "<issue-id-or-identifier>" --decision approve --comment "<ma
 rudder issue review "<issue-id-or-identifier>" --decision request_changes --comment "<markdown>" --json
 ```
 
-- keep the issue in review because specific evidence or follow-up is still
-  missing:
+- 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
@@ -175,23 +178,25 @@ rudder issue review "<issue-id-or-identifier>" --decision blocked --comment "<ma
 - progress-only update:
 
 ```bash
-rudder issue comment "<issue-id-or-identifier>" --body "<markdown>" --json
+rudder issue comment "<issue-id-or-identifier>" --body "<markdown>" [--image "<path>"] --json
 ```
 
 - completion:
 
 ```bash
-rudder issue done "<issue-id-or-identifier>" --comment "<markdown>" --json
+rudder issue done "<issue-id-or-identifier>" --comment "<markdown>" [--image "<path>"] --json
 ```
 
 - blocker:
 
 ```bash
-rudder issue block "<issue-id-or-identifier>" --comment "<markdown>" --json
+rudder issue block "<issue-id-or-identifier>" --comment "<markdown>" [--image "<path>"] --json
 ```
 
 - generic patch when workflow commands are not enough:
 
+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.
+
 ```bash
 rudder issue update "<issue-id-or-identifier>" ... --json
 ```
@@ -251,7 +256,8 @@ Planning rules:
 - Always communicate before exit on active work, except blocked issues with no new context.
 - Treat `issue_passive_followup` as close-out governance, not a fresh assignment: inspect current state, then comment, finish, block, or hand off explicitly.
 - Treat `issue_review_closeout_missing` as review close-out governance: inspect
-  current state, then record one structured review decision.
+  current state, including blocked handoffs, then record one structured review
+  decision.
 - A reviewer does not take over implementation unless explicitly asked.
 - A reviewer request for changes must use `rudder issue review --decision
   request_changes`, not only a reject comment.

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

@@ -20,13 +20,13 @@ Stable CLI contract for agents using the bundled `rudder` skill. Prefer these co
 | `rudder issue get <issue>` | Read a full issue by UUID or identifier. | no | no | 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>` | Add a comment to an issue. | yes | no | no | 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 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> ...` | Apply generic issue updates when workflow commands are not enough. | yes | no | no | attached when available |
+| `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 done <issue> --comment <text>` | Mark an issue done with a required completion comment. | yes | no | no | attached when available |
-| `rudder issue block <issue> --comment <text>` | Mark an issue blocked with a required blocker comment. | 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 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 |
@@ -46,21 +46,25 @@ Stable CLI contract for agents using the bundled `rudder` skill. Prefer these co
 
 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>`
-- work is complete: `rudder issue done <issue> --comment <text>`
-- work is blocked: `rudder issue block <issue> --comment <text>`
+- 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>]`
 - 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`.
+
+`--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 `RUDDER_WAKE_REASON=issue_passive_followup`, the run is close-out governance for the same issue. Inspect current issue state first, then leave a progress comment, completion, blocker, or explicit handoff.
 
 ## Reviewer Close-Out Signals
 
-When the inbox row or wake context says `relationship: "reviewer"`, `role: "reviewer"`, or `wakeSource: "review"`, finish the review with one structured reviewer decision:
+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: `rudder issue review <issue> --decision blocked --comment <text>`
+- blocked or blocker confirmed: `rudder issue review <issue> --decision blocked --comment <text>`
 
 Do not rely on a free-form reject or accept comment as the review outcome. The structured decision is the durable close-out signal.