update-ecosystem-hub

name	update-ecosystem-hub
description	Refresh the MCP Ecosystem Knowledge Hub by sweeping live sources (Google Docs, GitHub repos, Jira tickets, Slack channels) and updating stale pages. Use when the user says "update ecosystem hub", "refresh ecosystem site", "update the MCP site", "check if the ecosystem site is current", or wants to verify the ecosystem knowledge hub is up to date.

Update MCP Ecosystem Knowledge Hub

This skill refreshes the MCP Ecosystem Knowledge Hub (mcps/ecosystem/hub/) by checking live sources and updating stale content. The Knowledge Hub is an internal reference site built from multiple live data sources (Google Docs, GitHub repos, Jira tickets, Slack channels, meeting transcripts). Over time, the site goes stale as those sources evolve. This skill automates the sweep-and-update process.

Why This Matters

The Knowledge Hub is a critical internal resource for teams working on the MCP Ecosystem. Stale information creates confusion, misaligned pitches, and wasted work. This skill ensures the site stays current with minimal manual effort.

The site tracks verification dates via data-verified attributes in each page's footer. This skill uses those dates to prioritize which pages to check first.

Process Overview

Check Staleness → Sweep Live Sources → Generate Change Report → User Approval → Update Pages → Commit

Step 1: Check Staleness

Read all HTML files in mcps/ecosystem/hub/ recursively and extract data-verified dates from the <footer class="page-footer" data-verified="YYYY-MM-DD"> elements.

Implementation:

grep -r 'data-verified=' mcps/ecosystem/hub/ --include="*.html" | sed 's/.*data-verified="\([^"]*\)".*/\1/'

Present the staleness report to the user as a numbered list:

1. Oldest pages first (highest priority)
2. Show relative staleness ("verified 15 days ago")
3. Group by section (Understand, Sell, Build, Govern, Plan)

If all pages are current (verified within the last 7 days), ask the user if they still want to run a full sweep.

Step 2: Sweep Live Sources

Check all live sources for changes. These sources are known and fixed — the skill should hardcode them for efficiency.

2a. Google Docs (use mcp__google-workspace__get_doc_as_markdown)

Fetch the latest markdown from each Google Doc with user_google_email: [e-mail] and include_comments: true:

Document	Google Doc ID	Content Area
MCP Ecosystem Strategy	1Hkfrr6hnHJ08Y1DfTNaKTa-BY06lcjejLUwVnDz_w5Y	Understand, Sell, Plan
MCP Partner Ecosystem	1rFe_OuLw8hPtzHoV9RL8IMDtuL-iEgIfPBIj0FO3vs8	Understand, Sell, Govern
MCP Operators Deep Dive	1vRu8pSLi6VMrX1Cdn64RdQTOhjQZG97BIxTRZadtjVY	Build (MCPLO architecture)
MCPLO Support Agreement	11mJpJ-Py8FxRDYdw41mMWEBvlahENS4rHqnpDNpqa8Y	Plan (support commitments)
MCP Catalog Integration	1L3yVBHKJLwVJ2SzF5NunzXc8gFJNZKbMU6OWfPyB_fE	Build, Govern (catalog design)
Partners MCP Catalog	1Z2rA0fiAC2Zt_AWnond_Ogi3-2cqEzElN-U76M1x740	Govern (partner integration)
MCP Gateway Data Model	1KOLTSMVjdUhb06rQLSx4G5MVSQLXePToGAQ4wNn31m8	Build (Gateway CRDs)
MCPLO Data Model	11JTt4SHZJ1UFG9RWZsVL2t6MZqBFZ4Iuq4niXxtE59g	Build (MCPLO CRDs)

For each Google Doc:

• Extract last modified date from the response metadata
• Note if the doc has been modified since the last hub update
• Store the full markdown content for later comparison

Run Google Doc fetches in parallel where possible.

2b. GitHub Repositories (use gh CLI)

Check for new releases, tags, and recent commits in these repos:

Repo	What to Check
Kuadrant/mcp-gateway	Latest release tag, release date, release notes
kubernetes-sigs/mcp-lifecycle-operator	Latest release tag, major commits since last check

Implementation:

# Latest release tag and date
gh release view --repo Kuadrant/mcp-gateway --json tagName,publishedAt,name,body

# Recent commits (last 30 days)
gh api repos/kubernetes-sigs/mcp-lifecycle-operator/commits --jq '.[] | select(.commit.author.date > "2026-05-22") | {sha: .sha, message: .commit.message, date: .commit.author.date}'

Note any new releases, major commits, or breaking changes.

Run GitHub checks in parallel where possible.

2c. Jira Tickets (use curl with Jira API v3)

Check the RHAISTRAT-1339 tree and its children:

Implementation:

# Main strategy ticket
curl -s -u "$JIRA_USER:$JIRA_TOKEN" "$JIRA_SERVER/rest/api/3/issue/RHAISTRAT-1339?fields=summary,status,updated,resolution"

# Find all children
curl -s -u "$JIRA_USER:$JIRA_TOKEN" "$JIRA_SERVER/rest/api/3/search/jql" \
  -H "Content-Type: application/json" \
  -d '{"jql": "parent = RHAISTRAT-1339", "fields": ["summary","status","updated","resolution"], "maxResults": 100}'

For each ticket, extract:

• Current status (e.g., Approved, In Progress, Closed)
• Last updated date
• Resolution (if closed)

Compare against the current references in the Knowledge Hub. Note if any tickets have changed status or been updated recently.

Run Jira fetches in parallel where possible.

2d. Slack Channels (use mcp__slack__get_channel_history)

Check for significant discussions or announcements in:

• #forum-ai-asset-management — General ecosystem discussions, customer mentions
• #forum-mcp-lifecycle-operator — MCPLO technical updates, releases

Fetch the last 2 weeks of messages and filter for:

• Release announcements
• Customer names or use cases
• Performance metrics or benchmark updates
• Breaking changes or deprecations

Implementation:

# Use mcp__slack__get_channel_id_by_name to get channel IDs first
# Then use mcp__slack__get_channel_history with oldest = "2 weeks ago"

2e. Local Files

Check for new files in:

• mcps/ecosystem/transcripts/ — New meeting transcripts
• mcps/ecosystem/hub/ — New reference materials added directly to the site
• docs/knowledge-review/ — Updated knowledge docs

Implementation:

# Files modified in last 30 days
find mcps/ecosystem/transcripts/ -type f -mtime -30
find docs/knowledge-review/ -type f -mtime -30

Step 3: Generate Change Report

Compare findings from Step 2 against the current content in the Knowledge Hub HTML files. Present the report as a numbered list organized by change type:

Report Format:

## MCP Ecosystem Knowledge Hub Change Report

Generated: [timestamp]

### 🆕 New Information
1. [What's new] — affects [page(s)]
2. [What's new] — affects [page(s)]

### 🔄 Changed Information
1. [What changed from → to] — affects [page(s)]
2. [What changed from → to] — affects [page(s)]

### ⚠️ Stale Information
1. [What's currently on the site but no longer accurate] — affects [page(s)]
2. [What's currently on the site but no longer accurate] — affects [page(s)]

### 📁 New Source Materials
1. [New transcript/doc/file added locally]

### ❌ Source Fetch Failures
1. [Source that couldn't be fetched] — reason: [error message]

Examples:

• New: "MCPLO v0.3.0 released (June 21, 2026) with multi-namespace support" → affects index.html (What's New), plan/roadmap.html
• Changed: "RHAISTRAT-1339 status changed from Approved → Closed (June 20)" → affects reference.html
• Stale: "roadmap.html still shows v0.2.x as latest but v0.3.0 shipped on June 21" → affects plan/roadmap.html

Step 4: Present to User for Approval

Show the change report and ask the user which updates to apply. Options:

1. Apply all updates
2. Apply specific updates (user selects by number)
3. Skip this update
4. Show detailed diff for specific changes before deciding

If the user requests a detailed diff, show the current HTML snippet vs. the proposed new snippet.

Step 5: Update Pages

For each approved change:

5a. Update Content

Edit the affected HTML file(s) to incorporate the new information. Be precise — only change what needs to change. Don't rewrite entire pages.

Examples:

• Adding a new release to the "What's New" section on index.html
• Updating a version number in the hero badge
• Changing a Jira ticket status reference in reference.html
• Adding a new partner integration to sell/partner-ecosystem.html

5b. Update data-verified Date

After updating content, update the data-verified attribute in the page's footer to today's date:

Before:

<footer class="page-footer" data-verified="2026-06-10">

After:

<footer class="page-footer" data-verified="2026-06-22">

5c. Update Staleness Indicator

The Knowledge Hub includes JavaScript that calculates staleness from data-verified. After updating the date, the staleness indicator will automatically recalculate on page load. No additional action needed.

Step 6: Commit

After all updates are applied, commit the changes:

git add mcps/ecosystem/hub/
git commit -m "chore: refresh MCP Ecosystem Knowledge Hub (YYYY-MM-DD)"

Include a bullet list in the commit message body summarizing the key changes:

chore: refresh MCP Ecosystem Knowledge Hub (2026-06-22)

- Updated index.html with MCPLO v0.3.0 release announcement
- Updated roadmap.html to reflect v0.3.0 milestone completion
- Updated reference.html with latest RHAISTRAT-1339 status (Closed)
- Refreshed data-verified dates for all updated pages

Handling Edge Cases

Source is unavailable (network failure, auth issue)

Note it in the "Source Fetch Failures" section of the report. Don't fail the entire sweep — continue with the sources that are available.

Source has been heavily modified (100+ lines changed)

Present a summary of the major changes rather than a full diff. Ask the user if they want to see the full diff or trust the summary.

Conflicting information between sources

Flag the conflict in the change report and ask the user which source to trust. Don't automatically overwrite.

No changes detected

Report "All sources checked — no updates needed. Knowledge Hub is current." and exit.

User only wants to check specific sections

Accept a section filter (e.g., "only check Build pages") and limit the sweep to HTML files in the corresponding subdirectory:

• understand/ → Understand It
• sell/ → Sell It
• build/ → Build It
• govern/ → Govern It
• plan/ → Plan It
• index.html, reference.html → Landing/reference pages

Notes

• This skill is read-heavy initially (Step 2), but write-light (only updates specific pages, not the entire site).
• Parallelizing source fetches in Step 2 significantly speeds up the sweep.
• The skill does not rebuild the site from scratch — it updates existing HTML files in place.
• The skill does not auto-commit — it always requires user approval before making changes.
• Google Workspace MCP requires user_google_email: [e-mail] — never ask the user for their email.
• Jira API uses environment variables $JIRA_USER, $JIRA_TOKEN, $JIRA_SERVER — these must be set before running the skill.
• Slack MCP requires channel names, not IDs — use mcp__slack__get_channel_id_by_name to resolve names to IDs first.