@alook/cli 0.0.118 → 0.0.119

package/dist/index.js

@@ -19091,6 +19091,7 @@ The CLI auto-detects your identity from the environment. No need to pass \`--age
 ### Command quick reference
 | Capability | Command |
 |---|---|
+| Send a message to the user | \`${cmdPrefix()} sync send-dm\` |
 | Schedule / list / edit tasks | \`${cmdPrefix()} calendar set\` (also list, show, update, delete) |
 | Upload a file for your owner | \`${cmdPrefix()} sync upload-artifact\` |
 | Recruit a colleague agent | \`${cmdPrefix()} agent recruit\` |
@@ -19181,11 +19182,22 @@ Upload files for your owner to review in the app.
 ### Talking to the user
 You're texting a colleague, not filing a report. The only thing the user sees is what you send with \`${cmdPrefix()} sync send-dm\` — your task output, reasoning, and tool calls are all off-screen. If you finish without sending, they got silence.
 
+\`${cmdPrefix()} sync send-dm\` sends a message to **the user** (your owner), not to a colleague agent. This is how you communicate with the human who gave you the task. Use email to talk to colleague agents.
+
 Message at milestones, the way a person would: acknowledge when you pick something up, share a real step forward or a fork in the road, and deliver the result. A quick task is often one message; a long one is a few well-spaced check-ins. Trust your read of the moment — don't narrate every small step, and don't go dark for a long stretch on something they're waiting on.
 
 Say what a colleague would say, not a transcript — the answer in your own voice. (Email- and calendar-triggered tasks have no one watching the chat; use email there.)
 
-\`${cmdPrefix()} sync send-dm --message "…"\` (or \`--message-file <path>\` for long/markdown). The conversation is in $ALOOK_CONVERSATION_ID, so you usually need no flags. You can send several times in one task.
+**A real person is waiting on the other end.** Send updates at every milestone of your work — not just the final result. For any task longer than a minute:
+1. **Before you start**: tell them your plan ("I'll research X, then modify Y and Z")
+2. **During work**: update when you find something important, change direction, or hit a blocker ("Found the issue — it's in the auth module, fixing now")
+3. **When done**: deliver the clear result
+
+Don't bundle everything into one giant message at the end. The user shouldn't have to sit in silence wondering what's happening. A one-line progress update costs nothing and keeps the human in the loop. But don't send repetitive or near-identical messages — each update should carry new information, not just restate what you already said.
+
+**If the user sends you a message while you're working** — especially questions like "are you there?", "what's the status?", or unrelated requests — **respond to them immediately**. Don't finish your current task first and then reply. The user reached out because they need your attention NOW. Acknowledge them right away, then resume your work.
+
+\`${cmdPrefix()} sync send-dm --message "…"\` for short messages. For longer or markdown-rich messages, write to a file first and use \`--message-file <path>\` — this preserves formatting and avoids shell escaping issues. The conversation is in $ALOOK_CONVERSATION_ID, so you usually need no flags. You can send several times in one task.
 
 ### Attachments
 When your task includes attachments, their local paths are listed in the prompt JSON under "attachments".
@@ -19652,7 +19664,7 @@ function releaseSteeringLock(baseDir, contextKey) {
 }
 
 // daemon/prompt.ts
-var DM_RESPONSE_NOTICE = "Reply with `alook sync send-dm` — that's the only thing the user sees;" + " your task output and reasoning are not shown." + " Talk to them at milestones like a colleague would, and don't end your turn without sending what they need.";
+var DM_RESPONSE_NOTICE = "Reply with `alook sync send-dm` — that's the only thing the user sees; your task output and reasoning are not shown." + " Talk to them at milestones like a colleague would, and don't end your turn without sending what they need." + " If this task will take more than 30 seconds, send a quick ack first so the user knows you're on it.";
 var EMAIL_NOTICE = "This task was triggered automatically by an incoming email. There is no human in this session." + " If you need to communicate with a human, you MUST send an email using the email sending tool." + " If you need more information or confirmation from the human, send them an email asking for it and then exit." + " Do not wait — when the human replies, a new task will be triggered automatically and you will be woken up with their response.";
 var CALENDAR_NOTICE = "This task was triggered by a scheduled calendar event. There is no human in this session." + " If you need to communicate with a human, you MUST send an email using the email sending tool." + " If you need more information or confirmation, send an email asking for it and then exit." + " Do not wait — when the human replies, a new task will be triggered automatically and you will be woken up with their response.";
 var ISSUE_NOTICE = "This task was triggered by an assigned issue. The issue_id is provided in this message." + " Use `alook issue show --issue_id <issue_id>` to read full context." + " Use `alook issue update --issue_id <issue_id> --status <status>` to change status." + " Use `alook issue comment --issue_id <issue_id> --body <text>` to leave a comment." + " CRITICAL — You MUST manage the issue status correctly. This is NOT optional:" + " 1. Set status to 'in_progress' when you start working." + " 2. If you complete the work yourself: leave a summary comment, then set status to 'review' as your last action. 'review' means there is actual completed work (code, artifact, result) ready for the owner to look at." + " 3. If you delegated work to colleagues and are waiting for their response: KEEP status as 'in_progress' and exit. This is expected — you will be woken up when they reply. Set 'review' only after all delegated work is confirmed complete." + " 4. NEVER set 'review' unless there is concrete completed work for the owner to review. Sending a plan to a colleague is NOT completed work." + " NEVER exit without doing at least one of: updating the status, or leaving a comment explaining what you did and what you're waiting for.";
@@ -23046,7 +23058,8 @@ function syncCommand() {
         process.exit(1);
       }
     } else {
-      content = opts.message ?? "";
+      content = (opts.message ?? "").replace(/\\n/g, `
+`).replace(/\\t/g, "\t");
     }
     if (!content.trim()) {
       console.error("Error: --message or --message-file is required (and must not be empty)");

package/dist/session-runner.js

@@ -18310,6 +18310,7 @@ The CLI auto-detects your identity from the environment. No need to pass \`--age
 ### Command quick reference
 | Capability | Command |
 |---|---|
+| Send a message to the user | \`${cmdPrefix()} sync send-dm\` |
 | Schedule / list / edit tasks | \`${cmdPrefix()} calendar set\` (also list, show, update, delete) |
 | Upload a file for your owner | \`${cmdPrefix()} sync upload-artifact\` |
 | Recruit a colleague agent | \`${cmdPrefix()} agent recruit\` |
@@ -18400,11 +18401,22 @@ Upload files for your owner to review in the app.
 ### Talking to the user
 You're texting a colleague, not filing a report. The only thing the user sees is what you send with \`${cmdPrefix()} sync send-dm\` — your task output, reasoning, and tool calls are all off-screen. If you finish without sending, they got silence.
 
+\`${cmdPrefix()} sync send-dm\` sends a message to **the user** (your owner), not to a colleague agent. This is how you communicate with the human who gave you the task. Use email to talk to colleague agents.
+
 Message at milestones, the way a person would: acknowledge when you pick something up, share a real step forward or a fork in the road, and deliver the result. A quick task is often one message; a long one is a few well-spaced check-ins. Trust your read of the moment — don't narrate every small step, and don't go dark for a long stretch on something they're waiting on.
 
 Say what a colleague would say, not a transcript — the answer in your own voice. (Email- and calendar-triggered tasks have no one watching the chat; use email there.)
 
-\`${cmdPrefix()} sync send-dm --message "…"\` (or \`--message-file <path>\` for long/markdown). The conversation is in $ALOOK_CONVERSATION_ID, so you usually need no flags. You can send several times in one task.
+**A real person is waiting on the other end.** Send updates at every milestone of your work — not just the final result. For any task longer than a minute:
+1. **Before you start**: tell them your plan ("I'll research X, then modify Y and Z")
+2. **During work**: update when you find something important, change direction, or hit a blocker ("Found the issue — it's in the auth module, fixing now")
+3. **When done**: deliver the clear result
+
+Don't bundle everything into one giant message at the end. The user shouldn't have to sit in silence wondering what's happening. A one-line progress update costs nothing and keeps the human in the loop. But don't send repetitive or near-identical messages — each update should carry new information, not just restate what you already said.
+
+**If the user sends you a message while you're working** — especially questions like "are you there?", "what's the status?", or unrelated requests — **respond to them immediately**. Don't finish your current task first and then reply. The user reached out because they need your attention NOW. Acknowledge them right away, then resume your work.
+
+\`${cmdPrefix()} sync send-dm --message "…"\` for short messages. For longer or markdown-rich messages, write to a file first and use \`--message-file <path>\` — this preserves formatting and avoids shell escaping issues. The conversation is in $ALOOK_CONVERSATION_ID, so you usually need no flags. You can send several times in one task.
 
 ### Attachments
 When your task includes attachments, their local paths are listed in the prompt JSON under "attachments".
@@ -18788,7 +18800,7 @@ function clearKillIntent(baseDir, taskId) {
 }
 
 // daemon/prompt.ts
-var DM_RESPONSE_NOTICE = "Reply with `alook sync send-dm` — that's the only thing the user sees;" + " your task output and reasoning are not shown." + " Talk to them at milestones like a colleague would, and don't end your turn without sending what they need.";
+var DM_RESPONSE_NOTICE = "Reply with `alook sync send-dm` — that's the only thing the user sees; your task output and reasoning are not shown." + " Talk to them at milestones like a colleague would, and don't end your turn without sending what they need." + " If this task will take more than 30 seconds, send a quick ack first so the user knows you're on it.";
 var EMAIL_NOTICE = "This task was triggered automatically by an incoming email. There is no human in this session." + " If you need to communicate with a human, you MUST send an email using the email sending tool." + " If you need more information or confirmation from the human, send them an email asking for it and then exit." + " Do not wait — when the human replies, a new task will be triggered automatically and you will be woken up with their response.";
 var CALENDAR_NOTICE = "This task was triggered by a scheduled calendar event. There is no human in this session." + " If you need to communicate with a human, you MUST send an email using the email sending tool." + " If you need more information or confirmation, send an email asking for it and then exit." + " Do not wait — when the human replies, a new task will be triggered automatically and you will be woken up with their response.";
 var ISSUE_NOTICE = "This task was triggered by an assigned issue. The issue_id is provided in this message." + " Use `alook issue show --issue_id <issue_id>` to read full context." + " Use `alook issue update --issue_id <issue_id> --status <status>` to change status." + " Use `alook issue comment --issue_id <issue_id> --body <text>` to leave a comment." + " CRITICAL — You MUST manage the issue status correctly. This is NOT optional:" + " 1. Set status to 'in_progress' when you start working." + " 2. If you complete the work yourself: leave a summary comment, then set status to 'review' as your last action. 'review' means there is actual completed work (code, artifact, result) ready for the owner to look at." + " 3. If you delegated work to colleagues and are waiting for their response: KEEP status as 'in_progress' and exit. This is expected — you will be woken up when they reply. Set 'review' only after all delegated work is confirmed complete." + " 4. NEVER set 'review' unless there is concrete completed work for the owner to review. Sending a plan to a colleague is NOT completed work." + " NEVER exit without doing at least one of: updating the status, or leaving a comment explaining what you did and what you're waiting for.";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@alook/cli",
-  "version": "0.0.118",
+  "version": "0.0.119",
   "description": "Alook CLI — Enable Your Person Colleague",
   "license": "Apache-2.0",
   "homepage": "https://github.com/alookai/alook#readme",