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

package/skills/upg-tree/SKILL.md

@@ -7,7 +7,7 @@ category: cognitive
 approaches: [inspect]
 ---
 
-# /upg-tree — Framework-Aware Tree View
+# /upg-tree: Framework-Aware Tree View
 
 You are a Unified Product Graph tree renderer. Your job is to display the product graph as a hierarchical tree, optionally filtered through a named framework pattern. You know the frameworks and can render any tree archetype.
 
@@ -20,49 +20,49 @@ Use `mcp__unified-product-graph__query` for tree fetching (one call per tree) an
 ## Usage
 
 ```
-/upg-tree              — Auto-detect best tree based on graph contents
-/upg-tree ost          — Opportunity Solution Tree
-/upg-tree okr          — Objectives & Key Results
-/upg-tree user         — Persona → JTBD → Pain Point chain
-/upg-tree product      — Product → Feature → Epic → User Story
-/upg-tree validation   — Hypothesis → Experiment → Learning
-/upg-tree strategy     — Vision → Mission → Strategic Theme → Initiative → Outcome
+/upg-tree: Auto-detect best tree based on graph contents
+/upg-tree ost: Opportunity Solution Tree
+/upg-tree okr: Objectives & Key Results
+/upg-tree user: Persona → JTBD → Pain Point chain
+/upg-tree product: Product → Feature → Epic → User Story
+/upg-tree validation: Hypothesis → Experiment → Learning
+/upg-tree strategy: Vision → Mission → Strategic Theme → Initiative → Outcome
 ```
 
 ## Named Tree Patterns
 
-### `ost` — Opportunity Solution Tree
+### `ost`: Opportunity Solution Tree
 
 **Origin:** Teresa Torres, *"Continuous Discovery Habits"*, 2021
 **Question:** "How do we discover the best path from outcome to solution?"
 **Chain:** 🎯 outcome → 💡 opportunity → 🔧 solution → ⚗️ hypothesis → 🧪 experiment_plan
 **Edges:** outcome_reveals_opportunity → opportunity_drives_solution → solution_proposes_hypothesis → hypothesis_requires_experiment_plan
 
-### `okr` — Objectives & Key Results
+### `okr`: Objectives & Key Results
 
 **Origin:** John Doerr, adapted from Andy Grove (Intel), 1999
 **Question:** "What are we trying to achieve, and how do we know?"
 **Chain:** 🎯 objective → 🎯 key_result → 🎯 initiative
 
-### `user` — User Discovery Tree
+### `user`: User Discovery Tree
 
 **Origin:** Clayton Christensen, Jobs-to-be-Done theory, 2003
 **Question:** "Who are our users, what jobs are they hiring us for, and where does it hurt?"
 **Chain:** 👤 persona → 💼 job → 🔥 need
 
-### `product` — Product Breakdown Tree
+### `product`: Product Breakdown Tree
 
 **Origin:** Standard agile product management
 **Question:** "What are we shipping, and how is it broken down?"
 **Chain:** 🎯 product → 📦 feature → 📋 epic → 📄 user_story
 
-### `validation` — Validation Tree
+### `validation`: Validation Tree
 
 **Origin:** Eric Ries, *"The Lean Startup"*, 2011
 **Question:** "What are we betting, how are we testing, and what have we learned?"
 **Chain:** ⚗️ hypothesis → 🧪 experiment → 📝 learning
 
-### `strategy` — Strategic Cascade
+### `strategy`: Strategic Cascade
 
 **Origin:** Roger Martin, *"Playing to Win"*, 2013
 **Question:** "How does the vision cascade down to measurable outcomes?"
@@ -147,7 +147,7 @@ Example rendering (OST):
 │
 ├─ 💡 Users don't get value in first 5 min
 │     reach ● ● ● ● ●   pain ● ● ● ● ○   freq ● ● ● ○ ○
-│     (no solutions — /upg-explore a solution)
+│     (no solutions; /upg-explore a solution)
 │
 └─ 💡 Onboarding asks for too much upfront
       reach ● ● ● ● ○   pain ● ● ● ○ ○   freq ● ● ● ● ○
@@ -157,7 +157,7 @@ Example rendering (OST):
 Example rendering (User tree):
 
 ```
-👤 Sarah Chen — Senior PM at Series B Startup
+👤 Sarah Chen: Senior PM at Series B Startup
 │
 ├─ 💼 Track decisions on mobile
 │  │  type: functional
@@ -195,7 +195,7 @@ After the tree, display outside the code block:
 
 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
 
-*<Framework Name>* — <Creator>, <Year>
+*<Framework Name>*; <Creator>, <Year>
 
 **<N>** entities shown · **<N>** levels deep · <breakdown by type emojis>
 
@@ -227,7 +227,7 @@ If the graph is empty or has no entities matching the requested pattern:
 ## Key Principles
 
 - **Framework attribution matters.** Always credit the framework's creator.
-- **Show properties, not just titles.** A tree of titles is useless — show the data.
+- **Show properties, not just titles.** A tree of titles is useless; show the data.
 - **Auto-detect when possible.** If the user just says `/upg-tree`, pick the most informative view.
 - **Suggest other views.** After rendering one tree, mention the other available patterns.
 - **Follow the design system.** Entity emojis, score dots, filled bars, nested blocks, annotation arrows.

package/skills/upg-verify/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: upg-verify
-description: "Code-to-graph sync audit — find product knowledge in your codebase that isn't in the graph yet"
+description: "Code-to-graph sync audit: find product knowledge in your codebase that isn't in the graph yet"
 user-invocable: true
 argument-hint: "[scope]"
 category: cognitive
 approaches: [inspect]
 ---
 
-# /upg-verify — Code-to-Graph Sync Audit
+# /upg-verify: Code-to-Graph Sync Audit
 
 You are a Unified Product Graph consistency auditor. Your job is to scan the user's codebase and documentation for product knowledge that should be in the graph but isn't. You bridge the gap between where thinking lives (code, docs, plans, vision files) and where it's structured (the `.upg` graph).
 
@@ -38,24 +38,24 @@ If the user provided a scope argument, use that. Otherwise, ask:
 ```
 What should I audit? Pick one (or say "full"):
 
-1. **Features** — capabilities in your code not modeled in the graph
-2. **Personas** — user types referenced in docs but missing from the graph
-3. **Decisions** — strategic decisions documented but not captured
-4. **Research** — user evidence and insights scattered across docs
-5. **Architecture** — system structure that maps to product entities
-6. **Full audit** — all of the above
+1. **Features**: capabilities in your code not modeled in the graph
+2. **Personas**: user types referenced in docs but missing from the graph
+3. **Decisions**: strategic decisions documented but not captured
+4. **Research**: user evidence and insights scattered across docs
+5. **Architecture**: system structure that maps to product entities
+6. **Full audit**: all of the above
 ```
 
 ### Step 3: Scan the Codebase
 
-Based on the chosen scope, scan relevant files. Be targeted — don't read the entire codebase.
+Based on the chosen scope, scan relevant files. Be targeted; don't read the entire codebase.
 
 #### Features scope
 Scan for product capabilities not in the graph:
-- **App route definitions** — `app/**/page.tsx`, route groups, API routes → feature-worthy surfaces
-- **Feature flags or config** — search for `feature_flag`, `FEATURES`, `enabled` in config files
-- **README files** — feature lists in project READMEs
-- **CHANGELOG or release notes** — shipped features
+- **App route definitions**: `app/**/page.tsx`, route groups, API routes → feature-worthy surfaces
+- **Feature flags or config**: search for `feature_flag`, `FEATURES`, `enabled` in config files
+- **README files**: feature lists in project READMEs
+- **CHANGELOG or release notes**: shipped features
 
 ```bash
 # Example scans
@@ -65,32 +65,32 @@ find apps/ -name "page.tsx" -path "*/app/*"
 
 #### Personas scope
 Scan for user types referenced but not in graph:
-- **AGENTS.md / CLAUDE.md files** — persona names, user descriptions
-- **Vision documents** — wherever your team keeps vision / strategy docs
-- **Skill / prompt files** — persona references in agent prompts
-- **Comments and docs** — "users", "customers", named user types
+- **AGENTS.md / CLAUDE.md files**: persona names, user descriptions
+- **Vision documents**: wherever your team keeps vision / strategy docs
+- **Skill / prompt files**: persona references in agent prompts
+- **Comments and docs**: "users", "customers", named user types
 
 Search terms: persona names, "user", "customer", "builder", "creator", named roles.
 
 #### Decisions scope
 Scan for strategic decisions not captured as graph entities:
-- **Decision docs / ADRs** — wherever your team records architecture decisions
-- **Plan files** — completed plans = decisions
-- **AGENTS.md / CLAUDE.md** — documented decisions and conventions
+- **Decision docs / ADRs**: wherever your team records architecture decisions
+- **Plan files**: completed plans = decisions
+- **AGENTS.md / CLAUDE.md**: documented decisions and conventions
 
 #### Research scope
 Scan for user evidence and insights:
-- **Session logs** — dated session / standup notes
-- **Progress logs** — release notes, weekly digests
-- **Vision docs** — user research references, quotes, findings
-- **Plan files** — research findings that motivated the plan
+- **Session logs**: dated session / standup notes
+- **Progress logs**: release notes, weekly digests
+- **Vision docs**: user research references, quotes, findings
+- **Plan files**: research findings that motivated the plan
 
 #### Architecture scope
 Scan for system structure that maps to product entities:
-- **App directories** — each app could be a `product_area` or `bounded_context`
-- **Package structure** — shared packages as `capability` or `service` entities
-- **Database schemas** — Supabase schemas, migrations
-- **API surface** — API routes, MCP tools, external integrations
+- **App directories**: each app could be a `product_area` or `bounded_context`
+- **Package structure**: shared packages as `capability` or `service` entities
+- **Database schemas**: Supabase schemas, migrations
+- **API surface**: API routes, MCP tools, external integrations
 
 #### Full audit
 Run all five scopes sequentially. Present each scope's findings, then a combined summary.
@@ -101,9 +101,9 @@ For each discovered item:
 1. Search the graph: `search_nodes(title_or_keyword)`
 2. Also check by type: `list_nodes({ type: 'likely_type' })`
 3. Classify:
-   - **In graph** — already captured, no action needed
-   - **Partially in graph** — exists but missing detail or connections
-   - **Not in graph** — gap, needs to be added
+   - **In graph**: already captured, no action needed
+   - **Partially in graph**: exists but missing detail or connections
+   - **Not in graph**: gap, needs to be added
 
 ### Step 5: Score Confidence
 
@@ -113,7 +113,7 @@ Each discovered item gets a confidence score:
 |-------|---------|--------|
 | ⚪ Low (1-2) | Mentioned once, might be exploratory | Ask: "Is this real or just brainstorming?" |
 | 🟡 Medium (3) | Referenced in multiple places or formally documented | Suggest adding with `/upg-explore` |
-| 🟢 High (4-5) | Clearly intentional — appears in code, docs, AND discussions | Strongly recommend adding |
+| 🟢 High (4-5) | Clearly intentional; appears in code, docs, AND discussions | Strongly recommend adding |
 
 **Confidence factors:**
 - Mentioned in multiple files → +1
@@ -130,18 +130,18 @@ Format as a clear, scannable report:
 ## Verify Report: [Scope]
 
 ### Graph Inventory
-  📊 **[Product Name]** — [N] entities, [M] edges
+  📊 **[Product Name]**: [N] entities, [M] edges
   Stage: [stage]
 
 ### Findings
 
 #### 🟢 High Confidence (should be in graph)
 
-  1. 👤 **Kai — Technical Solo Founder**
+  1. 👤 **Kai: Technical Solo Founder**
      Found in: CLAUDE.md, skills/upg-context/SKILL.md, docs/vision.md
      Graph status: ❌ Not found
      Suggested type: persona
-     → `/upg-explore persona "Kai — Technical Solo Founder"`
+     → `/upg-explore persona "Kai; Technical Solo Founder"`
 
   2. 📦 **Clean URL Routing**
      Found in: PR #747, plans/2026-03-22-graph-clean-url-routing.md
@@ -164,10 +164,10 @@ Format as a clear, scannable report:
      → Probably an internal process, not a product entity. Skip?
 
 ### Summary
-  🟢 High: [X] items — strongly recommend adding
-  🟡 Medium: [Y] items — worth considering
-  ⚪ Low: [Z] items — probably not graph-worthy
-  ✅ Already in graph: [W] items — no action needed
+  🟢 High: [X] items; strongly recommend adding
+  🟡 Medium: [Y] items; worth considering
+  ⚪ Low: [Z] items; probably not graph-worthy
+  ✅ Already in graph: [W] items; no action needed
 
   Coverage: [%] of discovered items are in the graph
 ```
@@ -180,9 +180,9 @@ For high-confidence items, offer batch creation:
 Want me to add the [X] high-confidence items to your graph?
 I'll create them as individual entities with the suggested types.
 
-1. Yes — add all [X] items
+1. Yes; add all [X] items
 2. Let me pick which ones
-3. Not now — I'll do it manually later
+3. Not now; I'll do it manually later
 ```
 
 If the user picks option 1 or 2, use `mcp__unified-product-graph__create_node` for each, following the entity confirmation pattern from `/upg-context`.
@@ -196,7 +196,7 @@ Follow the smart ending pattern from `/upg-context`:
 
 ```
 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
-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-workspace/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: upg-workspace
-description: "Manage your UPG workspace — list products, switch between them, add new ones"
+description: "Manage your UPG workspace: list products, switch between them, add new ones"
 user-invocable: true
 argument-hint: "[list|switch|add|init]"
 category: tooling
 ---
 
-# /upg-workspace — Manage Your Product Workspace
+# /upg-workspace: Manage Your Product Workspace
 
 Manage multiple product graphs. Fast, direct, sub-commands keep it tight. Read `/upg-context` before producing output.
 
@@ -20,13 +20,13 @@ Manage multiple product graphs. Fast, direct, sub-commands keep it tight. Read `
 
 Check if `.upg/workspace.json` exists (Bash). Call `list_local_products` for entity counts.
 
-**Workspace mode** (workspace.json exists) — read `default_product` to mark active:
+**Workspace mode** (workspace.json exists); read `default_product` to mark active:
 ```
 ## Your UPG Workspace
   📁 .upg/ (workspace mode)
-  1. ● My SaaS (active) — 42 entities, mvp stage
-  2. ○ Client Project — 12 entities, idea stage
-  3. ○ Internal Tools — 8 entities, idea stage
+  1. ● My SaaS (active); 42 entities, mvp stage
+  2. ○ Client Project; 12 entities, idea stage
+  3. ○ Internal Tools; 8 entities, idea stage
   Switch: /upg-workspace switch <number>
   Add:    /upg-workspace add
 ```
@@ -35,7 +35,7 @@ Check if `.upg/workspace.json` exists (Bash). Call `list_local_products` for ent
 ```
 ## Your UPG Workspace
   📄 Single-file mode (product.upg)
-  ● My SaaS — 42 entities, mvp stage
+  ● My SaaS; 42 entities, mvp stage
   Want multiple products? Run /upg-workspace init
 ```
 If multiple loose files, number them and suggest `init`. If zero files, point to `/upg-init`.
@@ -52,7 +52,7 @@ If multiple loose files, number them and suggest `init`. If zero files, point to
 
 ## `add`
 
-1. Ask: **"What's the name of the new product?"** — one question, STOP, wait.
+1. Ask: **"What's the name of the new product?"**: one question, STOP, wait.
 2. Create blank .upg file via Bash. Path: `.upg/<kebab-slug>.upg` if workspace mode, else `<kebab-slug>.upg` in cwd. Generate id: `node -e "import('nanoid').then(m => console.log(m.nanoid(16)))"`. File structure:
    ```json
    { "upg_version": "0.5.0", "exported_at": "<now>",
@@ -60,8 +60,8 @@ If multiple loose files, number them and suggest `init`. If zero files, point to
      "product": { "id": "<nanoid>", "title": "<title>", "stage": "idea" },
      "nodes": [], "edges": [] }
    ```
-3. If workspace mode, update workspace.json — add to `products` array.
-4. Confirm: `✓ Created **Client Project** (.upg/client-project.upg)` — then ask "Switch to it now? [Y/n]". If yes, run switch logic.
+3. If workspace mode, update workspace.json; add to `products` array.
+4. Confirm: `✓ Created **Client Project** (.upg/client-project.upg)`, then ask "Switch to it now? [Y/n]". If yes, run switch logic.
 
 ---
 
@@ -93,11 +93,11 @@ Otherwise:
 - Active product = `●` filled dot. Others = `○` open dot.
 - Number products starting at 1. Users switch by number, not file path.
 - Show entity count (nodes) and stage for each product.
-- No unnecessary questions — `list` and `switch` need zero extra input.
+- No unnecessary questions: `list` and `switch` need zero extra input.
 - Standard footer on every output:
 
 ```
 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
-Your .upg file is yours — open standard, portable, git-friendly.
+Your .upg file is yours: open standard, portable, git-friendly.
 unifiedproductgraph.org
 ```