@human-avatar/skills-for-humanity 1.0.0

package/skills/aesthetic-simplicity-analysis/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: aesthetic-simplicity-analysis
+description: "Finds the simpler version while preserving what matters — not arbitrary reduction, but finding the core and discarding what is not it. TRIGGERS: 'find the simple version', 'simplify this', 'what's the essence', 'less but better', 'strip it back', 'what could we remove'."
+---
+
+# Aesthetic Simplicity Analysis
+
+Simplicity is not minimalism for its own sake — it is the clarity that emerges when
+everything that obscures the essence has been removed. Most things accumulate layers:
+additions made under pressure, elements that hedge against edge cases, features added
+to satisfy someone who asked. The result is a thing that does everything adequately
+and nothing powerfully. This skill finds the core and tests what must stay, what can
+go, and what removal would actually cost.
+
+---
+
+## Your Process
+
+**Step 1: State the Thing and Its Purpose**
+What is it, and what is it supposed to do? Name the object — a strategy, product,
+message, design, process, argument — and state its job in one sentence. If the
+purpose isn't clear, clarifying it is the first act of simplification.
+
+**Step 2: Find the Essence**
+If you could keep only one thing — one idea, one element, one mechanism — and it had
+to carry the entire weight of the purpose, what would it be? State this as one
+sentence. This is the essence. Everything else in the analysis flows from whether
+it serves this or doesn't.
+
+**Step 3: Classify Each Element**
+Go through every component or layer. Assign each one of three classifications:
+- **Essence** — it is the core, or it expresses the core directly and powerfully
+- **Supporting the essence** — it helps the core do its job; without it the
+  essence is harder to access or less effective
+- **Obscuring the essence** — it dilutes the core, competes with it for attention,
+  or adds noise that the reader or user must filter out to reach what matters
+
+**Step 4: Remove and Reduce**
+Eliminate everything classified as obscuring. Reduce everything classified as
+supporting to the minimum required for the essence to land clearly. Each reduction
+is a decision — name what it costs and why that cost is acceptable.
+
+**Step 5: Test with What Remains**
+With the reduced set: can the essence be felt clearly? Does the version with less
+do the original job? If not, something was misclassified — a supporting element was
+actually doing more work than was visible. Revise and keep it.
+
+**Step 6: Name What Was Lost**
+What was removed, and what did each removal cost? Some removals are free — the
+element was noise that looked like signal. Some involve real trade-offs — the
+removed element served a secondary purpose worth acknowledging even if not worth
+keeping.
+
+---
+
+## 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) Removals only** — what can be cut while preserving what matters
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Essence:** [one sentence — the irreducible core of what this thing is and does]
+
+**Element Classification**
+
+| Element | Classification | Rationale |
+|---|---|---|
+| [component] | [essence / supporting / obscuring] | [why — what it does for the core] |
+
+**Simplified Version:** [what remains after removal and reduction]
+
+**What Was Lost**
+
+| Removed Element | What It Did | Acceptable Loss? |
+|---|---|---|
+| [element] | [secondary function] | [yes — free / yes — acceptable trade-off / no — reclassify] |
+
+**Verdict:** Does the simplified version deliver the essence clearly?
+[yes / partial — state what's still competing / no — revise classification]
+
+---
+
+## Notes
+
+The goal is not the shortest version but the clearest. A long thing can be simple if
+every part serves the essence. A short thing can be incoherent if it's just been cut
+without finding the core first. Simplicity is achieved when adding anything would be
+wrong, and removing anything would be a loss.

package/skills/analogy/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: analogy
+description: "Entry point for the analogy toolkit. Routes to the right analogy skill based on your situation. Use when you say 'analogy', 'is this like that', 'find a comparison', 'import a solution from elsewhere', 'fresh eyes on this', 'where does this metaphor break', or want analogical reasoning applied without knowing which specific tool fits."
+---
+
+# Analogy
+
+Applies analogical reasoning to any problem. Diagnoses what kind of analogy work is needed and applies the right tool.
+
+## Which tool fits
+
+| You need to... | Tool |
+|---|---|
+| Find where an existing analogy or metaphor breaks down | boundary-testing |
+| Import solutions from a completely different domain | domain-transfer |
+| Approach a problem through a different field's lens | perspective-shifting |
+| Test the structural correspondence between two situations | structure-mapping |
+
+## Routing Decision
+
+- **Already using an analogy and want to stress-test it** → boundary-testing
+- **Stuck on a problem, want to find who's solved something like it elsewhere** → domain-transfer
+- **Need fresh eyes from an expert in a different field** → perspective-shifting
+- **Want to know if two situations are genuinely structurally similar** → structure-mapping
+- **Unclear** → structure-mapping first (establishing the analogy rigorously), then boundary-testing (finding where it fails)
+
+---
+
+## 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.
+
+---
+
+## Boundary Testing
+
+*Finds where an analogy breaks down before it's relied upon.*
+
+Name the analogy explicitly: A is like B because [shared properties]. Now systematically test each dimension of the comparison. For each shared property: does it actually hold? What differences exist? Find the dimension where the analogy fails in a way that matters for the decision at hand. Analogies fail silently — the damage happens when decisions are made on a mapping that doesn't hold in the relevant dimension.
+
+**Output:** Analogy map (what holds, what doesn't), the specific dimension of failure, and what decisions should not rely on this analogy.
+
+---
+
+## Domain Transfer
+
+*Imports solutions from unrelated domains by finding structural similarities.*
+
+Name the core structure of the problem: what kind of challenge is this underneath the surface details? Search for domains that have solved structurally similar problems — often in completely unrelated fields (biology for network design, military strategy for resource constraints, jazz for improvisational systems). For each candidate domain: what was the solution? How does it map back?
+
+**Output:** Core problem structure, candidate domains with solved analogues, and specific solutions mapped back to the original problem.
+
+---
+
+## Perspective Shifting
+
+*Approaches a problem through a completely different field's lens.*
+
+Name the home domain — the expertise lens being applied by default. Now select 2-3 radically different fields: what would a [biologist / game designer / urban planner / etc.] see when looking at this? Apply each lens genuinely, not superficially. The goal is to surface assumptions invisible from inside the home domain.
+
+**Output:** Per-lens analysis — what each field notices, what assumptions it challenges, what solutions it suggests that the home domain wouldn't.
+
+---
+
+## Structure Mapping
+
+*Identifies the deep structural correspondence between two situations.*
+
+List the elements of situation A. List the elements of situation B. For each element in A: does a corresponding element exist in B? Are the relationships between elements preserved? Test whether the mapping is genuine isomorphism or just surface similarity. Surface similarity fails on deeper structure; genuine isomorphism predicts behavior accurately.
+
+**Output:** Element-by-element correspondence table, relationship preservation check, verdict on whether the analogy is structurally valid, and what the mapping predicts.

package/skills/analogy-boundary-testing/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: analogy-boundary-testing
+description: "Finds where an analogy breaks down before it's relied upon. Analogies fail silently — the damage happens when decisions are made on a mapping that doesn't hold in the relevant dimension. Triggers: 'stress-test this analogy', 'where does this comparison break', 'does this really apply', 'test the metaphor', 'where is the analogy wrong'."
+---
+
+# Analogy Boundary Testing
+
+Analogies are tools, not truths. The danger is not using an analogy — it is using one past
+its boundary. Analogies fail silently: the flaw is invisible until a decision has been made
+that depended on the part that didn't hold. This skill finds the boundary before that
+happens.
+
+---
+
+## Your Process
+
+**Step 1: State the Analogy**
+Write it explicitly: "X is like Y." Name the analogy being tested, the domain it comes
+from, and the claim being made on the basis of it.
+
+**Step 2: List Similarities**
+What does the analogy capture correctly? List every genuine parallel — the aspects where
+the structural correspondence is real. This is not validation; it's establishing what the
+analogy is good for before finding what it isn't.
+
+**Step 3: List Differences**
+Every meaningful divergence between X and Y is a potential failure point. List them
+systematically: different actors, different dynamics, different constraints, different
+feedback mechanisms, different scales, different reversibility. Be thorough — incomplete
+difference-listing is the most common failure mode here.
+
+**Step 4: Test Each Difference Against the Decision**
+For each decision or conclusion being made on the basis of this analogy: which differences
+are relevant to that specific decision? A difference that doesn't affect the conclusion is
+harmless. A difference that does affect it invalidates the reasoning.
+
+**Step 5: Does the Conclusion Still Hold?**
+For each relevant difference identified in Step 4: if this difference is real, does the
+conclusion derived from the analogy still follow? If not, the analogy cannot support that
+conclusion.
+
+**Step 6: State Safe Scope**
+Where can this analogy be validly relied upon? What does it illuminate, and what decisions
+can it inform? State the boundary clearly.
+
+---
+
+## 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) Breaking points only** — where the analogy fails, not where it holds
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Analogy:** [X is like Y — domain and claim]
+
+**Similarities (what the analogy captures correctly):**
+> [Bulleted list]
+
+**Differences (potential failure points):**
+> [Bulleted list — be thorough]
+
+**Relevant differences for this decision:**
+
+| Difference | Relevant to decision? | Effect on conclusion |
+|------------|----------------------|----------------------|
+| | | |
+| | | |
+
+**Conclusion validity:**
+> [Does the analogy support the conclusion? Yes / Partially / No — with reason]
+
+**Safe scope — what this analogy validly applies to:**
+> [Bounded statement]
+
+---
+
+## Notes
+
+The most useful output is the safe scope statement — a positive claim about where the
+analogy is reliable. Discarding an analogy entirely because it has limits wastes the
+genuine insight it contains.

package/skills/analogy-domain-transfer/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: analogy-domain-transfer
+description: "Imports solutions from unrelated domains by finding structural similarities between your problem and solved problems elsewhere. Triggers: 'cross-domain analogy', 'what solves this elsewhere', 'find a parallel problem', 'look outside this field', 'borrow a solution'."
+---
+
+# Analogy Domain Transfer
+
+Your field has blind spots that your field created. The best solutions to structural
+problems often exist already — in biology, military strategy, architecture, sport, logistics,
+emergency medicine — because the underlying problem is not domain-specific. The work is
+abstraction: strip away the domain details until the pattern is visible, then find where
+that pattern is already solved.
+
+---
+
+## Your Process
+
+**Step 1: Abstract the Problem to Structural Essence**
+Describe the problem without any domain vocabulary. What is actually happening? What are
+the actors, their relationships, the failure mode, the goal? The moment you can describe
+it without industry jargon, you can search for it anywhere.
+
+**Step 2: Search Candidate Domains**
+Consider where this structural pattern appears: biology (systems, adaptation, immunity),
+military (logistics, command, deception), architecture (load, flow, resilience), sport
+(coordination, pressure, strategy), gaming (rules, incentives, escalation), logistics
+(sequencing, bottlenecks, routing), medicine (diagnosis, triage, recovery).
+
+**Step 3: Extract the Core Mechanism**
+For each candidate domain: what is the actual mechanism that solves the problem? Not the
+surface story — the operational logic. How does it work, step by step?
+
+**Step 4: Map Mechanism Back**
+Translate the mechanism into your problem. What plays what role? What would be the
+equivalent of each element? This is where analogies either click or reveal themselves as
+superficial.
+
+**Step 5: Test Where the Analogy Holds and Breaks**
+Every analogy breaks somewhere. Where does the mechanism still work when mapped? Where does
+it stop working? The break points tell you where to be careful and where the insight ends.
+
+---
+
+## 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 domain transfer** — the single most structurally similar domain, fully developed
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Problem (abstracted — no domain vocabulary):**
+> [Structural description]
+
+**Candidate domains and mechanisms:**
+
+| Domain | Analogous problem | Core mechanism | Strength of match |
+|--------|------------------|----------------|-------------------|
+| | | | |
+| | | | |
+
+**Best mapping:**
+- Domain element → Your problem element (for each key pair)
+
+**Where the analogy holds:**
+> [Specific aspects]
+
+**Where the analogy breaks:**
+> [Specific aspects — don't skip this]
+
+**Insight to import:**
+> [The actionable mechanism translated back into your problem]
+
+---
+
+## Notes
+
+A weak abstraction in Step 1 produces weak domain matches. If the domains found feel
+obvious or already-familiar, the abstraction still contains domain assumptions — strip
+further.

package/skills/analogy-perspective-shifting/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: analogy-perspective-shifting
+description: "Approaches a problem from completely different fields to break the assumption blindness that comes from domain expertise. Triggers: 'fresh eyes', 'outside perspective', 'what would a [different expert] say', 'beginner's mind', 'approach from another field'."
+---
+
+# Analogy Perspective Shifting
+
+Domain expertise creates assumption blindness. The more you know about a field, the more
+invisible its foundational assumptions become — they stop looking like choices and start
+looking like facts. Bringing in genuine outsider perspectives breaks this. Not
+hypothetically — by actually applying the diagnostic instincts and tools of people who
+have never heard of your problem's usual framing.
+
+---
+
+## Your Process
+
+**Step 1: State the Problem**
+Describe the problem as you currently understand it. This is the insider framing — it will
+contain the assumptions you're trying to surface.
+
+**Step 2: Choose 2-3 Genuinely Different Fields**
+Select fields with fundamentally different training, tools, and instincts. For software
+problems: film production, archaeology, emergency medicine, urban planning. For
+organisational problems: ecology, military logistics, theatre direction, structural
+engineering. Avoid fields that are adjacent — choose fields that would produce different
+first questions.
+
+**Step 3: Build Each Expert's Toolkit**
+For each field: what are their core diagnostic tools and instincts? What do they always
+check first? What patterns are they trained to spot? What would their first question be
+when encountering an unknown problem?
+
+**Step 4: Apply Each Lens**
+Apply each expert's toolkit to your problem. What do they immediately notice that insiders
+overlook? What would they try first that you haven't? What would strike them as obviously
+wrong or unnecessarily complex? Don't moderate the outsider view — let it be naive.
+
+**Step 5: Find Cross-Field Patterns**
+What do multiple outsiders notice independently? When different fields converge on the
+same observation, that observation has a strong claim to being real — it's visible from
+multiple angles, not an artefact of one framing.
+
+---
+
+## 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) Shifted perspective only** — the view from the new field, skip the formal structural mapping
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Problem (insider framing):**
+> [Current description]
+
+**Field perspectives:**
+
+| Field | Core instincts / tools | What they notice | What they'd try first |
+|-------|------------------------|------------------|-----------------------|
+| | | | |
+| | | | |
+
+**Cross-field patterns (what multiple outsiders see):**
+> [Observations that appear across more than one field]
+
+**Most useful foreign insight:**
+> [The single observation or approach from outside that would most change how you work
+> the problem — and why it's been invisible from inside]
+
+---
+
+## Notes
+
+The exercise fails if the "outside" perspectives are just your own reasoning relabelled.
+Each field's observations should surprise you. If they don't, you haven't actually left
+your frame — you've just dressed it in different vocabulary.

package/skills/analogy-structure-mapping/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: analogy-structure-mapping
+description: "Identifies the deep structural correspondence between two situations — genuine isomorphism vs superficial similarity. Triggers: 'does this analogy hold', 'map the structure', 'is this really like that', 'structural similarity', 'test the comparison'."
+---
+
+# Analogy Structure Mapping
+
+Analogies are persuasive but often wrong. The surface similarity that makes a comparison
+feel apt can obscure structural differences that make it invalid. This skill maps the deep
+structure of both situations and checks correspondence element by element — distinguishing
+genuine isomorphism (same structure, different content) from superficial similarity (same
+surface, different structure).
+
+---
+
+## Your Process
+
+**Step 1: State the Two Situations**
+Write Situation A and Situation B clearly. State the analogy as claimed: "A is like B
+because..."
+
+**Step 2: Extract Structure of Each**
+For each situation independently, map: key actors, their relationships, the dynamics
+(what drives change), the constraints (what limits action), and the goals (what success
+looks like). Do this for each situation before comparing — comparison before extraction
+introduces bias.
+
+**Step 3: Map Elements A to B**
+For each structural element in A, identify the corresponding element in B. State the
+mapping explicitly: "In A, X plays the role of Y in B."
+
+**Step 4: Classify Each Mapped Pair**
+For each mapped pair: is the correspondence genuine (same structural role, same
+relationship type, same dynamics) or superficial (same label or surface feature, different
+structural role)?
+
+**Step 5: Find Where the Mapping Breaks**
+Every analogy breaks somewhere — this is not a failure, it is where the analysis becomes
+useful. Which differences are structurally significant? Which make the analogy unreliable
+for the specific prediction or decision being made?
+
+**Step 6: State Valid Predictions and Invalid Ones**
+Based on where the mapping holds and where it breaks, state what the analogy validly
+predicts and what it cannot be relied upon to predict.
+
+---
+
+## 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) Structural differences only** — where the two situations diverge, not where they align
+- **D) Refine the framing** — adjust what we're analyzing before starting
+
+Proceed based on their choice.
+
+## Output Format
+
+**Situation A structure:** [actors / relationships / dynamics / constraints / goals]
+**Situation B structure:** [actors / relationships / dynamics / constraints / goals]
+
+**Element mapping:**
+
+| Element in A | Corresponding element in B | Genuine / Superficial | Reason |
+|-------------|---------------------------|----------------------|--------|
+| | | | |
+| | | | |
+
+**Where the mapping breaks:**
+> [Specific structural differences and why they matter]
+
+**Valid predictions (analogy holds):**
+> [What can be reliably inferred from B about A]
+
+**Invalid predictions (analogy breaks):**
+> [What cannot be inferred — where relying on the analogy would mislead]
+
+---
+
+## Notes
+
+Genuine structural correspondence requires that the relationship between elements matches —
+not just that individual elements can be paired. Two things can share every node and differ
+entirely on the edges that connect them.

package/skills/communication/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: communication
+description: "Entry point for the communication toolkit. Routes to the right communication skill based on your situation. Use when you say 'communication', 'how do I say this', 'will this land', 'which channel', 'what will they push back on', 'does this make sense', or want communication help without knowing which specific tool fits."
+---
+
+# Communication
+
+Applies communication thinking to any message, proposal, or delivery decision. Diagnoses what kind of communication problem this is and applies the right tool.
+
+## Which tool fits
+
+| You need to... | Tool |
+|---|---|
+| Understand what your audience actually believes and cares about | audience-modeling |
+| Find where a message will be misread or lost before sending | clarity-audit |
+| Choose the right channel and format for the message | medium-selection |
+| Anticipate and pre-address likely objections | objection-mapping |
+
+## Routing Decision
+
+- **Don't know your audience well or why they're not getting it** → audience-modeling
+- **Have a draft and want to find where it breaks** → clarity-audit
+- **Unsure whether to email, meet, async, sync, document** → medium-selection
+- **About to present something contentious and need to prepare** → objection-mapping
+- **Unclear** → audience-modeling first; communication fails at the receiver, not the sender
+
+## 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.
+
+---
+
+## Audience Modeling
+
+*Maps what the audience currently believes, actually cares about, and fears.*
+
+Build a model of the audience before communicating. What do they already believe about this topic? What are their real goals (often different from their stated role)? What do they fear — about the message, the change, the consequences? What would need to be true for them to change their mind or take action? Communication fails not because the message is unclear, but because the sender doesn't model the receiver.
+
+**Output:** Audience belief map, real goals, fears, and the threshold conditions for a positive response.
+
+---
+
+## Clarity Audit
+
+*Finds where a message will be lost, misread, or misunderstood.*
+
+Read the message as if you have no prior context. Where does it assume knowledge the reader may not have? Where could a word or phrase be interpreted differently? Where does structure obscure the point? Where is the ask buried or implicit? For each problem: classify as ambiguity (multiple valid interpretations), assumption (missing context), or structure (the architecture hides the message).
+
+**Output:** Annotated list of clarity problems, classified by type, with specific rewrites for each.
+
+---
+
+## Medium Selection
+
+*Matches the message to the right channel and format.*
+
+Assess the message against four dimensions: (1) complexity — does understanding require dialogue, or is the content self-contained? (2) tone — does this carry emotional weight requiring presence? (3) record — does this need to be findable later? (4) urgency — how time-sensitive is the response? Map these against available channels. The same content in the wrong medium loses most of its effect — an async message that needed presence, or a meeting that needed a document.
+
+**Output:** Recommended channel with reasoning, format within that channel, and what to avoid.
+
+---
+
+## Objection Mapping
+
+*Maps likely objections before delivering a proposal.*
+
+List all stakeholders who will encounter this proposal. For each: what is their likely first objection? What's the deeper concern beneath it? Now assess each objection: is it addressable by changing the proposal, addressable by framing, or genuinely unresolvable? Objections anticipated feel addressed; objections that arrive as surprises derail.
+
+**Output:** Objection map — stakeholder, surface objection, underlying concern, and how to address it. Flags unresolvable objections the presenter must prepare for.