@human-avatar/skills-for-humanity 1.0.0

package/skills/communication-audience-modeling/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: communication-audience-modeling
+description: "Maps what the audience currently believes, actually cares about, and fears before communicating — because communication fails at the receiver, not the sender. Triggers: 'model the audience', 'audience analysis', 'who am I talking to', 'what do they care about', 'why aren't they getting it'."
+---
+
+# Communication Audience Modeling
+
+Communication fails at the receiver. The sender almost always knows what they meant —
+the question is what the receiver hears, given what they currently believe, what they
+actually care about, and what they are trying to protect. Modeling this before communicating
+is the most leverage-bearing preparation step there is.
+
+---
+
+## Your Process
+
+**Step 1: Name the Specific People**
+Don't model "the team" or "leadership." Name the individuals or segments who will receive
+this message. Different people in the same meeting need different models.
+
+**Step 2: Current Belief**
+What do they already think about this topic? Not what you wish they thought — what they
+actually think right now. This is the starting position the message must move from.
+
+**Step 3: Real Goal**
+What is their underlying motivation? Stated preferences are often proxies for something
+deeper: security, recognition, autonomy, fairness, control. If you're addressing the
+stated preference without the underlying motivation, the message won't land.
+
+**Step 4: Fear**
+What do they need not to lose? Fear is more motivating than ambition for most people in
+most professional contexts. A message that threatens something they're protecting will be
+rejected even if the logic is sound.
+
+**Step 5: What Would Change Their Mind — and What Won't**
+What evidence, framing, or social proof would move them? And what — however well-reasoned
+— will not work on this person? Knowing what won't work is as important as knowing what
+will.
+
+**Step 6: Threshold Condition**
+What must they hear or feel first before they can receive the actual message? Some people
+need to feel heard before they can listen. Others need certainty about scope. Others need
+a specific concern addressed before anything else can land.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Fears and concerns only** — what the audience is most worried about, skip beliefs and goals
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Audience segments:**
+
+| Person / Segment | Current belief | Real goal | Fear | What moves them | What won't work | Threshold condition |
+|-----------------|---------------|-----------|------|-----------------|-----------------|---------------------|
+| | | | | | | |
+| | | | | | | |
+
+**Message implications:**
+> [What must the message do, in what order, to land for each segment?]
+> [Where do segments conflict — and how should that tension be resolved?]
+
+**Highest-risk segment:**
+> [The person or group most likely to reject the message — and why]
+
+---
+
+## Notes
+
+The threshold condition in Step 6 is the most commonly skipped and most valuable element.
+A message that tries to make its main point before meeting the threshold condition will be
+filtered out before it arrives.

package/skills/communication-clarity-audit/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: communication-clarity-audit
+description: "Audits a communication for places where the message will be lost, misread, or misunderstood — before it's sent. Triggers: 'clarity audit', 'will this be understood', 'check my message', 'edit for clarity', 'where will this be misread'."
+---
+
+# Communication Clarity Audit
+
+Most clarity failures are invisible to the sender because the sender knows what they meant.
+The receiver does not have that context, and the gap between what was meant and what is
+read is where miscommunication lives. This audit finds that gap by reading the message as
+the receiver would — without access to the sender's intent.
+
+---
+
+## Your Process
+
+**Step 1: Read from the Receiver's Perspective**
+Do not read this as the writer who knows what was meant. Read it as someone receiving it
+cold. What is actually on the page? This requires a deliberate perspective shift — it is
+the hardest step and the most important one.
+
+**Step 2: Structure Check**
+Can the main point be identified within 10 seconds? If not, the structure is obscuring it.
+Is the structure serving the reader or the writer's thinking process? The two are often
+different.
+
+**Step 3: Jargon Inventory**
+List every term or acronym that requires context the reader may not have. Each one is a
+potential comprehension failure. Include terms that feel obvious — "obvious" is always
+relative to what the writer knows.
+
+**Step 4: Assumption Inventory**
+What must the reader already know or believe for this message to make sense? State each
+assumption explicitly. For each: does this reader have this context? If not, the message
+has a gap.
+
+**Step 5: Ask — Is It Clear?**
+Is there a clear action or next step? Is it clear who does what, by when? A message that
+informs without directing produces nothing. A message that directs ambiguously produces
+the wrong thing.
+
+**Step 6: Name the Most Likely Misreading**
+State the single most plausible way this message will be misread or misunderstood by a
+reasonable receiver. This is the most valuable output — it is the failure that will
+actually happen if the message is sent as written.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Breakpoints only** — where this message will be misread or lost, skip what's already clear
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Issues found:**
+
+| Category | Issue | Severity (High/Med/Low) | Edit |
+|----------|-------|------------------------|------|
+| Structure | | | |
+| Jargon | | | |
+| Assumptions | | | |
+| Ask/Action | | | |
+
+**Most likely misreading:**
+> [Concrete statement of how a reasonable receiver will misread this — and what they
+> will do or believe as a result]
+
+**Priority edits:**
+1. [Highest-impact change]
+2. [Second highest]
+3. [Third]
+
+---
+
+## Notes
+
+A single clear next step with a named owner and a deadline eliminates more miscommunication
+than any amount of structural or vocabulary editing. If the ask is ambiguous, fix that
+before anything else.

package/skills/communication-medium-selection/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: communication-medium-selection
+description: "Matches the message to the right channel and format — the same content in the wrong medium loses most of its effect. Triggers: 'which channel', 'email vs meeting', 'should this be async or sync', 'medium fit', 'how should I deliver this'."
+---
+
+# Communication Medium Selection
+
+The same content delivered through the wrong medium loses most of its effect. Bad news in
+Slack destroys trust. A complex decision in an email generates confusion. A routine update
+in a meeting wastes an hour. Medium selection is not a logistics question — it is a
+communication design decision that determines whether the message can land at all.
+
+---
+
+## Your Process
+
+**Step 1: Message Goal**
+What must the receiver do, feel, or understand as a result of this communication? Be
+specific. "Understand the situation" is not a goal. "Approve the budget by Friday" is.
+"Feel heard about the reorg" is.
+
+**Step 2: Urgency**
+How quickly must they act or respond? Hours, days, weeks? Urgency drives the sync vs
+async question more than any other factor.
+
+**Step 3: Emotional Weight**
+Is this message carrying emotional content? Difficult news, a sensitive correction, a
+celebration, a request that requires trust, a change that affects someone's identity or
+security? Emotional weight requires channels that allow nuance and reaction.
+
+**Step 4: Complexity**
+Does this require back-and-forth to resolve, or can it land cleanly in a single read?
+Complex decisions with multiple unknowns require synchronous dialogue. Clear information
+transfers can be async.
+
+**Step 5: Match to Medium**
+Apply the selection logic:
+- Difficult news / sensitive topic → sync verbal (in person or video)
+- Complex decision requiring buy-in → meeting with written pre-read
+- Simple update, no action required → async written (email or doc)
+- Permanent record needed → written
+- Emotional connection is the goal → video or in person
+- Fast coordination, low stakes → messaging (Slack, etc.)
+- Formal commitment → written with signature or named acknowledgment
+
+**Step 6: Choose Primary and Secondary Medium**
+Select the primary channel. If the message needs reinforcement (complex, high-stakes,
+or high emotional weight), add a secondary: e.g., meeting followed by written summary.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Channel recommendation only** — which medium and why, skip the full analysis
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Message assessment:**
+
+| Dimension | Assessment |
+|-----------|------------|
+| Goal | [What must receiver do/feel/understand] |
+| Urgency | [Timeline] |
+| Emotional weight | [None / Low / Medium / High — why] |
+| Complexity | [One-way or requires dialogue] |
+
+**Recommended medium:** [Primary channel]
+**Secondary medium (if needed):** [Reinforcement channel + why]
+
+**Rationale:**
+> [2-3 sentences on why this medium fits this message — and what would go wrong in
+> the next-most-obvious alternative]
+
+---
+
+## Notes
+
+The most common error is defaulting to async written (Slack, email) for messages with
+high emotional weight, because it feels faster and less confrontational. The short-term
+comfort always costs more in trust and rework than the difficult conversation would have.

package/skills/communication-objection-mapping/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: communication-objection-mapping
+description: "Maps likely objections before delivering a proposal — objections that are anticipated feel addressed; objections that land as surprises derail. Triggers: 'anticipate objections', 'what will they push back on', 'steelman the opposition', 'prepare for resistance', 'objection mapping'."
+---
+
+# Communication Objection Mapping
+
+Anticipated objections feel handled. Unanticipated objections derail. The difference is
+not the content of the objection — it is whether the receiver senses that the sender
+has thought it through. A proposal that addresses likely objections before they are
+raised signals rigor and respect. One that doesn't signals that the sender only thought
+from their own perspective.
+
+---
+
+## Your Process
+
+**Step 1: State the Proposal**
+Write the proposal clearly — what is being asked, what it proposes to do, and what it
+asks of the audience (approval, resources, behaviour change, belief change).
+
+**Step 2: List Audience Segments**
+Who will receive this? Different roles and individuals will have different objections.
+A finance stakeholder's objection to a proposal is structurally different from an
+engineering lead's, even if both say "this is risky."
+
+**Step 3: Generate Objections per Segment**
+For each segment: given what they care about and what they fear, what is their most
+likely objection? Be specific — "they might push back on cost" is too vague. "They will
+argue the ROI model assumes usage patterns that contradict last quarter's data" is useful.
+
+**Step 4: Classify Each Objection**
+- **Legitimate**: the objection raises a real concern the proposal should genuinely engage
+  with. Dismissing it will damage credibility.
+- **Unfounded**: the objection reflects a misunderstanding, missing information, or
+  an assumption the proposal already addresses. Requires clarification, not capitulation.
+
+**Step 5: Respond to Legitimate Objections**
+For each legitimate objection: what is the honest, direct response? Acknowledge the
+concern genuinely. Address it specifically. Do not pretend it doesn't exist or soften
+it into irrelevance — that will be noticed.
+
+**Step 6: Pre-emptive Move**
+For each significant objection: is there something in the message itself that could reduce
+the objection's force without capitulating to it? Pre-empting an objection by raising it
+yourself is more credible than responding to it when challenged.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Top 3 objections only** — most likely showstoppers, skip the full map
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Proposal:** [Summary — what is being asked and what is being proposed]
+
+**Objection map:**
+
+| Audience segment | Likely objection | Legitimate / Unfounded | Response | Pre-emptive move |
+|-----------------|-----------------|----------------------|----------|------------------|
+| | | | | |
+| | | | | |
+
+**Objections to address in the message itself:**
+> [Which objections should be pre-empted in the proposal, not left for Q&A — and why]
+
+**Objections to prepare for but not address upfront:**
+> [Which are better handled in dialogue than in the message]
+
+---
+
+## Notes
+
+The classification in Step 4 requires honesty. The temptation is to classify all
+objections as unfounded — that they reflect misunderstanding rather than legitimate
+concern. If an objection is legitimate and you dismiss it, you lose credibility on
+everything else.

package/skills/constraint/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: constraint
+description: "Entry point for the constraint toolkit. Routes to the right constraint skill based on your situation. Use when you say 'constraint', 'given this limit', 'we can't do X', 'is this really fixed', 'use the limitation', 'minimum viable', 'how do we do this anyway', or want constraint thinking applied without knowing which specific tool fits."
+---
+
+# Constraint
+
+Applies constraint reasoning to any situation where limits are shaping (or blocking) what's possible. Diagnoses what kind of constraint work is needed and applies the right tool.
+
+## Which tool fits
+
+| You need to... | Tool |
+|---|---|
+| Test whether a stated constraint is actually real | hardness-testing |
+| Flip a constraint into a creative driver | rule-inversion |
+| Find the minimum that satisfies the actual requirement | scope-reduction |
+| Find paths around a fixed constraint to reach the same goal | workaround-mapping |
+
+## Routing Decision
+
+- **Constraint feels like it might be an assumption, habit, or politics** → hardness-testing
+- **Constraint is real but you want it to generate rather than block** → rule-inversion
+- **Scope has grown beyond what's actually needed** → scope-reduction
+- **Constraint is genuinely fixed and you need to route around it** → workaround-mapping
+- **Unclear** → hardness-testing first; most "constraints" dissolve under scrutiny
+
+## Confirm Direction
+
+After diagnosing which tool fits, present the recommendation before executing:
+
+> My read: **[diagnosed tool]** — one sentence on why it fits.
+
+- **A) Yes, run that tool**
+- **B) Show me all options** — list every skill in this category with one-line descriptions
+- **C) Quick version** — lighter-weight alternative for this situation, if one exists
+- **D) Re-diagnose** — describe the situation differently for a second read
+
+Wait for their selection before proceeding.
+
+---
+
+## Hardness Testing
+
+*Tests whether a stated constraint is real.*
+
+Ask: who said this was fixed? When was that decided, and under what conditions? Has anyone tested it recently? Classify the constraint: physical law (truly hard), technical limit (hard but may change), organizational rule (soft — someone could change it), habit or assumption (not a constraint at all). For soft constraints: what would it take to move them? The goal is to separate genuine limits from constraints that are merely convenient to accept.
+
+**Output:** Constraint classification (hard/soft/assumption), evidence for the classification, and for soft constraints: what it would take to move them.
+
+---
+
+## Rule Inversion
+
+*Flips a constraint into a creative driver.*
+
+Take the constraint and state it as a design requirement: "We must [constraint]." Now ask: what would a solution look like that didn't merely tolerate this limit but was actually *better because of it*? The constraint removes options — which remaining options does it make uniquely possible? Limitations forced some of the most interesting design decisions in history; they don't just restrict, they focus.
+
+**Output:** The constraint reframed as a requirement, 3-5 directions that only become possible under this constraint, and the most promising one to develop.
+
+---
+
+## Scope Reduction
+
+*Finds the minimum that satisfies the actual requirement.*
+
+Separate what is wanted from what is needed. For each element of the current scope: what is the actual job it does? Could that job be done more simply, or not done at all? Apply the question: if we had to deliver this in half the time/budget/scope, what would we cut first? Often the answer reveals which parts were never truly necessary. The minimum viable version is usually clearer than the full version.
+
+**Output:** The actual core requirement. Everything that can be removed. The simplest version that genuinely satisfies the need.
+
+---
+
+## Workaround Mapping
+
+*Finds paths around a fixed constraint without removing it.*
+
+Accept the constraint as fixed. Now map the solution space that exists within it: what can be done if this limit is permanent? Are there alternative routes to the same destination that don't require crossing this constraint? Are there partial solutions that get 80% of the value without hitting the limit at all? Routing around a constraint is often faster and more durable than trying to remove it.
+
+**Output:** Map of available paths given the fixed constraint, with effort and value estimates for each. The most viable workaround with reasoning.

package/skills/constraint-hardness-testing/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: constraint-hardness-testing
+description: "Tests whether a stated constraint is real — distinguishing genuine limits from assumptions, habits, or politics dressed as facts. Triggers: 'is this really a constraint', 'challenge the assumption', 'who says we can't', 'is this actually fixed', 'test the constraint'."
+---
+
+# Constraint Hardness Testing
+
+Organisations accumulate phantom constraints — rules that were real once and calcified, or
+beliefs that were never tested, or someone's preference that got repeated until it sounded
+like policy. This skill separates genuine limits from assumed ones before any energy is
+spent working around or accepting them.
+
+---
+
+## Your Process
+
+**Step 1: State the Constraint**
+Write it exactly as it's been stated or assumed. Don't clean it up — the imprecision is
+often where the phantom lives.
+
+**Step 2: Source It**
+Who said this constraint exists? When? Is the source a law or regulation, a signed contract,
+a technical impossibility, a leadership decision, a team preference, or unknown? The source
+determines the hardness ceiling.
+
+**Step 3: Consequence Test**
+What actually happens if this constraint is violated? State the consequence concretely. If
+the answer is "I'm not sure" or "someone would be unhappy," the constraint is not hard.
+Distinguish real consequences (fine, contract breach, system failure) from assumed ones
+(pushback, awkwardness, political cost).
+
+**Step 4: Precedent Check**
+Has anyone tried to change or violate this constraint before? What happened? No precedent
+often means no one has tested it — not that it can't be changed.
+
+**Step 5: Conditions Test**
+Under what circumstances would this constraint not apply? A truly hard constraint has no
+exceptions. If you can find a scenario where it wouldn't hold, the constraint is softer
+than stated.
+
+**Step 6: Classify**
+- **Hard**: real source, concrete consequence, no exceptions, precedent confirms
+- **Soft**: real but negotiable, consequence is political or preferential
+- **Assumed**: no clear source, untested consequence
+- **Outdated**: was once hard, circumstances have changed
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Real vs assumed verdict only** — classify each constraint without full analysis
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Constraint as stated:**
+> [Exact wording]
+
+**Source:** [Law/contract/technical/decision/preference/unknown] — [specific origin]
+
+**Consequence if violated:**
+> [Concrete statement] — Real / Assumed
+
+**Precedent:** [What happened when tested, or "untested"]
+
+**Conditions where it wouldn't apply:**
+> [If any]
+
+**Classification:** Hard / Soft / Assumed / Outdated
+
+**Recommended action:**
+
+| Classification | Action |
+|----------------|--------|
+| Hard | Accept — design around it |
+| Soft | Negotiate explicitly |
+| Assumed | Test it — ask the source directly |
+| Outdated | Challenge it — propose removal |
+
+---
+
+## Notes
+
+The most dangerous class is Assumed, because it looks like Hard. Before accepting any
+constraint that cannot be sourced precisely, treat it as Assumed and test it — the cost of
+testing is almost always lower than the cost of a permanent workaround.

package/skills/constraint-rule-inversion/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: constraint-rule-inversion
+description: "Flips a constraint into a creative driver — uses the limit as the generative force rather than working around it. Triggers: 'invert the constraint', 'use the limitation', 'constraint as feature', 'what if this limit was the requirement'."
+---
+
+# Constraint Rule Inversion
+
+Most constraints are treated as walls. This skill treats them as foundations. The limit that
+seems like an obstacle is often the thing that forces the insight — the moment you stop
+trying to work around it and start designing with it, better solutions appear.
+
+---
+
+## Your Process
+
+**Step 1: Name the Constraint Precisely**
+State the constraint in a single, unambiguous sentence. Vague constraints produce vague
+inversions. "We have no budget" is too loose. "We have $0 for external tooling for Q3" is
+something you can work with.
+
+**Step 2: Ask What the Constraint Forces**
+What does this constraint make you do that you'd otherwise avoid? What comfortable defaults
+does it eliminate? The constraint is doing work — what work?
+
+**Step 3: Invert — Restate as a Design Requirement**
+Convert the limit into a positive requirement: "must cost nothing" becomes "must work with
+only what we already have." The constraint is now the spec, not the problem.
+
+**Step 4: Generate Solutions That Only Work Because of the Constraint**
+Produce 3-5 solutions that are impossible or inferior without the constraint. These are not
+workarounds — they are solutions the constraint made visible.
+
+**Step 5: Select for Unexpected Value**
+Pick the solution where the constraint creates the most unexpected advantage — the one that
+would not have been found without the limit.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) One inversion only** — the single most powerful constraint flip
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Constraint (precise):**
+> [Single sentence, unambiguous]
+
+**Inverted form (as design requirement):**
+> [Positive restatement]
+
+**Solutions that use the constraint:**
+
+| # | Solution | Why it requires the constraint | Strength |
+|---|----------|-------------------------------|----------|
+| 1 | | | |
+| 2 | | | |
+| 3 | | | |
+
+**Most promising:**
+> [Solution name] — [1-2 sentences on why the constraint creates unexpected value here]
+
+---
+
+## Notes
+
+Every analogy breaks somewhere — so does every inversion. If the inverted form produces
+solutions that would work equally well without the constraint, the inversion wasn't deep
+enough. Go back to Step 2.

package/skills/constraint-scope-reduction/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: constraint-scope-reduction
+description: "Finds the minimum that satisfies the actual requirement — stripping everything wanted but not needed. Triggers: 'minimum viable', 'what's the minimum', 'strip this back', 'what do we actually need', 'scope reduction', 'simplify the requirement'."
+---
+
+# Constraint Scope Reduction
+
+Scope grows because wants accumulate alongside needs, and no one separates them. This skill
+forces that separation. The goal is not to build less — it is to find the version where
+every element is doing real work, and nothing is there because it sounded good in the
+planning meeting.
+
+---
+
+## Your Process
+
+**Step 1: State the Full Current Scope**
+List everything in the current plan, feature set, or requirement. Be complete — you can
+only strip what you've named.
+
+**Step 2: Find the Core Job**
+Ask: what is the single verb this must do? Not what it should do, what it must do. Strip
+all nouns and adjectives until only the job remains. "A user can complete a purchase" is a
+job. "A seamless, intuitive checkout experience" is not.
+
+**Step 3: Classify Each Element — Must or Want**
+For every element in scope: is it required for the core job (must) or desired beyond it
+(want)? Apply pressure to musts — if you removed it, would the core job fail?
+
+**Step 4: Remove All Wants and Test**
+Drop every want. Confirm: can the core job still be done? If yes, the wants were not load-
+bearing. If no, you've found a hidden must — reclassify and investigate why it felt optional.
+
+**Step 5: Simplify the Musts**
+For each must: is there a simpler way to achieve the same outcome? Simpler means fewer
+moving parts, less code, lower cost, or faster delivery — not necessarily less effort to
+design.
+
+**Step 6: State the Minimum Viable Version**
+Write the minimum scope in a single paragraph. It should be possible to build from this
+description without the original scope document.
+
+---
+
+## Human Check-in
+
+Before proceeding, ask the user:
+
+**How do you want to run this?**
+
+- **A) Full analysis** — complete all steps, reasoning shown throughout
+- **B) Key findings only** — bottom-line output, skip step-by-step detail
+- **C) Minimum viable scope only** — the smallest version that still satisfies the actual need
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Current scope:**
+> [Bulleted list of everything in scope]
+
+**Core job (the verb):**
+> [Single sentence]
+
+**Must vs Want classification:**
+
+| Element | Must / Want | Reason |
+|---------|-------------|--------|
+| | | |
+
+**What was removed and why it's safe to remove:**
+> [Brief list — each removal with one-line justification]
+
+**Minimum viable scope:**
+> [Single paragraph — buildable without further clarification]
+
+---
+
+## Notes
+
+The most common mistake is reclassifying wants as musts when pressure is applied. Challenge
+every must: "if we launched without this, what actually breaks?" The answer is usually
+"nothing breaks, someone would be annoyed."