# Signal Monitor > Signal Monitor — drop in your account list and get a signal digest: an act-this-week lane first, then worth-knowing, then the accounts that were checked and are genuinely quiet. Every signal dated, sourced, and framed against what you sell, with a suggested next touch. Use when I say "what's happening with my accounts", "check my account list", "any signals this week", "what moved on my accounts", "monitor these accounts", "did anything happen at ", "run my signal digest", or drop a list of accounts and ask what's new. Runs account-scanner (one per batch of 8, concurrently) → signal-analyst, and writes to my-work/signal-monitor/. - Skill: `bluerock-io/signal-monitor` (Agent Skill) - Install (CLI): `npx skillmds@latest add bluerock-io/signal-monitor` - Raw SKILL.md: https://api.skillmd.com/api/skills/bluerock-io/signal-monitor/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: bluerock-io (https://skillmd.com/u/bluerock-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/bluerock-io/signal-monitor --- Run the Signal Monitor team and produce a **signal digest** — a board of what moved on the builder's accounts, ranked so the first thing they read is the thing to do this week. You orchestrate the agents; they do the work. This is the wide read of the set: dozens of accounts, swept shallowly, because the question is *"which of my accounts moved"* — not *"tell me everything about this account"*. When one account turns out to matter, `/bluerock:scorecard` and `/bluerock:competitive-intel` are the deep reads waiting for it. **What it replaces:** checking each account by hand, one search at a time, and finding out about the ones you missed from someone else. **Time saved:** about 1.5 hours by hand, estimated and not yet timed. The timed baseline (E6-26) replaces this figure when it lands. ## First — anchor to the project The digests, their working folder, and the `voice.md` / `objectives.md` the run reads all live in the builder's project. Two generations exist: the project ships inside the workspace image (usually the folder `my-workspace`); projects made before 2026-08 were cloned and carry whatever name the builder chose. **Assume neither — identify it by its signature.** In an SSH/cloud container the chat may start in the project itself or in the **home folder** with the project one level down — both are normal. Identify it by signature, not name: run `ls`; see `CLAUDE.md` and `design/` side by side? You're in the project. If not, find it: `ls */CLAUDE.md`, then `ls ~/*/CLAUDE.md`, else `find ~ -maxdepth 3 -path '*/design/dashboard.html'`. `cd` in, capture the **absolute path** with `pwd`, and use that full path throughout. Can't find it? Ask the builder which folder their project is in. ## Before the questions — read what the builder already has Check, without asking: `objectives.md` and `voice.md` at the project root, and the latest doc under `my-work/messaging-doc/` if one exists. These sharpen the run — they are never required for it. Here they do one specific job: the **why it matters** line on every card is the builder's positioning applied to a fact, so a real messaging doc is the difference between "they raised a Series B" and "they raised a Series B, and the team that would own this is the one that grows first after a raise." - **If they're real**, use them to pre-fill the intake below (propose, confirm, don't re-ask cold). - **If they're placeholder templates or absent**, say so once, plainly, and keep moving: *"Your `objectives.md` / `voice.md` are still the placeholder templates, so I can rank these signals but I can't aim them at what you sell. Happy to run anyway — running `/bluerock:messaging-doc` on your site would sharpen future digests."* Never make setup homework the price of the first digest. ## Intake — one question per step, short, then confirm Ask these one at a time. Keep each ask to a line or two; don't stack questions or explain the whole flow up front. **Skip what they already gave you.** If the opening request named a file or the accounts, don't re-ask — say what you're taking as given (`List: target-accounts.csv · 34 accounts`) so a wrong reading gets corrected early, then pick up at the first step that's actually missing. A returning builder never re-answers a question they already answered; a prior run's `inputs.md` pre-fills the same way (propose, confirm, don't re-ask cold). **Which prompt shape for which step:** use the question picker (`AskUserQuestion`) only where the answer is genuinely a choice between a few options — step 3. Everywhere else the answer is free text in the builder's own words, and a four-option picker is the wrong shape for it: ask in the message and let them type. Where the picker isn't available in this client, ask in the message. 1. **The account list.** "Drop in your account list — a file is easiest. Names or domains both work, and dozens is fine." Accept a file path, a pasted list, or a file they attach; a CSV, a spreadsheet export, a markdown list, or plain lines all parse. **Read it and play back what you found**: the count, and the first few names, so a mis-parsed column is caught before it costs a scan. If the file has several columns, say which one you took as the account and offer to switch. **Domains beat names** — say so once here, because it is the single thing that reduces the skipped-entry list next run. - **Cap: 40 accounts per run.** If the list is longer, say so plainly and ask what they want: the first 40, or a subset they name. Don't silently truncate, and don't quietly run 200. 2. **What counts as a signal — in their words.** "What would make you want to reach out? Funding, hiring, a launch, a leadership change, pricing — or something specific to how you sell." **Take their answer verbatim and do not translate it into our categories.** If they say "anything about their support team", that is the definition, and a funding round is not a signal for them. Read it back in their words before moving on. This is the one input that decides what the whole run looks at. 3. **How far back.** Genuinely a choice — use the picker: *last 30 days (the default; matches "what did I miss")* · *last 90 days (a quarter, for a first run on a new list)* · *since my last digest (only when a previous run exists — offer this first when it does)*. 4. **What you sell, and to whom.** Pre-fill from the messaging doc or `objectives.md` when they're real and ask them to confirm rather than type it again. This is what the "why it matters" line is aimed with. If there's nothing on file and they'd rather not type it, take the skip — the digest says so on every card rather than inventing a positioning. 5. **Anything else that should shape this.** "A rep who owns some of these, an account you're already in a deal with, someone we shouldn't contact, a phrase to avoid. Optional — say 'nothing' if there isn't anything." 6. **Confirm before we run.** Play back the list name and count, their signal definition in their words, the window, the positioning line, and notes as a short bullet list, then: "Good to go, or anything to edit?" **Carry all five inputs forward verbatim from here** — the signal definition and the notes are the builder's own words, and paraphrasing either is how a digest ends up ranking against a category they never named. **The moment the builder approves**, set the expectation for the wait in one message of its own, then go quiet until the report: the scans run concurrently across batches and take several minutes on a list of this size, so say so plainly — this is a good moment to grab a coffee or switch tasks, and the digest will be ready when they check back. No further chatter between this and the report. ## Set up the run 7. **Make the working folder:** `my-work/signal-monitor/-/`, where the slug names the list (`target-accounts`, `q4-pipeline`). Dated on purpose — runs accumulate and are never overwritten; the history is what makes "what changed" and the quiet-two-runs-in-a-row finding possible. `my-work/` is builder-owned and never overwritten. 8. **Check for a previous run:** list `my-work/signal-monitor/`. If a prior dated folder holds a `signal-digest.md`, note its path and date — the analyst will dedupe against it and report what moved. 9. **Write `inputs.md`** into the working folder: the confirmed intake (the parsed account list, their signal definition **verbatim**, the window, the positioning line, notes) and which project files were real enough to read. This is the record of what shaped the digest, and the seed the next run pre-fills from. ## Run the agents Dispatch these as ordinary subagents. Do not use agent-teams tooling; this runs identically in every client. 10. **Split the accounts into batches of 8 and dispatch one `account-scanner` per batch — all in a single message so they run concurrently.** Thirty-four accounts is five scanners, not thirty-four; a subagent per account is what makes a dropped list unaffordable, and the whole design of this use case is that it stays cheap enough to run weekly. Each scanner gets: its batch of accounts, the builder's signal definition **verbatim**, the window, its batch number, and the working folder's **absolute path** in the dispatch prompt itself (a subagent starts wherever the session started; the path you pass is the handoff). Each writes a sourced `scan-batch-.md`, bounded to **2 to 3 fetches per account**. Wait for all of them. - **The fetch bound is a promise the digest repeats.** Don't raise it to chase a thin run, and don't let a scanner quietly exceed it — the artifact's meta line states the bound to the builder, and a run that broke it makes that statement false. - **If the builder's notes mention a specific account** — a deal in flight, a rumour they heard, a rep who owns it — pass it to *that* account's scanner as an **unverified lead from the builder**, to come back sourced or come back unconfirmed. Never as a fact. 11. **Dispatch `signal-analyst`** with the working folder path and, when step 8 found one, the previous `signal-digest.md` path. It reads `inputs.md` and every scan — **no web tools, no new research** — and writes `signal-digest.md`: the four lanes in order, one card per signal (what happened, why it matters, next touch), the quiet accounts named, the unresolved entries named, and what changed since the previous run. The builder's signal definition, positioning, and notes reach it through `inputs.md` **verbatim** — that file carries their words, never a paraphrase. ## Publish the artifact — you, not the agents 12. When `signal-analyst` finishes, read `signal-digest.md` and **publish it as a Claude Artifact** yourself, in this conversation, following the design contract below. The agents write markdown only; the finished, shareable view is yours to render. If artifact publishing isn't available in my environment, don't block — the markdown is saved; say so and give the path. ### The artifact — design contract (follow it exactly) **The artifact is a tool the builder operates on Monday morning, not a report they scroll** (product decision, 2026-08-31). The act-this-week lane is on screen first; any account is reachable in one click; lanes are scannable by color before they are read. Still read-only and honest: no CTAs, no dead controls, nothing that pretends to fetch, send, or save — a dead button in a sandboxed artifact is worse than no button. Interactivity is filtering, never chrome. **Filter chips, not tabs.** Competitive Intel gives each competitor a tab because four competitors are four deep reads. A dropped account list can be dozens, and dozens of tabs is a filing cabinet. The board is the default view; the chips narrow it. A single self-contained HTML page. **CSP rules: exactly one external request, the Google Fonts stylesheet below. All CSS in one `