@unified-product-graph/mcp-server 0.8.0 → 0.8.2

package/skills/{upg-init → upg-new-graph}/SKILL.md

@@ -1,12 +1,12 @@
 ---
-name: upg-init
+name: upg-new-graph
 description: "Initialize a UPG Product Graph"
 user-invocable: true
 argument-hint: "[description]"
 category: tooling
 ---
 
-# /upg-init: Initialize a Unified Product Graph
+# /upg-new-graph: Initialize a Unified Product Graph
 
 You are a product discovery guide. Your job is to help the user bootstrap a well-structured product graph through a conversational discovery process.
 
@@ -29,6 +29,8 @@ Display as: **"Phase 2 of 4: Your user"**
 
 Use the `mcp__unified-product-graph__*` MCP tools (create_node, create_edge, get_product_context, search_nodes).
 
+> **MCP-first (applies to every create below).** Before creating any entity (product, persona, desired outcome, job, need, outcome, metric, hypothesis), call `get_entity_schema(<type>)`. Build `properties` from its `expected_properties`, set `status` **top-level** from one of the lifecycle phases the schema returns (don't hard-code the status enum), and pass any assessment as `{ value, label }`. For the chain children under a persona, confirm the valid child types with `get_valid_children("persona")`. Before any edge, call `resolve_edge_for_pair({ source_type, target_type })` and let the server infer the edge type. The payloads below show shape and intent; the authoritative keys, phases, and stage values come from the schema/spec at runtime.
+
 ## CRITICAL RULES
 
 ### Rule 1: One Question Per Message
@@ -88,41 +90,47 @@ STOP. Wait for the answer.
 Ask: **"How far along is <product name>?"**
 
 ```
-1. 💭 Idea; still figuring it out
-2. 🛠️ MVP; building the first version
-3. 📈 Growth; product exists, finding scale
-4. 🏗️ Scale; established, optimizing
+1. 💭 Concept; still figuring it out
+2. 🔬 Validation; testing demand before building
+3. 🛠️ Build; building the first version
+4. 🧪 Beta; early users, iterating
+5. 🚀 Launch; generally available
+6. 📈 Growth; scaling users and revenue
+7. 🏗️ Mature; established, optimizing
 ```
 
-STOP. Wait. Then create the product node:
+Map the answer to a canonical product-stage value. **Don't hard-code the stage enum**: call `list_product_stages` (or read the `stage` property off `get_entity_schema("product")`) for the current valid values, and pick the one matching the user's answer. STOP. Wait. Then create the product node:
 
 ```
+// Read get_entity_schema("product") / list_product_stages first, then:
 create_node({
   type: "product",
   title: "<name>",
   description: "<their vision one-liner>",
-  properties: { stage: "<stage>" }
+  properties: { stage: "<canonical stage from list_product_stages>" }
 })
 ```
 
+Pass a canonical stage value — `create_node` (like `create_product`) rejects non-canonical values; the live list is the source of truth.
+
 Confirm: "🎯 **<Product Name>** is in the graph." Then move to Step 1d.
 
 ### Step 1d: Lens (infer, don't ask)
 
-**Do not ask about lenses.** Infer the lens from what the user said about their product and role:
+**Do not ask about lenses.** Infer the lens from what the user said about their product and role. **Fetch the valid lens ids first** with `list_lenses` (don't assume the id strings) and match intent to one of them:
 
-- They mentioned bugs, services, APIs, architecture, or called themselves an engineer → set `engineering`
-- They mentioned screens, components, flows, or called themselves a designer → set `design`
-- They mentioned funnels, channels, campaigns, or growth → set `growth`
-- Otherwise → default to `product`
+- Engineering signals (bugs, services, APIs, architecture, "I'm an engineer") → the engineering lens
+- Design signals (screens, components, flows, "I'm a designer") → the design/UX lens id `list_lenses` returns
+- Growth signals (funnels, channels, campaigns) → the growth lens
+- Otherwise → the default product lens
 
-Set silently:
+Set silently (using the exact id from `list_lenses`):
 
 ```
 update_session_context({ lens: "<inferred_lens>" })
 ```
 
-No confirmation needed. The user discovers lenses naturally through `/upg` or `/upg-status` later. Cold-start users don't need lens vocabulary on their first run.
+No confirmation needed. The user discovers lenses naturally through `/upg` or `/upg-show-status` later. Cold-start users don't need lens vocabulary on their first run.
 
 ### Step 2: Persona: Who
 
@@ -158,7 +166,7 @@ STOP. Wait for the answer.
 
 ### Step 2c: Persona: Desired Outcomes
 
-> **v0.2 chain model:** desired outcomes are SEPARATE nodes connected to the persona via `persona_aspires_to_desired_outcome`. Never inline them as a `goals` array on the persona.
+> **Chain model:** desired outcomes are SEPARATE nodes connected to the persona (resolve the edge with `resolve_edge_for_pair` at create time). Never inline them as a `goals` array on the persona.
 
 Ask: **"What outcomes is <Name> trying to achieve? What does success look like for them?"**
 
@@ -193,7 +201,7 @@ STOP. Wait for the answer.
 
 ### Step 2e: Persona: Needs
 
-> **v0.2 chain model:** needs are SEPARATE nodes connected via `persona_experiences_need`. Never inline as a `frustrations` array.
+> **Chain model:** needs are SEPARATE nodes connected to the persona (resolve the edge with `resolve_edge_for_pair` at create time). Never inline as a `frustrations` array.
 
 Ask: **"What gets in <Name>'s way today? What needs does your product address; the frustrations or unmet demands driving them to look for a solution?"**
 
@@ -213,60 +221,31 @@ STOP. Wait.
 
 **Vibe check:** Before creating, show a brief summary and ask: "Here's what I've captured about **<Name>**: anything you'd change?"
 
-Then create the persona node with canonical v0.2 properties only; `context`, `is_primary`, `experience_level`, `motivation`, `tech_comfort`, `domain_expertise`. **Never set `goals` or `frustrations` on the persona**: those are separate nodes connected by edges:
+Then create the persona node. **Read `get_entity_schema("persona")` first** and build `properties` from its `expected_properties` (don't assume a fixed allowlist). **Never set `goals` or `frustrations` on the persona**: those are separate chain nodes connected by edges. Confirm the chain child types with `get_valid_children("persona")` and resolve each edge with `resolve_edge_for_pair`:
 
 ```
-// 1. Create the persona (canonical v0.2 properties only)
+// 1. Create the persona — properties from get_entity_schema("persona")
 create_node({
   type: "persona",
   title: "<Name>; <Role>",
   description: "<narrative combining context and motivation>",
-  properties: {
-    context: "<their world>",
-    motivation: "<what drives them>"
-  },
+  properties: { /* keys from the schema, e.g. context, motivation */ },
   parent_id: "<product_id>"
 })
 // → persona_id = result.node.id
 
-// 2. For each desired outcome the user picked:
-create_node({
-  type: "desired_outcome",
-  title: "<outcome statement>",
-  description: "<why this outcome matters to them>",
-  parent_id: "<persona_id>"
-})
-create_edge({
-  source_id: "<persona_id>",
-  target_id: "<desired_outcome_id>",
-  type: "persona_aspires_to_desired_outcome"
-})
+// 2. For each desired outcome — child type from get_valid_children("persona"),
+//    edge from resolve_edge_for_pair({ source_type: "persona", target_type: <child> }):
+create_node({ /* type from schema */ title: "<outcome>", parent_id: "<persona_id>" })
+create_edge({ source_id: "<persona_id>", target_id: "<child_id>" })  // server infers type
 
-// 3. Create the job node (the domain anchor)
-create_node({
-  type: "job",
-  title: "<concise job statement>",
-  description: "<When I… I want to… So I can… statement>",
-  parent_id: "<persona_id>"
-})
-create_edge({
-  source_id: "<persona_id>",
-  target_id: "<job_id>",
-  type: "persona_pursues_job"
-})
+// 3. Create the job node (the domain anchor) — read its schema first:
+create_node({ type: "job", title: "<concise job statement>", parent_id: "<persona_id>" })
+create_edge({ source_id: "<persona_id>", target_id: "<job_id>" })  // server infers type
 
-// 4. For each need the user picked:
-create_node({
-  type: "need",
-  title: "<need statement>",
-  description: "<the specific frustration or unmet demand>",
-  parent_id: "<persona_id>"
-})
-create_edge({
-  source_id: "<persona_id>",
-  target_id: "<need_id>",
-  type: "persona_experiences_need"
-})
+// 4. For each need — same pattern (child type + edge resolved live):
+create_node({ /* need type from schema */ title: "<need statement>", parent_id: "<persona_id>" })
+create_edge({ source_id: "<persona_id>", target_id: "<need_id>" })  // server infers type
 ```
 
 Tip: for 3+ chain nodes, use `batch_create_nodes` with `parent_ref: "$0"` chaining instead of N individual `create_node` calls.
@@ -297,6 +276,7 @@ Offer outcome options based on the product vision and persona:
 STOP. Wait. Then create the outcome:
 
 ```
+// Read get_entity_schema("outcome") first, then:
 create_node({
   type: "outcome",
   title: "<measurable outcome>",
@@ -318,18 +298,13 @@ Offer metric options relevant to the outcome:
 4. Different metric; what would you track?
 ```
 
-STOP. Wait. Create the KPI (as a `metric` node with `designation: "kpi"`):
+STOP. Wait. Create the KPI as a `metric` node. Read `get_entity_schema("metric")` first and build `properties` from its keys (the KPI designation, current/target value, unit):
 
 ```
 create_node({
   type: "metric",
   title: "<metric name>",
-  properties: {
-    designation: "kpi",
-    current_value: <if known>,
-    target_value: <if known>,
-    unit: "<e.g. %, users, seconds>"
-  },
+  properties: { /* keys from the schema; mark this metric as a KPI per its designation property */ },
   parent_id: "<outcome_id>"
 })
 ```
@@ -349,18 +324,14 @@ Offer hypothesis options based on everything so far:
 4. Different bet; what do you believe will work?
 ```
 
-STOP. Wait. Create the hypothesis:
+STOP. Wait. Create the hypothesis. Read `get_entity_schema("hypothesis")` first; build `properties` from its keys and set `status` top-level from its first lifecycle (draft) phase:
 
 ```
 create_node({
   type: "hypothesis",
   title: "<concise hypothesis>",
-  properties: {
-    we_believe: "<the change>",
-    will_result_in: "<the expected outcome>",
-    we_know_when: "<the success signal>",
-    status: "untested"
-  },
+  status: "<draft phase from the schema>",
+  properties: { /* keys from the schema: we-believe / will-result-in / we-know-when */ },
   parent_id: "<outcome_id>"
 })
 ```
@@ -377,13 +348,13 @@ Display what was created as an indented tree with entity type emojis:
 🎯 <name> (<stage>)
 ├─ 👤 <persona name>
 │  │  Context: <context>
-│  ├─ 🎯 <desired outcome>             (persona_aspires_to_desired_outcome)
-│  ├─ 💼 <job>                          (persona_pursues_job)
-│  └─ ⚡ <need>                          (persona_experiences_need)
+│  ├─ 🎯 <desired outcome>
+│  ├─ 💼 <job>
+│  └─ ⚡ <need>
 ├─ 🎯 <outcome>
 │  └─ 📊 <metric> (<current> → <target>)
-├─ ⚗️ <h1>                                    ⚪ untested
-└─ ⚗️ <h2>                                    ⚪ untested
+├─ ⚗️ <h1>                                    ⚪ <draft phase>
+└─ ⚗️ <h2>                                    ⚪ <draft phase>
 ```
 
 ## Close with Smart Ending
@@ -394,11 +365,8 @@ Check the graph for the biggest gap across the 8 business areas (Identity, Under
 
 > Based on what we built, your biggest gap is **[area]**. I'd suggest running `/upg-[skill]` next to [reason].
 >
-> Or run `/upg-journey` to see where you are in the bigger picture.
+> Or run `/upg-show-journey` to see where you are in the bigger picture.
 
-┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
-Your `.upg` file is yours: open standard, portable, git-friendly.
-unifiedproductgraph.org
 
 ## Key Principles
 

package/skills/{upg-hypothesis → upg-new-hypothesis}/SKILL.md

@@ -1,16 +1,16 @@
 ---
-name: upg-hypothesis
+name: upg-new-hypothesis
 description: "Structured Hypothesis Creation"
 user-invocable: true
 argument-hint: "[description]"
 category: cognitive
 approaches: [plan]
-playbooks: [discovery-validation-hypothesis-cycle]
+playbooks: [playbook:discovery-research-validation]
 ---
 
-# /upg-hypothesis: Structured Hypothesis Creation
+# /upg-new-hypothesis: Structured Hypothesis Creation
 
-Note: In user-facing conversation, use "bet" or "design experiment" instead of "hypothesis"; the word triggers "formal/academic" anxiety for non-PM users. The canonical entity type is `hypothesis` (re-promoted at v0.4.0; the "claim" suffix was redundant). Evidence attaches via `hypothesis_has_evidence` with `evidence.direction` carrying supports/refutes/neutral.
+Note: In user-facing conversation, use "bet" or "design experiment" instead of "hypothesis"; the word triggers "formal/academic" anxiety for non-PM users. The canonical entity type is `hypothesis`. Evidence attaches via the edge `resolve_edge_for_pair` returns for the hypothesis→evidence pair, with the evidence node's direction carrying supports/refutes/neutral.
 
 You are a Unified Product Graph validation specialist. Your job is to guide the user through creating a well-structured hypothesis using the "We believe / Will result in / We know when" format, then help them design an experiment to test it.
 
@@ -80,7 +80,7 @@ This should be falsifiable:
 
 Ask: **"What's the riskiest assumption in this hypothesis? What's the one thing that, if wrong, kills the whole bet?"**
 
-Use this to set the `we_test_by` property and to inform experiment design.
+Use this to set the `risk_if_wrong` property and to inform experiment design. (The legacy `we_test_by` property was dropped in v0.2.8.)
 
 ### Step 3b: Vibe Check and Thresholds
 
@@ -94,39 +94,33 @@ Then ask for success/failure thresholds: "What would convince you this is workin
 - If the hypothesis relates to an opportunity: ask "Does a solution already exist for this opportunity? If not, should I create one first?" Wait for the answer. If yes, create the solution node first, then attach the hypothesis to the solution.
 - The hierarchy is: opportunity → solution → hypothesis. Don't skip the solution layer.
 
+**MCP-first.** Call `get_entity_schema("hypothesis")` before creating. Build `properties` from its `expected_properties` (the "We believe / Will result in / We know when / riskiest assumption" answers map onto those keys), and set `status` **top-level** (not inside `properties`) using one of the lifecycle phases the schema returns. Don't hard-code the status enum or property keys from memory; the schema is the source of truth.
+
 ```
+// Read get_entity_schema("hypothesis") first, then:
 create_node({
   type: "hypothesis",
   title: "<concise hypothesis; e.g. 'Onboarding wizard reduces Day-1 drop-off'>",
   description: "<full narrative combining all three parts>",
-  properties: {
-    we_believe: "<the change>",
-    will_result_in: "<the measurable outcome>",
-    we_know_when: "<the success signal and threshold>",
-  },
-  // Canonical lifecycle on UPGBaseNode.status (top-level, not in properties).
-  // hypothesis enum: drafted | active | validated | invalidated | archived.
-  // The legacy `we_test_by` property dropped in v0.2.8; experimental method
-  // now lives on the linked experiment_plan via `hypothesis_requires_experiment_plan`.
-  status: "drafted"
+  properties: { /* keys from get_entity_schema("hypothesis").expected_properties */ },
+  status: "<first lifecycle phase from the schema; typically the draft phase>"
 })
 ```
 
 Connect to a parent. The canonical OST chain is
-**opportunity → solution → hypothesis**. There is no canonical
-`opportunity → hypothesis` edge by design; solutions are the
-articulated *approach* the hypothesis tests. If the user has named an
-opportunity but no solution yet, surface a one-liner solution first
-(`opportunity_drives_solution`), then attach the hypothesis to that
-solution via `solution_proposes_hypothesis`.
+**opportunity → solution → hypothesis**: solutions are the
+articulated *approach* the hypothesis tests, so attach the hypothesis to a
+solution rather than directly to an opportunity. If the user named an
+opportunity but no solution yet, surface a one-liner solution first, then
+attach the hypothesis to that solution.
 
-- If related to a `solution` → use the `solution_proposes_hypothesis` edge (or `parent_id: <solution_id>` for parent_ref auto-chaining).
-- If related to an `opportunity` → create the intermediate solution first, then attach the hypothesis to that solution. Do not skip the solution layer.
+- Resolve every link with `resolve_edge_for_pair({ source_type, target_type })` (e.g. `opportunity`→`solution`, then `solution`→`hypothesis`) and let the server infer the edge type, or use `parent_id: <solution_id>` for parent_ref auto-chaining.
+- Do not skip the solution layer when starting from an opportunity.
 
 ### Step 5: Show the Result
 
 ```
-### ⚗️ <Title>                                    ⚪ untested
+### ⚗️ <Title>                                    ⚪ drafted
 
 **We believe that** <the change>
 **will result in** <the measurable outcome>.
@@ -152,20 +146,17 @@ Offer experiment templates based on context:
 | "The market is big enough" | Market sizing research, competitor analysis |
 | "Users will trust/adopt this" | A/B test with behavioral tracking or longitudinal usage study |
 
-If they describe an experiment, create it:
+If they describe an experiment, create it as the canonical test-plan type a hypothesis links to (a later run-type entity records the actual execution). Find that child type via `get_valid_children("hypothesis")`, then **call `get_entity_schema(<that type>)`** before writing: drive `properties` from its `expected_properties` and set `status` top-level from its lifecycle phases.
 
 ```
+// Read get_entity_schema for the experiment-plan type first, then:
 create_node({
-  type: "experiment",
+  type: "<experiment-plan type from get_valid_children('hypothesis')>",
   title: "<experiment name>",
   description: "<what we're testing and how>",
-  properties: {
-    method: "<e.g. A/B test, usability test, fake door>",
-    status: "planned",
-    start_date: "<if known>",
-    end_date: "<if known>"
-  },
-  parent_id: "<hypothesis_id>"  // auto-creates hypothesis_has_experiment edge
+  status: "<draft phase from the schema>",
+  properties: { /* keys from the schema: method, success criteria, dates, etc. */ },
+  parent_id: "<hypothesis_id>"  // parent_ref auto-chains the canonical edge
 })
 ```
 
@@ -175,16 +166,16 @@ Check the graph for the biggest gap across the 8 business areas. Recommend ONE n
 
 > Based on what we built, your biggest gap is **[area]**. I'd suggest running `/upg-[skill]` next to [reason].
 >
-> Or run `/upg-journey` to see where you are in the bigger picture.
+> Or run `/upg-show-journey` to see where you are in the bigger picture.
 
 After rendering your recommendation, call:
-`update_session_context({ skill_invoked: "upg-hypothesis", recommendation: "<the next skill you recommended>" })`
+`update_session_context({ skill_invoked: "upg-new-hypothesis", recommendation: "<the next skill you recommended>" })`
 
 ## Key Principles
 
 - **Hypotheses must be falsifiable.** If there's no way to prove it wrong, it's not a hypothesis; it's a wish.
 - **Specificity matters.** "Better retention" is not a hypothesis. "25% reduction in Day-7 churn for users who complete onboarding" is.
-- **Status starts at "untested".** Don't let anyone claim "validated" without evidence from a 🧪 experiment.
+- **Status starts at the draft phase** (read it from `get_entity_schema("hypothesis")`). Don't let anyone claim a validated phase without evidence from a 🧪 experiment.
 - **Follow the design system.** Entity emojis, score dots, filled bars, dashed dividers as defined in /upg-context.
 - **The riskiest assumption is the experiment target.** Don't test what's easy; test what's uncertain.
 - **Always bridge to experiment.** A ⚗️ hypothesis without a 🧪 experiment plan is just a conversation.

package/skills/{upg-launch → upg-new-launch}/SKILL-DETAIL.md

@@ -1,12 +1,14 @@
 ---
 name: upg-launch-detail
-description: "Detailed discovery flow steps for /upg-launch"
+description: "Detailed discovery flow steps for /upg-new-launch"
 ---
 
-# /upg-launch: Discovery Flow (Detail)
+# /upg-new-launch: Discovery Flow (Detail)
 
 Loaded on demand when entering the guided launch planning flow.
 
+> **MCP-first (applies to every create below).** Before creating any entity (GTM strategy, ICP, positioning, messaging, launch, acquisition channel, content strategy), call `get_entity_schema(<type>)`. Build `properties` from its `expected_properties`, set `status` **top-level** from one of the lifecycle phases the schema returns (don't hard-code the status enum), and pass any assessment as `{ value, label }`. Before any edge, call `resolve_edge_for_pair({ source_type, target_type })`: if it returns an edge, create it without an explicit `type:` (server infers); if it returns `null`, keep the relationship implicit (shared `parent_id`) rather than inventing an edge. The payloads below show shape and intent; the authoritative keys and phases come from the schema.
+
 ## Discovery Flow
 
 ### Starting Up
@@ -19,7 +21,7 @@ First, call `get_product_context` to understand the existing graph. Look for:
 - Features and releases (what's being launched)
 - Competitors (positioning context)
 
-If the user passed an argument (e.g., `/upg-launch beta release`), use it as context and jump straight into Step 1 with tailored options.
+If the user passed an argument (e.g., `/upg-new-launch beta release`), use it as context and jump straight into Step 1 with tailored options.
 
 ### Step 1: What Are You Launching?
 
@@ -43,27 +45,17 @@ STOP. Wait for the answer.
 Create the GTM strategy container:
 
 ```
+// Read get_entity_schema("gtm_strategy") first, then:
 create_node({
   type: "gtm_strategy",
   title: "<Product Name> GTM; <launch description>",
   description: "<what's being launched and why now>",
-  properties: {
-    launch_type: "<new_product | feature | release | pricing | expansion>",
-    target_date: "<if discussed>"
-  },
+  properties: { /* keys from the schema, e.g. launch type, target date */ },
   parent_id: "<product_id>"
 })
 ```
 
-If an existing feature or release was selected, create an edge:
-
-```
-create_edge({
-  source_id: "<gtm_strategy_id>",
-  target_id: "<feature_or_release_id>",
-  type: "launches"
-})
-```
+If an existing feature or release was selected, link them through a `launch` entity rather than the GTM strategy directly: resolve the GTM-strategy→launch edge with `resolve_edge_for_pair`, and the launch then relates to the feature/release it ships. Always confirm a pair has a canonical edge via `resolve_edge_for_pair` before connecting; if it returns `null`, note the relationship in the description rather than inventing an edge.
 
 Confirm: "📣 **GTM strategy started** for <launch description>."
 
@@ -75,8 +67,8 @@ Check for existing personas, ICPs, and market segments. Offer options:
 
 ```
 1. <existing persona>; they're the primary audience
-2. <existing ICP from `/upg-explore market_intelligence`>; launch to the beachhead
-3. <existing customer segment from `/upg-explore business_model`>; the paying segment
+2. <existing ICP from `/upg-walk-region market_intelligence`>; launch to the beachhead
+3. <existing customer segment from `/upg-walk-region business_model`>; the paying segment
 4. A new audience; <suggest based on launch type>
 5. Different audience; tell me who this is for
 6. Not sure yet; we can skip this or come back to it
@@ -87,28 +79,21 @@ STOP. Wait for the answer.
 If they pick an existing entity, create an edge. If new, create an ICP:
 
 ```
+// Read get_entity_schema("ideal_customer_profile") first, then:
 create_node({
   type: "ideal_customer_profile",
   title: "<ICP name>",
   description: "<who they are, why they care about this launch>",
-  properties: {
-    characteristics: ["<trait 1>", "<trait 2>", "<trait 3>"],
-    pain_level: "<how badly they need this>",
-    awareness: "<aware of problem | aware of solutions | aware of you>",
-    buying_stage: "<problem_aware | solution_aware | product_aware | most_aware>"
-  },
+  properties: { /* keys from the schema, e.g. characteristics, pain level, awareness, buying stage */ },
   parent_id: "<gtm_strategy_id>"
 })
 ```
 
-Connect to existing persona if relevant:
+Connect to existing persona if relevant; resolve the edge first:
 
 ```
-create_edge({
-  source_id: "<icp_id>",
-  target_id: "<persona_id>",
-  type: "represents"
-})
+// edge = resolve_edge_for_pair({ source_type: "ideal_customer_profile", target_type: "persona" })
+create_edge({ source_id: "<icp_id>", target_id: "<persona_id>" })  // server infers type
 ```
 
 Confirm: "🎯 **<ICP Name>** is the launch audience."
@@ -135,29 +120,21 @@ STOP. Wait for the answer.
 Create the positioning entity:
 
 ```
+// Read get_entity_schema("positioning") first, then:
 create_node({
   type: "positioning",
   title: "<positioning statement>",
   description: "<expanded positioning narrative>",
-  properties: {
-    framework: "<category | problem | competitive | new_category>",
-    for_who: "<target audience>",
-    unlike: "<the alternative or status quo>",
-    we_are: "<what you are>",
-    because: "<key differentiator>"
-  },
+  properties: { /* keys from the schema, e.g. framework, for-who, unlike, we-are, because */ },
   parent_id: "<gtm_strategy_id>"
 })
 ```
 
-If competitors exist in the graph, create edges:
+If competitors exist in the graph, resolve the edge first:
 
 ```
-create_edge({
-  source_id: "<positioning_id>",
-  target_id: "<competitor_id>",
-  type: "differentiates_from"
-})
+// edge = resolve_edge_for_pair({ source_type: "positioning", target_type: "competitor" })
+create_edge({ source_id: "<positioning_id>", target_id: "<competitor_id>" })  // server infers type
 ```
 
 Confirm: "🎯 **Positioning locked in**: <brief summary>."
@@ -182,29 +159,17 @@ STOP. Wait for the answer.
 Create the messaging entity:
 
 ```
+// Read get_entity_schema("messaging") first, then:
 create_node({
   type: "messaging",
   title: "<headline message>",
   description: "<expanded messaging; the full narrative>",
-  properties: {
-    headline: "<the one-liner>",
-    subheadline: "<supporting detail>",
-    proof_points: ["<proof 1>", "<proof 2>", "<proof 3>"],
-    tone: "<inspiring | practical | bold | reassuring | playful>"
-  },
+  properties: { /* keys from the schema, e.g. headline, subheadline, proof points, tone */ },
   parent_id: "<gtm_strategy_id>"
 })
 ```
 
-Connect to positioning:
-
-```
-create_edge({
-  source_id: "<messaging_id>",
-  target_id: "<positioning_id>",
-  type: "expresses"
-})
-```
+Connect to positioning only if a canonical edge exists: call `resolve_edge_for_pair({ source_type: "messaging", target_type: "positioning" })`. If it returns `null`, keep the relationship implicit (both hang off the same `gtm_strategy` via `parent_id`) rather than inventing an edge type.
 
 Confirm: "💬 **Key message set**: *\"<headline>\"*"
 
@@ -266,19 +231,18 @@ STOP. Wait for the answer.
 Create the launch entity with phases:
 
 ```
+// Read get_entity_schema("launch") first, then:
 create_node({
   type: "launch",
   title: "<Product Name> Launch; <type>",
   description: "<launch approach and rationale>",
+  status: "<planning phase from the schema>",
   properties: {
-    approach: "<gradual | big_bang | waitlist | internal_first>",
+    /* keys from the schema, e.g. approach, phases[], success metric */
     phases: [
       { "name": "<phase 1>", "target_date": "<date or timeframe>", "goal": "<what success looks like>" },
-      { "name": "<phase 2>", "target_date": "<date or timeframe>", "goal": "<what success looks like>" },
-      { "name": "<phase 3>", "target_date": "<date or timeframe>", "goal": "<what success looks like>" }
-    ],
-    success_metric: "<primary launch KPI>",
-    status: "planned"
+      { "name": "<phase 2>", "target_date": "<date or timeframe>", "goal": "<what success looks like>" }
+    ]
   },
   parent_id: "<gtm_strategy_id>"
 })
@@ -314,28 +278,21 @@ STOP. Wait for the answer.
 Create an `acquisition_channel` entity for each selected channel:
 
 ```
+// Read get_entity_schema("acquisition_channel") first, then:
 create_node({
   type: "acquisition_channel",
   title: "<channel name>",
   description: "<how this channel works for the product and audience>",
-  properties: {
-    channel_type: "<seo | social | referral | paid | content | partnerships | community | product_led>",
-    cost_model: "<free | low | medium | high>",
-    time_to_impact: "<immediate | weeks | months | long_term>",
-    primary: <true if this is the lead channel, false otherwise>
-  },
+  properties: { /* keys from the schema, e.g. channel type, cost model, time to impact, primary */ },
   parent_id: "<gtm_strategy_id>"
 })
 ```
 
-Connect each channel to the ICP:
+Connect each channel to its audience. Resolve the canonical edge first: `resolve_edge_for_pair({ source_type: "acquisition_channel", target_type: "persona" })` (channels typically reach the underlying persona rather than the ICP directly — confirm via the resolver). Then:
 
 ```
-create_edge({
-  source_id: "<acquisition_channel_id>",
-  target_id: "<icp_id>",
-  type: "targets"
-})
+// edge = resolve_edge_for_pair({ source_type: "acquisition_channel", target_type: "persona" })
+create_edge({ source_id: "<acquisition_channel_id>", target_id: "<persona_id>" })  // server infers type
 ```
 
 Confirm: "📣 **<N> acquisition channels mapped**: <primary channel> as the lead growth engine."
@@ -363,30 +320,17 @@ STOP. Wait for the answer.
 Create the `content_strategy` entity:
 
 ```
+// Read get_entity_schema("content_strategy") first, then:
 create_node({
   type: "content_strategy",
   title: "<Product Name> Content Strategy",
   description: "<content philosophy and approach>",
-  properties: {
-    content_types: ["<type 1>", "<type 2>", "<type 3>"],
-    primary_format: "<blog | newsletter | social | video | podcast | educational>",
-    publishing_cadence: "<daily | weekly | biweekly | monthly>",
-    target_audience: "<ICP name>",
-    goal: "<awareness | trust | education | conversion | retention>"
-  },
+  properties: { /* keys from the schema, e.g. content types, primary format, cadence, audience, goal */ },
   parent_id: "<gtm_strategy_id>"
 })
 ```
 
-Connect to relevant acquisition channels:
-
-```
-create_edge({
-  source_id: "<content_strategy_id>",
-  target_id: "<acquisition_channel_id>",
-  type: "fuels"
-})
-```
+Connect to relevant acquisition channels only if a canonical edge exists: call `resolve_edge_for_pair({ source_type: "content_strategy", target_type: "acquisition_channel" })`. If it returns `null`, keep the relationship implicit (both hang off the same `gtm_strategy` via `parent_id`) rather than inventing an edge type.
 
 Confirm: "📝 **Content strategy set**: <primary format> focused on <goal>."