Research current primary-source guidance for MCP, Claude Code plugins, Codex plugins, and the language/runtime stack used by homelab plugins. Use when the user asks "what changed in the MCP SDK", "is this transport pattern still current", "find the latest docs for X", "before I scaffold this plugin I need to know...", or any time up-to-date information about MCP protocol changes, plugin manifests, SDK versions, transport patterns, package choices, Docker guidance, or the latest official docs is needed to scaffold, review, or align a plugin.
From plugin-labnpx claudepluginhub jmagar/claude-homelab --plugin plugin-labThis skill uses the workspace's default tool permissions.
references/approved-sources.mdProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Calculates TAM/SAM/SOM using top-down, bottom-up, and value theory methodologies for market sizing, revenue estimation, and startup validation.
Research current canonical information for homelab plugin work. This skill exists because local templates and past notes go stale — the only reliable way to know what is current is to consult primary sources before acting.
Use this skill for current-information questions involving:
Local repo materials — ~/workspace/plugin-templates/, language layer dirs, existing plugins — are useful as context but cannot be treated as proof of what is current. They reflect a past state of external specs. An SDK may have shipped a breaking release after the template was written. The MCP transport spec may have deprecated a pattern. A plugin manifest field may have been renamed or removed.
The consequence: scaffolding or alignment work done from local materials alone can produce a plugin that compiles and passes internal checks but fails at runtime because it relies on a superseded API. Research is the step that prevents this.
Use local repo materials to understand the current template shape, not to validate that the template shape is still correct against the upstream spec.
Prefer primary sources in this order:
Do not use secondary blog posts, tutorials, or community discussions as primary evidence. Use them only to locate primary sources faster.
Rate-limited or login-gated sources: If a primary source requires authentication or is rate-limited, use web search to extract a current summary. State explicitly in the research output that the source was accessed indirectly and that the finding may be incomplete. Do not omit the limitation — a clearly flagged partial answer is more useful than a confident answer with hidden gaps.
Step 1 — Define the exact questions.
Write down what you need to know before fetching anything. Vague research produces vague answers. Good research questions are specific: "Does the MCP Python SDK ≥1.5 require a different lifespan handler signature?" is answerable. "What is new in MCP?" is not.
Step 2 — Gather primary-source evidence for each question.
Consult the sources listed in references/approved-sources.md. For each question, identify which source is authoritative and fetch from it directly. Record the source URL, the date accessed, and the specific section or version that contains the answer.
Step 3 — Compare findings against local canonical assets.
After gathering primary-source evidence, compare it against the shared assets in ~/workspace/plugin-templates/ and the relevant language layer (~/workspace/plugin-templates/py/, ~/workspace/plugin-templates/rs/, or ~/workspace/plugin-templates/ts/).
A confirmation looks like: "The current MCP SDK README shows the same lifespan handler pattern used in ~/workspace/plugin-templates/py/my_plugin_mcp/server.py. No update required."
A conflict looks like: "The MCP Python SDK changelog for v1.6.0 introduces FastMCP.run(transport=...) as the new entrypoint, replacing the mcp.server.stdio.stdio_server() context manager used in the local template. The local template is one major version behind."
When a primary source conflicts with the local template, the primary source wins. The local template must be updated, not defended. Document the conflict explicitly — do not silently discard one side.
When primary sources conflict with each other (for example, the protocol spec and an SDK implementation disagree), apply this precedence: prefer the more recent document; when recency is equal, prefer the official protocol spec over SDK implementation; prefer SDK implementation over any generated or derived documentation. Document the conflict explicitly in the output regardless of which side wins.
Step 4 — Separate facts from recommendations.
Facts are things the source states directly. Recommendations are inferences about what the template or plugin should do as a result. Keep them in separate output sections. Do not present a recommendation as if it were a stated fact.
Step 5 — Summarize the implications.
For each conflict or change found, produce at least one concrete implication statement. An implication statement names both the upstream change and the downstream action required.
Examples of well-formed implication statements:
lifespan parameter to be an async context manager (changed in v1.6.0), which means the scaffold template's server.py startup section needs to be rewritten to use @asynccontextmanager."minVersion field as of the March 2025 spec release, which means existing plugins scaffolded before that date will fail manifest validation unless the field is added."ubuntu-latest runner now defaults to Ubuntu 24.04, which means any CI step relying on Python 3.9 system packages will fail — the workflow must pin the Python version explicitly."Vague implication statements ("this might affect the template") are not acceptable. Name the specific file, section, or field that needs to change.
Present findings in these buckets:
Confirmed current facts — things that are true now per primary sources, with citations.
Changes from prior assumptions — things the local template or prior notes assumed that are no longer accurate.
Implications for the language template — concrete, specific changes needed in ~/workspace/plugin-templates/<lang>/.
Implications for existing plugins — changes that affect already-deployed plugins, not just new scaffolds.
Open uncertainties — questions that could not be resolved from available sources.
For the open uncertainties bucket: surface an uncertainty rather than attempting to resolve it when resolution would require running code against a live service, accessing credentials you do not have, or testing behavior that only manifests at runtime. Resolve an uncertainty before writing the output when a quick doc check or source read would settle it — do not surface something as uncertain when one more lookup would answer it. When you surface an uncertainty, state clearly what evidence would resolve it.
When the work is substantial or when the findings will be consumed by another skill (scaffold, align, review), write the result to:
docs/research/<topic>-<YYYYMMDD-HHMMSS>.mdThe timestamp format is YYYYMMDD-HHMMSS (e.g., 20260401-143022).
Include:
Do not guess when information is likely to have changed. If a spec, SDK, or runtime has had a release since the template was last updated, assume it may contain breaking changes and verify.
Do not rely on secondary blog posts when official docs or source repos are available.
Call out explicitly when a recommendation is an inference rather than something directly stated in the source material. Use language like "this implies" or "based on the pattern shown in X, the likely update is..." rather than asserting it as fact.
Do not present a single source as definitive when multiple authoritative sources exist and they disagree. Surface the disagreement.
When a source is unexpectedly unavailable (404, timeout, auth wall), note the failure, fall back to the next best source, and flag in the output that the primary source was not accessible.