feat(agent): manager asks admin before assigning tasks to workers

- Add Step 0 to Task Workflow: when no worker is specified, manager
  checks existing workers/workload and presents options (assign to
  existing worker, create new worker, or handle itself)
- Self-handling is listed last with a security note about broader
  system access vs isolated workers
- find-skills configuration (Step 4) moved from SKILL.md into AGENTS.md
  to keep interaction logic centralized; SKILL.md now only covers ops
- Post-creation greeting added: manager @mentions new worker to
  introduce themselves, then reminds admin to @mention when giving tasks
- YOLO mode default changed to auto-create worker instead of self-handle

Author: johnlanni

manager/agent/AGENTS.md

@@ -94,6 +94,84 @@ Skills provide your tools. When you need one, check its `SKILL.md`. Keep local n
 
 ## Task Workflow
 
+### Step 0: Worker Availability Check (when no Worker is explicitly specified)
+
+When the human admin assigns a task **without explicitly naming a Worker**, you MUST first assess whether a Worker is needed and offer options before proceeding.
+
+**Trigger condition**: Admin gives you a task but does NOT say "assign to [worker]" or "let [worker] do this".
+
+**Step 1 — Check existing Workers:**
+
+```bash
+cat ~/workers-registry.json
+```
+
+Also check current workload:
+
+```bash
+cat ~/state.json
+```
+
+**Step 2 — Present options to the admin:**
+
+Based on what you find, present a message like:
+
+> You've assigned me a task: **{task title}**
+>
+> How would you like to handle this?
+>
+> **Option A — Assign to an existing Worker** *(only if idle Workers exist)*
+> {For each idle Worker: "**{name}**: {role/description from their SOUL.md} — currently idle"}
+>
+> **Option B — Create a new Worker**
+> I'll create a dedicated Worker for this task. Suggested configurations:
+> - **{Suggested name}** (e.g., `coder-01`): Focused on {relevant role based on task type}. Skills: {relevant skills}. Model: {default model}.
+> - **{Alternative name}** (e.g., `researcher-01`): Focused on {alternative role}. Skills: {alternative skills}. Model: {default model}.
+>
+> *(You can also describe a custom Worker configuration.)*
+>
+> **Option C — I'll handle it myself**
+> I'll work on this directly. Note: I run with broader system access than Workers — for tasks involving external code, third-party skills, or untrusted inputs, using an isolated Worker is safer.
+>
+> Which option do you prefer?
+
+**Step 3 — Act on the admin's choice:**
+
+| Choice | Action |
+|--------|--------|
+| Existing Worker name / Option A | Proceed to "Before Assigning Tasks" section below, assign to that Worker |
+| "Create a Worker" / Option B (with or without customization) | Ask about find-skills (Step 4), then follow the worker-management skill to create the Worker, then assign the task |
+| Custom Worker description | Use the description to configure and create the Worker (ask about find-skills first), then assign the task |
+| "Handle it yourself" / Option C | Proceed to work on the task directly, without creating a task directory or assigning to a Worker |
+
+**Step 4 — Find-Skills configuration (only when creating a new Worker):**
+
+Check the current default:
+```bash
+echo "${HICLAW_SKILLS_API_URL:-not set (will use https://skills.sh)}"
+```
+
+Ask the admin:
+
+> **Find-Skills** — Workers can discover and install new skills from the Agent Skills ecosystem to extend their capabilities. Workers run in isolated containers and cannot access your personal data.
+>
+> Current default registry: `${HICLAW_SKILLS_API_URL:-https://skills.sh}`
+>
+> 1. **Enable** (Recommended) — Worker can search and install skills
+> 2. **Disable** — Worker uses only pre-installed skills
+>
+> If enabled, enter a custom registry URL or leave empty to use the default.
+
+Record `enable_find_skills` (true/false) and `skills_api_url` (custom URL or empty), then pass to `create-worker.sh` via `--find-skills` / `--skills-api-url`.
+
+**Skip this step when:**
+- The admin explicitly names a Worker ("assign to alice", "let bob handle this")
+- The admin explicitly says "do it yourself" or "handle it"
+- This is a heartbeat-triggered infinite task (already assigned)
+- YOLO mode is active (`$HICLAW_YOLO = "1"`) — in that case, create a Worker autonomously unless the task is trivial enough to handle directly
+
+---
+
 ### Before Assigning Tasks: Container Status Check (if container API is available)
 
 Before assigning any task (finite or triggering an infinite task) to a Worker:

manager/agent/skills/worker-management/SKILL.md

@@ -29,36 +29,14 @@ No need to set defaults - these are always available in the container environmen
 
 ## Create a Worker
 
-### Step 0: Ask Admin about Find-Skills (IMPORTANT)
+### Step 0: Receive configuration from AGENTS.md interaction
 
-**Before creating any Worker, you MUST ask the admin about find-skills configuration.**
-
-> **Note**: If the environment variable `HICLAW_SKILLS_API_URL` is set (configured during Manager installation), it will be used automatically as the default skills registry URL. The admin can override it per-worker, or leave it empty to accept the default.
-
-Check the current default first:
-```bash
-echo "${HICLAW_SKILLS_API_URL:-not set (will use https://skills.sh)}"
-```
-
-Ask the admin:
-
-> **Find-Skills Configuration**
->
-> Workers can discover and install new skills from the Agent Skills ecosystem (skills.sh) to extend their capabilities.
->
-> **Security Note**: Workers run in completely isolated containers and **cannot access any of admin's personal sensitive data**. You can safely enable this feature.
->
-> Current default skills registry: `${HICLAW_SKILLS_API_URL:-https://skills.sh}`
->
-> Please choose:
-> 1. **Enable find-skills** (Recommended) - Worker can search and install skills
-> 2. **Disable** - Worker can only use pre-installed skills from Manager
->
-> If enabled, do you want to use a different registry URL than the default? (Leave empty to keep current default)
-
-Wait for admin's response and record:
+By the time you reach this skill, the admin has already confirmed:
+- Worker name, role description, and any custom model/MCP server preferences
 - `enable_find_skills`: true/false
-- `skills_api_url`: custom URL or empty (default: https://skills.sh)
+- `skills_api_url`: custom URL or empty (uses `${HICLAW_SKILLS_API_URL:-https://skills.sh}` as default)
+
+These are determined during the Task Workflow Step 0 / Step 4 interaction in AGENTS.md. Do not re-ask.
 
 ### Step 1: Write SOUL.md
 
@@ -160,6 +138,20 @@ bash -c 'source /opt/hiclaw/scripts/lib/container-api.sh && container_status_wor
 bash -c 'source /opt/hiclaw/scripts/lib/container-api.sh && container_logs_worker "<WORKER_NAME>" 20'
 ```
 
+### Post-creation greeting
+
+Once the Worker is confirmed `ready`, send a message in the Worker's Room to kick off the introduction:
+
+```
+@<WORKER_NAME>:${HICLAW_MATRIX_DOMAIN} You're all set! Please introduce yourself to everyone in this room.
+```
+
+The Worker will greet the room. After the Worker's greeting, send a follow-up addressed to the admin:
+
+```
+@${HICLAW_ADMIN_USER}:${HICLAW_MATRIX_DOMAIN} <WORKER_NAME> is ready. When giving them tasks or instructions, remember to @mention them so they see your message.
+```
+
 ## Monitor Workers
 
 ### Heartbeat Check (automated every 15 minutes)