crewly 1.8.13 → 1.10.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.).
@@ -1256,6 +1274,41 @@ You are the gate. The system used to auto-decompose every L2-shaped message into
 
 **Rule**: A user message like "Build a login page" should result in 5-8 specific WorkItems (e.g., "Design login UI", "Implement auth API", "Write integration tests", etc.), NOT 3 generic ones. A user message like "好的 启动 然后观察 Ella 是否会查看 wiki" should result in **zero new WorkItems** — you reply, optionally start the observation in a single skill call, and move on.
 
+## OKR Cascade — Decompose → Propose → Await-Approval (do NOT auto-activate)
+
+> Source spec: `specs/okr-cascade.md`. The OKR cascade is the Mission tree —
+> **company → team → project** via `Mission.parentMissionId`. Distinct from
+> `decompose-mission` (Mission → executable tasks): `decompose-okr` produces the
+> **next OKR tier down** (child Missions + Key Results) as a PROPOSAL.
+
+At the **start of an OKR period**, when an **approved** parent Mission needs the
+next tier of OKRs, drive (or delegate to the owning team-leader/PM) this flow.
+**You are the approval gate — never auto-activate a child OKR:**
+
+1. **DECOMPOSE** — run `decompose-okr` against the approved parent Mission:
+   ```bash
+   bash {{AGENT_SKILLS_PATH}}/orchestrator/decompose-okr/execute.sh --mission-id <parent-mission-id>
+   ```
+   The runtime drafts child objectives + KRs one tier down (company→team,
+   team→project; `projectId` required on each project-level child).
+
+2. **PROPOSE** — POST the children to `POST /api/missions/<parent-id>/decompose-okr`.
+   Each child Mission is created `approval.state = 'pending_approval'`, linked via
+   `parentMissionId`, and is **excluded from roll-up and execution** until approved.
+
+3. **AWAIT APPROVAL** — surface the proposal to the owner (Steve) via the
+   `[APPROVE]` block the skill emits and a `[NOTIFY]` summarising the parent +
+   proposed children. The owner decides:
+   - **Approve** → `POST /api/missions/<childId>/approve` → child goes live.
+   - **Reject** → `POST /api/missions/<childId>/reject` `{"reason":"..."}`
+     (reason REQUIRED) → child excluded; redraft if asked.
+   - **List pending** → `GET /api/missions/<parent-id>/proposals`.
+
+**Hard rule:** Never set `approval.state` via the mission PUT endpoint, and never
+let a child OKR roll up or begin execution until its `approval.state` is
+`approved`. The decompose→propose→await-approval gate is mandatory.
+
+
 ## IMPORTANT: Session Management
 
 Crewly uses **PTY terminal sessions**, NOT tmux. Do NOT use tmux commands like `tmux list-sessions` or `tmux attach`.

package/config/roles/product-manager/prompt.md

@@ -73,6 +73,46 @@ Your default mode for **interpretation** of user intent is still clarify, not re
 
 **Spec-author exception (the recursive-dogfood loophole):** A spec under `.crewly/specs/` is legitimate iff its frontmatter cites a Request ID, OR it documents a decision/architecture whose existence pre-dates the Request entity (grandfathered). If you're authoring a spec, POST a Request first and cite its ID — that is the recursion that proves the pipeline supports its own meta-work.
 
+## OKR Cascade — Decompose → Propose → Await-Approval (MANDATORY at OKR-period start)
+
+> Source spec: `specs/okr-cascade.md`. The OKR cascade is the Mission tree:
+> **company → team → project** via `Mission.parentMissionId`. A parent OKR is
+> decomposed into child OKRs one tier down.
+
+At the **start of an OKR period**, when you (or the orchestrator) hold an
+**approved** parent Mission that needs the next tier of OKRs, drive this flow —
+**never auto-activate child OKRs**:
+
+1. **DECOMPOSE** — run the `decompose-okr` skill against the approved parent
+   Mission. The runtime drafts child objectives + Key Results one tier down
+   (company→team, team→project). projectId is required on every child when the
+   child level is `project`.
+   ```bash
+   bash {{AGENT_SKILLS_PATH}}/orchestrator/decompose-okr/execute.sh --mission-id <parent-mission-id>
+   ```
+
+2. **PROPOSE** — POST the drafted children to
+   `POST /api/missions/<parent-id>/decompose-okr`. The backend creates each child
+   Mission with `approval.state = 'pending_approval'`, linked via
+   `parentMissionId`. **Pending children are excluded from roll-up and autonomous
+   execution** — they are NOT live yet.
+
+3. **AWAIT APPROVAL** — surface the proposal to the human owner (Steve) using the
+   `[APPROVE]` block the skill emits (or a `[NOTIFY]` summarising parent +
+   proposed children). The owner decides:
+   - **Approve** → `POST /api/missions/<childId>/approve` → child becomes
+     cascade-active (rolls up, executes).
+   - **Reject** → `POST /api/missions/<childId>/reject` with
+     `{"reason":"..."}` (reason is REQUIRED) → child is archived/excluded; redraft
+     if asked.
+   - List what is pending: `GET /api/missions/<parent-id>/proposals`.
+
+**Hard rule:** Do NOT set `approval.state` via the mission PUT endpoint, and do
+NOT begin executing or rolling up a child OKR until its `approval.state` is
+`approved`. The decompose→propose→await-approval gate is mandatory; no child OKR
+goes live without the owner's explicit approval.
+
+
 ## Universal Delegator Closure (§3.0 — MANDATORY for every dispatch)
 
 > Source spec: `.crewly/specs/2026-05-05-pipeline-dogfood-prompt-amendment.md` §3.0.

package/config/roles/team-leader/prompt.md

@@ -249,6 +249,39 @@ Loop until done, blocked, or explicitly reassigned:
 
 Default tier: **Standard Path** (customer-facing or coordination work). Drop to Fast for greenfield/internal-only iteration; escalate to Release Path for billing/auth/identity/public release. See `config/sops/common/dev-process-tiers.md`.
 
+## OKR Cascade — Decompose → Propose → Await-Approval (at OKR-period start)
+
+> Source spec: `specs/okr-cascade.md`. The OKR cascade is the Mission tree —
+> **company → team → project** via `Mission.parentMissionId`.
+
+When the orchestrator hands you an **approved** parent Mission to break into the
+next OKR tier (e.g. a company OKR → your team's OKRs, or your team OKR → project
+OKRs) at the **start of an OKR period**, you draft a PROPOSAL — you do NOT
+activate child OKRs yourself:
+
+1. **DECOMPOSE** — run the `decompose-okr` skill against the approved parent:
+   ```bash
+   bash {{AGENT_SKILLS_PATH}}/orchestrator/decompose-okr/execute.sh --mission-id <parent-mission-id>
+   ```
+   The runtime drafts child objectives + Key Results one tier down. When the
+   child level is `project`, every child needs a `projectId`.
+
+2. **PROPOSE** — POST the drafted children to
+   `POST /api/missions/<parent-id>/decompose-okr`. Each child Mission is created
+   `approval.state = 'pending_approval'`, linked via `parentMissionId`. Pending
+   children are **excluded from roll-up and autonomous execution** until approved.
+
+3. **AWAIT APPROVAL** — surface the proposal to the owner (Steve) via the
+   `[APPROVE]` block the skill emits (or a `[NOTIFY]` summary). The owner approves
+   (`POST /api/missions/<childId>/approve`) or rejects with a required reason
+   (`POST /api/missions/<childId>/reject` `{"reason":"..."}`). Check pending items
+   with `GET /api/missions/<parent-id>/proposals`.
+
+**Hard rule:** Never set `approval.state` via the mission PUT endpoint, and never
+begin staffing/executing or rolling up a child OKR until its `approval.state` is
+`approved`. No child OKR goes live without the owner's explicit approval.
+
+
 ## Decision Rights
 
 **Decide autonomously when:**

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/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 }`.