Generated by AI agent: add beam-create-microview skill, supersede the portal-extension one

[Brandoffsky]

Ticket

https://disruptorbeam.atlassian.net/browse/BEAM-XXXX

Brief Description

microView is the current name for the feature; the backend hasn't caught up. Every CLI command, flag, and directory still spells it extension — project new portal-extension, portal extension list-extension-options, extensions/<Name>/. Today the only skill covering this flow is beam-create-portal-extension, so an agent either uses the old name with users, or "corrects" the commands to match the new name and hits commands that don't exist.

Adds beam-create-microview, derived from beam-create-portal-extension. It speaks microViews to the user and calls the un-renamed commands verbatim, with an explicit mapping table up front so the mismatch reads as intentional:

You will see	Where
project new portal-extension	command
portal extension list-extension-options	command
portal extension add-microservice	command
portal open-extension	command
extensions/<Name>/	directory the CLI scaffolds into

Say "microView" when talking to the user; type "extension" when talking to the CLI.

Two changes beyond the rename

1. Stop on an empty mount catalog. list-extension-options reads {env}.console.beamable.com/extension-pages.json, and not every environment publishes it — an empty list is a normal outcome, not an error. The skill now tells the agent to report that and stop, because a guessed --mount-page/--mount-selector produces a microView that silently never mounts.
2. Hub-path form in the command example. The page-microView example and pitfalls now use hub / hub/page rather than <routePrefix><your-route>. The Hubs-vs-pages section (added to the portal-extension skill recently) already explains that routePrefix is a discovery marker and the ! in !hub/ is a wildcard marker rather than part of the value — the literal-concatenation phrasing elsewhere contradicts it.

On the old skill

beam-create-portal-extension is marked superseded in its description and body but kept. beam_get_skill matches on the skill name, so removing or renaming it would break anything asking for it by name; the description is what steers an agent choosing between the two.

Descriptions are deliberately plain single-line text with no wrapping quotes — McpToolExecutor.ExtractDescription is a line-prefix scan, not a YAML parser, so quoted or multi-line YAML surfaces its own quoting in the catalog output.

No registry to update: GenerateSkillDocsCommand globs SkillTemplates/*.md.scriban, and <EmbeddedResource Include="Docs\**\*.md" /> picks up the rendered result.

Checklist

• Have you added appropriate text to the CHANGELOG.md files?

Notes

Verification. The RegenerateSkillDocs MSBuild target can't run in a local checkout — its type-schema prerequisite dies on client/Packages/com.beamable/Samples/.../LootBoxService.csproj (The expression "[System.IO.File]::ReadAllText(/.config/dotnet-tools.json)" cannot be evaluated), and the target sets IgnoreExitCode="true", so the build goes green while Docs/Skills/ stays empty. That's pre-existing and unrelated to this PR, but it's worth someone looking at — it means skill-template changes are unverifiable locally through the normal build.

Verified around it instead:

1. Rendered all 17 templates through Scriban 5.12.0 (the version cli.csproj pins) replicating GenerateSkillDocsCommand's parse+render — all parse and render, and each description extracts the way ExtractDescription will read it. This matters because a template with HasErrors is logged and skipped, so a syntax error would silently drop the skill rather than fail the build.
2. Built the CLI with the rendered skills embedded and fetched the new skill over a live beam mcp serve (JSON-RPC initialize → tools/call):

beam_get_skill('beam-create-microview')  → isError=false, 13817 chars
beam_get_skill('')                       → 17 skills; superseded one points at the new one

To reproduce the MCP check: build cli/cli.csproj, run <bin>/Beamable.Tools mcp serve from a dir containing .beamroot, then initialize + tools/call beam_get_skill.

Related: #4803 fixes list-extension-options, which is step 1 of this skill — it currently 404s against a hardcoded localhost:4950. This PR is independently mergeable, but the skill's step 1 won't work until that lands (and then only on dev, which is why the empty-catalog guidance above matters).

🤖 Generated with Claude Code

[github-actions]

Lightbeam link