agentsclimarketplace

Audience transformation positioning

Skill ArthurZakirov/ProofStack/skills/audience_transformation_positioning

Public-safe skills and schemas for turning private work evidence into career signal

Install
npx -y skills add ArthurZakirov/ProofStack --skill audience_transformation_positioning

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Define the reader/customer avatar, painful current state, desired outcome, transformation bridge, objections, and proof needed before writing profile copy, posts, articles, landing pages, or visual concepts.

SKILL.md

4.5 KB, as published. Nobody here has run it

Audience Transformation Positioning Skill

Use this when

Use this skill before writing any asset where persuasion or attention matters:

  • LinkedIn About sections
  • profile headlines
  • article introductions
  • YouTube/video hooks
  • landing-page sections
  • project README positioning
  • portfolio pages
  • banner or article-header concepts
  • offer descriptions

Core principle

People read only when they believe reading will benefit them.

Before writing, define the reader's transformation:

current painful situation → bridge/mechanism → desired situation

The text must make the reader feel:

"This person understands my problem and may have a useful way out."

Step 1 — Define the reader/avatar

Answer:

  • Who is likely reading this?
  • What are they trying to decide?
  • What problem, fear, deadline, risk, or desire is active in their mind?
  • What are they already searching for?
  • What would make them stop scrolling or keep reading?

Common reader types:

  • recruiter
  • hiring manager
  • senior engineering leader
  • founder
  • technical peer
  • potential user of a project
  • reader of a post/article
  • buyer of a service/product

Step 2 — Define the painful current state

Make it concrete. Avoid abstract pain.

Good current-state examples:

  • too much manual work
  • unclear requirements
  • missed deadlines
  • costly bottlenecks
  • AI demos that never become adopted systems
  • engineers overloaded by repetitive operational work
  • hiring uncertainty: unclear who can actually create value
  • a tool exists, but users still cannot achieve the outcome

Ask:

  • What is frustrating right now?
  • What is expensive right now?
  • What feels risky right now?
  • What is slow, confusing, manual, brittle, or invisible?

Step 3 — Define the desired outcome

The desired outcome should be what the reader actually wants, not merely what the creator wants to talk about.

Good desired-state examples:

  • hit deadlines
  • reduce manual load
  • make the system reliable
  • get leadership buy-in
  • make users adopt the tool
  • make work measurable through KPIs
  • turn vague requests into shipped outcomes
  • avoid wasting effort on the wrong solution

Step 4 — Define the bridge

The bridge is the mechanism that moves the reader from current state to desired state.

The bridge should not be a buzzword. It should be a believable process, framework, tool, or capability.

Good bridge format:

I help [audience] move from [painful current state] to [desired outcome] using [specific mechanism].

Examples:

I help engineering teams turn messy manual processes into adopted automation systems using data, software, and agentic AI.

I turn messy operational context into reusable automation capabilities.

Step 5 — Identify objections and risks

The reader may object:

  • Is this just hype?
  • Does this generalize beyond one lucky case?
  • Can this person do it in my stack/domain?
  • Is this only a demo, or did people adopt it?
  • Does this require too much effort from my team?
  • Is AI safe enough for this workflow?
  • Are the results measurable?

Address objections with:

  • numbers
  • proof examples
  • scope boundaries
  • clear mechanism
  • adoption evidence
  • before/after comparison
  • risk reversal or low-friction next step

Step 6 — Choose the promise

Every asset needs a promise.

Templates:

If you read this, you will understand how [unexpected result] happened despite [constraint].

If you read this, you will learn a repeatable way to move from [current pain] to [desired outcome].

If you use this, your team can reduce [pain] and achieve [result] with [mechanism].

Output format

Before drafting, produce this map:

## Reader
- Primary reader:
- What they want:
- What they fear:
- What they are deciding:

## Current Situation
-

## Desired Situation
-

## Bridge / Mechanism
-

## Objections
-

## Proof Needed
-

## Core Promise
-

Quality bar

Strong positioning is:

  • reader-centered
  • concrete
  • benefit-driven
  • emotionally legible
  • grounded in proof
  • connected to a mechanism

Weak positioning is:

  • generic
  • self-centered
  • full of buzzwords
  • focused on tools instead of outcomes
  • missing the reader's pain
  • missing why the reader should care

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.