Provenote is a long-context-first, source-grounded workbench for structured insight, auditable markdown, notebook drafts, and outcome workflows across notes, documents, audio, and web content.
The short version: it is built to help you move from “I have too much messy material” to “I can structure it, inspect it, and keep working with the result.”
Provenote is not trying to be just another chat box over files.
Its strongest hook is the combination of:
Because a star is not only applause on GitHub. It is also a bookmark for projects that look likely to matter later.
Good reasons to star Provenote today:
No, but provenance still matters.
Provenote is a deep, productized fork of the upstream Open Notebook project. Upstream lineage remains part of the evidence story, while the current public support, release, and review boundary is repository-local to this checkout.
The current runtime contract in this repository is Gemini-first.
If you are evaluating the repo today, the practical answer is yes: plan around the Gemini-first setup described in configuration.md.
Yes, through the first-party MCP server documented in mcp.md.
The short version is:
If your starting problem is long messy context rather than agent integration, start with use-cases/long-context-to-structured-notes.md first and treat MCP as the carry-forward surface.
If you want host-specific setup and boundary notes, start with:
If you want the narrowest self-verify loop instead of the full host list, start with integrations/opencode.md. That page points back to the shipped provenote-mcp entrypoint and the concrete outcome-tool families.
Yes, at the repo-owned package layer, but not as a live official listing.
The safe current host list is:
All four are documented as compatibility-through-MCP surfaces.
Tracked public-ready example bundles now exist under ../examples/hosts/README.md, including OpenClaw-compatible layouts under examples/hosts/openclaw/.
If you want the narrowest repo-owned OpenClaw install path, use integrations/openclaw.md together with ../examples/hosts/openclaw/README.md.
Those artifacts now reach a stronger rung:
https://clawhub.ai/xiaojiou176/provenote-mcp-outcome-workflowsThe same caution applies to plugin, marketplace, and public Skills language:
If you want the exact boundary map, use project-status.md. If you want the claim ladder and distribution matrix in one place, use distribution.md.
Yes.
The repository now ships a first-party local operator CLI through the provenote command.
That surface is useful when you want to:
The honest boundary is still important:
Start with runbooks/operator-cli.md for the concrete commands. Use project-status.md if you want the bigger map around CLI, MCP, OpenClaw, and packaging claims.
Not as an official listing.
The current public surfaces are:
provenote operator CLIexamples/hosts/What is not claimed today:
In plain language: the repo already has real doors you can use, but it is not pretending there is a gift shop outside each one.
provenote.ai?Not by default.
The current repo truth supports Provenote as the product brand and treats any future .ai domain as a possible landing or redirect domain, not a reason to rename the repository, package, CLI, or MCP script surface.
In plain language: a .ai domain can help people find the product, but it does not automatically improve the product’s identity. The real differentiator is still the source-grounded, auditable outcome path.
If a domain decision happens later, keep these boundaries:
The shortest honest answer is: external publication and naming/distribution moves.
Current repo-side preparation can go far, but these steps are still outside pure repository truth:
In plain language: the workshop can be swept and labeled before someone unlocks the storefront.
If your raw material already looks like one long messy source, start with long-context-to-structured-notes.md first, then use the quick result path.
If you want the shortest general proof loop, use the quick result path:
.envThat path gives you the fastest feel for what Provenote is trying to make easier.
Start with proof.md.
It maps product claims to inspectable repo surfaces so you do not have to reverse-engineer trust from scattered files.