update-gateway-hub

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

Update MCP Gateway Knowledge Hub

This skill refreshes the MCP Gateway Knowledge Hub (mcps/mcp-gateway/RHCL/) by checking live sources and updating stale content. The Knowledge Hub is a 22-page 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 MCP Gateway. 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/mcp-gateway/RHCL/ recursively and extract data-verified dates from the <footer class="page-footer" data-verified="YYYY-MM-DD"> elements.

Implementation:

grep -r 'data-verified=' mcps/mcp-gateway/RHCL/ --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
RHCL Overview Deck	14ekB7bfRxvpZNl1SLBoD_MUQ7T4Ot5Tes3xvyftFOW0	Understand, Sell, Plan
MCP Gateway Delivery	1asuSND63alcJGIExLH-VvBzevtKleuuWge39lO5Su7Q	Plan (roadmap, milestones, delivery commitments)
MCP Gateway on OpenShift	1liziAy55qQBd80qRN63WTZjhu5mJRQ4-OlogP_edftQ	Build (deployment, OCP integration)
Support Agreement	11JTt4SHZJ1UFG9RWZsVL2t6MZqBFZ4Iuq4niXxtE59g	Plan (support SKU, lifecycle commitments)
Data Model Proposal	1KOLTSMVjdUhb06rQLSx4G5MVSQLXePToGAQ4wNn31m8	Build (CRDs, API design)
MCP Catalog	1L3yVBHKJLwVJ2SzF5NunzXc8gFJNZKbMU6OWfPyB_fE	Govern (catalog integration)
Partners MCP Catalog	1Z2rA0fiAC2Zt_AWnond_Ogi3-2cqEzElN-U76M1x740	Govern (partner ecosystem)

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
opendatahub-io/ai-gateway-payload-processing	Recent commits (last 30 days), any breaking changes

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/opendatahub-io/ai-gateway-payload-processing/commits --jq '.[] | select(.commit.author.date > "2026-05-21") | {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 status and key fields of these Jira tickets:

• RHAIRFE-1370 — Main registry RFE
• RHAIRFE-1457 — Gateway in RHOAI RFE
• RHAIRFE-1456 — Lifecycle operator in RHOAI RFE
• RHAISTRAT-1937 — MCP strategy ticket

Implementation:

curl -s -u "$JIRA_USER:$JIRA_TOKEN" "$JIRA_SERVER/rest/api/3/issue/RHAIRFE-1370?fields=summary,status,updated,resolution"

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:

• #mcp-gateway — General discussions, customer mentions
• #mcp-gateway-dev — Technical updates, releases, bug discussions

Fetch the last 2 weeks of messages and filter for:

• Release announcements
• Customer names (Dell, Verizon, NVIDIA, etc.)
• 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/mcp-gateway/transcripts/ — New meeting transcripts
• mcps/mcp-gateway/RHCL/ — New reference materials added directly to the site

Implementation:

# Files modified in last 30 days
find mcps/mcp-gateway/transcripts/ -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 Gateway 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: "Gateway v0.7.2 released (June 20, 2026) with multi-tenant AuthConfig support" → affects index.html (What's New), plan/roadmap.html
• Changed: "RHAIRFE-1370 status changed from Approved → Closed (June 19)" → affects reference.html
• Stale: "roadmap.html still shows v0.7.1 as latest but v0.7.2 shipped on June 20" → 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 (e.g., v0.7.1 → v0.7.2)
• Changing a Jira ticket status reference in reference.html
• Adding a new customer story bullet to sell/customer-stories.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-21">

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/mcp-gateway/RHCL/
git commit -m "chore: refresh MCP Gateway Knowledge Hub (YYYY-MM-DD)"

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

chore: refresh MCP Gateway Knowledge Hub (2026-06-21)

- Updated index.html with v0.7.2 release announcement
- Updated roadmap.html to reflect v0.7.2 milestone completion
- Updated reference.html with latest RHAIRFE-1370 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.