English | 繁體中文
Make the work fit the people—and the change it is meant to create.
A lightweight reasoning skill for aligning AI-generated work with who will receive, use, decide on, or be affected by it, the situation they are in, and what should become different if the result is useful.
Install · Run the smoke tests · Evaluation protocol · Trust & security · Changelog
Many AI outputs are complete in form and wrong in direction. They contain all the expected sections, yet emphasize the wrong things, assume the wrong reader, ask unnecessary questions, or optimize for an outcome that was never established.
Audience Outcome Lens adds one small checkpoint before execution and one before delivery:
request and evidence
↓
people → situation → intended change → material unknowns
↓
relevant domain or format skill
↓
usefulness, evidence, and scope check
It is not a copywriting framework, persona worksheet, content template, or replacement for domain expertise. It is a thin, reusable judgment layer that helps another skill make better choices about emphasis, omission, sequence, explanation, and recommendation.
| Without the lens | With the lens |
|---|---|
| A polished answer for an imagined generic reader | A result calibrated to the people and situation supported by the request |
| A long discovery questionnaire before useful work begins | Existing context is inferred first; only consequential forks are surfaced |
| Recipient, buyer, operator, and affected user are merged into one persona | Roles remain distinct when their needs materially conflict |
| The desired outcome quietly biases evidence | Accuracy, evidence, safety, and non-manipulation outrank the preferred result |
| Every task becomes strategy work | Objective, audience-independent checks stay exact and bounded |
| The agent returns an audience analysis | The agent completes the original task and keeps the frame internal by default |
Before acting, the skill asks only what can change the result:
- Who is the primary recipient or user?
- Who else is affected or holds relevant decision authority?
- What situation are they in now?
- What should become different if the result is useful?
- Which evidence, constraints, and prior decisions shape the work?
- Which unknowns would materially change a valid direction?
The frame is provisional. Supplied facts and direct observations remain separate from assumptions. Low-risk, reversible assumptions should not block progress. A genuinely consequential unresolved fork should be made visible rather than guessed away.
| Task | Typical effect |
|---|---|
| Articles, emails, announcements, and public communication | Adjusts depth, language, emphasis, and next action |
| Courses, workshops, and presentations | Aligns difficulty and sequence with what learners should understand or do |
| Product flows and user-facing behavior | Keeps actual users, operators, buyers, and affected people visible |
| Proposals, plans, and recommendations | Prioritizes the decision and constraints instead of producing a generic list |
| Decision-oriented research and data analysis | Selects useful evidence without cherry-picking toward the hoped-for answer |
| User-facing technical work | Applies to behavior, explanation, failure states, and accessibility—not to unrelated implementation detail |
The same core works across domains because it does not prescribe an artifact structure. It carries the frame into the relevant writing, presentation, product, data, design, or coding skill.
Do not invoke the lens when success is defined by objective, audience-independent acceptance criteria, including:
- exact format or schema transformations;
- calculations with a supplied formula;
- single factual lookups;
- literal translation where adaptation was not requested;
- bounded lint, test, or bug checks with known acceptance criteria.
For mixed tasks, keep the factual or technical core exact and use the lens only for the audience-dependent presentation or behavior.
The skill was distilled from a real website-rewrite workflow. The useful part was not a particular page template. It was the sequence of judgments behind the copy: identify the visitor's current situation, define the useful change, separate intent paths, preserve evidence limits, and give each path a fitting next step.
The rewritten homepage attracted outside interest and motivated the extraction of the reusable lens. That is valuable source-case evidence, not a claim that the skill has a measured universal quality multiplier. The published evaluation protocol keeps the website case as one golden case and tests transfer boundaries across communication, education, product, data, recommendations, and bounded technical work.
Ask your agent to inspect the versioned runbook, show an exact plan, and wait before writing:
Read https://raw.githubusercontent.com/cablate/audience-outcome-lens/v0.1.0/install/AGENT-INSTALL.md
and prepare a plan to install Audience Outcome Lens as $audience-outcome-lens.
Inspect my current skill directories first. Do not overwrite existing files.
Show the source, destination, changed files, non-changes, and verification steps.
Wait for my approval before writing anything.
Review the installation manifest and trust boundary before installation.
Clone the tagged release into the skill directory used by your agent harness:
git clone --branch v0.1.0 --depth 1 https://github.com/cablate/audience-outcome-lens.git audience-outcome-lensPlace or link the cloned folder where your product discovers SKILL.md packages. Discovery paths differ across products, so follow the current documentation for your harness. Start a fresh session if discovery is cached, then run the smoke tests.
The runtime entrypoint is SKILL.md. README, benchmark, release, and installation files are for people and are not required in normal model context.
Use it explicitly with a people-facing task:
Use $audience-outcome-lens to turn these raw service notes into a clear proposal.
Complete the proposal itself. Surface only assumptions or choices that would
materially change the result.
Use it before a domain skill:
Use $audience-outcome-lens, then the relevant presentation skill, to create
an eight-minute budget request for a CFO. Preserve the supplied numbers and
do not invent ROI evidence.
Use it to protect a mixed technical task:
Use $audience-outcome-lens only for the weak-network upload experience and
user-facing error behavior. Keep the supplied API contract and tests exact.
Version 0.1.0 has:
- passed the official structural skill validator;
- passed static checks for trigger, exclusion, stakeholder, evidence, scope, and UI-prompt contracts;
- passed a cross-domain boundary review covering both positive and negative invocation cases;
- passed source-case alignment checks against the original website plan and resulting homepage copy.
These checks establish specification quality and source-case alignment. Independent repeated model trials are the next evidence layer; no measured universal uplift is claimed yet.
.
├── SKILL.md
├── VERSION
├── agents/
│ └── openai.yaml
├── install/
│ ├── AGENT-INSTALL.md
│ ├── MANIFEST.md
│ ├── SMOKE-TESTS.md
│ └── UNINSTALL.md
├── benchmarks/
│ ├── README.md
│ └── cases.md
└── docs/
└── TRUST.md
- Infer before asking. Use available context before creating question burden.
- Keep the frame provisional. Do not turn assumptions into facts.
- Separate people when their interests conflict. A buyer is not automatically the user.
- Let evidence outrank intent. A useful result cannot depend on distortion.
- Guide selection, not structure. The domain skill still owns the artifact.
- Keep bounded work bounded. Exact tasks should remain exact.
- Complete the original task. The lens is internal judgment, not ceremonial output.
MIT © 2026 CabLate. See LICENSE.