| 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:
- Oldest pages first (highest priority)
- Show relative staleness ("verified 15 days ago")
- 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: pedouble@redhat.com 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:
gh release view --repo Kuadrant/mcp-gateway --json tagName,publishedAt,name,body
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 RFERHAIRFE-1457 — Gateway in RHOAI RFERHAIRFE-1456 — Lifecycle operator in RHOAI RFERHAISTRAT-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:
2e. Local Files
Check for new files in:
mcps/mcp-gateway/transcripts/ — New meeting transcriptsmcps/mcp-gateway/RHCL/ — New reference materials added directly to the site
Implementation:
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:
- Apply all updates
- Apply specific updates (user selects by number)
- Skip this update
- 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 Itsell/ → Sell Itbuild/ → Build Itgovern/ → Govern Itplan/ → Plan Itindex.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: pedouble@redhat.com — 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.
