CtrlK
BlogDocsLog inGet started
Tessl Logo

map-personas

Use when mapping supplied roles or stakeholder evidence into buyer, user, champion, and blocker personas for an offer or account.

73

Quality

90%

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

SKILL.md
Quality
Evals
Security

Map Personas

Purpose

Map stakeholder functions without inventing people, authority, needs, or influence. Treat persona-level interpretations as hypotheses unless supplied evidence supports them.

Required inputs

  • Offer facts and constraints
  • Supplied roles, responsibilities, or stakeholder records
  • Evidence of authority, use, advocacy, review, or resistance
  • Known concerns, objections, and unknowns

If no person is supplied for a persona, keep the persona unfilled.

Workflow

  1. Extract each supplied role and each substantive claim about it.
  2. Record responsibilities, buying functions, concerns, and offer relevance as separate claims; do not combine their evidence status.
  3. For every claim, assign Fact, Hypothesis, or Missing and give its supplied source or the reason it is only a hypothesis or missing.
  4. Assign Buyer, User, Champion, or Blocker as a fact only when supplied evidence directly establishes that function for the offer or evaluation. Title, ownership, or operational responsibility alone leaves the function Hypothesis or Missing.
  5. Preserve supplied “likely” language as a hypothesis rather than a confirmed pain.
  6. List missing stakeholders, authority, influence, and account-specific concerns as unknowns.

Output format

Persona or roleClaim typeClaimStatusSource or reason
[supplied role]Responsibility / Function / Concern / Offer relevance[one substantive claim]Fact / Hypothesis / Missing[supplied source or reason]

Use a separate row for every responsibility, function, concern, and offer-relevance claim. Follow the table with Unknowns and list unfilled roles or unsupported assumptions.

Guardrails

  • Never invent named employees, contact details, reporting lines, authority, budget, pain, or intent.
  • Do not collapse every stakeholder into a decision-maker.
  • Do not upgrade title, ownership, or responsibility into factual buying, user, champion, or blocker status.
  • Keep facts, hypotheses, and missing information distinct.
  • Do not infer a real account contact from a generic persona.
  • Do not research, contact, enrich, or update external systems.

Quality check

Confirm each responsibility, function, concern, and offer-relevance claim has its own status and source or reason; inferred functions are not facts; all names come from supplied inputs; and unknown stakeholders remain explicit.

Example invocation

Use map-personas on the five Northstar Relay personas. Preserve their economic buyer, operational buyer, champion, user or evaluator, and blocker or reviewer functions without creating contacts for unfilled roles.

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.