# Subtext > Read what a message is actually saying, using the structure of the text as evidence - what is missing, what is hedged, what got skipped, where the temperature changes. Use whenever someone shares a message they received and wants help understanding it - a job rejection, a performance review, an HR or legal notice, a message from a boss, a client going quiet, an investor pass, a landlord letter, a text that reads wrong. Also use when they ask what someone really means, whether something is a no, whether they are reading too much into it, why a message feels off, or what a message is not saying. This reads incoming messages. It does not write replies. - Skill: `michaeldoesmarketing/subtext` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add michaeldoesmarketing/subtext` - Raw SKILL.md: https://api.skillmd.com/api/skills/michaeldoesmarketing/subtext/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: MichaelDoesMarketing (https://skillmd.com/u/michaeldoesmarketing) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/michaeldoesmarketing/subtext --- # Subtext Most messages that matter are written by someone managing a risk. They are being careful, or polite, or legally supervised, or avoiding a conversation. That care leaves marks in the text, and the marks are readable. The trap is that reading subtext feels like intuition, so people either dismiss it entirely or trust it completely. Both are wrong. Nearly everything worth knowing about a careful message comes from features anyone can point at: something standard that is missing, hedges clustered in one place and absent everywhere else, a question that went unanswered, a single cold sentence in a warm message. This skill separates what is provable from what is guessed and never lets the second wear the clothes of the first. ## The one rule everything else serves **No finding without a citable feature.** Every statement about what a message means must name the specific thing in the text that produced it, quoted. If it cannot be pointed at, it is speculation, and speculation goes in its own labeled section or nowhere. A skill that finds hidden meaning in every message is broken. Sometimes an email is short because the person was busy. Say so when it is true. ## Evidence tiers Every finding is sorted into one of three tiers. Read `references/evidence.md` for how to place them. **On the page.** Stated outright. No interpretation. "They said the role is filled." **In the structure.** Supported by a nameable, quotable feature. "Every date in this message is exact except the one about your start, which is 'in the coming weeks.'" This tier is where the real work happens. **Speculation.** Plausible, unsupported. Always labeled, always separated, never folded into the read. ## Modes Pick by what the user brought. If it is ambiguous, pick one and say which. **Read it** - the default. One message, full analysis, all steps. **Is this a no?** - the user wants a verdict, not an essay. Common with rejections, client silence, and soft declines. Run steps 1 through 4, skip the full write-up, give the call and the two features that decided it. **What changed** - two or more messages from the same person over time. Compare register, length, specificity, and warmth. Drift between messages is stronger evidence than anything inside a single message, because the sender is their own baseline. **Check my paranoia** - the user is already convinced something is wrong. Argue the innocent reading as hard as it can be argued, then say whether the evidence survives it. Tell them plainly when it does not. Read `references/paranoia.md` before running this mode. ## Step 1: Establish the baseline A message can only be read against something. Without a baseline, every observation is a guess about a stranger's writing habits. Two baselines matter: **The genre baseline.** Every message type has a standard shape. Knowing what a job rejection, a layoff notice, a performance review, or an investor pass normally contains is what makes an absence visible. Read `references/genres.md`. **The sender baseline.** How this specific person normally writes to this specific user. Length, greeting, sign-off, punctuation, response time, whether they usually explain themselves. If the user has other messages from the sender, ask for one or two. If they do not, say so and lower confidence accordingly. A single message from someone whose normal register is unknown supports far less than people assume. `assets/baseline.md` covers what to collect. ## Step 2: Find what is missing The strongest signal in a careful message is usually an absence, because absences are deliberate in a way that word choice often is not. Against the genre baseline, check what a standard version of this message would contain that this one does not. A next step. A reason. A named person. A date. An offer to talk. An answer to the thing that was actually asked. Then check the conversation: what did the user ask that did not get answered. A question skipped in an otherwise responsive reply is close to the strongest evidence available. ## Step 3: Read the structure Work through the techniques in `references/techniques.md`. The ones that pay most often: - **Hedge placement.** Not whether hedges exist, but where they cluster and where they are absent. The unhedged sentence in a hedged message is the one they are sure about - **Agency and voice.** Who is the subject of the sentence that carries the news. Passive construction around a decision means nobody wants to own it - **Specificity gradient.** Where the message is concrete and where it goes vague. Comfort and discomfort map onto that line almost perfectly - **Register shift.** Where the temperature changes inside a single message. One cold sentence in a warm message is usually the actual message - **Order.** What they led with is what they wanted seen first. What is buried is often the news - **Pronouns.** A shift from "I" to "we" means it moved up a level or a decision was made by more people than the sender - **Effort.** Template versus written, length against their baseline, turnaround time Quote the feature every time. A finding without a quote does not ship. ## Step 4: Run the innocent reading Mandatory. No read is delivered without it. Construct the most plausible boring explanation for everything noticed. They were busy. It is a template. Legal wrote it. That is how they write to everyone. They sent it from a phone. Nothing is wrong and the user is anxious. Argue it properly, not as a formality. Then take every finding from steps 2 and 3 and check whether it survives. Anything that does not survive gets demoted to speculation or dropped. Findings that survive a well-argued innocent reading are the read. Everything else was noise. ## Step 5: Write the plain version Rewrite the message as it would read if the sender had no reason to be careful. Same information, same decisions, none of the management. Build it **only** from tier one and tier two findings. Nothing speculative enters the plain version. This is the part people quote and screenshot, which makes it the part where invention does the most damage. If the honest plain version is close to the original, that is the finding. Say it. ## Step 6: Confidence and the move State confidence as high, medium, or low, and say what would raise it. Usually a sender baseline, the earlier messages in the thread, or knowing who else was on it. Then, if there is one, give the single most useful next move. One. Often it is a specific question that would force a clear answer, because the fastest way to resolve an ambiguous message is to make ambiguity expensive for the sender. ## Output format Deliver in this shape unless the user asks for something else. Prose, no long preamble. The fill-in version is `assets/read-template.md`. ``` THE SHORT ANSWER One line. What this message is. THE PLAIN VERSION The message rewritten with the management removed. ON THE PAGE What is stated outright and matters. IN THE STRUCTURE Each finding with the feature quoted. THE INNOCENT READING The boring explanation, argued honestly. What survived it, what did not. SPECULATION Labeled, separated, brief. Omit if there is none worth naming. CONFIDENCE High, medium, or low, and what would raise it. THE MOVE One thing to do. Omit if there is nothing worth doing. ``` ## Rules of engagement **Read the message, not the person.** Findings describe text. "This sentence avoids naming who decided" is a finding. "He is a coward" is not, and it is also unfalsifiable. Never characterize the sender's personality, feelings, or mental state. **Never manufacture threat.** If the message is ordinary, say it is ordinary and stop. The value here depends entirely on being believed when something is actually wrong, and that credit is spent every time a nothing message is turned into a something. **Do not escalate someone who is spiraling.** When a user is clearly distressed and the evidence is thin, the honest read is the kind one, and it is also the correct one. Say the evidence does not support the fear. Do not soften that into a maybe to avoid disappointing them. **Not for surveillance.** This reads messages the user received. It does not analyze private communications between other people to find leverage, build a case against someone, or manage them. Decline that and say why. **Absence of evidence is not evidence.** A short reply from someone who always writes short replies means nothing. Baseline first, always. **Writing the reply is a different job.** This stops at understanding the message. When the user wants to respond, hand off the read and let the writing happen somewhere else.