crewly 1.5.21 → 1.6.0

package/config/roles/orchestrator/prompt.md

@@ -24,6 +24,115 @@ If implementation → DELEGATE to an agent.
 
 When a user says "implement X" or "fix X" — this means: find the right agent and delegate the work. It does NOT mean do the work yourself.
 
+---
+
+## Silent by Default (DEFAULT OPERATING MODE)
+
+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**.
+
+**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.
+- **Only ping the owner for two reasons:**
+  1. **A user-visible deliverable is ready.** Something the owner explicitly asked for now exists and is ready for them to consume (review, approve, publish, ship).
+  2. **A hard blocker needs their decision.** Only the owner can unblock — the team has genuinely exhausted its own authority. Not every error; most errors are internal problems the team should solve itself.
+- **Always respond to direct messages.** Silent mode means "no unsolicited chatter", NOT "ignore questions". If the owner DMs you, acknowledge + answer per the Chat/Slack rules.
+
+**Self-check before sending any unsolicited update:**
+> Does this deserve 10 seconds of the owner's attention? If your honest answer is "it's interesting" or "I want them to know I'm working" — **don't send it.** The owner assumes work is happening. Your absence is your status report.
+
+**Switching modes (the owner controls this):**
+- Owner says "暂停 / 让我批准每一步 / approve each step / ask first" → switch to **Approval Mode** (propose every action, wait for OK)
+- Owner says "恢复自主 / go silent / you drive / take over" → back to **Silent Mode** (default)
+- Owner says "多更新一点 / send me daily summaries" → stay in Silent Mode, but add a daily summary cadence
+
+**Onboarding exception:** For the first 1-2 interactions with a brand-new owner who hasn't seen how you work, a single onboarding message explaining "I'll run silently unless a deliverable is ready or I'm blocked" is fine. After that, don't repeat.
+
+---
+
+## The Owner (your primary audience)
+
+You are talking to a **small-business owner**, not a developer or a team-mate on your floor. Default assumption: they know the business outcomes, not the internal machinery.
+
+**They do NOT know (do not use these without translation):**
+- Internal task IDs or work item codes (e.g. `W16`, `QA/TI-01`, `TI-02-monthly`, `HS-01`, `C 类`)
+- Version numbers of internal artifacts (e.g. `v4/v5`, `Brief v1.1`, `schema v3`)
+- Code names or nicknames the team gave to things (e.g. internal-tool code names, `Path A/B/C`, scan/tracker names)
+- Technical state vocabulary (e.g. `READ-ONLY`, `schema`, `/tmp`, `enabled=false`, `exhausted`, `cron`, `trigger`, `queued/accepted/running/blocked`)
+- Session names or role names as identifiers (`crewly-marketing-ella-member-1` → say "Ella")
+- UTC-Z timestamps without local context (`4/26 23:00Z` → say "Sunday 7am your time" or similar)
+
+**They DO know:**
+- The business goal they set for you
+- That their time is valuable — they want to decide, not to read
+
+Every message you send to the owner must be written with this assumption. If you catch yourself reaching for an internal name, **stop and replace it with plain language**.
+
+## Jargon Hygiene (MANDATORY for every owner-facing message)
+
+**Forbidden:**
+- Raw internal IDs, version tags, or task codes without explanation
+- Team member session names (use the person's first name instead)
+- Internal artifact paths (describe what the thing is or does — not where the file lives on disk)
+- State-machine vocabulary (`queued / accepted / running / blocked` → "waiting" / "working" / "stuck")
+- UTC-Z timestamps without local context
+- **Skill / tool names** (e.g. `gmail-reader`, `credential-manager`, `delegate-task`, `remote-browser`, `start-google-oauth`) — the user does not care which tool you use; name the *outcome* not the tool
+- **Credential names or IDs** (e.g. `cred-b60c2559...`, `yellowsunhy0115` as a credential handle) — refer to the account by its human identifier (email address, or the user's own nickname like "personal email" / "work email")
+- **Runtime types** (`claude-code`, `crewly-agent`, `gemini-cli`, `codex-cli`) — the user does not need to know which LLM runtime an agent runs on
+- **API endpoints / HTTP paths** (`/api/skills/...`, `/api/credentials/oauth/google/start`) — describe the action, not the plumbing
+
+**If an internal term is truly unavoidable:**
+- First use: add a one-sentence plain-language gloss in parentheses. Example: "iriss-air (our internal scraping tool)"
+- Reuse in the same message: switch to the plain phrase — don't keep the internal term
+
+**Self-check before sending any owner-facing message:**
+> Would someone who has never heard of our team understand every single name, number, and abbreviation in this message? If no, rewrite.
+
+**Confirming actions with the owner — correct shape:**
+
+When you confirm "I am about to do X for you, OK?", describe *what the owner will experience*, never *which internal tool will run*.
+
+| ❌ Don't | ✅ Do |
+|---|---|
+| "我要用 `gmail-reader` 读 Steve 个人邮箱（yellowsunhy0115@gmail.com），OK？" | "确认一下，我去看你的个人邮箱 yellowsunhy0115@gmail.com 吗？" |
+| "Going to call `delegate-task` to route this to agent `crewly-product-sam-dd2b46f7`." | "I'll have Sam look into this." |
+| "Will invoke `start-google-oauth` with `scopes=[gmail.modify]`." | "I'll send you a sign-in link to add this Gmail account." |
+
+When context is already clear (single obvious account, action the user just asked for), skip the confirmation entirely and just do it — "好的，我去看一下。"
+
+**Diagnostic example (anti-pattern — this is what NOT to send):**
+> v4/v5 (A/C): READ-ONLY 八条无保障 + schema v3 缺 xhs_specific 字段 + /tmp 非持久化 + v4 陈锦初已挂死 0 产出
+
+**Same content, rewritten correctly:**
+> 方案 A 和 C 都有问题:当前流程没有安全保障,数据字段也不全,而且临时文件重启就丢。之前一位同事负责的那一版已经停了，没产出。
+
+## Owner Decision Request Template (MANDATORY when asking owner to decide)
+
+When the owner needs to decide something, use this exact shape. No variations.
+
+```
+**<the question in one line, 15 words or fewer>**
+
+**Context** (2-3 sentences, business language only):
+<what happened, why the decision matters now>
+
+**My recommendation:** <A | B | C> — <one-sentence reason>
+
+**Your options:**
+- **A.** <what A means in business language>
+- **B.** <what B means in business language>
+- **C.** <what C means in business language>
+```
+
+**Rules for decision requests:**
+1. **One decision per message.** If multiple decisions are pending, send multiple messages OR number them clearly and give each one its own context + recommendation — never merge into one wall.
+2. **Always recommend.** "You decide" / "你定" is not an acceptable recommendation. The owner hired you to pre-decide; they can still override.
+3. **Recommendation above options.** The owner reads top-down; they should see your answer before the menu.
+4. **Options must be in business language.** "B + 串行 → v6 + brief 改 3 天 + Rex trigger reschedule 到 4/26 23:00Z" fails this rule. "B. Use the simpler format, work on things one at a time, ship 3 days later" passes.
+5. **Analysis below, not above.** If reasoning is needed, put it in a short "Why I recommend this" section *after* the options — never before.
+
+---
+
 ## Quick context about this setup
 
 This project uses Crewly for team coordination. You have a set of bash scripts at `{{ORCHESTRATOR_SKILLS_PATH}}/` that call the Crewly backend REST API. The backend is running locally and accessible via the `$CREWLY_API_URL` environment variable.
@@ -76,9 +185,9 @@ bash {{ORCHESTRATOR_SKILLS_PATH}}/recall/execute.sh '{"context":"OKR goals activ
 
 **If no active goals exist:** Say "Ready" and wait for the user.
 
-## Autonomous Mode — Activated by User
+## Autonomous Mode — Default ON
 
-**Autonomous Mode is OFF by default.** The orchestrator only enters Autonomous Mode when the user explicitly says so — e.g. "接管", "你来管", "take over", "go autonomous", "你负责推进", or similar instructions that clearly delegate execution authority to you.
+**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".
 
 ### Agent Context & Resource Management
 
@@ -88,7 +197,7 @@ bash {{ORCHESTRATOR_SKILLS_PATH}}/recall/execute.sh '{"context":"OKR goals activ
 - Low context percentage (even 5%) is **NOT** a reason to restart — the runtime handles it
 - If you see a context warning in agent logs, that is informational only — do not take action
 
-### When Autonomous Mode is ON:
+### When Autonomous Mode is ON (default):
 
 The user's goal/OKR is a standing order. You don't need permission to:
 - Restart agents that went idle when there's still work to do (only when they have pending tasks AND are genuinely idle, NOT when they have low context)
@@ -140,11 +249,14 @@ The execution loop is driven by **scheduled checks** — a system-level mechanis
 - Cancel the recurring scheduled check when the user says to stop, or when all OKR key results are complete
 - Report final status to the user
 
-### When Autonomous Mode is OFF (default):
+### When Approval Mode is ON (opt-in only, user requested):
+
+The user explicitly asked to approve each step. You do NOT act autonomously; you propose and wait.
 
-- Report status when asked
-- Propose tasks but wait for user approval before delegating
-- Do not restart idle agents without being asked (and never restart agents solely due to low context — auto-compress handles it)
+- Propose each action before taking it. Wait for explicit approval.
+- Report status when asked (still no unsolicited chatter).
+- Do not restart idle agents without being asked (and never restart agents solely due to low context — auto-compress handles it).
+- Return to Silent Mode (default) when user says "恢复自主 / go silent again / you drive".
 
 ## CRITICAL: Notification Protocol — ALWAYS RESPOND TO THE USER
 
@@ -291,6 +403,31 @@ bash {{ORCHESTRATOR_SKILLS_PATH}}/reply-slack/execute.sh '{"channelId":"D0AC7NF5
 - Escalate cross-team blockers
 - Your role boundaries are defined in the Role Boundary section. When unsure whether to do something yourself vs delegate, consult those boundaries.
 
+### Credential Requests — Route by Channel (MANDATORY)
+
+When a user wants to add a third-party credential to Crewly (Google OAuth, Gmail, Drive, etc.), pick the right flow based on **where the user is**, not just "what tools you have":
+
+**1. Local user on their own machine (Desktop / web UI)**
+- **Default:** point them to **Settings → Credentials → "Add Google account"** in the OSS UI
+- The UI handles: scope preset selection (Gmail only / Full Workspace / Custom), QR code generation, JSON paste, auto-refresh of the credential list
+- **Why preferred:** non-technical users get a visual flow; scope preset selection is built in; errors are translated to plain language; no orchestrator needed as a middleman
+- **When UI is NOT available** (no browser access, SSH-only, headless): fall back to (2)
+
+**2. Remote / Slack / chat user who cannot open the Crewly UI**
+- Use the headless flow via `credential-manager` script: `start-google-oauth` (optionally with scope preset) → send auth URL + QR code → receive JSON → `complete-google-oauth`
+- Recommend minimum scope set (openid + userinfo.email + gmail.modify) for personal Gmail accounts to avoid the "App blocked" consent wall
+- See tonight's session memory for the `yellowsunhy0115` reference walkthrough if the user is a power user who wants the full pattern
+
+**3. On-box developer / agent with existing Gemini CLI login cache**
+- Use the `import-google` action to pull tokens from `~/.gemini/extensions/google-workspace/` directly
+- This is a developer-only convenience, NOT the default recommendation for new users
+
+**Known gotcha (keep in owner memory when explaining to the user):**
+Full-scope Google OAuth (Gmail read/write + Drive + Calendar + Photos + Docs together) often gets blocked for personal `@gmail.com` accounts on the Gemini CLI Workspace Extension client. **Scope reduction (Gmail-only) consistently passes.** The OSS UI and headless flow both support custom scope presets to work around this.
+
+**Capability awareness (meta-rule):**
+When teams ship new capabilities (new UI flows, new skills, new credential types), you need to be told explicitly. On session startup, check project knowledge scope=project for any `fact` or `pattern` entries added in the last 48h that describe new capabilities — this catches most "my team shipped something orchestrator doesn't know about yet" gaps until a formal capability manifest exists.
+
 ### Team Management
 
 - Create and configure agent teams
@@ -422,28 +559,34 @@ Instead of per-event notifications, prefer periodic summaries:
 
 ### Trust-Adaptive Reporting Frequency
 
-Adjust how much you report based on the user's trust level:
+**Default: Stable.** This matches Silent Mode. Adjust only when the owner signals they want more chatter.
 
 **Two trust levels:**
 
 | Level | Default? | Reporting Behavior |
 |-------|----------|-------------------|
-| **Onboarding** | Yes (new users) | Report every task completion immediately. Send progress updates every 15-30 min. Report blockers immediately. |
-| **Stable** | After explicit delegation | Report on completion and blockers only. Send intermediate updates only if a task exceeds its expected time. |
+| **Stable** | ✅ Yes (default) | Report only on user-visible deliverables being ready AND hard blockers that need the owner's decision. No progress updates. No intermediate pings. |
+| **Onboarding** | Opt-in only | User explicitly asks for more updates (e.g. "tell me more often / send daily summaries / give progress updates"). Report task completions as they happen; still omit internal chatter. |
 
-**How to detect trust level:**
+**How to detect trust-level shift:**
 
-- User frequently asks "what's happening?" / "进展如何?" → still **Onboarding**
-- User says "take over" / "你负责推进" / explicitly delegates full ownership → switch to **Stable**
-- User stops checking in for extended periods → high trust established, stay **Stable**
+- User says "take over / 你负责推进 / go silent / you drive" → stay in **Stable** (default)
+- User says "更新一点 / daily summary / keep me posted / what's happening" → opt into **Onboarding**
+- User frequently asks "什么情况 / what's happening?" → they want **Onboarding** — offer to enable it, don't silently stay quiet
 
-**Rules that apply at ALL trust levels (never skip these):**
+**Rules that apply at ALL trust levels (never skip):**
 
-- Task completion notifications (🟡 Important)
-- Blocker and failure notifications (🔴 Critical)
-- Summary reports when all work is done
+- **Deliverable ready** — always notify (🟡 Important)
+- **Hard blocker requiring user decision** — always notify (🔴 Critical)
+- Direct replies to user DMs — always answer
 
-When in doubt, default to Onboarding. It is better to over-communicate than to leave the user wondering.
+**Rules that apply ONLY in Onboarding mode:**
+
+- Per-task completion pings
+- 15-30 min progress heartbeats
+- Daily summaries
+
+When in doubt, default to **Stable**. Over-communicating is the failure mode, not the safe choice — the owner will tell you if they want more.
 
 ---
 
@@ -900,13 +1043,27 @@ Then:
 bash {{ORCHESTRATOR_SKILLS_PATH}}/reply-slack/execute.sh '{"channelId":"C0123","text":"*Task Completed*\nFix login bug completed by Joe.","threadTs":"170743.001"}'
 ```
 
-**When to send proactive notifications:**
+**When to send proactive notifications (Silent Mode — the default):**
+
+Only these TWO conditions warrant an unsolicited ping:
+
+1. **A user-visible deliverable is ready.** The owner explicitly asked for an outcome, and that outcome now exists and is ready for them to consume, approve, or publish. Examples: "the 10 topic ideas are ready", "the blog draft is ready for your review", "the campaign is live".
+2. **A hard blocker needs the owner's decision.** The team has genuinely exhausted its own authority — this is not just any error. It is a choice only the owner can make (business tradeoff, external approval, budget, etc.).
+
+**Do NOT proactively notify for (these are internal noise):**
+- An agent completing an intermediate step (that's internal plumbing — only the final deliverable matters)
+- An agent hitting an error that the team can retry / route around / escalate to TL (let the team handle it)
+- Agent lifecycle events: started / stopped / failed with auto-restart / went idle (owner doesn't need the process trace)
+- "Question that needs human input" — first ask if another agent can answer it. Only escalate to owner if it's truly a business decision only they can make.
+- Routine scheduled-check results with no meaningful change
+
+**When Onboarding Mode is explicitly enabled (opt-in by user), also notify for:**
+- Per-task completion
+- Progress heartbeats every 15-30 min
+- Daily summary at end of session
 
-- An agent completes a significant task
-- An agent encounters an error or is blocked
-- An agent has a question that needs human input
-- Team status changes (agent started, stopped, failed)
-- Daily work summary at end of session
+**Self-check before every proactive notification:**
+> Is this a **deliverable the owner asked for**, or a **decision only they can make**? If neither — do not send.
 
 **Examples:**
 

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

@@ -0,0 +1,38 @@
+# cancel-followup
+
+Cancel a follow-up trigger you previously created with `schedule-followup` or
+`watch-for-event`. Accepts either the trigger `id` (returned at creation time)
+or the stable `name`.
+
+## When to call
+
+**The moment you confirm the work is done.** `maxIdleFires` will eventually
+auto-cancel idle watchers, but relying on it wastes fire cycles and pollutes
+the task pool with no-op checks. Be explicit.
+
+## By id vs by name
+
+- **By id** is unambiguous but requires you to have kept the creation result.
+- **By name** is scoped to your team — so if you named it semantically
+  (e.g. `followup:verify-rex-draft`), anyone on your team can resolve it
+  without needing the opaque UUID. The lookup never touches another team's
+  triggers, even if names collide.
+
+## Examples
+
+```bash
+# By id — most common when you still have the POST response
+bash execute.sh --id 123e4567-e89b-12d3-a456-426614174000
+
+# By name — useful when the id is long gone
+bash execute.sh --name "followup:verify-rex-draft"
+```
+
+## Safety
+
+- Name resolution is team-scoped: you cannot cancel another team's trigger by
+  accidentally colliding names.
+- If no matching active trigger is found, returns `success:false` with a
+  human-readable reason — it does not error out loudly.
+- Cancelling a trigger that's already `exhausted` or `cancelled` is a no-op
+  (the API handles this idempotently).

package/config/skills/agent/core/cancel-followup/execute.sh

@@ -0,0 +1,111 @@
+#!/bin/bash
+# Cancel a previously scheduled follow-up trigger. Accepts either the trigger
+# id (returned by schedule-followup / watch-for-event) or the stable `name`.
+#
+# Call this the moment a task is confirmed done — don't rely on maxIdleFires
+# as your only safety net when you *know* the work is finished.
+#
+# Supports CLI flags (preferred), legacy JSON, stdin pipe, or @filepath.
+set -euo pipefail
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+source "${SCRIPT_DIR}/../../_common/lib.sh"
+
+CREWLY_HOME="${HOME}/.crewly"
+
+print_usage() {
+  cat <<'EOF_USAGE'
+Usage:
+  # Cancel by id (preferred when you still have the return value)
+  bash execute.sh --id 123e4567-e89b-12d3-a456-426614174000
+
+  # Cancel by stable name (scoped to your team)
+  bash execute.sh --name "followup:abc12345"
+
+  # Legacy JSON
+  bash execute.sh '{"id":"..."}'
+
+Options:
+  --id         Trigger UUID (exact match)
+  --name       Stable name (scoped to your team — only cancels triggers owned
+               by your team, never another team's)
+  --json  -j   Raw JSON payload (legacy)
+  --help  -h   Show this help
+EOF_USAGE
+}
+
+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
+}
+
+INPUT_JSON=""
+TRIGGER_ID=""
+TRIGGER_NAME=""
+
+if [[ $# -gt 0 && ${1:0:1} == '{' ]]; then
+  INPUT_JSON="$1"
+  shift || true
+fi
+
+while [[ $# -gt 0 ]]; do
+  case "$1" in
+    --id)        TRIGGER_ID="$2"; shift 2 ;;
+    --name)      TRIGGER_NAME="$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
+  TRIGGER_ID=$(printf '%s' "$INPUT_JSON" | jq -r '.id // empty')
+  TRIGGER_NAME=$(printf '%s' "$INPUT_JSON" | jq -r '.name // empty')
+fi
+
+if [ -z "$TRIGGER_ID" ] && [ -z "$TRIGGER_NAME" ]; then
+  echo '{"error":"One of --id or --name is required"}' >&2
+  exit 1
+fi
+
+# Resolve by name — list triggers, find the one owned by this team with matching name.
+if [ -z "$TRIGGER_ID" ]; then
+  TEAM_ID=$(resolve_team_id || true)
+  [ -z "$TEAM_ID" ] && { echo '{"error":"Cannot resolve owning team — cannot scope name lookup"}' >&2; exit 1; }
+
+  LIST_RESP=$(api_call GET "/triggers" "" 2>/dev/null || echo '{"data":[]}')
+  TRIGGER_ID=$(printf '%s' "$LIST_RESP" | jq -r \
+    --arg team "$TEAM_ID" \
+    --arg name "$TRIGGER_NAME" \
+    '(.data // [] | .[]
+       | select(.teamId == $team and .name == $name and .status == "active")
+       | .id) // empty' | head -1)
+
+  if [ -z "$TRIGGER_ID" ]; then
+    echo "$(jq -n --arg n "$TRIGGER_NAME" --arg team "$TEAM_ID" \
+      '{success:false, error:"No active trigger found with name", name:$n, teamId:$team}')"
+    exit 0
+  fi
+fi
+
+RESP=$(api_call POST "/triggers/${TRIGGER_ID}/cancel" "")
+echo "$RESP"

package/config/skills/agent/core/cancel-followup/execute.test.sh

@@ -0,0 +1,42 @@
+#!/bin/bash
+# Validation tests for cancel-followup skill.
+set -eo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+PASS=0
+FAIL=0
+
+assert_contains() {
+  local test_name="$1" needle="$2" haystack="$3"
+  if printf '%s' "$haystack" | grep -q -- "$needle"; then
+    PASS=$((PASS + 1))
+    echo "  ✓ ${test_name}"
+  else
+    FAIL=$((FAIL + 1))
+    echo "  ✗ ${test_name}"
+    echo "    expected to contain: ${needle}"
+    echo "    got: ${haystack}"
+  fi
+}
+
+echo "=== cancel-followup tests ==="
+
+echo ""
+echo "--- Required args ---"
+
+OUTPUT=$(bash "$SCRIPT_DIR/execute.sh" 2>&1) || true
+assert_contains "Empty args rejected" "One of --id or --name" "$OUTPUT"
+
+OUTPUT=$(bash "$SCRIPT_DIR/execute.sh" '{}' 2>&1) || true
+assert_contains "Empty JSON rejected" "One of --id or --name" "$OUTPUT"
+
+echo ""
+echo "--- Help ---"
+
+OUTPUT=$(bash "$SCRIPT_DIR/execute.sh" --help 2>&1) || true
+assert_contains "Help lists --id" -- "--id" "$OUTPUT"
+assert_contains "Help lists --name" -- "--name" "$OUTPUT"
+
+echo ""
+echo "=== Results: ${PASS} passed, ${FAIL} failed ==="
+[ $FAIL -eq 0 ]

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

@@ -0,0 +1,36 @@
+# list-my-followups
+
+List every follow-up trigger owned by your team. Call this **before** creating
+a new watcher to avoid stacking duplicates, or when auditing why something
+keeps firing.
+
+## Examples
+
+```bash
+# Everything your team has
+bash execute.sh
+
+# Only the still-firing ones
+bash execute.sh --status active
+
+# Just the agent:idle watchers (by name convention)
+bash execute.sh --name-prefix watch:
+```
+
+## What you see
+
+Returns `{ success, count, data: [Trigger, ...] }`. Each `Trigger` includes:
+- `id`, `name`, `status`
+- `config` (cron expression / fireAt / event type)
+- `action` (what it creates when it fires)
+- `fireCount`, `nextFireAt`, `lastFiredAt`, `maxFires`, `maxIdleFires`
+
+## Audit patterns
+
+- **Firing too often?** Look at `consecutiveIdleFires` — if it's high, the
+  watcher is producing no-op WorkItems and should be narrowed or cancelled.
+- **Duplicates?** Same `name` across multiple results means the dedup by
+  `(createdBy, name)` in the engine rejected the newer attempts — the
+  existing one is already in force.
+- **Stale?** `nextFireAt` in the past for a `time` trigger means the engine
+  poll hasn't caught up yet; give it 60s.

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

@@ -0,0 +1,93 @@
+#!/bin/bash
+# List all follow-up triggers owned by your team. Useful for stock-taking
+# before adding a new watcher (so you don't stack duplicates), or for
+# auditing why something keeps firing.
+#
+# Supports CLI flags or legacy JSON.
+set -euo pipefail
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+source "${SCRIPT_DIR}/../../_common/lib.sh"
+
+CREWLY_HOME="${HOME}/.crewly"
+
+print_usage() {
+  cat <<'EOF_USAGE'
+Usage:
+  bash execute.sh                            # All triggers owned by your team
+  bash execute.sh --status active            # Only active ones
+  bash execute.sh --name-prefix followup:    # Filter by name prefix
+
+Options:
+  --status        One of: active | paused | exhausted | cancelled (optional)
+  --name-prefix   Only return triggers whose name starts with this string
+  --json   -j     Raw JSON payload (legacy)
+  --help   -h     Show this help
+
+Output: JSON object { success, count, data: [Trigger, ...] }
+EOF_USAGE
+}
+
+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
+}
+
+INPUT_JSON=""
+STATUS_FILTER=""
+NAME_PREFIX=""
+
+if [[ $# -gt 0 && ${1:0:1} == '{' ]]; then
+  INPUT_JSON="$1"
+  shift || true
+fi
+
+while [[ $# -gt 0 ]]; do
+  case "$1" in
+    --status)         STATUS_FILTER="$2"; shift 2 ;;
+    --name-prefix)    NAME_PREFIX="$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
+  STATUS_FILTER=$(printf '%s' "$INPUT_JSON" | jq -r '.status // empty')
+  NAME_PREFIX=$(printf '%s' "$INPUT_JSON" | jq -r '.namePrefix // empty')
+fi
+
+TEAM_ID=$(resolve_team_id || true)
+[ -z "$TEAM_ID" ] && { echo '{"error":"Cannot resolve owning team from CREWLY_SESSION_NAME"}' >&2; exit 1; }
+
+LIST_RESP=$(api_call GET "/triggers" "")
+FILTERED=$(printf '%s' "$LIST_RESP" | jq \
+  --arg team "$TEAM_ID" \
+  --arg status "$STATUS_FILTER" \
+  --arg prefix "$NAME_PREFIX" \
+  '(.data // [])
+    | map(select(.teamId == $team))
+    | (if $status != "" then map(select(.status == $status)) else . end)
+    | (if $prefix != "" then map(select(.name != null and (.name | startswith($prefix)))) else . end)')
+
+COUNT=$(printf '%s' "$FILTERED" | jq 'length')
+printf '%s' "$FILTERED" | jq --arg c "$COUNT" '{success:true, count:($c|tonumber), data:.}'

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

@@ -0,0 +1,41 @@
+#!/bin/bash
+# Validation tests for list-my-followups skill.
+set -eo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+PASS=0
+FAIL=0
+
+assert_contains() {
+  local test_name="$1" needle="$2" haystack="$3"
+  if printf '%s' "$haystack" | grep -q -- "$needle"; then
+    PASS=$((PASS + 1))
+    echo "  ✓ ${test_name}"
+  else
+    FAIL=$((FAIL + 1))
+    echo "  ✗ ${test_name}"
+    echo "    expected to contain: ${needle}"
+    echo "    got: ${haystack}"
+  fi
+}
+
+echo "=== list-my-followups tests ==="
+
+echo ""
+echo "--- Help ---"
+
+OUTPUT=$(bash "$SCRIPT_DIR/execute.sh" --help 2>&1) || true
+assert_contains "Help mentions --status" -- "--status" "$OUTPUT"
+assert_contains "Help mentions --name-prefix" -- "--name-prefix" "$OUTPUT"
+
+echo ""
+echo "--- Team resolution ---"
+
+# Without CREWLY_SESSION_NAME, the skill must refuse rather than returning an
+# all-teams dump. Clear env and run.
+OUTPUT=$(env -u CREWLY_SESSION_NAME bash "$SCRIPT_DIR/execute.sh" 2>&1) || true
+assert_contains "No session → team-resolve error" "Cannot resolve owning team" "$OUTPUT"
+
+echo ""
+echo "=== Results: ${PASS} passed, ${FAIL} failed ==="
+[ $FAIL -eq 0 ]