crewly 1.9.0 → 1.11.0

package/config/roles/orchestrator/prompt.md

@@ -37,6 +37,21 @@ When a user says "implement X" or "fix X" — this means: find the right agent a
 
 The owner hired you to deliver results, not to narrate progress or ask permission for every step. Unless the owner explicitly pauses you or asks for approval mode, you operate in **Silent Mode**.
 
+> ## ⛔ APPROVAL BOUNDARY — read this before you dispatch anything
+>
+> Silent / Autonomous Mode governs **HOW already-approved work proceeds** — it is NOT a license to **start new committed work**. Two action classes:
+>
+> - **Continuation (autonomous OK):** advancing a goal/project the owner has ALREADY approved — assign the next task, re-prompt an idle agent, route an approved OKR's KRs, course-correct. No permission needed.
+> - **Commitment (ALWAYS needs explicit approval, regardless of mode):** **launching a team / spinning up or waking agents for a new project / starting a multi-step production pipeline**, creating a team or project, changing OKRs, irreversible or money-spending actions. These require an explicit **affirmative directive** before you dispatch.
+>
+> **A QUESTION IS NEVER APPROVAL.** "是否需要启动团队？" / "should we…?" / "帮我看看…" / "can you check…" / "你觉得呢？" are **decision REQUESTS** — you answer them and then **WAIT**. Approval is an explicit affirmative token the owner sends *after* your proposal: **启动 / 开始 / go / do it / 批准 / 同意 / proceed**. If you cannot quote the exact approving message, you do **NOT** have approval — treat it as **PENDING** and do not dispatch.
+>
+> **NEVER fabricate approval.** Do not write "已批准 / 已拍板 / Steve approved / user confirmed" in any WorkItem title, message, brief, or task unless you can cite the specific approving message (who said it, when). If you cannot, the WorkItem must say approval is **PENDING owner sign-off**.
+>
+> **Honor stand-downs.** If the owner says "我来做就好 / 你先不管 / I'll handle it / leave it / 不用了" → that goal is **PARKED**. Do not dispatch or wake agents on it until the owner **re-engages with an affirmative directive**. A later *question* about the parked topic does NOT un-park it.
+>
+> **Verification = run the tool, then quote it.** Never assert a file's existence, size, or path ("已验证 48MB", "文件在 ~/Movies/…") — or any other checkable fact — without an actual tool call (`ls`/`stat`/`find`) **in the same turn**, and quote its output. If you have not run the check, say "not yet verified" — never "已验证".
+
 **In Silent Mode you:**
 - **Drive work forward autonomously.** Delegate, monitor, re-prompt idle agents, retry blocked ones, reschedule stuck work. Use the trigger/cron/follow-up infrastructure. Do not wait for the owner to tell you to move the next step.
 - **Do NOT surface internal team chatter.** If Ella and Luna are negotiating a handoff, or an agent is mid-retry, the owner does not see that. It stays inside the team.
@@ -320,7 +335,7 @@ If a `watch:` or `fallback:` for the same delegatee already exists, do NOT add a
 
 ## Autonomous Mode — Default ON
 
-**Autonomous Mode is ON by default** (see "Silent by Default" above). The owner hired you to deliver results — you drive work forward without asking permission for every step. The orchestrator only leaves Autonomous Mode when the user explicitly opts into Approval Mode — e.g. "暂停 / 让我批准每一步 / ask first / approve each step".
+**Autonomous Mode is ON by default** (see "Silent by Default" above) — but it ONLY covers **continuation of work the owner has already approved** (see the **⛔ APPROVAL BOUNDARY**). It is NOT permission to launch a new team/project/pipeline or otherwise take a commitment-class action; those always need an explicit affirmative directive first. You drive *approved* work forward without asking permission for every step. The orchestrator only leaves Autonomous Mode (for continuation) when the user explicitly opts into Approval Mode — e.g. "暂停 / 让我批准每一步 / ask first / approve each step".
 
 ### Agent Context & Resource Management
 
@@ -338,11 +353,14 @@ The user's goal/OKR is a standing order. You don't need permission to:
 - Route OKR key results to the appropriate Team Lead for task decomposition
 - Monitor progress and course-correct
 
-You DO need permission to:
+You DO need permission to (see the **⛔ APPROVAL BOUNDARY** at the top — these are commitment-class actions; a question never grants this permission):
+- **Launch a team / wake or spin up agents for a NEW project, or start a multi-step production pipeline** (this is the #1 thing owners do NOT expect you to do on your own)
 - Change the OKRs themselves
 - Create new teams or projects
 - Make architectural decisions not covered by the OKR
 
+Autonomous Mode being ON does **not** waive these — it only lets you continue work the owner already approved. The first launch of any team/project/pipeline for a new goal requires an explicit affirmative directive (启动 / go / 开始), not a question and not your own inference.
+
 **Continuous Execution Protocol (only when Autonomous Mode is ON):**
 
 The execution loop is driven by **scheduled checks** — a system-level mechanism that reliably keeps work moving regardless of orchestrator state (restarts, context loss, etc.).
@@ -770,6 +788,39 @@ If a WI's brief begins with `# Wiki Queue Drain`, `# Wiki Legacy Migration`,
 or similar `# Wiki <action>` heading **AND** carries `metadata.autoCreated
 === true`, it's a bridge WI. Process it via the named skill; don't delete.
 
+## Verify before you alarm — operational actions (restart / upgrade / cleanup / bulk ops) — MANDATORY
+
+Before you WARN about (or perform) any operational action with perceived risk
+— a restart, a version upgrade, a bulk delete, a cleanup — do the cheap
+READ-ONLY verification of the ACTUAL state FIRST, then report what you found.
+Do NOT lead with a memory- or pattern-matched alarm and a menu of options.
+
+The 2026-06-02 pattern this prevents: asked to upgrade + restart, the orc
+warned "cron may be lost or duplicated on restart (Issue #613)" and offered
+A/B/C options — *before* ever reading the cron files. A 30-second read showed
+all 23 crons were safely persisted in the team stores; nothing was at risk.
+The instinct to be careful was right; leading with the alarm instead of the
+check was the mistake.
+
+- **Restart / cron example:** before claiming "cron may be lost or duplicated
+  on restart," actually read the stores and report real counts:
+  `~/.crewly/cron-tasks.json`, each team's `teams/<id>/cron-tasks.json`, and
+  `~/.crewly/triggers/triggers.json`. Persisted crons survive restart
+  (`create()` writes to disk) and load-time dedup prevents doubling — a normal
+  restart neither loses nor duplicates them. An empty GLOBAL cron file is
+  **normal** when crons are team-scoped; check the team files before
+  concluding "lost."
+- **Don't assume your INSTALLED version's bugs apply to the version you're
+  upgrading TO.** A known issue may already be fixed in the target version —
+  verify the target's behavior (or changelog) before citing it as a risk.
+- **Cite an issue number only after confirming it exists AND that its
+  mechanism still applies** to the version in play. (e.g. #613 was a real,
+  open issue, but its registry-duplication mechanism was refactored away; the
+  symptom now arises only from a separate path — so quoting it as a blocking
+  restart risk was wrong.)
+- Caution before a risky op is GOOD. The rule is **verify-first, report the
+  facts, then flag any real residual risk** — never alarm-first.
+
 ## Your Capabilities
 
 > **Note:** You achieve these capabilities by **delegating to agents**. Do not perform these tasks yourself — assign them to the right team member.

package/config/skills/agent/core/get-sops/SKILL.md

@@ -47,13 +47,17 @@ Query standard operating procedures (SOPs) relevant to your current context or t
 | `context` | Yes | Description of what you need SOPs for (e.g., `"deploying to production"`) |
 | `category` | No | Filter by SOP category (e.g., `"deployment"`, `"testing"`, `"code-review"`) |
 | `role` | No | Filter by role relevance (e.g., `"developer"`, `"qa"`) |
+| `sessionName` | No | Your session name. Lets the skill resolve your team and ALSO return your team's own installed/custom SOPs (the ones authored via `update-sop` / the wiki). |
+| `teamId` | No | Explicit team id (skips the sessionName lookup). |
+
+The result includes both the global SOPs and — when your team is resolved — a **Team SOPs** section from your team's library (`~/.crewly/teams/<id>/sops/`), so SOPs your team authored are actually visible here.
 
 ## Example
 
 ```bash
-bash config/skills/agent/get-sops/execute.sh '{"context":"deploying a new backend service","category":"deployment","role":"developer"}'
+bash config/skills/agent/core/get-sops/execute.sh '{"context":"publishing an XHS post","category":"marketing","sessionName":"crewly-marketing-ella"}'
 ```
 
 ## Output
 
-JSON with matching SOPs including their titles, content, and applicability metadata.
+JSON with matching SOPs including their titles, content, and applicability metadata, plus a Team SOPs section when a team is resolved.

package/config/skills/agent/core/get-sops/execute.sh

@@ -12,13 +12,38 @@ require_param "context" "$CONTEXT"
 
 CATEGORY=$(printf '%s' "$INPUT" | jq -r '.category // empty')
 ROLE=$(printf '%s' "$INPUT" | jq -r '.role // empty')
+TEAM_ID=$(printf '%s' "$INPUT" | jq -r '.teamId // empty')
+SESSION_NAME=$(printf '%s' "$INPUT" | jq -r '.sessionName // empty')
+
+# Resolve teamId so the backend can also surface THIS team's installed/custom
+# SOP library (~/.crewly/teams/<id>/sops/), not just the global store.
+CREWLY_HOME="${HOME}/.crewly"
+resolve_team_id() {
+  local session="${1:-${CREWLY_SESSION_NAME:-}}"
+  [ -z "$session" ] && return 1
+  local teams_dir="${CREWLY_HOME}/teams"
+  [ ! -d "$teams_dir" ] && return 1
+  for config in "$teams_dir"/*/config.json; do
+    [ -f "$config" ] || continue
+    if [ "$(jq -r --arg s "$session" '.members[]? | select(.sessionName == $s) | "found"' "$config" 2>/dev/null | head -1)" = "found" ]; then
+      basename "$(dirname "$config")"
+      return 0
+    fi
+  done
+  return 1
+}
+if [ -z "$TEAM_ID" ]; then
+  TEAM_ID=$(resolve_team_id "$SESSION_NAME" || true)
+fi
 
 BODY=$(jq -n \
   --arg context "$CONTEXT" \
   --arg category "$CATEGORY" \
   --arg role "$ROLE" \
+  --arg teamId "$TEAM_ID" \
   '{context: $context} +
    (if $category != "" then {category: $category} else {} end) +
-   (if $role != "" then {role: $role} else {} end)')
+   (if $role != "" then {role: $role} else {} end) +
+   (if $teamId != "" then {teamId: $teamId} else {} end)')
 
 api_call POST "/system/sops/query" "$BODY"

package/config/skills/agent/core/get-team-norms/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: Get Team Norms
+description: Read your team's norms (operating agreements — canDelegate, escalation, rules of engagement) relevant to the current moment.
+version: 1.0.0
+category: system
+skillType: claude-skill
+assignableRoles:
+  - developer
+  - qa
+  - tpm
+  - designer
+  - frontend-developer
+  - backend-developer
+  - fullstack-dev
+  - qa-engineer
+  - product-manager
+  - architect
+  - generalist
+  - team-leader
+  - sales
+  - support
+triggers:
+  - get team norms
+  - team norms
+  - rules of engagement
+  - can i delegate
+  - escalation policy
+tags:
+  - system
+  - norms
+  - governance
+  - team
+execution:
+  type: script
+  script:
+    file: execute.sh
+    interpreter: bash
+    timeoutMs: 15000
+---
+
+# Get Team Norms
+
+Read your **team norms** — the team's own operating agreement: who may delegate
+to whom (`canDelegate`), role conventions, escalation paths, decision rights,
+and rules of engagement. Norms are team-specific and authored by the team
+(by the owner in the wiki, or proposed by agents via `update-team-norm`).
+
+Norms differ from SOPs: a **SOP** is a reusable procedure ("how to do task X");
+a **norm** is "how THIS team operates together." Consult norms before acting on
+anything governance-related — delegating, escalating, deciding scope.
+
+## Parameters
+
+| Parameter | Required | Description |
+|-----------|----------|-------------|
+| `trigger` | No | Filter to norms relevant to a moment (e.g. `"before_commit"`, `"before_delegate"`). Omit to read all. |
+| `teamId` | No | Team to read. Defaults to the team resolved from your `sessionName`. |
+| `sessionName` | No | Your session name, used to resolve the team when `teamId` is omitted. |
+
+## Example
+
+```bash
+bash config/skills/agent/core/get-team-norms/execute.sh '{"trigger":"before_delegate"}'
+```
+
+## Output
+
+JSON `{ success, count, data: [{ normId, title, trigger, content, updatedBy, updatedAt }] }`.
+Returns an empty list if the team has no norms yet.

package/config/skills/agent/core/list-my-crons/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: list-my-crons
+description: List the recurring cron tasks the orchestrator has scheduled FOR you — call before self-scheduling so you don't create duplicates that fire N× reports.
+version: 1.0.0
+category: followup
+skillType: claude-skill
+tags:
+  - cron
+  - schedule
+  - audit
+execution:
+  type: script
+  script:
+    file: execute.sh
+    interpreter: bash
+    timeoutMs: 15000
+---
+
+# list-my-crons
+
+List the recurring **cron tasks** that target you — i.e. schedules the
+orchestrator (or you) registered with you as the `targetAgent`. Call this
+**before** creating a cron or a `schedule-followup`, so you can confirm whether
+you are already scheduled instead of stacking a duplicate.
+
+## Why this exists
+
+Cron tasks and follow-up triggers live in **two different stores**:
+
+| What | Store | List it with |
+|------|-------|--------------|
+| Recurring cron the orchestrator set for you | cron-tasks (per-team file) | **`list-my-crons`** (this skill) |
+| Follow-up timers you created | triggers (TriggerEngine) | `list-my-followups` |
+
+`list-my-followups` will **not** show the orchestrator's crons — they are in a
+separate store. If you only check followups, you can wrongly conclude "I have
+no schedule" and self-create a duplicate cron. That duplicate then fires every
+trigger N× (N identical reports/PDFs). Always check **both** before scheduling.
+
+> Note: "cron API shows 0" is **not** a reliable "no schedule exists" signal on
+> its own — historically agents misread it and self-duplicated (#621). Check
+> the actual list here, and if unsure, ask the orchestrator rather than
+> re-creating.
+
+## Examples
+
+```bash
+# All crons targeting you
+bash execute.sh
+
+# Only enabled ones
+bash execute.sh --enabled true
+```
+
+## Options
+
+| Flag | Meaning |
+|------|---------|
+| `--enabled <true\|false>` | Filter by enabled state (optional) |
+| `--target <session>` | Query a different agent's crons (default: yourself) |
+| `--json`, `-j` | Raw JSON payload (legacy) |
+
+## Output
+
+```
+{ "success": true, "count": <n>, "data": [ CronTask, ... ] }
+```

package/config/skills/agent/core/list-my-crons/execute.sh

@@ -0,0 +1,77 @@
+#!/bin/bash
+# List the recurring cron tasks that target YOU (or another agent via --target).
+#
+# Cron tasks and follow-up triggers live in two different stores. This skill
+# reads the cron-tasks store (what the orchestrator schedules FOR an agent),
+# which `list-my-followups` does NOT cover. Call this before self-scheduling so
+# you don't stack a duplicate cron that fires N× reports per trigger (#621).
+#
+# Supports CLI flags (preferred) or legacy JSON.
+set -euo pipefail
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+source "${SCRIPT_DIR}/../../_common/lib.sh"
+
+print_usage() {
+  cat <<'EOF_USAGE'
+Usage:
+  bash execute.sh                      # All crons targeting you
+  bash execute.sh --enabled true       # Only enabled crons targeting you
+  bash execute.sh --target <session>   # Crons targeting another agent
+
+Options:
+  --enabled   One of: true | false (optional)
+  --target    Agent session to query (default: yourself, $CREWLY_SESSION_NAME)
+  --json -j   Raw JSON payload (legacy)
+  --help -h   Show this help
+
+Output: JSON object { success, count, data: [CronTask, ...] }
+EOF_USAGE
+}
+
+INPUT_JSON=""
+ENABLED_FILTER=""
+TARGET=""
+
+if [[ $# -gt 0 && ${1:0:1} == '{' ]]; then
+  INPUT_JSON="$1"
+  shift || true
+fi
+
+while [[ $# -gt 0 ]]; do
+  case "$1" in
+    --enabled)   ENABLED_FILTER="$2"; shift 2 ;;
+    --target)    TARGET="$2"; shift 2 ;;
+    --json|-j)   INPUT_JSON="$2"; shift 2 ;;
+    --help|-h)   print_usage; exit 0 ;;
+    --)          shift; break ;;
+    *)
+      if [[ -z "$INPUT_JSON" && ${1:0:1} == '{' ]]; then
+        INPUT_JSON="$1"; shift
+      else
+        echo '{"error":"Unknown argument: '"$1"'"}' >&2
+        exit 1
+      fi
+      ;;
+  esac
+done
+
+if [ -n "$INPUT_JSON" ]; then
+  ENABLED_FILTER=$(printf '%s' "$INPUT_JSON" | jq -r '.enabled // empty')
+  TARGET=$(printf '%s' "$INPUT_JSON" | jq -r '.target // empty')
+fi
+
+# Default target = self
+[ -z "$TARGET" ] && TARGET="${CREWLY_SESSION_NAME:-}"
+[ -z "$TARGET" ] && { echo '{"error":"No --target and CREWLY_SESSION_NAME is unset"}' >&2; exit 1; }
+
+# Build query string: filter by targetAgent (Option A from #621 — the API
+# returns crons where targetAgent == session, regardless of who created them).
+QUERY="?targetAgent=${TARGET}"
+[ -n "$ENABLED_FILTER" ] && QUERY="${QUERY}&enabled=${ENABLED_FILTER}"
+
+LIST_RESP=$(api_call GET "/cron-tasks${QUERY}" "")
+
+# Normalise to { success, count, data } so callers get a stable shape.
+DATA=$(printf '%s' "$LIST_RESP" | jq '(.data // [])')
+COUNT=$(printf '%s' "$DATA" | jq 'length')
+printf '%s' "$DATA" | jq --arg c "$COUNT" '{success:true, count:($c|tonumber), data:.}'

package/config/skills/agent/core/schedule-followup/SKILL.md

@@ -34,6 +34,19 @@ that went quiet.
 | "Whenever Rex goes idle, check progress" | `watch-for-event` (event-based, not this skill) |
 | Simple self-reminder with no team scope | `schedule-check` (older skill) |
 
+## Before you schedule — check you aren't already scheduled
+
+Schedules live in **two stores**: follow-up triggers (this skill) and cron
+tasks the orchestrator sets for you. Check **both** before creating, or you
+will stack a duplicate that fires N× reports:
+
+- `list-my-followups` — your follow-up triggers
+- `list-my-crons` — recurring crons targeting you (the orchestrator's)
+
+Do **not** treat "cron list shows 0" alone as "no schedule exists" — verify
+with both skills, and if still unsure, ask the orchestrator instead of
+re-creating (#621).
+
 ## Key invariants
 
 - Every followup is **team-scoped**. It shows up under `list-my-followups` and

package/config/skills/agent/core/update-sop/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: Update SOP
+description: Author or update a custom SOP (a reusable procedure / playbook) for your team.
+version: 1.0.0
+category: system
+skillType: claude-skill
+assignableRoles:
+  - team-leader
+  - tpm
+  - product-manager
+  - architect
+  - generalist
+  - developer
+  - qa
+  - qa-engineer
+  - backend-developer
+  - frontend-developer
+  - fullstack-dev
+triggers:
+  - update sop
+  - write a sop
+  - document the procedure
+  - create a playbook
+  - standardize how we
+tags:
+  - system
+  - sops
+  - procedures
+  - team
+execution:
+  type: script
+  script:
+    file: execute.sh
+    interpreter: bash
+    timeoutMs: 15000
+---
+
+# Update SOP
+
+Create or update a **custom SOP** for your team — a reusable procedure /
+playbook for *how to do a class of work* (e.g. "publishing an XHS post",
+"running a release"). The SOP is written into the team's own SOP store
+(`~/.crewly/teams/<id>/sops/`) and surfaces in the wiki under the team's
+**SOPs** folder, alongside SOPs installed from the catalog. The owner can edit
+it in the wiki UI.
+
+Use this for durable, repeatable procedures — not one-off task notes (use the
+wiki/memory) and not team governance rules (those are **team norms** — use
+`update-team-norm`). Prefer installing an existing catalog SOP when one fits;
+author a custom SOP only when the team needs something the catalog lacks.
+
+## Parameters
+
+| Parameter | Required | Description |
+|-----------|----------|-------------|
+| `sopId` | Yes | Stable kebab-case id / filename, e.g. `"xhs-posting"`. |
+| `content` | Yes | The SOP body (markdown). The steps/procedure. |
+| `title` | No | Human title, e.g. `"XHS Posting Checklist"`. Required when creating. |
+| `category` | No | Optional sub-folder, e.g. `"common"`, `"marketing"`. |
+| `append` | No | `"true"` to append to an existing SOP instead of overwriting. |
+| `teamId` | No | Team to write to. Defaults to the team resolved from `sessionName`. |
+| `sessionName` | No | Your session name, used to resolve the team when `teamId` is omitted. |
+| `updatedBy` | No | Who authored the change (your agent/session name). |
+
+## Example
+
+```bash
+bash config/skills/agent/core/update-sop/execute.sh '{"sopId":"xhs-posting","title":"XHS Posting Checklist","category":"marketing","content":"1. Draft hook.\n2. Add 3-5 tags.\n3. Post 7-9pm."}'
+```
+
+## Output
+
+JSON `{ success, action: "created" | "updated", sopId, title, category, path, relativePath }`.

package/config/skills/agent/core/update-sop/execute.sh

@@ -0,0 +1,115 @@
+#!/bin/bash
+# Create or update a team's custom SOP.
+# Writes to ~/.crewly/teams/{teamId}/sops/[{category}/]{sopId}.md
+# (the per-team installed/custom SOP store the wiki surfaces under sop/).
+set -euo pipefail
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+source "${SCRIPT_DIR}/../../_common/lib.sh"
+
+CREWLY_HOME="${HOME}/.crewly"
+
+INPUT=$(read_json_input "${1:-}")
+[ -z "$INPUT" ] && error_exit "Usage: execute.sh '{\"sopId\":\"xhs-posting\",\"title\":\"XHS Posting\",\"content\":\"...\",\"category\":\"common\"}'"
+
+SOP_ID=$(printf '%s' "$INPUT" | jq -r '.sopId // empty')
+TITLE=$(printf '%s' "$INPUT" | jq -r '.title // empty')
+CATEGORY=$(printf '%s' "$INPUT" | jq -r '.category // empty')
+CONTENT=$(printf '%s' "$INPUT" | jq -r '.content // empty')
+APPEND=$(printf '%s' "$INPUT" | jq -r '.append // "false"')
+TEAM_ID=$(printf '%s' "$INPUT" | jq -r '.teamId // empty')
+SESSION_NAME=$(printf '%s' "$INPUT" | jq -r '.sessionName // empty')
+UPDATED_BY=$(printf '%s' "$INPUT" | jq -r '.updatedBy // empty')
+
+require_param "sopId" "$SOP_ID"
+require_param "content" "$CONTENT"
+
+# Sanitize id/category to safe path segments (no traversal, no slashes).
+SOP_ID=$(printf '%s' "$SOP_ID" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9._-]/-/g; s/^-*//; s/-*$//')
+CATEGORY=$(printf '%s' "$CATEGORY" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9_-]/-/g; s/^-*//; s/-*$//')
+[ -z "$SOP_ID" ] && error_exit "sopId resolved to empty after sanitization"
+
+# Resolve teamId: explicit param > lookup by sessionName > CREWLY_SESSION_NAME env
+resolve_team_id() {
+  local session="${1:-${CREWLY_SESSION_NAME:-}}"
+  [ -z "$session" ] && return 1
+  local teams_dir="${CREWLY_HOME}/teams"
+  [ ! -d "$teams_dir" ] && return 1
+  for config in "$teams_dir"/*/config.json; do
+    [ -f "$config" ] || continue
+    local found
+    found=$(jq -r --arg s "$session" '.members[]? | select(.sessionName == $s) | "found"' "$config" 2>/dev/null | head -1)
+    if [ "$found" = "found" ]; then
+      basename "$(dirname "$config")"
+      return 0
+    fi
+  done
+  return 1
+}
+
+if [ -z "$TEAM_ID" ]; then
+  TEAM_ID=$(resolve_team_id "$SESSION_NAME") || error_exit "Could not resolve teamId. Provide teamId or sessionName."
+fi
+
+SOPS_DIR="${CREWLY_HOME}/teams/${TEAM_ID}/sops"
+if [ -n "$CATEGORY" ]; then
+  SOPS_DIR="${SOPS_DIR}/${CATEGORY}"
+  REL_PATH="sop/${CATEGORY}/${SOP_ID}.md"
+else
+  REL_PATH="sop/${SOP_ID}.md"
+fi
+mkdir -p "$SOPS_DIR"
+
+SOP_FILE="${SOPS_DIR}/${SOP_ID}.md"
+TODAY=$(date +%Y-%m-%d)
+ACTION="created"
+
+if [ -f "$SOP_FILE" ]; then
+  ACTION="updated"
+  EXISTING_TITLE=$(sed -n '/^---$/,/^---$/{ /^---$/d; s/^title: *//p; }' "$SOP_FILE" | head -1)
+  EXISTING_UPDATED_BY=$(sed -n '/^---$/,/^---$/{ /^---$/d; s/^updatedBy: *//p; }' "$SOP_FILE" | head -1)
+  [ -z "$TITLE" ] && TITLE="$EXISTING_TITLE"
+  [ -z "$UPDATED_BY" ] && UPDATED_BY="$EXISTING_UPDATED_BY"
+
+  if [ "$APPEND" = "true" ]; then
+    EXISTING_CONTENT=""
+    FM_DONE=false
+    FM_COUNT=0
+    while IFS= read -r line || [ -n "$line" ]; do
+      if [ "$line" = "---" ]; then
+        FM_COUNT=$((FM_COUNT + 1))
+        if [ "$FM_COUNT" -ge 2 ]; then
+          FM_DONE=true
+          continue
+        fi
+      elif [ "$FM_DONE" = true ]; then
+        EXISTING_CONTENT="${EXISTING_CONTENT}${line}
+"
+      fi
+    done < "$SOP_FILE"
+    EXISTING_CONTENT=$(echo "$EXISTING_CONTENT" | sed '/./,$!d')
+    CONTENT="${EXISTING_CONTENT}
+${CONTENT}"
+  fi
+else
+  [ -z "$TITLE" ] && error_exit "title is required when creating a new SOP"
+fi
+
+{
+  echo "---"
+  echo "title: ${TITLE}"
+  [ -n "$CATEGORY" ] && echo "category: ${CATEGORY}"
+  [ -n "$UPDATED_BY" ] && echo "updatedBy: ${UPDATED_BY}"
+  echo "updatedAt: ${TODAY}"
+  echo "---"
+  echo ""
+  echo "$CONTENT"
+} > "$SOP_FILE"
+
+jq -n \
+  --arg sopId "$SOP_ID" \
+  --arg title "$TITLE" \
+  --arg category "$CATEGORY" \
+  --arg action "$ACTION" \
+  --arg path "$SOP_FILE" \
+  --arg relativePath "$REL_PATH" \
+  '{success: true, action: $action, sopId: $sopId, title: $title, category: $category, path: $path, relativePath: $relativePath}'

package/config/skills/agent/core/update-team-norm/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: Update Team Norm
+description: Propose or update a team norm (an operating agreement — canDelegate, escalation, rules of engagement) for your team.
+version: 1.0.0
+category: system
+skillType: claude-skill
+assignableRoles:
+  - team-leader
+  - tpm
+  - product-manager
+  - architect
+  - generalist
+  - developer
+  - qa
+triggers:
+  - update team norm
+  - propose a norm
+  - set a team rule
+  - we should always
+  - going forward the team should
+tags:
+  - system
+  - norms
+  - governance
+  - team
+execution:
+  type: script
+  script:
+    file: execute.sh
+    interpreter: bash
+    timeoutMs: 15000
+---
+
+# Update Team Norm
+
+Create or update a **team norm** — a durable operating agreement for your team
+(who may delegate to whom, escalation paths, decision rights, rules of
+engagement, recurring conventions). Use this when a lasting team-wide rule
+emerges that future work should follow — not for one-off task notes (use the
+wiki/memory for those) and not for reusable procedures (those are SOPs).
+
+Norms you write land in the team's norm store and surface in the wiki under the
+team's **Team Norms** folder, where the owner can review and edit them. Treat
+this as *proposing* a norm: keep it concise, state the rule and when it applies.
+
+## Parameters
+
+| Parameter | Required | Description |
+|-----------|----------|-------------|
+| `normId` | Yes | Stable kebab-case id / filename, e.g. `"code-commit"`, `"delegation"`. |
+| `content` | Yes | The norm body (markdown). State the rule and its rationale. |
+| `title` | No | Human title, e.g. `"Code Commit Norm"`. |
+| `trigger` | No | When this norm applies, e.g. `"before_commit"`, `"before_delegate"`. |
+| `append` | No | `"true"` to append to an existing norm instead of overwriting. |
+| `teamId` | No | Team to write to. Defaults to the team resolved from `sessionName`. |
+| `sessionName` | No | Your session name, used to resolve the team when `teamId` is omitted. |
+| `updatedBy` | No | Who authored the change (your agent/session name). |
+
+## Example
+
+```bash
+bash config/skills/agent/core/update-team-norm/execute.sh '{"normId":"delegation","title":"Delegation","trigger":"before_delegate","content":"Leads may delegate to their own team only; cross-team work goes through the orchestrator."}'
+```
+
+## Output
+
+JSON `{ success, action: "created" | "updated", normId, path }`.

package/dist/backend/backend/src/controllers/chat-v2/chat-v2.controller.d.ts

@@ -113,6 +113,8 @@ export interface ChatV2ControllerHandlers {
     listMessages: (req: Request, res: Response) => void;
     sendMessage: (req: Request, res: Response) => void | Promise<void>;
     ensureDmChannel: (req: Request, res: Response) => void;
+    ensureTeamChannel: (req: Request, res: Response) => void;
+    createHuddle: (req: Request, res: Response) => void;
     listAgents: (req: Request, res: Response) => void | Promise<void>;
     getAgentPresence: (req: Request, res: Response) => void | Promise<void>;
 }