feat: add Prompt Switchboard and Provenote public skills

[xiaojiou176]

What these skills teach

• prompt-switchboard-compare-workflows: how an agent wires the local Prompt Switchboard MCP sidecar into a host, checks bridge readiness, and runs a compare-first browser workflow.
• provenote-mcp-outcome-workflows: how an agent wires the first-party Provenote MCP server into a host, starts with read-first listing tools, and then performs one narrow mutation tied back to an inspectable artifact.

Why this revision is stronger

• both skills now begin with what the agent learns
• setup and host configs are explicit in references/INSTALL.md, references/OPENHANDS_MCP_CONFIG.json, and references/OPENCLAW_MCP_CONFIG.json
• safe-first tool ordering is explicit in references/CAPABILITIES.md
• first-success paths are explicit in references/DEMO.md
• troubleshooting is explicit in references/TROUBLESHOOTING.md
• claims stay local-first and artifact-backed instead of sounding like generic product marketing

Boundaries kept explicit

• no hosted relay/runtime claims
• no "listed everywhere" claim hiding review-pending state
• no broad write automation claim without inspectable outcomes

Validation

• local packet consistency checks passed before this PR refresh

[enyst]

Thank for the PR. Like in the other PR, please see: #150 (review)

[xiaojiou176]

Updated the two skills to make them more like executable agent guidance and less like boundary disclaimers.

What changed:

• both SKILL.md files now lead with Use this skill when, What the agent should know, and Recommended workflow
• the workflows are now concrete and task-oriented instead of spending most of the space on what the projects are not
• both README.md files now explain what the skill actually teaches the agent

The intent is to make it much clearer what capability each skill adds:

• Prompt Switchboard: browser-native compare workflows with a local MCP sidecar
• Provenote: read-first outcome workflows over the first-party provenote-mcp server

I have not attached an OpenHands video yet. If that is still required after this rewrite, I can prepare a follow-up demo artifact.

[enyst]

Yes, thank you. I don’t understand the skills and how will the agent use them, I’d love to see them in actual use.

[xiaojiou176]

I pushed a larger follow-up that turns both skills into self-contained host packets rather than lightweight prompt stubs.

New material now included in each skill directory:

• references/INSTALL.md — how to install the local MCP sidecar / first-party MCP server without repo-local assumptions
• references/OPENHANDS_MCP_CONFIG.json — ready-to-edit mcpServers config
• references/OPENCLAW_MCP_CONFIG.json — OpenClaw config variant
• references/CAPABILITIES.md — exposed MCP tools and recommended first-use sequence
• references/DEMO.md — exact demo prompt, expected tool sequence, and visible success criteria

I also rewrote the SKILL.md entrypoints so they lead with:

• when to use the skill
• what the agent should know
• how to install/connect the MCP surface
• what first prompt to try

This should make the skills much closer to reusable plugin-style packets instead of boundary-only prose. If you still need a literal UI video after reviewing the new demo docs, I can prepare that as a separate follow-up.

[xiaojiou176]

Small follow-up: I also pushed one more demo refinement so the demo docs now include the shape of successful outputs, not only the prompt + tool sequence.

That means each skill now shows all of these inside its own folder:

• install steps
• MCP config
• exposed MCP tools
• first prompt to try
• what successful output should roughly look like

[xiaojiou176]

Thanks. These two skills are meant to teach capability-first MCP workflows, not introduce the products abstractly.

• prompt-switchboard-compare-workflows teaches an agent how to attach the local Prompt Switchboard MCP sidecar, check readiness first, run a compare turn, and inspect the resulting artifact instead of guessing.
• provenote-mcp-outcome-workflows teaches an agent how to attach Provenote MCP, read drafts/research threads/auditable runs first, then take one narrow next step tied to a real artifact.

Both folders are structured as self-contained packets so a host or reviewer can understand install, tool surface, safe-first order, and first-success path without reopening the source repo.

[xiaojiou176]

Revision note for re-review:

• both packets now start with what the agent learns
• install/config lives in references/INSTALL.md, references/OPENHANDS_MCP_CONFIG.json, and references/OPENCLAW_MCP_CONFIG.json
• safe-first capabilities live in references/CAPABILITIES.md
• first-success flow lives in references/DEMO.md
• troubleshooting lives in references/TROUBLESHOOTING.md
• the wording now stays centered on local-first agent workflows and inspectable outcomes, not generic product promotion

This update is intended to make the packets legible as OpenHands-facing capability kits.

[xiaojiou176]

Follow-up with actual-use proof.

You said you wanted to see how these skills are actually used, not just what they claim in prose. That is fair, so here is the most concrete proof I can add today.

prompt-switchboard-compare-workflows actual use

• Exact prompt used from the packet demo path:
  "Use Prompt Switchboard to compare this rewrite request across the ready ChatGPT and Gemini tabs: Rewrite the following onboarding email so it sounds warmer and 30% shorter. Start with prompt_switchboard.bridge_status and prompt_switchboard.check_readiness. If both tabs are ready, run prompt_switchboard.compare. After the compare turn lands, use prompt_switchboard.analyze_compare to summarize the biggest wording differences and recommend which answer is better for a friendly product update."
• Fresh repo-owned smoke proof today:
  • npm run test:mcp:smoke
  • returned a real MCP smoke payload with:
    • tools including prompt_switchboard.bridge_status, prompt_switchboard.check_readiness, prompt_switchboard.compare, prompt_switchboard.analyze_compare, prompt_switchboard.run_workflow, and prompt_switchboard.resume_workflow
    • readiness result ok=true
    • compare result status=queued, sessionId=session-smoke, turnId=turn-smoke
    • workflow result runId=run-smoke, workflowId=compare-analyze-follow-up, status=completed
• Fresh public proof surfaces that are live today:
  • first compare guide: https://xiaojiou176-open.github.io/multi-ai-sidepanel/first-compare-guide.html
  • demo GIF: https://xiaojiou176-open.github.io/multi-ai-sidepanel/assets/prompt-switchboard-demo.gif

provenote-mcp-outcome-workflows actual use

• Exact prompt used from the packet demo contract:
  "Use Provenote to inspect the current notes workspace. Start with draft.list, research_thread.list, and auditable_run.list. Summarize what already exists. Then pick one narrow next step: either research_thread.to_draft or draft.verify. Finally, explain which repo-owned artifact changed and how the user can inspect it."
• Fresh reviewer-facing proof surfaces that already exist in the repo today:
  • the public proof map: https://github.com/xiaojiou176-open/provenote/blob/main/docs/proof.md
  • the reproducible public proof pack: https://github.com/xiaojiou176-open/provenote/blob/main/examples/public-proof/auditable-markdown/README.md
  • that proof pack is explicit about the reproducible loop and expected outputs: source_id=..., run_id=..., saved_markdown=...
  • the homepage is live: https://xiaojiou176-open.github.io/provenote/

Exact remaining gap for Provenote today

• I do not have a truthfully-run local Provenote workspace loop attached in this PR thread right now.
• The exact missing piece is very specific: a provisioned local stack plus OPEN_NOTEBOOK_PASSWORD, so that draft.list / research_thread.list / auditable_run.list (or the public-proof auditable-markdown loop) can be executed live in the same way I just did for Prompt Switchboard.
• I do not want to fake that part or pretend the README proof pack is the same as a fresh local workspace run.

So the current state is:

• Prompt Switchboard now has fresh actual-use smoke evidence in addition to the packet docs
• Provenote has concrete public proof and a reproducible proof pack, but the exact missing piece for a live host-backed run is the local workspace/password-backed loop above

[enyst]

@xiaojiou176 Your agent continues to fail to prove anything works, sorry, and we will not accept in the default marketplace skills that are unproven, and on top, for software that is unproven. The default marketplace file has skills that go in thousands of installations, we cannot just do that.

However, you have a simple alternative if you wish to provide skills for OpenHands users: make a custom marketplace.json and distribute it to people.

OpenHands has extended the marketplace json format to handle skills. All you need is define a json and reference the skills in the json.

Thank you for the proposals, and sorry this doesn't work.