Use cases / Changelogs
Know what changed—and why.
Keep current feature documentation separate from release history, with links back to code and decisions.
Separate current behavior from history
- Feature docs: how the product works now.
- Changelog: what changed for users in each release.
- Decisions: why the behavior changed.
Link release entries to the relevant code, tests, and current guide. Keep old entries as history rather than letting them describe today’s interface.
Create a reviewable release record
okn setup◆ Select knowledge sources
1. docs/ (3 Markdown files)
Select comma-separated numbers [1]: 1Choose your files, then create a managed copy or adopt a directory. Setup shows the plan before writing.
okn review Wiki# Open Knowledge Content Review
Review scope: `changed`
Deterministic validation: 0 errors, 0 warnings.
Treat findings as advisory.Choose an installed agent, copy the task, or save it. The task guides a review; it is not a completed review result.
okn check WikiKnowledge status
Structure READY
Links READY
Freshness NOT CONFIGURED
Retrieval NOT CONFIGURED
Overall READYStructure and links pass. Freshness and retrieval checks stay optional until you configure them.
Ask your agent to summarize the actual code diff and update the linked docs. Open Knowledge provides the structure and review workflow; it does not infer a correct release history without source material.
Find the reason behind a change
okn search Wiki "what changed for invalid source URLs?"Source: `changelog/editor-helper.md:16-23`
- Citation review now returns stable reason codes for each result.
- Users can distinguish an invalid URL from a non-HTTPS source.Find the recorded change without reading the entire release history.
Try this question in the release-history demo. It connects a user-visible validation change to its implementation and current feature guide.
Explore the example
Open the changelogs demo. It contains real Markdown pages, working links, and local search.
Open demo wiki Read citation review View source files