@desplega.ai/agent-swarm 1.92.0 → 1.92.2

package/src/tools/tool-config.ts

@@ -128,11 +128,12 @@ export const DEFERRED_TOOLS = new Set([
   // Approval Requests (1)
   "request-human-input",
 
-  // Skills (11)
+  // Skills (12)
   "skill-create",
   "skill-update",
   "skill-delete",
   "skill-get",
+  "skill-get-file",
   "skill-list",
   "skill-search",
   "skill-install",

package/src/types.ts

@@ -1555,12 +1555,18 @@ export const TERMINAL_SCRIPT_RUN_STATUSES = [
 ] as const;
 export type TerminalScriptRunStatus = (typeof TERMINAL_SCRIPT_RUN_STATUSES)[number];
 
+// `workflow` = durable background run launched via /api/script-runs (has a journal).
+// `inline` = synchronous one-off run via /api/scripts/run (no journal).
+export const ScriptRunKindSchema = z.enum(["workflow", "inline"]);
+export type ScriptRunKind = z.infer<typeof ScriptRunKindSchema>;
+
 export const ScriptRunSchema = z.object({
   id: z.string().uuid(),
   agentId: z.string(),
   scriptName: z.string().optional(),
   source: z.string(),
   args: z.unknown(),
+  kind: ScriptRunKindSchema,
   status: ScriptRunStatusSchema,
   pid: z.number().int().optional(),
   startedAt: z.string(),
@@ -1584,6 +1590,7 @@ export const ScriptRunJournalEntrySchema = z.object({
   error: z.string().optional(),
   startedAt: z.string(),
   completedAt: z.string().optional(),
+  durationMs: z.number().optional(),
 });
 export type ScriptRunJournalEntry = z.infer<typeof ScriptRunJournalEntrySchema>;
 
@@ -1794,6 +1801,19 @@ export const SkillWithInstallInfoSchema = SkillSchema.extend({
 });
 export type SkillWithInstallInfo = z.infer<typeof SkillWithInstallInfoSchema>;
 
+export const SkillFileSchema = z.object({
+  id: z.string(),
+  skillId: z.string(),
+  path: z.string(),
+  content: z.string(),
+  mimeType: z.string(),
+  isBinary: z.boolean(),
+  size: z.number().nullable(),
+  createdAt: z.string(),
+  lastUpdatedAt: z.string(),
+});
+export type SkillFile = z.infer<typeof SkillFileSchema>;
+
 // ── MCP Servers ──────────────────────────────────────────────────────────
 
 export const McpServerTransportSchema = z.enum(["stdio", "http", "sse"]);

package/src/utils/internal-ai/complete-structured.ts

@@ -85,8 +85,8 @@ async function defaultSpawnClaudeCli(
   jsonSchema?: object,
 ): Promise<string> {
   // SWARM_USE_CLAUDE_BRIDGE mirrors the main claude adapter's subscription-pool
-  // routing. Otherwise CLAUDE_BINARY may be a single binary ("claude", "shannon")
-  // or a whitespace-separated command string ("bunx @dexh/shannon").
+  // routing. Otherwise CLAUDE_BINARY may be a single binary, an absolute path,
+  // or a whitespace-separated command string.
   const useClaudeBridge = ["true", "1"].includes(
     (process.env.SWARM_USE_CLAUDE_BRIDGE ?? "").trim().toLowerCase(),
   );

package/templates/schedules/daily-blocker-digest/content.md

@@ -15,39 +15,53 @@ Ask the lead to summarize stuck work, failing checks, and owner decisions every
 
 ## Scheduled Task
 
-This is the full task prompt the schedule runs on each fire — including the accumulated operational learnings baked into it. Adapt the swarm-specific references (channel IDs, agent names, repo paths) to your environment before enabling.
+This is a reusable starting prompt. Before enabling it, adapt the placeholder repo list, Slack channel, owner mentions, memory paths, and escalation rules to your swarm. As you learn from real incidents, expand this template with your own local runbook notes instead of assuming these defaults cover every environment.
 
-Task Type: Daily Blocker Digest — "Compound Prelude" (unified with PR review)
+Task Type: Daily Blocker Digest
 
-You are Lead. This runs 5 minutes before the compound evolution. Purpose: surface every item claimed to be "awaiting human" so the compound can detect stale-state items (blockers actually resolved but never removed), AND provide the single daily summary of open PRs. Rule from Taras (2026-04-22): verify, don't assume.
+You are Lead. Produce one concise daily digest of blockers, stale claims, open PRs, and stuck work. Verify current state before escalating anything.
 
 ---
 
-## Phase 1: Gather Blockers from 4 Sources
+## Phase 0: Seeded Data-Gathering
 
-### 1A. HEARTBEAT.md "Active Blockers" section
-Read `/workspace/HEARTBEAT.md`. Extract every bullet under "Active Blockers (awaiting Taras)" or similar. Each item is a claim of the form "X is broken/pending".
+Run these read-only global scripts first. Use their outputs as evidence, then apply judgment:
 
-### 1B. Open PRs across all our repos — with clickable URLs
-Loop over the repo list and gather ALL open PRs with their URL, age, review status, draft flag, labels, author.
+1. `script-run` global script `Heartbeat Audit` with args `{ "heartbeatMarkdown": "<current /workspace/HEARTBEAT.md text>" }`
+2. `script-run` global script `schedule-health` with args `{ "days": 7, "publishPage": true }`
+3. `script-run` global script `task-failure-audit` with args `{ "days": 7, "groupBy": "reason", "publishPage": true }`
+
+Do not script-ify judgment or notification copy. Use the script outputs to identify stale blocker claims, schedule risks, provider failure clusters, and digest-run health.
+
+## Phase 1: Gather Blockers
+
+### 1A. HEARTBEAT.md active blockers
+
+Read `/workspace/HEARTBEAT.md`. Extract every bullet under "Active Blockers" or a similar section. Treat each item as a claim that must be verified, not as ground truth.
+
+### 1B. Open PRs across tracked repositories
+
+Replace the repo list below with repositories your team wants in the digest:
 
 ```bash
-for repo in desplega-ai/agent-swarm desplega-ai/agent-swarm-landing desplega-ai/landing desplega-ai/landing-labs desplega-ai/qa-use desplega-ai/agent-fs desplega-ai/chat-py desplega-ai/argus desplega-ai/argus-action desplega-ai/ai-toolbox desplega-ai/agent-work; do
+for repo in owner/repo-one owner/repo-two owner/repo-three; do
   gh pr list --repo "$repo" --state open --json number,title,author,createdAt,url,reviewDecision,isDraft,labels 2>/dev/null | jq --arg repo "$repo" '.[] | . + {repo: $repo}'
 done
 ```
 
 Compute `daysOpen` from `createdAt`. Split PRs into buckets:
-- **Dependabot**: author.login == "dependabot" or "app/dependabot" — handled separately at the bottom
-- **Security dependabot**: any dependabot PR with "critical", "high", "security", or "vulnerability" in title or labels — list separately with :shield:
-- **Stale** (60+ days open): :rotating_light: at the top
-- **Aging** (30-59 days): :warning:
-- **Recent** (<30 days): normal listing
+- **Dependency updates**: author.login is `dependabot` or `app/dependabot`
+- **Security dependency updates**: dependency PRs with "critical", "high", "security", or "vulnerability" in title or labels
+- **Stale**: 60+ days open
+- **Aging**: 30-59 days open
+- **Recent**: fewer than 30 days open
 
-Format every PR link as: `<URL|repo #NUM>` — always a clickable Slack link, never raw numbers.
+Format every PR link as `<URL|repo #NUM>` so the digest is clickable.
 
 ### 1C. Tasks awaiting user reply
+
 Use `db-query`:
+
 ```sql
 SELECT id, task, slackUserId, createdAt
 FROM agent_tasks
@@ -60,46 +74,48 @@ LIMIT 20
 ```
 
 ### 1D. Stuck in-flight tasks
-Use `get-tasks` with status=in_progress. Flag any with `lastUpdatedAt` >2h old.
+
+Use `get-tasks` with `status=in_progress`. Flag any task with no update for more than 2 hours. Cross-check against the seeded script outputs before escalating.
 
 ---
 
-## Phase 2: Verify Each Blocker Claim
+## Phase 2: Verify Each Claim
 
-For each claim in 1A, run a quick verification:
-- PR numbers → check if merged (use gh pr view)
-- API/key issues → test the actual API (curl + check response)
-- "awaiting response from X" items → check Slack thread for newer messages
-- Worker-activity claims → check the actual task status
+For each blocker claim, run a quick verification:
+- PR numbers: check whether the PR is still open or already merged
+- API/key issues: test the actual API or check the current config status
+- "Awaiting response" items: check the relevant thread for newer replies
+- Worker-activity claims: check the current task status
 
-Do NOT trust the HEARTBEAT wording. If verification shows the item is resolved, mark it `RESOLVED-STALE` and commit to removing from HEARTBEAT in Phase 4.
+Do not trust stale notes. If verification shows the item is resolved, mark it `RESOLVED-STALE` and remove it from the source note in Phase 4.
 
 ---
 
-## Phase 3: Post Unified Digest to Slack
+## Phase 3: Post One Digest
 
-Use `slack-post` with channelId `C0A4J7GB0UD`, pinging `<@U08NR6QD6CS>`. Format:
+Post one message to your team's chosen channel. Replace `<OWNER_OR_TEAM_MENTION>` and `<CHANNEL_ID>` before enabling this schedule.
 
-```
+Template:
+
+```text
 :clipboard: *Daily Blocker Digest + PR Review* — [YYYY-MM-DD]
 
-<@U08NR6QD6CS> Here's the combined morning digest.
+<OWNER_OR_TEAM_MENTION> Here's the daily digest.
 
-*Awaiting Taras — HEARTBEAT blockers* (N verified real, M stale)
-• PR link — <title> — [verified: still open]
-• <other item> — [verified: status]
-• ~~<stale item>~~ — RESOLVED-STALE, removed from HEARTBEAT
+*Active blockers* (N verified real, M stale)
+• <PR or task link> — <title> — [verified: still open]
+• ~~<stale item>~~ — RESOLVED-STALE, removed from source notes
 
-:rotating_light: *STALE PRs (60+ days)*
+*Stale PRs (60+ days)*
 1. <url|repo #NUM> — <title> (X days) — @author
 
-:warning: *AGING PRs (30-59 days)*
+*Aging PRs (30-59 days)*
 1. <url|repo #NUM> — <title> (X days) — @author
 
 *Recent PRs*
 1. <url|repo #NUM> — <title> (X days) — @author
 
-:shield: *Security dependabot (merge soon)*
+*Security dependency updates*
 • <url|repo #NUM> — <bump text>
 
 *Tasks awaiting user reply* (N)
@@ -109,42 +125,40 @@ Use `slack-post` with channelId `C0A4J7GB0UD`, pinging `<@U08NR6QD6CS>`. Format:
 • <task id> — <age>
 
 ---
-_Also: X dependabot PRs pending (routine dependency bumps)_
-_Stale HEARTBEAT items removed this run: N_
+Dependency update PRs pending: X
+Stale source-note items removed this run: Y
 ```
 
-Keep it scannable. Every PR MUST be a clickable `<url|repo #N>` link. If everything is clean, say "All clear — no blockers, no stuck tasks, only routine dependabot churn."
+If everything is clean, say: "All clear — no blockers, no stuck tasks, only routine dependency-update churn."
 
 ---
 
-## Phase 4: Clean HEARTBEAT.md
+## Phase 4: Clean Source Notes
 
 For each item marked `RESOLVED-STALE`:
-- Remove the line from `/workspace/HEARTBEAT.md`
-- Save a shared memory noting the stale-state catch (permanent receipt for the compound)
+- Remove or update the stale line in the source note, such as `/workspace/HEARTBEAT.md`
+- Save a memory noting how the stale state was detected, so future runs can catch the same pattern sooner
 
 ---
 
-## Phase 5: Hand-off to Compound
-
-Write a memory titled `daily-blocker-digest-YYYY-MM-DD.md` to `/workspace/shared/memory/d454d1a5-4df9-49bd-8a89-e58d6a657dc3/` with:
-- List of all verified blockers (still real) with PR URLs
-- List of RESOLVED-STALE items removed this run
-- Summary counts: total PRs open, stale count, aging count
-- Any patterns noticed ("I keep forgetting X finished shipping on date Y")
+## Phase 5: Save a Receipt
 
-The compound evolution runs 5 minutes after this. Its Phase 0 reads this memory via `memory-search "daily-blocker-digest"`.
+Write a memory titled `daily-blocker-digest-YYYY-MM-DD.md` with:
+- Verified blockers that are still real
+- RESOLVED-STALE items removed
+- Summary counts: total open PRs, stale count, aging count, dependency-update count
+- Patterns noticed and template improvements worth adding
 
 ---
 
 ## Anti-patterns
 
-- ❌ Copying HEARTBEAT verbatim without verifying each line
-- ❌ Raw PR numbers instead of clickable `<url|repo #N>` links
-- ❌ Listing all dependabot PRs inline — collapse into single footer count (except security ones)
-- ❌ Marking things RESOLVED-STALE without evidence
-- ❌ Skipping Phase 4 — if you don't clean HEARTBEAT, the problem recurs tomorrow
+- Copying HEARTBEAT or source notes verbatim without verifying each line
+- Raw PR numbers instead of clickable `<url|repo #N>` links
+- Listing all dependency-update PRs inline when a count is enough
+- Marking things RESOLVED-STALE without evidence
+- Skipping source-note cleanup
 
 ## Completion
 
-Call `store-progress` with status `completed` and `output` = one-paragraph summary of (a) how many blockers verified real vs stale, (b) PR counts (stale/aging/recent/dependabot), (c) any surprises.
+Call `store-progress` with status `completed` and an output paragraph covering verified blockers, stale items removed, PR counts, and any follow-up needed.

package/templates/schedules/daily-compounding-reflection/content.md

@@ -15,11 +15,11 @@ Capture lessons from the day into memory, skills, and workflow improvements.
 
 ## Scheduled Task
 
-This is the full task prompt the schedule runs on each fire — including the accumulated operational learnings baked into it. Adapt the swarm-specific references (channel IDs, agent names, repo paths) to your environment before enabling.
+This is the full task prompt the schedule runs on each fire. Adapt the team names, channel IDs, agent roster, repo paths, and profile-management rules to your environment before enabling. As you learn from real incidents, expand this prompt with your own operational lessons.
 
 Task Type: Daily Evolution — "Compounding Engine"
 
-You are Lead. This is the swarm's daily evolution routine. You are a real team working for Desplega Labs (desplega.ai) — the agent swarm, agent-fs, and related products. Your job is to make the team sharper every single day through three concrete folds.
+You are Lead. This is the swarm's daily evolution routine. You are operating a real team of agents for your organization. Your job is to make the team sharper every single day through three concrete folds.
 
 The purpose is NOT to write a nice Slack post. It's to make measurable changes to the swarm's memory, agent context files, and skills. The Slack post is just the receipt.
 
@@ -69,7 +69,7 @@ The swarm's memory is its institutional knowledge. It should grow smarter, not j
 Each agent has context files that shape how they think and work: SOUL.md (personality, values, core identity), IDENTITY.md (role, expertise, working style), CLAUDE.md (operational rules, project instructions), and TOOLS.md (environment knowledge). These should evolve based on real performance.
 
 ### 2A. Performance Review (per agent)
-For each active agent (Lead, Picateclas, Researcher, Reviewer, Tester, Jackknife):
+For each active agent in your swarm roster:
 - How many tasks did they complete in the last 24-48h?
 - Did any tasks fail? What was the failure pattern?
 - Did they need retries or corrections?
@@ -152,7 +152,7 @@ For each candidate:
 
 ## Phase 4: Post to Slack (THE RECEIPT)
 
-Use `slack-post` with channelId "C0A4J7GB0UD". Format:
+Use `slack-post` with your configured channel ID. Format:
 
 ```
 🧬 Daily Evolution — [date]

package/templates/schedules/daily-hn-briefing/content.md

@@ -24,7 +24,7 @@ Instructions:
 
 1. Use qa-use browser commands (e.g., `/qa-use:explore`) to scrape the following HN pages **ONE AT A TIME, STRICTLY SEQUENTIAL**.
 
-   **CRITICAL — DO NOT PARALLELIZE.** Do NOT fan out parallel browser sessions, do NOT launch multiple Browser Use SDK flows concurrently, do NOT batch the URLs into a single multi-target call. This template has auto-failed on 2026-05-10 and 2026-05-11 because the worker scraped all 5 URLs in parallel and crossed the heartbeat-stale watchdog threshold before the flows completed. Strict serial execution is required.
+   **CRITICAL — DO NOT PARALLELIZE.** Do NOT fan out parallel browser sessions, do NOT launch multiple Browser Use SDK flows concurrently, do NOT batch the URLs into a single multi-target call. Browser-heavy runs can cross the heartbeat-stale watchdog threshold when several pages are scraped in parallel. Strict serial execution is required.
 
    **Workflow:** Scrape URL #1 → call `store-progress` with a one-line update (e.g., "Scraped HN page 1 — N stories found") → scrape URL #2 → `store-progress` → … → URL #5 → `store-progress`. After every individual URL scrape, you MUST call `store-progress` BEFORE starting the next URL. This keeps the session heartbeat fresh and prevents the watchdog from killing the task.
 
@@ -42,7 +42,7 @@ Instructions:
    - Agentic coding / AI-powered development
    - E2E testing / browser automation / QA
    - Developer tools / DevOps
-   - Startups / SaaS relevant to Desplega's space
+   - Startups / SaaS relevant to your team's space
 
 3. Format a quick-scan briefing. Organize by source section:
    - **Front Page** (from pages 1-3)
@@ -60,7 +60,7 @@ Instructions:
    • Emdash — Open-source agentic dev environment (https://news.ycombinator.com/item?id=12345) · Feb 24 · 65 pts · 30 comments
      Direct peer to Cursor/Windsurf — agentic-first IDE.
 
-4. If any story is exceptionally relevant to Desplega (E2E testing, browser automation, AI agents), add a "Deep Dive" section with 2-3 sentences.
+4. If any story is exceptionally relevant to your team's focus areas, add a "Deep Dive" section with 2-3 sentences.
 
 5. STORE THE REPORT: Save the full briefing as a markdown file at:
    /workspace/shared/hn-briefings/YYYY-MM-DD.md
@@ -73,7 +73,7 @@ Instructions:
 
 6. SEND EMAIL: Use AgentMail MCP tools to send the report as an email:
    - From inbox: lead@agent-swarm.dev
-   - To: t@desplega.ai AND e@desplega.ai
+   - To: the configured recipient list for this briefing
    - Subject: "HN Briefing — [TODAY'S DATE, e.g. Feb 25, 2026]"
    - Body: Send as HTML email. Format the briefing nicely with:
      - A header: "HN Briefing — [DATE]"
@@ -94,4 +94,4 @@ IMPORTANT:
 - Target 5-20 relevant stories (quality over quantity)
 - You MUST scrape all 5 URLs (3 main pages + new + show) — this is required, but ONE AT A TIME
 - The email is sent from lead@agent-swarm.dev using AgentMail MCP `send_message` tool
-- Recipients: t@desplega.ai AND e@desplega.ai
+- Recipients: use the configured recipient list for this briefing

package/templates/schedules/daily-workflow-health-audit/content.md

@@ -15,11 +15,11 @@ Check scheduled jobs and workflows for repeated failures, stale runs, and silent
 
 ## Scheduled Task
 
-This is the full task prompt the schedule runs on each fire — including the accumulated operational learnings baked into it. Adapt the swarm-specific references (channel IDs, agent names, repo paths) to your environment before enabling.
+This is the full task prompt the schedule runs on each fire. Adapt the channel IDs, mentions, app URLs, and escalation rules to your environment before enabling. As you learn from real incidents, expand this prompt with your own local failure modes and recovery notes.
 
 Task Type: Daily Workflow + Schedule Health Audit
 
-You are Lead. Run this audit and post a single Slack digest. **Source ask:** Eze in `C0A4J7GB0UD` thread ts `1779264760.065579` (2026-05-20). Cadence: daily at 08:00 UTC. Purpose: surface any workflow run or scheduled-task fire from the last 24h that hard-failed or silently failed (completed but produced nothing useful) so we catch broken cron/workflow plumbing before it ages out.
+You are Lead. Run this audit and post a single Slack digest. Cadence: daily at 08:00 UTC. Purpose: surface any workflow run or scheduled-task fire from the last 24h that hard-failed or silently failed (completed but produced nothing useful) so the team catches broken cron/workflow plumbing before it ages out.
 
 ---
 
@@ -137,7 +137,7 @@ If TOTAL issues across 1A–1F is zero:
 ```
 :white_check_mark: *Daily Workflow + Schedule Health Audit* — <YYYY-MM-DD>
 
-<@U08NY4B5R2M> All clear — <workflowRuns24h> workflow runs + <scheduledFires24h> scheduled fires in the last 24h, all produced expected output.
+<OWNER_OR_TEAM_MENTION> All clear — <workflowRuns24h> workflow runs + <scheduledFires24h> scheduled fires in the last 24h, all produced expected output.
 ```
 
 Otherwise:
@@ -145,7 +145,7 @@ Otherwise:
 ```
 :stethoscope: *Daily Workflow + Schedule Health Audit* — <YYYY-MM-DD>
 
-<@U08NY4B5R2M> Audit window: last 24h. Totals: <workflowRuns24h> workflow runs · <scheduledFires24h> scheduled fires · *<TOTAL_ISSUES> issues*
+<OWNER_OR_TEAM_MENTION> Audit window: last 24h. Totals: <workflowRuns24h> workflow runs · <scheduledFires24h> scheduled fires · *<TOTAL_ISSUES> issues*
 
 *Hard failures — workflow runs* (<N1A>)
 • <url|workflow:name> — failed <relative-time>
@@ -174,7 +174,7 @@ Omit any section whose count is 0. Cap message at 4000 chars (Slack limit) — i
 
 ## Phase 3 — Post to Slack and complete
 
-1. Call `slack-post` with `channelId="C0A4J7GB0UD"` and `message=<rendered digest>`. **Do NOT** thread under the design thread `1779264760.065579` — daily fires are top-level so they're easy to scan.
+1. Call `slack-post` with your configured channel ID and `message=<rendered digest>`. Prefer a top-level daily fire unless your team's convention is to thread recurring audit messages.
 2. Call `store-progress` with `status: "completed"` and a one-paragraph `output` summary:
    - `Issues found: hard-fail-wf=<N1A>, hard-fail-task=<N1B>, halted-24h=<N1C>, silent-empty=<N1D>, cron-stuck=<N1E>, consec-err=<N1F>.`
    - `Totals: workflowRuns24h=<X>, scheduledFires24h=<Y>.`
@@ -185,5 +185,5 @@ Omit any section whose count is 0. Cap message at 4000 chars (Slack limit) — i
 - ❌ Posting a separate Slack message per failure mode — ONE digest.
 - ❌ Raw IDs without clickable URLs.
 - ❌ Dumping full `error` / `output` content — truncate to 220 chars per item.
-- ❌ Threading the daily digest under the original 1779264760.065579 design thread.
+- ❌ Threading the daily digest somewhere your team will not scan.
 - ❌ Skipping the "all clear" message when zero issues — the heartbeat itself is the signal that the audit ran.

package/templates/schedules/gtm-weekly-review/content.md

@@ -15,25 +15,25 @@ Summarize product, marketing, or sales signals into an operator-friendly weekly
 
 ## Scheduled Task
 
-This is the full task prompt the schedule runs on each fire — including the accumulated operational learnings baked into it. Adapt the swarm-specific references (channel IDs, agent names, repo paths) to your environment before enabling.
+This is the full task prompt the schedule runs on each fire. Adapt the repositories, Search Console properties, report paths, and campaign goals to your environment before enabling.
 
 Task Type: Research
-Topic: Weekly GTM Metrics Review for agent-swarm
+Topic: Weekly GTM Metrics Review for your product
 
 Goal: Check current GitHub stars, traffic, Google Search Console performance, and content metrics for the GTM campaign.
 
 Instructions:
-1. Check GitHub metrics: `gh api repos/desplega-ai/agent-swarm` (stars, forks, issues)
-2. Check traffic: `gh api repos/desplega-ai/agent-swarm/traffic/views` and `/traffic/clones`
-3. Check referrers: `gh api repos/desplega-ai/agent-swarm/traffic/popular/referrers`
-4. Check popular content: `gh api repos/desplega-ai/agent-swarm/traffic/popular/paths`
+1. Check GitHub metrics: `gh api repos/owner/repo` (stars, forks, issues)
+2. Check traffic: `gh api repos/owner/repo/traffic/views` and `/traffic/clones`
+3. Check referrers: `gh api repos/owner/repo/traffic/popular/referrers`
+4. Check popular content: `gh api repos/owner/repo/traffic/popular/paths`
 
 5. **Pull Google Search Console data** using the `gsc-analytics` skill (already installed on this agent). Do NOT write Python auth code — use the `gsc` CLI at `/workspace/repos/agent-work/gsc/gsc`. The setup script already wires up `GOOGLE_APPLICATION_CREDENTIALS`, so no extra env setup needed.
 
-   Pull the weekly snapshot for each of the 4 Desplega properties:
+   Pull the weekly snapshot for each configured site:
    ```bash
    GSC=/workspace/repos/agent-work/gsc/gsc
-   for site in desplega.ai agent-swarm.dev desplega.sh agent-fs.dev; do
+   for site in example.com docs.example.com; do
      echo "=== $site ==="
      $GSC analytics "sc-domain:$site" --top 20 --json > "/tmp/gsc-$site.json"
      jq '{current, previous, window, prior,
@@ -55,4 +55,4 @@ Instructions:
 
 Save report to /workspace/shared/thoughts/shared/research/gtm-weekly-{date}.md
 
-This is part of the GTM: Agent Swarm → 100k GitHub Stars epic.
+This is part of your team's GTM goal; update the goal statement before enabling the schedule.

package/templates/schedules/weekly-dependabot-triage/content.md

@@ -15,31 +15,35 @@ Review dependency update PRs, group safe patches, and flag risky upgrades.
 
 ## Scheduled Task
 
-This is the full task prompt the schedule runs on each fire — including the accumulated operational learnings baked into it. Adapt the swarm-specific references (channel IDs, agent names, repo paths) to your environment before enabling.
+This is a reusable starting prompt. Before enabling it, replace the repository, paths, branch names, reviewers, and notification target with values for your project.
 
-Triage dependabot PRs from https://github.com/desplega-ai/desplega.ai/pulls
+Task Type: Weekly Dependency Triage
+
+Repository: `owner/repo`
+Important paths: `path-one`, `path-two`
 
 ## Instructions
 
-1. **List all open dependabot PRs** in desplega-ai/desplega.ai using `gh pr list`
-2. **Only paths we care about**: `/be` and `/new-fe`. Close all other dependabot PRs (ones that don't touch these paths).
-3. **DO NOT touch non-dependabot PRs** — leave them as-is.
-4. **Create two unified PRs** that merge all dependabot bumps into one PR each:
-   - One for `/be` changes — branch name format: `YYYY-MM-DD-dependabot-be` (use today's date)
-   - One for `/new-fe` changes — branch name format: `YYYY-MM-DD-dependabot-fe` (use today's date)
-   - Each unified PR should be based on latest `main` and include all the dependency bumps from the individual dependabot PRs for that path.
-   - After creating the unified PRs, close the individual dependabot PRs that were merged into them.
-5. **Return the URLs** of the two final unified PRs.
-6. If there are no open dependabot PRs, just report that and complete.
+1. List all open dependency-update PRs in the configured repository using `gh pr list`.
+2. Separate PRs by the paths they touch. Close or ignore PRs outside the configured path list only if that is your team's policy.
+3. Do not touch non-dependency PRs.
+4. For each configured path, create one unified PR that combines compatible dependency bumps:
+   - Branch name format: `YYYY-MM-DD-dependencies-<path-name>`
+   - Base the branch on latest `main`
+   - Include the dependency bumps for that path
+   - Leave incompatible or conflicting upgrades as separate PRs with notes
+5. After creating a unified PR, close only the individual dependency PRs that were incorporated.
+6. Return the final PR URLs and call out any skipped PRs with a reason.
+7. If there are no open dependency PRs, report that and complete.
 
 ## Approach
 
-- Clone the repo, checkout main, pull latest
-- For each path (be, new-fe): create a branch, cherry-pick or merge the dependabot changes, push, create PR
-- Close individual dependabot PRs after unifying
-- Be careful: some dependabot PRs may have conflicts — handle gracefully
+- Clone or update the repo, checkout `main`, and pull latest
+- Create a branch per path group
+- Cherry-pick, merge, or manually apply each dependency update as appropriate
+- Run the repo's required dependency checks before pushing
+- Push, open PRs, request the configured reviewers, and notify the configured channel or thread
+
+## Completion
 
-## Important
-- The PR title should be descriptive, e.g. "chore(be): consolidate dependabot bumps YYYY-MM-DD"
-- Add @tarasyarema as reviewer on both PRs
-- Post the final PR URLs back to Slack
+Call `store-progress` with status `completed` and an output summary listing unified PR URLs, closed source PRs, skipped PRs, and failed checks if any.

package/templates/skills/agentmail-sending/content.md

@@ -4,7 +4,7 @@ These rules are MANDATORY for all agents sending email via AgentMail. Violating
 
 ## Rule 1: TEXT ONLY — Never Pass `html` Parameter
 
-**AgentMail has a critical bug (as of 2026-03-25):** When both `text` and `html` parameters are passed to `send_message` or `reply_to_message`, the HTML body content is silently dropped. The resulting email has an empty `<div dir="ltr"></div>`. Email clients (Gmail, etc.) prefer the HTML version over plain text, so recipients see a completely blank email.
+**AgentMail can drop visible email content when both `text` and `html` parameters are passed:** Some clients prefer the HTML version, so a blank or malformed HTML body can make recipients see an empty email even when plain text was provided.
 
 **What to do:**
 - ONLY pass the `text` parameter
@@ -13,22 +13,22 @@ These rules are MANDATORY for all agents sending email via AgentMail. Violating
 
 **Why this matters:** This bug caused real outbound prospect emails to arrive blank, burning contacts permanently. It is not a cosmetic issue — it's a data loss / reputation issue.
 
-## Rule 2: Always BCC t@desplega.ai on Outbound Emails
+## Rule 2: Apply Your Team's Outbound Visibility Policy
 
-All outbound emails to external recipients (anyone outside @agent-swarm.dev) MUST include `t@desplega.ai` as BCC. This gives the human founder visibility into what emails the swarm is sending.
+All outbound emails to external recipients must follow your deployment's visibility policy. If your team requires a BCC reviewer or audit inbox, include that configured address. Do not hardcode another organization's reviewer address into this template.
 
 **How:**
 ```
 send_message({
   inboxId: "lead@agent-swarm.dev",
   to: ["recipient@example.com"],
-  bcc: ["t@desplega.ai"],
+  bcc: ["configured-reviewer@example.com"],
   subject: "...",
   text: "..."
 })
 ```
 
-**Exception:** Internal emails between agent inboxes (@agent-swarm.dev) or to t@desplega.ai / e@desplega.ai directly do NOT need BCC.
+**Exception:** Internal emails between agent inboxes or messages already addressed to the configured reviewer list do not need an extra BCC.
 
 ## Rule 3: Always Include Signature
 
@@ -42,7 +42,6 @@ Never send outreach/cold emails to external prospects without explicit human app
 
 Before every `send_message` or `reply_to_message` call:
 - [ ] Only `text` param, NO `html` param
-- [ ] BCC `t@desplega.ai` if recipient is external
+- [ ] Apply the configured BCC/audit policy if the recipient is external
 - [ ] Plain text signature appended
 - [ ] Human-approved if it's outreach/cold email
-

package/templates/skills/desloppify/content.md

@@ -1,6 +1,6 @@
 # desloppify — Code-health scan workflow (swarm edition)
 
-`desloppify` is a multi-language codebase health scanner (peteromallet/desloppify). This skill is the swarm-adapted SKILL.md: it codifies the **install recipe with the tree-sitter pin**, the surface-only **scan → status → next → triage** workflow we run for repos like `agent-swarm`, and the **publish-to-agent-fs** step so humans (Eze) can see the findings.
+`desloppify` is a multi-language codebase health scanner (peteromallet/desloppify). This skill is the swarm-adapted SKILL.md: it codifies the **install recipe with the tree-sitter pin**, the surface-only **scan → status → next → triage** workflow for code-health scans, and the **publish-to-agent-fs** step so humans can see the findings.
 
 > **Default mode for swarm workers: surface-only.** Run Phase 1 + early Phase 2, publish a memo to agent-fs, stop. Do **not** run Phase 3 (queue-grinding refactors) unless the task explicitly asks.
 
@@ -8,7 +8,7 @@
 
 - A task asks you to run desloppify, do a code-health scan, get a health score, or surface debt themes on a repo.
 - A task references `peteromallet/desloppify` or the upstream `docs/SKILL.md`.
-- You need to triage tech debt on a TS / Python / multi-lang repo (agent-swarm, landing, agent-swarm-landing, desplega-ai, etc.).
+- You need to triage tech debt on a TS / Python / multi-lang repo.
 
 If the task is "fix this one bug" or "rename X" → not this skill. Desloppify is for batch debt-surfacing, not point fixes.
 
@@ -28,7 +28,7 @@ pipx runpip desloppify show tree-sitter-language-pack | grep Version
 
 ## Step 2 — Install (first run only)
 
-Use `pipx`. This is the working recipe verified in PR #463 (Dockerfile.worker) and across multiple sprite smokes:
+Use `pipx`. This keeps the scanner isolated from the project environment:
 
 ```bash
 pipx install 'desloppify[full]==0.9.15'
@@ -39,7 +39,7 @@ pipx runpip desloppify show tree-sitter-language-pack | grep Version
 # → must show 1.6.2 (or another <1.8)
 ```
 
-**Why the pin:** `tree-sitter-language-pack` 1.8.0 has an ABI mismatch with `tree-sitter` that crashes desloppify in `cohesion.py:52` → `extractors.py:90` with a `TypeError`. Upstream fix is [peteromallet/desloppify#605](https://github.com/peteromallet/desloppify/pull/605) — open, unmerged. Until that ships, we cap locally. (See task `616b4bba-43de-40b5-af3b-4e219b622218` for the full repro.)
+**Why the pin:** some `tree-sitter-language-pack` 1.8.x builds have ABI mismatches with `tree-sitter` that crash scans during language extraction. Until the installed scanner version is known to work with newer language-pack releases, cap it below 1.8.
 
 If `pipx` isn't installed: `python3 -m pip install --user pipx && python3 -m pipx ensurepath` and start a new shell. If `pipx install` fails with build errors, jump to **Sprite escape hatch** below.
 
@@ -94,11 +94,11 @@ What to capture for the memo:
 
 ## Step 6 — Publish findings to agent-fs
 
-Save the scan memo so Eze and the swarm can see it. Use the shared org (`648a5f3c-35c8-4f11-8673-b89de52cd6bd`) and namespace the path under your own agent ID:
+Save the scan memo somewhere durable so operators can review it. If your deployment uses agent-fs, write it under your own agent namespace:
 
 ```bash
 DATE=$(date +%Y-%m-%d)
-agent-fs --org 648a5f3c-35c8-4f11-8673-b89de52cd6bd write \
+agent-fs --org <org-id> write \
   thoughts/$AGENT_ID/research/$DATE-desloppify-<repo>-scan.md \
   --content "$(cat <<'EOF'
 # desloppify scan — <repo> @ <SHA>
@@ -160,7 +160,7 @@ sprite exec -s desloppify-scan -- bash -c '
   pipx install "desloppify[full]==0.9.15"
   pipx inject --force desloppify "tree-sitter-language-pack<1.8"
   pipx runpip desloppify show tree-sitter-language-pack | grep Version
-  git clone --depth=1 https://github.com/desplega-ai/<repo>.git /tmp/repo
+  git clone --depth=1 https://github.com/<owner>/<repo>.git /tmp/repo
   cd /tmp/repo
   desloppify scan --path .
   desloppify status
@@ -191,11 +191,10 @@ desloppify status
 desloppify next --count 15
 
 # Publish + report
-agent-fs --org 648a5f3c-35c8-4f11-8673-b89de52cd6bd write thoughts/$AGENT_ID/research/$(date +%F)-desloppify-<repo>-scan.md --content "..." -m "scan memo"
+agent-fs --org <org-id> write thoughts/$AGENT_ID/research/$(date +%F)-desloppify-<repo>-scan.md --content "..." -m "scan memo"
 # slack-reply on the originating thread
 ```
 
 ## Upstream reference
 
 Full Phase 3 / review workflow / plan commands are in the upstream SKILL.md: <https://github.com/peteromallet/desloppify/blob/main/docs/SKILL.md>. Reach for it when you're explicitly asked to grind the queue (rare). Default swarm mode stops after the memo + Slack reply.
-