Audience constraint check
Skill ralfyishere/piensalo/micro-skills/audience-constraint-check
PIÉNSALO is the open artificial cortex for AI—reduce context tokens, verify response quality, expand when needed, and safely fall back.
npx -y skills add ralfyishere/piensalo --skill audience-constraint-checkAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 1 stars1 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
Check a deliverable against its actual consumer: who reads it, what they do next, what format and register they need, and what they will assert downstream on its basis. Activate when the deliverable has a named audience beyond the requester, or its text will be forwarded, announced, or acted on by someone absent from the conversation.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.7 KB, 473 tokens by cl100k_base, as published. Nobody here has run it
audience-constraint-check
Trigger (observable): The deliverable has a named audience other than the requester-as-peer — execs, customers, a board, an on-call engineer, a handoff recipient, a public reader — or its text will be forwarded, announced, or acted on by someone absent from this session.
When NOT to activate: Working notes for the requester themselves; audience constraints already gathered and applied this session; interactive conversation where the consumer is present and can push back.
Procedure
- Name the consumer and their next action: what will this person do within minutes of reading (decide, forward, execute, announce)?
- List the constraints that consumer imposes: length ceiling, format (memo, runbook, table), expertise level and jargon budget, and political/PII/confidentiality boundaries for where it travels.
- Identify what the consumer will assert downstream on the strength of this deliverable — and scope every claim to survive that assertion (an unverified item they'll announce as fact is your failure, not theirs).
- Check the draft against each constraint; the answer's first two sentences must carry what the consumer needs for their next action.
- Strip content serving the author rather than the reader — methodology tours, hedging walls, internal jargon.
Required output
A consumer statement (who + next action), a constraint list with per-item draft compliance, and claims scoped to what the consumer will assert downstream.
Verification
- The named consumer's stated next action is answerable from the deliverable's first two sentences.
- No claim in the deliverable exceeds what the consumer can safely assert downstream; unverified items are marked as such.
Known risk: Over-fitting to an imagined audience and stripping technical content the real reader needed. Mitigation: constraints must come from the task or known facts about the consumer, not stereotype.
Max intended cost: ≤250 added output tokens; one pass over the draft.
Evidence status: DESIGNED — specified from documented reasoning-failure modes; not yet executed as a packaged skill.
Lineage: Derived from an evidence-backed completion-integrity repair pattern (scoping claims to the promise the consumer will actually rely on) and a documented reasoning-failure mode: presenting confidence at a level the evidence does not support.