@levistudio/redline 0.4.0 → 0.4.1

package/CHANGELOG.md

@@ -4,6 +4,11 @@ All notable changes to Redline are documented here. The format follows [Keep a C
 
 ## [Unreleased]
 
+## [0.4.1] - 2026-05-15
+
+### Fixed
+- `redline-review` now launches Redline with `--open` so agent sessions open the review in the user's real browser instead of relying on clickable localhost links that some agent UIs capture in an embedded preview panel.
+
 ## [0.4.0] - 2026-05-15
 
 ### Added
@@ -60,7 +65,8 @@ Initial public release on npm as `@levistudio/redline`.
 - Auto-installs missing dependencies on first CLI run.
 - Initial test suite: server, sidecar, parsing, model-picking, rendering, diff, SSE, integration, happy-dom client.
 
-[Unreleased]: https://github.com/alevi/redline/compare/v0.4.0...HEAD
+[Unreleased]: https://github.com/alevi/redline/compare/v0.4.1...HEAD
+[0.4.1]: https://github.com/alevi/redline/compare/v0.4.0...v0.4.1
 [0.4.0]: https://github.com/alevi/redline/compare/v0.3.0...v0.4.0
 [0.3.0]: https://github.com/alevi/redline/releases/tag/v0.3.0
 [0.2.0]: https://github.com/alevi/redline/releases/tag/v0.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@levistudio/redline",
-  "version": "0.4.0",
+  "version": "0.4.1",
   "description": "Inline comments on Markdown files, for human-in-the-loop AI doc review.",
   "keywords": [
     "markdown",

package/skills/redline-review/SKILL.md

@@ -20,8 +20,8 @@ STARTUP="$DIR/.review/$BASE.startup.json"
 RESULT="$DIR/.review/$BASE.result"
 LOG=/tmp/redline-$BASE.log
 
-# Kick off the review in the background.
-__REDLINE_BIN__ "$FILE" > "$LOG" 2>&1 &
+# Kick off the review in the background and open it in the user's real browser.
+__REDLINE_BIN__ "$FILE" --open > "$LOG" 2>&1 &
 
 # Step 1: wait for startup, read the URL.
 for i in $(seq 1 60); do [ -f "$STARTUP" ] && break; sleep 0.5; done
@@ -34,7 +34,7 @@ PID=$(grep -o '"pid": *[0-9]*' "$STARTUP" | grep -o '[0-9]*')
 echo "REDLINE_URL: $URL"
 echo "REDLINE_PID: $PID"
 
-# Step 2: surface the URL to the human (you do this after the first shell call returns
+# Step 2: tell the human the browser opened (you do this after the first shell call returns
 # — see the next section), then wait for the redline process to exit. Watching
 # the PID (essentially free) instead of polling for the result file means you
 # wake up within ~0.5s of the human clicking Done, not up to 30s later.
@@ -46,7 +46,7 @@ The startup file at `.review/<basename>.startup.json` is written synchronously w
 
 In practice, run the script above as **two separate shell calls** so you can tell the human the URL between steps:
 1. First call: everything through `echo "REDLINE_PID: $PID"`. Returns in ~1s with the URL and PID on stdout.
-2. Surface the URL to the human in your reply text (see "Surfacing the URL" below).
+2. Tell the human Redline opened in their browser, and include the URL only as a fallback (see "Surfacing the URL" below).
 3. Second call: just the `while kill -0` loop waiting for the PID, then `cat "$RESULT"`. Long timeout (`timeout: 1800000` = 30 min, or longer).
 
 If invocation fails (binary missing, startup file never appears, etc.), surface the error verbatim and stop — do not try to recover. The human will re-run `redline install-skill`.
@@ -61,11 +61,9 @@ The context string is shown in the reader's header so the human knows what they'
 
 ### Surfacing the URL
 
-After the first shell call returns with `REDLINE_URL: http://localhost:NNNN`, surface that URL in your reply text. The human has no other signal that something is waiting for them. One short sentence:
+The `--open` flag launches the review in the user's real browser via the OS opener (`open` on macOS, `xdg-open` on Linux, `start` on Windows). After the first shell call returns with `REDLINE_URL: http://localhost:NNNN`, tell the human the browser opened and include the URL only as a fallback. Do **not** make the URL the primary action; in some agent UIs, clicking localhost opens an embedded preview panel instead of the user's browser.
 
-> "Opening this in Redline for review at http://localhost:NNNN — cmd-click to open. I'll continue once you click Done."
-
-(There is an `--open` flag that auto-launches the browser, but prefer leaving it off — the human may not be at the keyboard the moment the session starts, and a stolen-focus browser tab is worse than a URL they click when ready.)
+> "I opened this in Redline in your browser. Fallback URL: http://localhost:NNNN. I'll continue once you click Done."
 
 ## How to interpret the result
 
@@ -87,8 +85,8 @@ The full loop, when you are the outer agent producing the doc:
 
 1. Write the markdown file to disk at an absolute path.
 2. Tell the human in one sentence what's about to happen.
-3. First shell call: launch `__REDLINE_BIN__ <abs-path> --context "<one-liner>"` in the background and poll for `.startup.json`. Returns in ~1s with the URL.
-4. Surface the URL to the human in your reply text so they can cmd-click to open.
+3. First shell call: launch `__REDLINE_BIN__ <abs-path> --context "<one-liner>" --open` in the background and poll for `.startup.json`. Returns in ~1s with the URL.
+4. Tell the human Redline opened in their browser and include the URL only as a fallback.
 5. Second shell call: wait on the redline PID (`while kill -0 "$PID" 2>/dev/null; do sleep 0.5; done`) then `cat "$RESULT"`, with a long timeout (30+ min). While the session runs, you are idle — do not start unrelated work, do not run other tools.
 6. On `approved`: re-read the file from disk (it may have been revised) and continue with whatever required sign-off.
 7. On `abandoned` or `error`: stop and ask the human how to proceed; do not retry automatically.

package/src/agent.ts

@@ -91,7 +91,7 @@ const REPLY_SYSTEM_PROMPT_BODY =
   "Good: message: \"Got it.\"  reason: \"Add a third line to the hard line breaks example\"\n" +
   "When requires_revision is false, leave reason empty (or a very short note about why no edit). The reply IS the answer.\n" +
   "\n" +
-  "Separately, decide whether this comment needs the agent that LAUNCHED this review rather than you. That outer agent has the project context, tools, and authority you don't — e.g. an external style guide or canon you can't see, a spec to check the document against, or a decision that depends on the wider project. When the comment asks for something like that, set ESCALATE: true and briefly tell the reviewer in your message that you've routed it to the launching agent. Otherwise ESCALATE: false. Escalating does not change requires_revision — judge that on its own.\n" +
+  "Separately, decide whether this comment needs the agent that LAUNCHED this review rather than you. ESCALATE is rare: set ESCALATE: true only when the reviewer explicitly asks for information, tools, authority, or project context you cannot access from the document and comment thread — for example an external style guide, a hidden spec, repo-wide code context, or a decision the launching agent must make. Do NOT escalate ordinary requested edits, reframes, emphasis changes, priority changes, rewrites, or approvals; those are handled by requires_revision. If the comment can be satisfied by editing this document, set ESCALATE: false. When you do escalate, briefly tell the reviewer in your message that you've routed it to the launching agent. Escalating does not change requires_revision — judge that on its own.\n" +
   "\n" +
   "Output exactly this format and nothing else (no prose before/after, no code fences). Use these literal markers — do not escape quotes inside the message:\n" +
   "REQUIRES_REVISION: <true|false>\n" +