@unified-product-graph/mcp-server 0.7.1 → 0.7.3

package/skills/upg-diff/SKILL.md

@@ -7,9 +7,9 @@ category: cognitive
 approaches: [inspect]
 ---
 
-# /upg-diff — Semantic Graph Diff
+# /upg-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.
+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.
 
 **Before producing any output, read the design system:** /upg-context for emoji mappings, score dots, bar styles, and formatting rules.
 
@@ -31,7 +31,7 @@ git diff HEAD -- "*.upg"
 
 If the `.upg` file isn't tracked by git yet:
 ```
-This .upg file isn't tracked by git yet — there's nothing to diff against.
+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"
 
@@ -76,13 +76,13 @@ Format as a clear, scannable summary:
   + 4 connections added
 
 ### Added
-  + 👤 Sarah Chen — Senior PM at Series B startup
+  + 👤 Sarah Chen: Senior PM at Series B startup
   + 💼 Track decisions on mobile (functional, importance ● ● ● ● ●)
   + 🎯 Reduce time-to-value by 40%
 
 ### Modified
-  ~ ⚗️ "Wizard reduces drop-off" — status: ⚪ untested → 🟡 in_progress
-  ~ 📊 Day-7 retention — target_value: 55% → 65%
+  ~ ⚗️ "Wizard reduces drop-off": status: ⚪ untested → 🟡 in_progress
+  ~ 📊 Day-7 retention: target_value: 55% → 65%
 
 ### Removed
   - ⚔️ OldRival (removed from graph)
@@ -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-gaps: Check if these changes closed any gaps
+  /upg-tree: See the updated graph structure
+  /upg-status: Full health dashboard
 ```
 
 ## Handling Edge Cases
@@ -127,7 +127,7 @@ Group by entity type and show counts, then offer to expand:
   + 12 connections added
   ~ 3 entities modified
 
-Want me to show the full details? That's a lot of changes — might be worth
+Want me to show the full details? That's a lot of changes; might be worth
 committing as a checkpoint first.
 ```
 
@@ -137,7 +137,7 @@ If the repo has multiple `.upg` files, list them and ask which one to diff.
 ## Key Principles
 
 - **Semantic, not syntactic.** "Added 👤 Sarah Chen" is useful. A JSON diff line is not.
-- **Group by action.** Added, modified, removed — in that order. Additions are the most interesting.
+- **Group by action.** Added, modified, removed, in that order. Additions are the most interesting.
 - **Show the important properties.** For modified entities, show what changed (old → new).
 - **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.
@@ -145,6 +145,6 @@ If the repo has multiple `.upg` files, list them and ask which one to diff.
 
 ```
 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
-Your .upg file is yours — open standard, portable, git-friendly.
+Your .upg file is yours: open standard, portable, git-friendly.
 unifiedproductgraph.org
 ```

package/skills/upg-discover/SKILL.md

@@ -8,9 +8,9 @@ approaches: [plan]
 playbooks: [discovery-research-validation, users-needs]
 ---
 
-# /upg-discover — OST-Guided Discovery Session
+# /upg-discover: OST-Guided Discovery Session
 
-> **This skill runs a structured Opportunity Solution Tree (OST) session** — it creates new Outcome → Opportunity → Solution → Hypothesis → Experiment chains from scratch.
+> **This skill runs a structured Opportunity Solution Tree (OST) session**: it creates new Outcome → Opportunity → Solution → Hypothesis → Experiment chains from scratch.
 > 
 > Looking to explore what's already in your graph? Use `/upg-explore` (add entities) or `/upg-inspect` (audit an entity).
 
@@ -53,7 +53,7 @@ Every level must be grounded in evidence, not opinion. Outcomes come from busine
 ## Discovery Flow
 
 ### Step 1: Check Existing State
-**Phase 1 of 5 — Setting the frame** (~10 minutes total)
+**Phase 1 of 5: Setting the frame** (~10 minutes total)
 
 First, check what already exists:
 
@@ -79,7 +79,7 @@ Good outcomes are:
 Bad outcomes:
 - "Make the product better" (not measurable)
 - "Ship feature X" (that's a solution, not an outcome)
-- "Increase revenue" (too broad — which lever?)
+- "Increase revenue" (too broad, which lever?)
 
 If they give a solution disguised as an outcome, coach them: **"That sounds more like a solution. What outcome would that solution drive? What changes for the user or the business?"**
 
@@ -97,12 +97,12 @@ create_node({
 Show the tree so far:
 ```
 🎯 <title>
-  (no opportunities yet — let's discover some)
+  (no opportunities yet; let's discover some)
 ```
 
 ### Step 3: Discover Opportunities
 
-Ask: **"What opportunities have you discovered through research? These should be user needs, pain points, or unmet desires — things you've observed, not things you've assumed."**
+Ask: **"What opportunities have you discovered through research? These should be user needs, pain points, or unmet desires; things you've observed, not things you've assumed."**
 
 Coach them on the difference:
 - **Opportunity (good):** "Users spend 15 minutes manually copying data between tools" (observed friction)
@@ -114,7 +114,7 @@ Help them generate 2-3 opportunities. For each:
 create_node({
   type: "opportunity",
   title: "<user need or problem observed>",
-  description: "<evidence — where did you observe this?>",
+  description: "<evidence; where did you observe this?>",
   properties: {
     status: "identified",
     reach: <1-5>,
@@ -140,7 +140,7 @@ Show the growing tree with score dots:
 
 ### Step 4: Generate Solutions
 
-For the highest-pain opportunity, ask: **"For this opportunity — '<opportunity title>' — what solutions could address it? Think broadly: what are 2-3 different approaches?"**
+For the highest-pain opportunity, ask: **"For this opportunity, '<opportunity title>', what solutions could address it? Think broadly: what are 2-3 different approaches?"**
 
 Coach divergent thinking:
 - "What's the simplest version?"
@@ -195,7 +195,7 @@ Create the experiment chain:
 //
 // Hypothesis MUST attach to a solution (`solution_proposes_hypothesis`),
 // never directly to an opportunity. The OST chain is opportunity → solution
-// → hypothesis — short-circuiting through opportunity produces an
+// → hypothesis; short-circuiting through opportunity produces an
 // orphan hypothesis because there is no canonical
 // `opportunity → hypothesis` edge by design. If you find yourself
 // wanting to skip the solution layer, that is a signal you have not
@@ -286,5 +286,5 @@ After rendering your recommendation, call:
 - **Credit the framework.** Teresa Torres created OST. Always attribute.
 
 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
-Your `.upg` file is yours — open standard, portable, git-friendly.
+Your `.upg` file is yours: open standard, portable, git-friendly.
 unifiedproductgraph.org

package/skills/upg-explore/SKILL-DETAIL.md

@@ -3,7 +3,7 @@ name: upg-explore-detail
 description: "Full property schemas and edge type reference for /upg-explore"
 ---
 
-# /upg-explore — Property Schemas & Edge Types (Detail)
+# /upg-explore: Property Schemas & Edge Types (Detail)
 
 This file contains the full property schemas and edge type reference for entity creation. It is loaded on demand by /upg-explore when the agent needs to know the specific properties or valid connections for an entity type.
 
@@ -30,7 +30,7 @@ Ask: "What's the timeline for this outcome?"
   "range_max": 100
 }
 ```
-Ask: "What's the current value? What's the target? What unit?" (KPIs are `metric` nodes with `designation: "kpi"` — the `kpi` type was consolidated into `metric` in v0.1.0.)
+Ask: "What's the current value? What's the target? What unit?" (KPIs are `metric` nodes with `designation: "kpi"`; the `kpi` type was consolidated into `metric` in v0.1.0.)
 
 ### objective
 ```json
@@ -165,7 +165,7 @@ Ask: "How often does this happen (1-5)? How bad is it (1-5)? Is this a pain, gap
   "status": "draft | validated | active | pivoting"
 }
 ```
-Ask: "What type of canvas is this — lean, BMC, or custom? Who are the customer segments? What are the key activities?"
+Ask: "What type of canvas is this; lean, BMC, or custom? Who are the customer segments? What are the key activities?"
 
 ### value_proposition
 ```json
@@ -200,7 +200,7 @@ Ask: "What's the target market? Is this product-led, sales-led, or community-led
   "industry": "Target industry",
   "budget_range": "Typical budget",
   "buying_triggers": ["What causes them to look for a solution"],
-  "disqualifiers": ["Red flags — who is NOT a fit"],
+  "disqualifiers": ["Red flags; who is NOT a fit"],
   "decision_makers": ["Roles involved in the buying decision"]
 }
 ```
@@ -245,7 +245,7 @@ Ask: "Which persona takes this journey? What's the scenario? What stages does it
   "decided_on": "ISO date"
 }
 ```
-Ask: "What's the context — why was this decision needed? What was decided? What alternatives were considered? Which layer does this belong to — engineering, design, or product?" (`architecture_decision`, `design_decision`, and `product_decision` were consolidated into the single `decision` type with a `layer` property in v0.2.0.)
+Ask: "What's the context; why was this decision needed? What was decided? What alternatives were considered? Which layer does this belong to; engineering, design, or product?" (`architecture_decision`, `design_decision`, and `product_decision` were consolidated into the single `decision` type with a `layer` property in v0.2.0.)
 
 ### growth_loop
 ```json
@@ -259,7 +259,7 @@ Ask: "What's the context — why was this decision needed? What was decided? Wha
   "status": "theoretical | testing | proven | scaling"
 }
 ```
-Ask: "What type of loop — viral, content, paid, or product? What triggers it? What action does the user take? How does the output feed back into the trigger?"
+Ask: "What type of loop; viral, content, paid, or product? What triggers it? What action does the user take? How does the output feed back into the trigger?"
 
 ### pricing_strategy
 ```json
@@ -272,7 +272,7 @@ Ask: "What type of loop — viral, content, paid, or product? What triggers it?
   "status": "research | testing | launched | iterating"
 }
 ```
-Ask: "What pricing model — freemium, usage-based, per-seat, etc.? What's the anchor price? How does this compare to competitors — cheaper, parity, or premium?"
+Ask: "What pricing model; freemium, usage-based, per-seat, etc.? What's the anchor price? How does this compare to competitors; cheaper, parity, or premium?"
 
 ### ai_model
 ```json
@@ -287,9 +287,9 @@ Ask: "What pricing model — freemium, usage-based, per-seat, etc.? What's the a
   "status": "prototyping | evaluating | staging | production | deprecated"
 }
 ```
-Ask: "What type of model — LLM, classifier, recommender? Which provider? What's its use case in the product?"
+Ask: "What type of model; LLM, classifier, recommender? Which provider? What's its use case in the product?"
 
-## Edge Types — Valid Connections
+## Edge Types: Valid Connections
 
 After creating an entity, search for related entities and suggest connections. Use these valid edge types:
 

package/skills/upg-explore/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: upg-explore
-description: "Explore a UPG region — walk its canonical playbook"
+description: "Explore a UPG region: walk its canonical playbook"
 user-invocable: true
 argument-hint: "[region or description]"
 category: cognitive
 approaches: [plan]
 ---
 
-# /upg-explore — Explore a UPG Region
+# /upg-explore: Explore a UPG Region
 
 You are a Unified Product Graph-aware product assistant. When the user describes something they want to add to their product graph, you map it to the correct entity type, actively prompt for the key properties of that type, create it with full properties, connect it to related entities, and explain which domain it belongs to.
 
@@ -19,7 +19,7 @@ Use the `mcp__unified-product-graph__*` MCP tools (create_node, create_edge, sea
 
 ## Entity Type Mapping
 
-Map the user's intent to the correct UPG entity type. Don't guess — ask if ambiguous.
+Map the user's intent to the correct UPG entity type. Don't guess; ask if ambiguous.
 
 ### 🎯 Strategic
 
@@ -171,7 +171,7 @@ Map the user's intent to the correct UPG entity type. Don't guess — ask if amb
 |---|---|---|
 | A blog post, article, video, asset | `content_piece` | Content & Knowledge |
 | A help article, docs page | `knowledge_base_article` | Content & Knowledge |
-| A brand asset — logo, guideline, template | `brand_asset` | Content & Knowledge |
+| A brand asset; logo, guideline, template | `brand_asset` | Content & Knowledge |
 
 ### 🛡️ DevOps & Platform
 
@@ -236,10 +236,10 @@ Map the user's intent to the correct UPG entity type. Don't guess — ask if amb
 
 ## Property Schemas & Edge Types
 
-**Full property schemas and edge type reference are in `SKILL-DETAIL.md`.** Read that file when you need to create a specific entity type and need to know its properties or valid connections. Don't load it upfront — only when you've identified the entity type.
+**Full property schemas and edge type reference are in `SKILL-DETAIL.md`.** Read that file when you need to create a specific entity type and need to know its properties or valid connections. Don't load it upfront; only when you've identified the entity type.
 
 **Quick reference for the most common types:**
-- **persona**: context, motivation, experience_level (goals[] and frustrations[] are separate nodes — use desired_outcome + need with edges)
+- **persona**: context, motivation, experience_level (goals[] and frustrations[] are separate nodes; use desired_outcome + need with edges)
 - **job**: statement (When I... I want to... So I can...), job_type, importance 1-5
 - **hypothesis**: we_believe, will_result_in, we_know_when, status: drafted
 - **opportunity**: status, reach 1-5, frequency 1-5, pain 1-5
@@ -250,9 +250,9 @@ For all other types, read SKILL-DETAIL.md.
 
 ## After Creation
 
-1. Show what was created with all properties, using entity type emojis (e.g. `👤 Sarah Chen — Senior PM`) and score dots for 1-5 values (e.g. `importance ● ● ● ● ○`)
+1. Show what was created with all properties, using entity type emojis (e.g. `👤 Sarah Chen: Senior PM`) and score dots for 1-5 values (e.g. `importance ● ● ● ● ○`)
 2. Search for related entities using `search_nodes`
-3. Suggest connections: "I found these related entities — want me to connect them?"
+3. Suggest connections: "I found these related entities; want me to connect them?"
 4. Mention which Unified Product Graph domain this entity belongs to
 5. Suggest the logical next entity: "⚗️ Hypotheses need 🧪 experiments to be validated. Want to create one?"
 
@@ -260,7 +260,7 @@ For all other types, read SKILL-DETAIL.md.
 
 Check `get_session_context()` for the current lens. After creating certain entity types, prompt for causal/structural edges:
 
-**Engineering lens — after creating:**
+**Engineering lens: after creating:**
 - `bug`: "Which feature does this bug affect?" → create `bug_affects_feature` edge
 - `task`: "Which user story or feature is this task for?" → create `story_has_task` or connect to feature
 - `technical_debt_item`: "Does this debt block any features?" → create `debt_blocks_feature` edge
@@ -269,12 +269,12 @@ Check `get_session_context()` for the current lens. After creating certain entit
 - `fix`: "Which bug or root cause does this fix?" → create `fix_resolved_bug` or `fix_resolved_root_cause` edge
 - `feature`: "Does this feature depend on or block anything?" → create blocking edges
 
-**Design lens — after creating:**
+**Design lens: after creating:**
 - `screen`: "Which feature does this screen implement?" → use existing `screen_uses_feature` edge
 - `design_component`: "Which design system does this belong to?" → connect to design_system
 - `decision` (layer: design): "Does this affect any engineering decisions?" → create `decision_informs_decision` edge
 
-**Growth lens — after creating:**
+**Growth lens: after creating:**
 - `acquisition_channel`: "Which funnel does this channel feed?" → connect to funnel
 - `growth_campaign`: "Which channel is this campaign for?" → create `channel_has_growth_campaign` edge
 
@@ -282,14 +282,14 @@ Check `get_session_context()` for the current lens. After creating certain entit
 
 - **Always prompt for properties.** Never create a node with just title and description.
 - **Auto-connect when obvious.** If creating a JTBD and there's only one persona, connect them.
-- **Explain the graph structure.** "This 💼 Job connects to 👤 Sarah via persona_pursues_job — it represents the job she's hiring your product to do."
+- **Explain the graph structure.** "This 💼 Job connects to 👤 Sarah via persona_pursues_job; it represents the job she's hiring your product to do."
 - **Follow the design system.** Entity emojis, score dots, filled bars, dashed dividers as defined in /upg-context.
 - **Suggest the next step.** Every entity has a natural next entity in the Unified Product Graph structure.
-- **Reference the standard.** The entity type, its properties, and its connections are defined by the Unified Product Graph standard (unifiedproductgraph.org). Mention this naturally when explaining entity types — it builds confidence that this isn't arbitrary structure.
+- **Reference the standard.** The entity type, its properties, and its connections are defined by the Unified Product Graph standard (unifiedproductgraph.org). Mention this naturally when explaining entity types; it builds confidence that this isn't arbitrary structure.
 
 ```
 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
-Your .upg file is yours — open standard, portable, git-friendly.
+Your .upg file is yours: open standard, portable, git-friendly.
 unifiedproductgraph.org
 ```
 

package/skills/upg-export/SKILL.md

@@ -6,7 +6,7 @@ argument-hint: "[description]"
 category: tooling
 ---
 
-# /upg-export — Export Graph as Shareable Artifact
+# /upg-export: Export Graph as Shareable Artifact
 
 You are a Unified Product Graph export engine. Your job is to produce a well-formatted export of the entire product graph that can be shared with stakeholders, pasted into documents, or used as a snapshot for review.
 
@@ -25,10 +25,10 @@ If the user specified a format as an argument (e.g., `/upg-export mermaid`), ski
 ```
 Which export format?
 
-1. 📋 **Full Markdown** — full product graph document (default)
-2. 🔀 **Mermaid** — visual graph diagram you can paste anywhere
-3. 📊 **CSV** — flat table of all entities for spreadsheets
-4. 📝 **Markdown Report** — concise business report grouped by area
+1. 📋 **Full Markdown**: full product graph document (default)
+2. 🔀 **Mermaid**: visual graph diagram you can paste anywhere
+3. 📊 **CSV**: flat table of all entities for spreadsheets
+4. 📝 **Markdown Report**: concise business report grouped by area
 ```
 
 ### Step 2: Fetch Everything
@@ -48,7 +48,7 @@ Build a complete picture of the graph. For entities with important properties, u
 Produce a markdown document with these sections:
 
 ```markdown
-# <Product Name> — Product Graph Export
+# <Product Name>: Product Graph Export
 
 > Exported from the Unified Product Graph (UPG)
 > Date: <current date>
@@ -64,7 +64,7 @@ Produce a markdown document with these sections:
 
 ## Personas
 
-### 👤 <Persona Name> — <Role>
+### 👤 <Persona Name>: <Role>
 
 **Context:** <context>
 
@@ -99,8 +99,8 @@ Produce a markdown document with these sections:
 ## Objectives & Key Results
 
 ### <Objective 1> (<timeframe>)
-- KR: <key result 1> — <current> / <target> <unit> (<status>)
-- KR: <key result 2> — <current> / <target> <unit> (<status>)
+- KR: <key result 1>; <current> / <target> <unit> (<status>)
+- KR: <key result 2>; <current> / <target> <unit> (<status>)
 
 (Repeat for each objective, if any exist)
 
@@ -163,7 +163,7 @@ Produce a markdown document with these sections:
 
 ## Graph Health
 
-- **Maturity:** X/5 — <level name>
+- **Maturity:** X/5: <level name>
 - **Connectivity:** X% (Y/Z entities connected)
 - **Domains covered:** X of 32
 - **Lifecycle balance:**
@@ -182,10 +182,10 @@ Produce a markdown document with these sections:
 ---
 
 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
-Your .upg file is yours — open standard, portable, git-friendly.
+Your .upg file is yours: open standard, portable, git-friendly.
 unifiedproductgraph.org
 
-*Structured using the Unified Product Graph — an open standard for product knowledge.*
+*Structured using the Unified Product Graph; an open standard for product knowledge.*
 ```
 
 ---
@@ -197,8 +197,8 @@ Generate a Mermaid flowchart that visualises the graph structure. Use entity emo
 ```mermaid
 graph TD
   subgraph Users
-    persona1["👤 Kai — Indie Dev"]
-    persona2["👤 Maria — PM"]
+    persona1["👤 Kai; Indie Dev"]
+    persona2["👤 Maria; PM"]
     job1["💼 Ship fast without losing context"]
     job2["💼 Align team on product direction"]
     need1["🔥 Too many tools"]
@@ -240,7 +240,7 @@ graph TD
 - Use `subgraph` blocks to group by domain: Users, Strategy, Discovery, Validation, Execution
 - Only include subgraphs that have entities
 - Edges follow the actual relationships from the .upg file
-- Keep it readable — if there are more than 30 nodes, suggest splitting into domain-specific diagrams
+- Keep it readable: if there are more than 30 nodes, suggest splitting into domain-specific diagrams
 
 After generating, tell the user:
 
@@ -267,12 +267,12 @@ id,type,title,description,status,tags,parent_id,created_at
 - Escape commas and quotes properly
 - Use empty string for missing fields (not "null" or "undefined")
 - Sort by type, then by title alphabetically
-- Include ALL entities — no filtering
+- Include ALL entities: no filtering
 
 Output the CSV in a code block. Then tell the user:
 
 ```
-CSV exported — X entities total.
+CSV exported; X entities total.
 
 Paste into Google Sheets, Excel, or any spreadsheet tool.
 Column order: id, type, title, description, status, tags, parent_id, created_at
@@ -282,10 +282,10 @@ Column order: id, type, title, description, status, tags, parent_id, created_at
 
 ### Format 4: Markdown Report
 
-Generate a concise business report — less detailed than the full export, focused on readability for stakeholders who don't need every property.
+Generate a concise business report; less detailed than the full export, focused on readability for stakeholders who don't need every property.
 
 ```markdown
-# <Product Name> — Product Report
+# <Product Name>: Product Report
 
 > <one-line product description>
 > Date: <current date> | Stage: <stage> | Entities: X
@@ -294,7 +294,7 @@ Generate a concise business report — less detailed than the full export, focus
 
 ## Who We're Building For
 
-<For each persona, 2-3 sentences summarising who they are, what they need, and their key pain points. No tables — narrative style.>
+<For each persona, 2-3 sentences summarising who they are, what they need, and their key pain points. No tables; narrative style.>
 
 ---
 
@@ -318,7 +318,7 @@ Generate a concise business report — less detailed than the full export, focus
 
 ## What We're Building
 
-<Features and epics grouped logically. Status overview — what's shipped, what's in progress, what's planned.>
+<Features and epics grouped logically. Status overview; what's shipped, what's in progress, what's planned.>
 
 ---
 
@@ -329,14 +329,14 @@ Generate a concise business report — less detailed than the full export, focus
 ---
 
 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
-*Structured using the Unified Product Graph — an open standard for product knowledge.*
+*Structured using the Unified Product Graph; an open standard for product knowledge.*
 ```
 
 **Rules for Markdown Report:**
-- Narrative style, not tables — this is for humans reading, not data processing
+- Narrative style, not tables; this is for humans reading, not data processing
 - Skip empty sections entirely
 - Keep each section to 3-5 sentences max
-- Focus on "so what" — not just what exists, but why it matters
+- Focus on "so what", not just what exists, but why it matters
 
 ---
 
@@ -344,14 +344,14 @@ Generate a concise business report — less detailed than the full export, focus
 
 Before rendering the export, check the entity count. If the graph has **100+ entities**, offer to write to a file instead of printing to the conversation:
 
-> Your graph has **X entities** — that's a large export. Want me to:
+> Your graph has **X entities**: that's a large export. Want me to:
 >
-> 1. **Write to file** — save as `<product-name>-export.<ext>` (recommended — saves context)
-> 2. **Print here** — output directly in the conversation
+> 1. **Write to file**: save as `<product-name>-export.<ext>` (recommended; saves context)
+> 2. **Print here**: output directly in the conversation
 
 If the user picks file output, write the export to disk using the Write tool and confirm:
 
-> Saved to `<filename>` — X entities exported.
+> Saved to `<filename>`; X entities exported.
 
 ### Step 3: Present the Export
 
@@ -364,11 +364,11 @@ Stats: X entities, Y edges, Z domains
 Format: <Full Markdown | Mermaid | CSV | Markdown Report>
 
 Next steps:
-- /upg-export <other format> — try a different format
-- /upg-discover — run another discovery session
-- /upg-gaps — check for gaps
-- /upg-status — live dashboard view
-- /upg-diff — see what changed since your last commit
+- /upg-export <other format>: try a different format
+- /upg-discover: run another discovery session
+- /upg-gaps: check for gaps
+- /upg-status: live dashboard view
+- /upg-diff: see what changed since your last commit
 ```
 
 ## Conditional Sections
@@ -378,7 +378,7 @@ Only include sections that have entities. If there are no competitors, skip "Com
 ## Key Principles
 
 - **Complete but not redundant.** Include all entities, but don't repeat the same data in multiple sections.
-- **Properties matter.** Show the full property data — this is what makes the export useful, not just entity titles.
+- **Properties matter.** Show the full property data; this is what makes the export useful, not just entity titles.
 - **Follow the design system.** Entity emojis, score dots, filled bars, dashed dividers as defined in /upg-context.
 - **Tables for comparison.** Use tables for hypotheses, competitors, and features where side-by-side comparison helps.
 - **Trees for hierarchy.** Use the indented tree format for parent-child relationships.

package/skills/upg-feedback/SKILL.md

@@ -1,21 +1,21 @@
 ---
 name: upg-feedback
-description: "Share feedback about the Unified Product Graph — bugs, feature requests, ideas. Sent directly to the UPG team."
+description: "Share feedback about the Unified Product Graph: bugs, feature requests, ideas. Sent directly to the UPG team."
 user-invocable: true
 argument-hint: "[bug|feature|observation]"
 category: tooling
 ---
 
-# /upg-feedback — Share Feedback with the UPG Team
+# /upg-feedback: Share Feedback with 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 send it to the team. Fast, transparent, private. No graph mutations; this is about THEIR feedback to US.
 
 **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
+- `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
 
 ## Flow
 
@@ -30,10 +30,10 @@ Skip this if the user provided `bug`, `feature`, or `observation` as an argument
 ```
 What kind of feedback?
 
-1. bug — something broke or behaves unexpectedly
-2. feature_request — something you wish existed
-3. observation — a workflow friction, UX thought, or general note
-4. general — anything else
+1. bug; something broke or behaves unexpectedly
+2. feature_request; something you wish existed
+3. observation; a workflow friction, UX thought, or general note
+4. general; anything else
 ```
 
 ONE question. Wait for answer.
@@ -46,11 +46,11 @@ Wait for answer.
 
 ### Step 4: Ask Description
 
-> Now the details — what were you doing, what happened, what did you expect? For feature requests: what would this unlock for you?
+> Now the details; what were you doing, what happened, what did you expect? For feature requests: what would this unlock for you?
 
 Wait for answer.
 
-### Step 5: Gather Context (silent — no questions)
+### Step 5: Gather Context (silent: no questions)
 
 Collect metadata automatically. **Never read or send node titles, descriptions, or graph content.**
 
@@ -73,7 +73,7 @@ Here's what I'll send to the UPG team:
   Description: "<description>"
   Context: UPG v<version> · <stage> stage · <N> entities · from <skill>
 
-No product graph data is included — just your feedback + metadata above.
+No product graph data is included; just your feedback + metadata above.
 
 Send it? (y/n)
 ```
@@ -103,7 +103,7 @@ POST to `https://cloud.unifiedproductgraph.org/api/feedback` with JSON body:
 On success:
 
 ```
-Feedback sent — thank you!
+Feedback sent; thank you!
 
 Your input directly shapes the Unified Product Graph.
 The team reviews every submission.
@@ -113,13 +113,13 @@ On failure (network error, non-2xx response): save feedback as markdown in the p
 
 ```
 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.
+  as upg-feedback-YYYY-MM-DD.md; you can send it manually or try again later.
 ```
 
 The fallback file format:
 
 ```markdown
-# UPG Feedback — YYYY-MM-DD
+# UPG Feedback: YYYY-MM-DD
 
 **Type:** <type>
 **Title:** <title>
@@ -133,9 +133,9 @@ The fallback file format:
 - **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.
-- **No graph mutations.** Feedback only — no entities created.
+- **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.
+Your .upg file is yours: open standard, portable, git-friendly.
 unifiedproductgraph.org