CtrlK
BlogDocsLog inGet started
Tessl Logo

scan-signals

Use when reviewing supplied dated evidence for recent account signals, buying-context changes, or a manual weekly pulse.

63

Quality

73%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/scan-signals/SKILL.md
SKILL.md
Quality
Evals
Security

Scan Signals

Purpose

Summarize time-bounded account signals without converting operational activity into confirmed purchase intent or claiming that monitoring was scheduled.

Required inputs

  • Supplied evidence excerpts
  • Source type, publication/access date, event occurrence/effective date, and citation for each excerpt
  • Requested observation window, account scope, and comparison date
  • Eligibility or disqualification state, if prioritization is requested

Default to a manual seven-day window ending on the stated as-of date. If no as-of date exists, mark the window Missing rather than implying recency.

Workflow

  1. State the as-of date, inclusive observation window, evidence cutoff, and Manual run status.
  2. Record publication/access date separately from event occurrence/effective date. Never substitute one for the other.
  3. Apply the seven-day window only to the event date. Put out-of-window events under excluded candidates, even when published in-window.
  4. If event timing is absent or ambiguous, label TIMING UNVERIFIED and exclude the item from verified signals. Reject uncited claims likewise.
  5. For in-window events, record the fact, source metadata, citation, strength, and uncertainty. Treat activity as context unless purchase intent is directly evidenced.
  6. Rank only eligible records. Never let signal strength override a disqualifier.
  7. Leave the next pulse manual or separately configured; never imply recurrence exists.

Output format

# Signal pulse
- As of: [date or Missing]
- Window: [start through end]
- Run mode: Manual; no recurrence configured
## Signals
| Account | Fact | Event date | Published/accessed | Strength | Uncertainty | Source type | Citation |
## Excluded or unverified candidates
| Account/claim | Status | Event date | Published/accessed | Reason | Citation |
## Priorities
1. [eligible account — evidence-based reason]
## Gaps
- [missing or stale evidence]
## Next manual pulse
- [unexecuted review step]

Guardrails

  • Do not describe stale, undated, or uncited evidence as current or real-time.
  • Do not use publication or access date to place an event inside the observation window.
  • Do not call activity, hiring, pain, relevance, or model judgment verified buying intent.
  • Do not invent sources, events, identities, contactability, credentials, budgets, authority, urgency, or purchase timing.
  • Preserve facts, inferences, missing information, opt-outs, and disqualifications.
  • Exclude protected-trait targeting and unnecessary sensitive personal data.
  • Do not browse, scrape, contact people, mutate systems, schedule work, or claim a recurring pulse was configured.

Quality check

Confirm every verified signal's event date falls within the window; publication/access and event dates are separate; stale, uncited, and TIMING UNVERIFIED items are excluded; buying intent is not overstated; and recurrence remains manual or separately configured.

Example invocation

Use scan-signals on the two supplied dated fictional excerpts. Produce a manual seven-day pulse with citations, strength, uncertainty, evidence limits, and an unexecuted next-pulse checklist.

Repository
llaskin/AI-SDR-Skill-Pack
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.