@unified-product-graph/mcp-server 0.8.1 → 0.8.4

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

@@ -1,14 +1,14 @@
 ---
-name: upg-strategy
+name: upg-new-strategy
 description: "Build a Strategic Cascade (how your big vision connects to what you build day to day)"
 user-invocable: true
 argument-hint: "[vision or strategic theme]"
 category: cognitive
 approaches: [plan]
-playbooks: [strategy-outcomes]
+playbooks: [playbook:strategy-outcomes]
 ---
 
-# /upg-strategy: Strategic Cascade (how your big vision connects to what you build day to day)
+# /upg-new-strategy: Strategic Cascade (how your big vision connects to what you build day to day)
 
 You are a Unified Product Graph strategy facilitator. Your job is to walk the user through building a strategic cascade: vision, mission, strategic themes, initiatives (the projects or workstreams that make it real), and outcomes. This creates the top-down strategy tree that connects long-term aspiration to near-term action.
 
@@ -20,6 +20,8 @@ Use the `mcp__unified-product-graph__*` MCP tools (create_node, create_edge, sea
 When creating 3+ entities, use `batch_create_nodes` with `parent_ref` chaining.
 When deleting 3+ entities, use `batch_delete_nodes`.
 
+> **MCP-first (applies to every create below).** Before creating a vision, mission, strategic theme, initiative, or outcome, 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 })` and let the server infer the edge type. The payloads below show shape and intent; the authoritative keys and phases come from the schema at runtime.
+
 ## Phase Map
 
 | Phase | Label | Steps |
@@ -112,14 +114,13 @@ Offer vision options based on the product context:
 STOP. Wait for the answer. Then create the vision node:
 
 ```
+// Read get_entity_schema("vision") first, then:
 create_node({
   type: "vision",
   title: "<vision statement>",
   description: "<expanded context; what this world looks like>",
-  properties: {
-    timeframe: "5-10 years",
-    status: "active"
-  },
+  status: "<ratified phase from the schema>",
+  properties: { /* keys from the schema, e.g. timeframe */ },
   parent_id: "<product_id>"
 })
 ```
@@ -145,13 +146,12 @@ Offer mission options that connect the vision to a specific audience and value:
 STOP. Wait for the answer. Then create the mission node:
 
 ```
+// Read get_entity_schema("mission") first, then:
 create_node({
   type: "mission",
   title: "<mission statement>",
   description: "<who you serve and why it matters>",
-  properties: {
-    status: "active"
-  },
+  status: "<active phase from the schema>",
   parent_id: "<vision_id>"
 })
 ```
@@ -184,13 +184,12 @@ STOP. Wait for the answer.
 For each theme the user provides, create a node:
 
 ```
+// Read get_entity_schema("strategic_theme") first, then:
 create_node({
   type: "strategic_theme",
   title: "<theme name>",
   description: "<why this is a bet worth making>",
-  properties: {
-    status: "active"
-  },
+  status: "<active phase from the schema>",
   parent_id: "<mission_id>"
 })
 ```
@@ -228,14 +227,13 @@ STOP. Wait for the answer.
 For each initiative:
 
 ```
+// Read get_entity_schema("initiative") first, then:
 create_node({
   type: "initiative",
   title: "<initiative name>",
   description: "<what this involves and why it matters for the theme>",
-  properties: {
-    status: "planned",
-    timeline: "<quarter or timeframe if given>"
-  },
+  status: "<proposed phase from the schema>",
+  properties: { /* keys from the schema, e.g. timeline */ },
   parent_id: "<strategic_theme_id>"
 })
 ```
@@ -263,25 +261,21 @@ You already have outcomes in your graph:
 If creating a new outcome:
 
 ```
+// Read get_entity_schema("outcome") first, then:
 create_node({
   type: "outcome",
   title: "<measurable outcome>",
   description: "<what success looks like>",
-  properties: {
-    status: "planned"
-  },
+  status: "<identified phase from the schema>",
   parent_id: "<initiative_id>"
 })
 ```
 
-If linking to an existing outcome:
+If linking to an existing outcome, resolve the edge first:
 
 ```
-create_edge({
-  source_id: "<initiative_id>",
-  target_id: "<existing_outcome_id>",
-  type: "initiative_drives_outcome"
-})
+// edge = resolve_edge_for_pair({ source_type: "initiative", target_type: "outcome" })
+create_edge({ source_id: "<initiative_id>", target_id: "<existing_outcome_id>" })  // server infers type
 ```
 
 Repeat for each initiative, one at a time.
@@ -320,7 +314,7 @@ 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.
 
 ## Key Principles
 

package/skills/upg-prioritise/SKILL.md

@@ -171,11 +171,11 @@ Always confirm before writing. Never silently mutate graph nodes.
 
 Pick ONE next move based on what the ranking revealed:
 
-- **If a clear winner emerged with an unclear implementation path:** "The top-ranked item has a clear priority but no epic yet. Want me to run `/upg-inspect` on it to see what's missing?"
-- **If a high-value item scored low on confidence:** "Low confidence on that one might mean the hypothesis hasn't been tested. Want to run `/upg-hypothesis` to design an experiment?"
+- **If a clear winner emerged with an unclear implementation path:** "The top-ranked item has a clear priority but no epic yet. Want me to run `/upg-show-entity` on it to see what's missing?"
+- **If a high-value item scored low on confidence:** "Low confidence on that one might mean the hypothesis hasn't been tested. Want to run `/upg-new-hypothesis` to design an experiment?"
 - **If items scored similarly and the user is unsure which to commit to:** "Close scores like these suggest a risk/opportunity lens might help. Want to try `/upg-reflect` with a Value vs Effort pre-mortem?"
 - **If the Won't list was surprising:** "Three items ended up in the Won't bucket; that's a useful decision record. Want me to capture them as explicit deferrals in the graph?"
-- **If the ranking feels complete and actionable:** "Prioritisation done. Want to `/upg-snapshot` so this ranking is preserved?"
+- **If the ranking feels complete and actionable:** "Prioritisation done. Want to `/upg-sync-snapshot` so this ranking is preserved?"
 
 After rendering your recommendation, call:
 `update_session_context({ skill_invoked: "upg-prioritise", recommendation: "<the next skill you recommended>" })`
@@ -192,4 +192,4 @@ After rendering your recommendation, call:
 
 Prioritise is one of the 5 canonical UPG approaches (`get_approach({ approach_id: "prioritise" })`). The approach had no skill home; the frameworks lived in the spec but no conversational surface invoked them for ranking workflows. This skill closes that gap.
 
-It is the only canonical entry point for the Prioritise approach in the user-invocable surface. Other skills use prioritisation implicitly (a good `/upg-launch` should sequence its phases), but `/upg-prioritise` is where the user goes when they explicitly need to rank a candidate set and commit to an order.
+It is the only canonical entry point for the Prioritise approach in the user-invocable surface. Other skills use prioritisation implicitly (a good `/upg-new-launch` should sequence its phases), but `/upg-prioritise` is where the user goes when they explicitly need to rank a candidate set and commit to an order.

package/skills/upg-reflect/SKILL.md

@@ -165,8 +165,8 @@ Common patterns and where they go:
 | A load-bearing belief that hasn't been tested | `assumption` entity, link to the anchor |
 | A risk to mitigate | `risk` entity, link to the target it threatens |
 | A decision that needs revisiting | `decision` entity with rationale field, link to original decision |
-| A new hypothesis to test | Suggest `/upg-hypothesis` |
-| A path through the graph the user wants to walk | Suggest `/upg-impact` or `/upg-connect` |
+| A new hypothesis to test | Suggest `/upg-new-hypothesis` |
+| A path through the graph the user wants to walk | Suggest `/upg-show-impact` or `/upg-link` |
 | Just notes; nothing structural | Skip capture; suggest user re-run `/upg-reflect` after they sit with it |
 
 Use `create_node` + `create_edge` to capture. Always confirm before writing.
@@ -175,10 +175,10 @@ Use `create_node` + `create_edge` to capture. Always confirm before writing.
 
 Don't dump a menu. Pick ONE next move based on what surfaced:
 
-- **If a hypothesis emerged:** "The biggest assumption you surfaced sounds testable. Want me to run `/upg-hypothesis` to design that experiment?"
-- **If a risk landed:** "That risk is concrete. Want to capture it and connect it to its target so it's visible from `/upg-status`?"
-- **If a decision is now uncertain:** "Sounds like the decision needs a revisit. Want to `/upg-inspect` it to see what depends on it?"
-- **If reflection produced clarity, not action:** "That was the work. Want me to `/upg-snapshot` so the graph remembers this state?"
+- **If a hypothesis emerged:** "The biggest assumption you surfaced sounds testable. Want me to run `/upg-new-hypothesis` to design that experiment?"
+- **If a risk landed:** "That risk is concrete. Want to capture it and connect it to its target so it's visible from `/upg-show-status`?"
+- **If a decision is now uncertain:** "Sounds like the decision needs a revisit. Want to `/upg-show-entity` it to see what depends on it?"
+- **If reflection produced clarity, not action:** "That was the work. Want me to `/upg-sync-snapshot` so the graph remembers this state?"
 - **If the framework felt wrong for the scope:** "We can switch frameworks. Want me to walk this through Pre-mortem instead?"
 
 After rendering your recommendation, call:
@@ -198,4 +198,4 @@ A few rules that make this work:
 
 Reflect is one of the 5 canonical UPG approaches (`get_approach({ approach_id: "reflect" })`). Until v0.3.0, the approach had no skill home; the frameworks lived in the spec but no conversational surface invoked them. This skill closes that gap.
 
-It's the only canonical entry point for the Reflect approach in the user-invocable surface. Other skills *use* reflect implicitly (a good `/upg-launch` should have a Pre-mortem step), but `/upg-reflect` is where the user goes when they explicitly want to question rather than build.
+It's the only canonical entry point for the Reflect approach in the user-invocable surface. Other skills *use* reflect implicitly (a good `/upg-new-launch` should have a Pre-mortem step), but `/upg-reflect` is where the user goes when they explicitly want to question rather than build.

package/skills/{upg-feedback → upg-send-feedback}/SKILL.md

@@ -1,21 +1,23 @@
 ---
-name: upg-feedback
-description: "Share feedback about the Unified Product Graph: bugs, feature requests, ideas. Sent directly to the UPG team."
+name: upg-send-feedback
+description: "Share feedback about the Unified Product Graph: bugs, feature requests, ideas. Captured locally as a portable file you can send to the team."
 user-invocable: true
 argument-hint: "[bug|feature|observation]"
 category: tooling
 ---
 
-# /upg-feedback: Share Feedback with the UPG Team
+# /upg-send-feedback: Capture Feedback for the UPG Team
 
-You collect user feedback about the UPG and send it to the team. Fast, transparent, private. No graph mutations; this is about THEIR feedback to US.
+You collect user feedback about the UPG and write it to a local Markdown file in the project root. Fast, transparent, private. No graph mutations; this is about THEIR feedback to US.
+
+There is no public feedback endpoint to submit to, and the `WebFetch` tool cannot POST a body anyway. So the path is **capture locally, then the user sends the file** (paste into a GitHub issue, email, or attach it). The local file IS the deliverable, not a fallback.
 
 **Before producing any output, read the design system:** `/upg-context` for emoji mappings, formatting rules, and shared interaction patterns.
 
 ## Tools
 
 - `mcp__unified-product-graph__get_product_context` and `mcp__unified-product-graph__get_graph_digest`: for automatic context gathering only
-- `WebFetch`: to POST the feedback payload
+- `Write`: to save the feedback file to the project root
 
 ## Flow
 
@@ -63,10 +65,10 @@ If MCP calls fail, use defaults silently. Don't slow down the flow.
 
 ### Step 6: Show Payload (mandatory)
 
-Transparency is critical. Show exactly what will be sent:
+Transparency is critical. Show exactly what will be written to the file:
 
 ```
-Here's what I'll send to the UPG team:
+Here's what I'll save for the UPG team:
 
   Type: <type>
   Title: "<title>"
@@ -75,67 +77,44 @@ Here's what I'll send to the UPG team:
 
 No product graph data is included; just your feedback + metadata above.
 
-Send it? (y/n)
+Save it? (y/n)
 ```
 
 Wait for confirmation. If they say no, ask what to change or cancel gracefully.
 
-### Step 7: Send
-
-POST to `https://cloud.unifiedproductgraph.org/api/feedback` with JSON body:
-
-```json
-{
-  "type": "<bug|feature_request|observation|general>",
-  "title": "<title>",
-  "description": "<description>",
-  "context": {
-    "upg_version": "<version>",
-    "product_stage": "<stage>",
-    "entity_count": <N>,
-    "from_skill": "<skill or null>"
-  }
-}
-```
+### Step 7: Save
 
-### Step 8: Confirm
+Use the `Write` tool to save the feedback as Markdown in the project root, filename `upg-feedback-YYYY-MM-DD.md` (use today's date; if a file with that name already exists, append `-2`, `-3`, etc. so nothing is overwritten).
 
-On success:
+The file format:
 
-```
-Feedback sent; thank you!
+```markdown
+# UPG Feedback: YYYY-MM-DD
 
-Your input directly shapes the Unified Product Graph.
-The team reviews every submission.
+**Type:** <bug|feature_request|observation|general>
+**Title:** <title>
+**Description:** <description>
+**Context:** UPG v<version> · <stage> · <N> entities · from <skill>
 ```
 
-On failure (network error, non-2xx response): save feedback as markdown in the project root:
+### Step 8: Confirm
 
 ```
-I couldn't reach the server right now. I've saved your feedback locally
-  as upg-feedback-YYYY-MM-DD.md; you can send it manually or try again later.
-```
-
-The fallback file format:
+Saved to upg-feedback-YYYY-MM-DD.md; thank you!
 
-```markdown
-# UPG Feedback: YYYY-MM-DD
+To get it to the team, send the file however suits you:
+- open an issue at github.com/unified-product-graph/spec and paste it in, or
+- email it / attach the file.
 
-**Type:** <type>
-**Title:** <title>
-**Description:** <description>
-**Context:** UPG v<version> · <stage> · <N> entities · from <skill>
+Your input directly shapes the Unified Product Graph.
 ```
 
 ## Key Principles
 
-- **FAST.** 30 seconds. Three questions max (type + title + description), then confirm and send.
+- **FAST.** 30 seconds. Three questions max (type + title + description), then confirm and save.
 - **One question at a time.** Never batch questions.
-- **NEVER send product graph data.** Only feedback text + opt-in metadata shown in the payload preview.
-- **Show before sending.** The user must see and approve the exact payload.
+- **Capture locally.** There is no submit endpoint; write the file, the user sends it. The file is the deliverable.
+- **NEVER include product graph data.** Only feedback text + opt-in metadata shown in the preview.
+- **Show before saving.** The user must see and approve the exact payload.
 - **No graph mutations.** Feedback only; no entities created.
-- **Graceful degradation.** If MCP calls or the POST fail, keep going with defaults and local fallback.
-
-┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
-Your .upg file is yours: open standard, portable, git-friendly.
-unifiedproductgraph.org
+- **Graceful degradation.** If MCP context calls fail, use defaults silently and still write the file.

package/skills/{upg-diff → upg-show-diff}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: upg-diff
+name: upg-show-diff
 description: "See what changed in your product graph since last commit"
 user-invocable: true
 argument-hint: "[ref]"
@@ -7,7 +7,7 @@ category: cognitive
 approaches: [inspect]
 ---
 
-# /upg-diff: Semantic Graph Diff
+# /upg-show-diff: Semantic Graph Diff
 
 You are a Unified Product Graph diff engine. Your job is to show meaningful, human-readable changes to the product graph since the last git commit (or a specified ref), not raw JSON, but semantic product changes.
 
@@ -35,7 +35,7 @@ This .upg file isn't tracked by git yet; there's nothing to diff against.
 
 Run: git add product.upg && git commit -m "Initial product graph"
 
-Then /upg-diff will show changes from that baseline.
+Then /upg-show-diff will show changes from that baseline.
 ```
 
 ### Step 2: Parse Both States
@@ -106,9 +106,9 @@ This is a good checkpoint. Consider:
   git add product.upg && git commit -m "Add Sarah persona + retention outcome"
 
 Or keep going:
-  /upg-gaps: Check if these changes closed any gaps
-  /upg-tree: See the updated graph structure
-  /upg-status: Full health dashboard
+  /upg-check-gaps: Check if these changes closed any gaps
+  /upg-show-tree: See the updated graph structure
+  /upg-show-status: Full health dashboard
 ```
 
 ## Handling Edge Cases
@@ -142,9 +142,3 @@ If the repo has multiple `.upg` files, list them and ask which one to diff.
 - **Follow the design system.** Entity emojis, score dots, filled bars, dashed dividers as defined in /upg-context.
 - **Suggest git hygiene.** Encourage committing at natural checkpoints.
 - **Reference matters.** Always show which ref you're diffing against.
-
-```
-┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
-Your .upg file is yours: open standard, portable, git-friendly.
-unifiedproductgraph.org
-```

package/skills/{upg-inspect → upg-show-entity}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: upg-inspect
+name: upg-show-entity
 description: "Deep-dive into a single entity: connections, properties, gaps, enrichment suggestions"
 user-invocable: true
 argument-hint: "<entity name or type>"
@@ -7,7 +7,7 @@ category: cognitive
 approaches: [inspect]
 ---
 
-# /upg-inspect: Entity Deep-Dive
+# /upg-show-entity: Entity Deep-Dive
 
 You are a Unified Product Graph entity analyst. Your job is to show everything about a single entity; its properties, all connections in and out, connected chains, missing fields, and actionable enrichment suggestions. You're the magnifying glass on any node in the graph.
 
@@ -134,8 +134,8 @@ ENRICHMENT CHECKLIST
 ```
 
 - [ ] Add a description
-- [ ] Connect to a job (`/upg-connect`)
-- [ ] Add needs (`/upg-explore a need for "<title>"`)
+- [ ] Connect to a job (`/upg-link`)
+- [ ] Add needs (`/upg-walk-region a need for "<title>"`)
 - [x] Has status
 - [x] Has 3 outgoing connections
 
@@ -145,8 +145,8 @@ Based on the gaps found, suggest 2-3 specific actions:
 
 > **Suggested next steps:**
 >
-> 1. `/upg-explore a job for "<entity title>"`; this persona needs Jobs-to-be-Done
-> 2. `/upg-connect`; wire this to related entities
+> 1. `/upg-walk-region a job for "<entity title>"`; this persona needs Jobs-to-be-Done
+> 2. `/upg-link`; wire this to related entities
 > 3. Update properties: `update_node({ node_id: "<id>", description: "..." })`
 
 ## Key Principles
@@ -160,8 +160,6 @@ Based on the gaps found, suggest 2-3 specific actions:
 
 ---
 
-Your `.upg` file is yours: open standard, portable, git-friendly.
-unifiedproductgraph.org
 
 After rendering your recommendation, call:
-`update_session_context({ skill_invoked: "upg-inspect", recommendation: "<the next skill you recommended>" })`
+`update_session_context({ skill_invoked: "upg-show-entity", recommendation: "<the next skill you recommended>" })`

package/skills/{upg-impact → upg-show-impact}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: upg-impact
+name: upg-show-impact
 description: "Impact analysis: what does this unblock (forward), or what blocks this (--upstream)?"
 user-invocable: true
 argument-hint: "[--upstream] [entity ID or search term]"
@@ -7,7 +7,7 @@ category: cognitive
 approaches: [trace, prioritise]
 ---
 
-# /upg-impact: Causal Impact Analysis
+# /upg-show-impact: Causal Impact Analysis
 
 You are an impact analyst. Given a specific entity (bug, debt item, root cause, feature, or any node), you traverse the graph's causal relationships to answer one of two questions:
 
@@ -18,22 +18,22 @@ You are an impact analyst. Given a specific entity (bug, debt item, root cause,
 
 ## Modes
 
-- `/upg-impact <entity>`: forward blast-radius analysis (the default).
-- `/upg-impact --upstream <entity>`: upstream causal-chain analysis: what blocks this entity? Use the **Upstream Mode** section below.
-- `/upg-impact --upstream` (no entity); graph-wide blocker scan: ALL bugs / debt items / root causes / open investigations, ranked by impact. Same Upstream Mode logic, applied across the graph.
+- `/upg-show-impact <entity>`: forward blast-radius analysis (the default).
+- `/upg-show-impact --upstream <entity>`: upstream causal-chain analysis: what blocks this entity? Use the **Upstream Mode** section below.
+- `/upg-show-impact --upstream` (no entity); graph-wide blocker scan: ALL bugs / debt items / root causes / open investigations, ranked by impact. Same Upstream Mode logic, applied across the graph.
 
 ## Graph Readiness Check
 
 Before running the impact analysis, call `get_graph_digest()` and check the following against `counts.by_type` (which lists every entity type with at least one instance):
 
 - **No blocker-type entities exist at all**: if `by_type` contains none of `bug`, `technical_debt_item`, `root_cause`, `investigation`, surface:
-  > Your graph has no blocker, debt, root-cause, or investigation entities yet. Impact analysis traces blocker → feature chains, so there's nothing to walk. Run `/upg-connect` to link bugs/debt/root-causes to features, or `/upg-explore bug` to add the first one.
+  > Your graph has no blocker, debt, root-cause, or investigation entities yet. Impact analysis traces blocker → feature chains, so there's nothing to walk. Run `/upg-link` to link bugs/debt/root-causes to features, or `/upg-walk-region bug` to add the first one.
 
 - **Fewer than 3 features total**: if `by_type.feature` is missing or < 3, surface:
-  > You need at least a few features in your graph for impact analysis to be meaningful. Run `/upg-explore feature` to add some.
+  > You need at least a few features in your graph for impact analysis to be meaningful. Run `/upg-walk-region feature` to add some.
 
 If the user provided an anchor entity, also call `get_node({ node_id })` and inspect its `edges`. If the anchor has zero outgoing edges of types `bug_affects_feature` / `debt_blocks_feature` / `root_cause_affects_feature` / `causes` / `blocks`, surface (do not silently return an empty blast radius):
-> `<anchor title>` has no outgoing impact edges in the graph, so its blast radius is empty by definition. Run `/upg-connect <anchor>` to wire it to the features or stories it affects, then re-run this analysis.
+> `<anchor title>` has no outgoing impact edges in the graph, so its blast radius is empty by definition. Run `/upg-link <anchor>` to wire it to the features or stories it affects, then re-run this analysis.
 
 If the user is in the engineering lens, you may also consult `lens_digest.blockers` and `lens_digest.blocked_features` for a richer signal.
 
@@ -61,7 +61,7 @@ list_nodes({ type: "investigation", include_edges: true })
 
 After rendering, register this invocation:
 ```
-update_session_context({ skill_invoked: "upg-impact", direction: "forward" | "upstream" })
+update_session_context({ skill_invoked: "upg-show-impact", direction: "forward" | "upstream" })
 ```
 
 ## Flow
@@ -206,7 +206,7 @@ Chain 1: [title]; Impact: HIGH (blocks N features)
 (Blockers with no resolution plan)
 
 🔴 [title]; no linked fix or task
-→ Create a resolution with `/upg-explore task` or `/upg-explore fix`
+→ Create a resolution with `/upg-walk-region task` or `/upg-walk-region fix`
 
 ---
 
@@ -222,8 +222,4 @@ If yes, use `create_node` to create task or fix entities and `create_edge` to li
 - **Impact-first ranking.** The blocker that affects the most features goes first.
 - **Offer resolution.** Don't just diagnose; offer to create the fix/task.
 - **Edge confidence matters.** If an edge is `speculative`, flag it as uncertain.
-- **Engineering emojis:** 🐛 bug, 🔧 debt, 🌿 root_cause, 💊 fix, 🔍 investigation, 📦 feature, 🔴 blocker
-
----
-Your .upg file is yours: open standard, portable, git-friendly.
-unifiedproductgraph.org
+- **Engineering emojis:** 🐛 bug, 🔧 debt, 🌿 root_cause, 💊 fix, 🔍 investigation, 📦 feature (a "blocker" is any of bug / debt / dependency / root_cause that blocks a feature; there is no `blocker` entity type)

package/skills/{upg-journey → upg-show-journey}/SKILL.md

@@ -1,13 +1,13 @@
 ---
-name: upg-journey
+name: upg-show-journey
 description: "Guided product journey: 7 phases from idea to iteration"
 user-invocable: true
 category: cognitive
 approaches: [plan]
-playbooks: [strategy-outcomes, users-needs, discovery-research-validation, product-delivery, business-gtm-growth, analytics-data, operations-quality]
+playbooks: [playbook:strategy-outcomes, playbook:users-needs, playbook:discovery-research-validation, playbook:product-delivery, playbook:business-gtm-growth, playbook:analytics-data, playbook:operations-quality]
 ---
 
-# /upg-journey: Guided Product Journey
+# /upg-show-journey: Guided Product Journey
 
 You are a Unified Product Graph journey guide. Your job is to show where the user stands across all 7 phases of the solo builder journey, celebrate what they've accomplished, and recommend what to work on next.
 
@@ -31,7 +31,9 @@ The digest provides counts by type, chain completeness, and business area covera
 
 ### Step 2: Determine Phase Completion
 
-Check which entity types exist (at least 1 node of that type) to classify each phase:
+The **7 phases are an editorial product-thinking framing** (stable). The **type-list backbone for each phase is derived from the spec, not hard-coded**: read counts-by-type and business-area coverage from `get_graph_digest` (Step 1), and treat the type names in the tables below as illustrative anchors — confirm any type still exists with `list_entity_types` before relying on it, and prefer the digest's `by_type` counts and chain/area fields for everything quantitative. If a type named below has been renamed or removed in the spec, fall back to the digest's business-area coverage for that phase.
+
+Check which entity types have at least 1 node (from the digest) to classify each phase:
 
 | Phase | ✓ Complete if | Bonus if also |
 |---|---|---|
@@ -67,13 +69,13 @@ YOUR PRODUCT JOURNEY
 
 | | Phase | Status | Skills |
 |---|---|---|---|
-| 1 | Identity | ✓ complete | `/upg-init`, `/upg-strategy` |
-| 2 | Understanding | ● in progress | `/upg-persona`, `/upg-research` |
-| 3 | Discovery | ○ not started | `/upg-discover`, `/upg-hypothesis`, `/upg-explore market_intelligence` |
-| 4 | Business | ○ not started | `/upg-explore business_model`, `/upg-explore market_intelligence`, `/upg-okr` |
-| 5 | Reaching | ○ not started | `/upg-launch`, `/upg-explore marketing` |
-| 6 | Building | ○ not started | `/upg-explore product_spec`, `/upg-explore engineering` |
-| 7 | Learning | ○ not started | `/upg-explore team_org`, `/upg-gaps` |
+| 1 | Identity | ✓ complete | `/upg-new-graph`, `/upg-new-strategy` |
+| 2 | Understanding | ● in progress | `/upg-new-persona`, `/upg-new-research` |
+| 3 | Discovery | ○ not started | `/upg-new-discovery`, `/upg-new-hypothesis`, `/upg-walk-region market_intelligence` |
+| 4 | Business | ○ not started | `/upg-walk-region business_model`, `/upg-walk-region market_intelligence`, `/upg-new-okr` |
+| 5 | Reaching | ○ not started | `/upg-new-launch`, `/upg-walk-region marketing` |
+| 6 | Building | ○ not started | `/upg-walk-region product_spec`, `/upg-walk-region engineering` |
+| 7 | Learning | ○ not started | `/upg-walk-region team_org`, `/upg-check-gaps` |
 
 Progress: ● ● ○ ○ ○ ○ ○  **2/7 phases**
 
@@ -117,11 +119,11 @@ List 3 numbered options based on the most impactful incomplete phases, followed
 
 If they pick a phase, respond with the specific skill to run:
 
-> Great; run `/upg-persona` to start deepening your understanding of who you're building for. When you're done, run `/upg-journey` again to see your updated progress.
+> Great; run `/upg-new-persona` to start deepening your understanding of who you're building for. When you're done, run `/upg-show-journey` again to see your updated progress.
 
 If they pick option 5, close warmly:
 
-> Your graph is in good shape. Keep building; every entity you add makes the picture clearer. Run `/upg-journey` anytime to check in.
+> Your graph is in good shape. Keep building; every entity you add makes the picture clearer. Run `/upg-show-journey` anytime to check in.
 
 ### Step 6: Completion Celebration
 
@@ -137,18 +139,18 @@ Your product graph spans the full journey; from identity to learning. This isn't
 
 | | |
 |---|---|
-| `/upg-status` | See your full health dashboard |
-| `/upg-gaps` | Find the deepest remaining gaps |
-| `/upg-push` | Sync your graph to the cloud |
+| `/upg-show-status` | See your full health dashboard |
+| `/upg-check-gaps` | Find the deepest remaining gaps |
+| `/upg-sync-push` | Sync your graph to the cloud |
 | Keep iterating | The journey is a loop, not a line |
 
 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
 
 ## Phase → Entity Type Reference
 
-Use this to check which entities belong to each phase when scanning the graph:
+This grouping is **editorial (which phase a type belongs to), not authoritative for which types exist**. Confirm the live type set with `list_entity_types` and derive per-type counts from `get_graph_digest`; the lists below may lag the spec. The phase a type maps to is the product-thinking part; whether a type still exists is a live question.
 
-| Phase | Entity Types |
+| Phase | Entity Types (illustrative) |
 |---|---|
 | 1. Identity | `product`, `vision`, `mission` |
 | 2. Understanding | `persona`, `job`, `need`, `research_study`, `insight` |
@@ -164,24 +166,21 @@ Use this when recommending which skill to run:
 
 | Phase | Primary Skill | Other Skills |
 |---|---|---|
-| 1. Identity | `/upg-init` | `/upg-strategy` |
-| 2. Understanding | `/upg-persona` | `/upg-research` |
-| 3. Discovery | `/upg-discover` | `/upg-hypothesis`, `/upg-explore market_intelligence` |
-| 4. Business | `/upg-explore business_model` | `/upg-explore market_intelligence`, `/upg-okr`, `/upg-explore pricing` |
-| 5. Reaching | `/upg-launch` | `/upg-explore marketing`, `/upg-explore growth`, `/upg-explore content` |
-| 6. Building | `/upg-explore product_spec` | `/upg-explore engineering`, `/upg-explore ux_design` |
-| 7. Learning | `/upg-explore team_org` | `/upg-gaps` |
+| 1. Identity | `/upg-new-graph` | `/upg-new-strategy` |
+| 2. Understanding | `/upg-new-persona` | `/upg-new-research` |
+| 3. Discovery | `/upg-new-discovery` | `/upg-new-hypothesis`, `/upg-walk-region market_intelligence` |
+| 4. Business | `/upg-walk-region business_model` | `/upg-walk-region market_intelligence`, `/upg-new-okr`, `/upg-walk-region pricing` |
+| 5. Reaching | `/upg-new-launch` | `/upg-walk-region marketing`, `/upg-walk-region growth`, `/upg-walk-region content` |
+| 6. Building | `/upg-walk-region product_spec` | `/upg-walk-region engineering`, `/upg-walk-region ux_design` |
+| 7. Learning | `/upg-walk-region team_org` | `/upg-check-gaps` |
 
 ## Footer
 
 Always end with:
 
-┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
-Your `.upg` file is yours: open standard, portable, git-friendly.
-unifiedproductgraph.org
 
 After rendering your recommendation, call:
-`update_session_context({ skill_invoked: "upg-journey", recommendation: "<the next skill you recommended>" })`
+`update_session_context({ skill_invoked: "upg-show-journey", recommendation: "<the next skill you recommended>" })`
 
 ## Lens-Aware Phase Emphasis
 
@@ -193,9 +192,9 @@ Check `get_session_context()` for the current lens. Visually emphasize the most
 - **product (default):** All phases weighted equally.
 
 For non-default lenses, recommend the most useful skill set:
-- engineering: "For a build-focused view, try `/upg-status` then `/upg-impact --upstream` to surface blockers."
-- design: "For a design-focused view, try `/upg-explore ux_design` (covers screens, flows, wireframes, audit)."
-- growth: "For a growth-focused view, try `/upg-explore growth`, `/upg-explore marketing`, and `/upg-launch`."
+- engineering: "For a build-focused view, try `/upg-show-status` then `/upg-show-impact --upstream` to surface blockers."
+- design: "For a design-focused view, try `/upg-walk-region ux_design` (covers screens, flows, wireframes, audit)."
+- growth: "For a growth-focused view, try `/upg-walk-region growth`, `/upg-walk-region marketing`, and `/upg-new-launch`."
 
 ## Key Principles