원클릭으로 Manus에서 모든 스킬 실행

audience-analyze-list

스타5

포크0

업데이트2026년 7월 6일 13:12

Read who a supplied list of people is — take a list of people as identifiers (emails, phones, names, addresses, inline or as a CSV) to resolve, or as already-resolved entity IDs (a roster from grouping, or a pasted entity-ID set), and render the discovered half of the read (the traits that define them against the world by lift, plus segmentation). No specified-signals section — the user gave people, not signals. The list way into audience-analyze, behind /watt:audience. Aggregates only — never individual records, never an export. Not a user command. Use when the user brings a list of people and asks who they are — "profile my customer list", "what do these people have in common", "read this roster's groups".

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

wattdata

wattdata/plugin

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Analyze a supplied list of people

Purpose

audience-analyze-list is the way into the read when the user brings a list of people, not signals. The list arrives in one of two forms, and they differ only in whether resolution is needed:

identifiers — a customer CSV, a pasted set of emails/phones/names/addresses → resolve them to Watt entities first.
entity IDs — a roster from the grouping objective, or any pre-resolved entity-ID set the user holds → already entities; skip resolution and read them directly.

Either way, because no signals were specified, there is no your-signals half — only the discovered read: the traits that define these people against the world by lift, plus per-domain segmentation.

This is a delta over audience-analyze: the unique work here is getting the list to a chainable entity set — resolving identifiers, or taking an entity-ID set as-is; the discovered read and the shareable report are the parent's shared procedure (audience-analyze → The read & report), composed with verbatim — discovered-only.

Works with

Called by: the audience-analyze router, when the user supplied a list of people — a CSV/identifiers to resolve, or a pre-resolved entity-ID set (a roster from grouping).
Runs inline:
- the resolution procedure (context/resolution.md) (identifiers only) — the supplied identifiers → a workflow:// entity-IDs URI plus the counts (identifiers submitted, entities resolved). The resolve runs inline but stays IDs-only — the leaf handles only the URI and counts, never a contact record. Skipped entirely when the list is already entity IDs — there is nothing to resolve.
- the profiling procedure — mode B (the entity-IDs URI, no signals) → the discovered-only read. The parent's shared read, run inline (context/profiling.md).

Language

Inherits the parent's table (lift explained once; sample named). The headcount here is a count of the people in hand, not a market total: "N people resolved from your list" for identifiers, or "N people in the set" / "N in this group" for an entity-ID set or roster.

The flow

1 — Get the list to an entity-ID set

Two input shapes; the only difference is whether resolution is needed.

Identifiers (a pasted set, or a CSV — uploaded or to upload). Name the identifier types present (email, phone, name, address); addresses need explicit handling, so call them out. Run the resolution procedure inline (context/resolution.md) with the identifiers (inline) or the csv_resource_uri, the entity_type, and a workflow_id. It matches them, dedupes, and returns the entity_ids_uri plus the counts — input_identifier_count and resolved_count (and below_floor_count). Narrate them plainly ("5,000 identifiers in, 4,200 people resolved — reading those"). The resolve runs inline but stays IDs-only — the leaf handles only the URI and counts, never a contact record.
Entity IDs already (a roster's roster_uri from grouping, or a pasted entity-ID set). These are the resolved entities — skip the resolution procedure entirely; take the URI as-is and the count of IDs in it. For a roster, the user can read the whole set (the roster_uri) or a single group (its entity_ids_uri); the group_label classification is what lets a per-group read be a separate inline run.

2 — Run the shared read (discovered-only)

Run the parent's shared read & report (audience-analyze → The read & report): run the profiling procedure inline (context/profiling.md) in mode B with the entity_ids_uri (the resolved set, or the roster/group URI taken as-is), the headcount, and the workflow_id — no signals, so the read is discovered-only. Render the dashboard with the discovered half (defining traits by lift, segmentation, the intent panel by reach); there is no your-signals section. Offer the shareable report — built with --no-specified so it drops Section 1 — and the next step (for a roster, a per-group read is the natural deeper cut, one mode-B inline run per group).

How to behave

The list is people, not signals — so the read is discovered-only, and the dashboard says so plainly rather than showing an empty your-signals section.
Aggregates only, and IDs never become records here. The resolution procedure returns entity IDs; the profiling procedure reads aggregates over them. No name, email, address, or contact data is ever pulled, shown, or written — turning IDs back into people is audience-activate's lane, behind its own confirmation.
Honest about the match. For identifiers, both counts are on screen — identifiers submitted vs. people resolved — and the read covers who matched, not everything uploaded; say so. For an entity-ID set or roster there's no match step (they're already entities) — the count is the set size, and for a roster the pruned/coverage from the build still applies.
Narrate the inline run and report the return in one plain line each — counts, never identifier values or records.
US-only, adults-only, person audiences only.

Refuse cleanly

"Enrich my list / give me their emails and phones." That's enrichment/export — audience-activate's lane, behind its confirmation. This leaf reads the list as aggregates only.
"Show me which of my people matched." Aggregates only — the read is over the matched set as a whole, not a per-row report; the counts say how many matched.
A brief instead of a list ("people interested in X") → that's audience-analyze-search (discover signals) — route there.

Failure modes

The resolution procedure matches few or none (bad identifiers, wrong column mapping) — surface the counts (how few of the submitted identifiers resolved) and the likely cause; never read an empty or near-empty set as if it were the list.
The profiling procedure errors mid-read. Surface where it stopped and what completed; never fill a panel with plausible numbers.

이 저장소의 다른 Skills

같은 저장소

audience-activate

wattdata/plugin

Export a built audience as platform-ready files — confirms the platforms, the scale, and the identifier types with the user, then materializes the audience once on this thread, batch by batch, and runs each platform's deterministic writer script, returning the finished files and honest row counts. Contact identifiers only by default; device IDs (mobile-ad IDs) ride an after-export pass added only when the user asks for them. Meta, Google, Reddit, and TikTok are the supported platforms, one or several at once. Never runs unconfirmed. Not a user command — /watt:audience is the front door. Use when an export-shaped ask arrives — "export it", "push it to Meta", "push it to Google and Reddit", "push it to TikTok", the audience as a file.

2026-07-065

audience-analyze-search

wattdata/plugin

Read who a market is, starting from a plain-English brief — discover → pivot → read. The discovery-first way into audience-analyze, behind /watt:audience; size is an output, never a target. Aggregates only — never individual records, never an export. Not a user command. Use when a read-shaped ask arrives with a brief and no signals yet — "who's in the market for X", "profile this audience", "an audience profile for my client".

2026-07-065

audience-analyze-signal

wattdata/plugin

Read who a built audience reaches when the signals are already in hand — a signal stack fresh from generate, an explore pool, a pasted audience record, or signals the user names — skip discovery, materialize, and render the two-section read (your signals + discovered). The signals-in-hand way into audience-analyze, behind /watt:audience. Aggregates only — never individual records, never an export. Not a user command. Use when a built audience is in session or the user supplies its signals and asks who's in it — "who's actually in this audience", "what do these people look like".

2026-07-065

audience-analyze

wattdata/plugin

Read who a built audience reaches, as aggregates over a deterministic sample — and, on request, a shareable signal membership report. The read step behind /watt:audience; routes to the way in that fits what the user has — a brief, signals they already hold, or a list of people. Aggregates only — never individual records, never contact data, never an ad-platform export. Not a user command — /watt:audience is the front door. Use when a read-shaped ask arrives — "who's actually in this audience", "what do these people look like", "an audience profile for my client" — or to sanity-check a signal stack before exporting.

2026-07-065

audience-generate-list

wattdata/plugin

Build a person audience from an owned list — customers, leads, accounts — resolving it to Watt entity IDs and emitting a roster, or learning what defines it and handing back a tunable signal pool. The list-anchored way into a build, behind /watt:audience. Four plays — resolve-only, expand (households via addresses), lookalike (the signals that define the list, to tune), overlay (score and rank against signals); group and traverse aren't built. Produces a roster of entity IDs or a signal pool — never an export, never contact data. Not a user command — /watt:audience is the front door. Use when a list arrives to build from — "match my customer list", "find more like my customers", "rank my list by intent", "score the people from my last run". A read intent is audience-analyze-list.

2026-07-065

audience-generate-search

wattdata/plugin

Build a person audience from a plain-English description — discover the signals behind the brief, score them, and compose, partition, or cross them into a measured result. The discovery-driven way into a build, behind /watt:audience; anchored on a description (no owned list). The objective picks how it lands — a size band, the widest credible reach, the highest-precision few, grouping into the best-concentrated cells, or crossing the employment graph to their employers (or employees). Produces a signal stack + measured reach, or a roster — never an export, never contact data. Not a user command. Use when a build starts from a description — "build me an audience of about 1–5M weekend hikers", "the highest-intent people in-market for solar", "where do these people cluster", "a lead list of in-market companies".

2026-07-065

name	audience-analyze-list
description	Read who a supplied list of people is — take a list of people as identifiers (emails, phones, names, addresses, inline or as a CSV) to resolve, or as already-resolved entity IDs (a roster from grouping, or a pasted entity-ID set), and render the discovered half of the read (the traits that define them against the world by lift, plus segmentation). No specified-signals section — the user gave people, not signals. The list way into audience-analyze, behind /watt:audience. Aggregates only — never individual records, never an export. Not a user command. Use when the user brings a list of people and asks who they are — "profile my customer list", "what do these people have in common", "read this roster's groups".
user-invocable	false
compatibility	Designed for Claude Cowork, Claude Code, or Agent SDK. Requires Signal Graph.

Analyze a supplied list of people

Purpose

audience-analyze-list is the way into the read when the user brings a list of people, not signals. The list arrives in one of two forms, and they differ only in whether resolution is needed:

identifiers — a customer CSV, a pasted set of emails/phones/names/addresses → resolve them to Watt entities first.
entity IDs — a roster from the grouping objective, or any pre-resolved entity-ID set the user holds → already entities; skip resolution and read them directly.

Works with

Called by: the audience-analyze router, when the user supplied a list of people — a CSV/identifiers to resolve, or a pre-resolved entity-ID set (a roster from grouping).
Runs inline:
- the resolution procedure (context/resolution.md) (identifiers only) — the supplied identifiers → a workflow:// entity-IDs URI plus the counts (identifiers submitted, entities resolved). The resolve runs inline but stays IDs-only — the leaf handles only the URI and counts, never a contact record. Skipped entirely when the list is already entity IDs — there is nothing to resolve.
- the profiling procedure — mode B (the entity-IDs URI, no signals) → the discovered-only read. The parent's shared read, run inline (context/profiling.md).

Language

The flow

1 — Get the list to an entity-ID set

Two input shapes; the only difference is whether resolution is needed.

Identifiers (a pasted set, or a CSV — uploaded or to upload). Name the identifier types present (email, phone, name, address); addresses need explicit handling, so call them out. Run the resolution procedure inline (context/resolution.md) with the identifiers (inline) or the csv_resource_uri, the entity_type, and a workflow_id. It matches them, dedupes, and returns the entity_ids_uri plus the counts — input_identifier_count and resolved_count (and below_floor_count). Narrate them plainly ("5,000 identifiers in, 4,200 people resolved — reading those"). The resolve runs inline but stays IDs-only — the leaf handles only the URI and counts, never a contact record.
Entity IDs already (a roster's roster_uri from grouping, or a pasted entity-ID set). These are the resolved entities — skip the resolution procedure entirely; take the URI as-is and the count of IDs in it. For a roster, the user can read the whole set (the roster_uri) or a single group (its entity_ids_uri); the group_label classification is what lets a per-group read be a separate inline run.

2 — Run the shared read (discovered-only)

How to behave

The list is people, not signals — so the read is discovered-only, and the dashboard says so plainly rather than showing an empty your-signals section.
Aggregates only, and IDs never become records here. The resolution procedure returns entity IDs; the profiling procedure reads aggregates over them. No name, email, address, or contact data is ever pulled, shown, or written — turning IDs back into people is audience-activate's lane, behind its own confirmation.
Honest about the match. For identifiers, both counts are on screen — identifiers submitted vs. people resolved — and the read covers who matched, not everything uploaded; say so. For an entity-ID set or roster there's no match step (they're already entities) — the count is the set size, and for a roster the pruned/coverage from the build still applies.
Narrate the inline run and report the return in one plain line each — counts, never identifier values or records.
US-only, adults-only, person audiences only.

Refuse cleanly

"Enrich my list / give me their emails and phones." That's enrichment/export — audience-activate's lane, behind its confirmation. This leaf reads the list as aggregates only.
"Show me which of my people matched." Aggregates only — the read is over the matched set as a whole, not a per-row report; the counts say how many matched.
A brief instead of a list ("people interested in X") → that's audience-analyze-search (discover signals) — route there.

Failure modes

The resolution procedure matches few or none (bad identifiers, wrong column mapping) — surface the counts (how few of the submitted identifiers resolved) and the likely cause; never read an empty or near-empty set as if it were the list.
The profiling procedure errors mid-read. Surface where it stopped and what completed; never fill a panel with plausible numbers.