[feature request] Build Document Agent for OpenKruise website

[furykerry]

Note: this is a candidate lfx mentorship program, and will be assign to the selected mentee

What would you like to be added:

• agentic harness infrastructure for openkruise website (AGENTS.md, tools)
• GitHub workflow to regularly update and evaluate docs, blogs and other resources for openkruise website.
• A refreshed documentation and blogs in openkruise website.

Why is this needed:
[
OpenKruise projects involves multiple quickly evolving projects, each with its own documentation, blogs, and other resources.

This project aims to build a document agent for openkruise website, which can help to collect, update and evaluate docs, blogs and other resources for openkruise website.

[sksingh2005]

Hi @furykerry ,

I have gone the live website, and a few things stand out clearly.

Current state of the repo:

• The website is built on Docusaurus and hosts docs for four sub-projects: kruise, rollouts, kruise-game, and kruise-agents each under its own top-level nav section, maintained entirely via manual PRs with no automation.
• There are no scheduled or event-driven workflows in openkruise.io. Sub-projects like kruise and charts have their own CI (E2E, CodeQL, Chart Publish), but none of that activity flows into the website.
• kruise is already tracking v1.10 in docs, while rollouts and kruise-game show no equivalent versioning cadence on the site despite being actively developed.
• The blog has one post from 2025, then a gap back to 2023 release notes and changelogs from sub-project repos never surface as website content.
• Blog posts lack consistent metadata: no tags, no version references, no cross-links to related documentation pages.

Proposed approach:

The agent I would propose is an AGENTS.md driven harness with per-project collection rules. A scheduled GitHub Actions workflow would poll release tags and changelogs from each sub-project repository, evaluate content freshness and quality against a defined rubric, and open PRs against openkruise.io with standardized, metadata-enriched content ready for maintainer review. The agent would not publish autonomously humans review and merge. For context engineering, I would use RAG over the existing docs corpus to detect stale cross-references, and MCP tooling to standardize metadata enrichment across blog posts and versioned doc pages.

@furykerry I would appreciate your feedback on whether this direction aligns with what the project has in mind particularly the PR-based review flow and whether there are any existing automation efforts or constraints in the repo I should build on rather than duplicate.
I will also add some new findings in this comment as I dig through it more and more.

[1Ninad]

Hi @furykerry @zmberg, I came across this project through LFX mentorship and found the project interesting.
I have experience with agent frameworks (LangGraph, Pydantic AI, Dapr Agents). Happy to get any pointers on the codebase

[aprv10]

Hi @furykerry
This sounds like a really cool project. I’m especially interested in the agentic tooling and automated evaluation/update pipeline for docs and blogs.

I enjoy working on developer infrastructure, ML/AI systems and workflow automation and I’d love to contribute and learn more about the mentorship scope and current plans for implementation.

[mdryaaan]

Hi @furykerry I've been going through the OpenKruise documentation, the website repository and the upstream issue for about a week now and this project really caught my attention.

The problem makes a lot of sense to me — when documentation is spread across multiple rapidly evolving repositories it's very easy for things to go stale or become inconsistent, and having an intelligent agent handle collection, sync and quality evaluation automatically is a much better long term solution than manual maintenance.
I've been reading about the context engineering techniques mentioned in the description — RAG for retrieval, MCP for tool use, AGENTS.md for agentic configuration — and I think the combination of these with GitHub Actions for automation is a really solid architecture for this kind of problem.

One thing I wanted to ask — for the documentation collection part, is the plan to pull directly from the source repositories via GitHub API on a schedule, or is the design leaning more towards webhook-driven updates so the agent reacts to changes as they happen?

I'm really interested in contributing to this project and any guidance on where to begin or which part of the codebase to explore first would be really helpful. Thanks!

[PewterZz]

Hi @furykerry @zmberg, I'm interested in applying for this project for LFX mentorship, I'm a newbie when it comes to open source but I would love to learn more about this codebase in the coming weeks as I prepare my proposal.

[abhisheksainimitawa]

Hi @furykerry , @zmberg ,

I'm Abhishek, a Python and Go engineer, IIT Patna graduate, currently at
Infosys where I've built production MCP servers and RAG pipelines for AI
agent workflows. I also have hands-on experience with LangChain, GitHub
Actions, and agentic frameworks.

This project aligns well with my background and I'm planning to apply through
the LFX Mentorship 2026 Term 2.

A few questions before I draft my proposal:

1. Is the preference for a scheduled workflow (cron-based polling) or
   webhook-driven updates reacting to changes in sub-project repos?
2. Should the agent target the main branch of openkruise.io directly, or
   is there a staging branch where PRs should land first?
3. Are there any existing automation efforts in the repo I should be
   aware of to avoid duplication?

Thanks!

[PraverBajaj]

Hi @furykerry,

I'm applying for this project through LFX Mentorship Term 2. Rather than just describing an approach, I built a working proof-of-concept and opened a PR: #353

The PoC currently:

• Fetches releases from kruise, rollouts, kruise-game, and kruise-rollout-api via the GitHub Releases API
• Auto-detects documentation freshness (all 4 sub-projects currently flagged stale — surfaced in the freshness report)
• Auto-generates Docusaurus-compatible blog posts from release changelogs with prose fallback for sparse release bodies
• Includes a scheduled GitHub Actions workflow for weekly automation

During the mentorship term I would extend this with RAG-based cross-reference detection for stale doc links and MCP tooling for metadata enrichment + automated PR creation.

Would love any feedback on the direction before I finalize my LFX proposal — particularly on whether the staging-directory approach (agent-output/) is the right separation for human review, or if you'd prefer the agent to write directly into blog/ with a draft flag.

[PraverBajaj]

Quick update on the PoC — pushed an additional commit that extends the agent with a documentation evaluation layer alongside the existing blog generation.

The full pipeline now runs end-to-end as: fetch releases → generate blogs → evaluate existing docs → write all reports.

The evaluation layer is a pluggable package (scripts/doc_agent/checkers/) with three independent checkers:

• broken_links — detects empty hrefs and links pointing to non-existent local files
• staleness — flags docs with no git activity in > 180 days
• todo_scan — surfaces TODO / FIXME / XXX markers in docs

Running it against this repo's docs/ folder on the first try surfaced 3 broken links and 20 stale pages — including docs/core-concepts/architecture.md and docs/best-practices/hpa-configuration.md, both untouched for ~1,696 days (4.6 years). Full report is generated at agent-output/docs-evaluation-report.md in the PR.

The architecture intentionally keeps generation and evaluation as independent modules so they can be extended separately during the mentorship — Phase 2 would replace the current heuristic checkers with RAG-based semantic cross-reference detection, and Phase 3 would add MCP tooling for the agent to open targeted fix PRs back into the docs.

PR: #353

[PraverBajaj]

Another small update — pushed a pytest suite (17 tests, all passing in <100ms) covering the three doc checkers, plus a fourth checker for external links.
The external link checker HEAD-requests outbound URLs in docs/ with 1 req/sec rate limiting and a SKIP_EXTERNAL_LINKS env toggle for CI offline mode. First run against the live docs corpus surfaced 6 broken external links in addition to the 3 internal ones already reported. Full picture on the current docs:

3 broken internal links
6 broken external links
20 stale pages (>180 days since last git activity)
0 unresolved TODO/FIXME/XXX markers

All four checkers are wired into the same agent run, so a single weekly GitHub Actions execution now produces a complete docs health report alongside the release-driven blog generation.
Commit: 0e11551 on #353.

[evelyn32h]

Hi @furykerry ,

I am preparing an application for this LFX Mentorship project. I have cloned and run the openkruise.io website locally, checked both the English and Chinese locale structures, and verified that the production build succeeds.

I also reviewed the current website structure and existing workflows to better understand how documentation is maintained today. My current understanding is that this project should build on the existing Docusaurus and review-based workflow, rather than replacing it with an autonomous publishing system.

One area where I think I may be able to start with a small, low-risk contribution is a review-safe audit layer for documentation quality. Instead of modifying content automatically, the first step could be to generate structured Markdown/JSON reports that maintainers can inspect before deciding whether any follow-up issue or PR is needed.

The checks I am considering are:

1. Navigation / sidebar integrity audit
   Cross-check Docusaurus sidebar definitions against the filesystem across docs, rollouts, kruisegame, and kruiseagents. The four docs plugin instances each have separate sidebar definition files, and some navigation-level issues may not always become build-blocking errors, so a structured report could make them easier to review.

2. Frontmatter and metadata consistency audit
   Validate blog fields such as slug, title, authors, and tags, and check author handles against authors.yml. For docs, this could start with auditing title / H1 / sidebar_label conventions without rewriting content automatically.

3. Bilingual file-tree parity report as an auxiliary checker
   Compare English source files and Chinese i18n counterparts across the website. I would treat this as a deterministic coverage report, not a translation task, and let maintainers decide which gaps are intentional and which deserve follow-up.

I would keep the initial scope intentionally small and CI-friendly: the checks would produce reports or workflow artifacts for human review, rather than failing the build by default or opening publishing PRs automatically. If this foundation is useful, LLM/RAG/MCP-based repair suggestions could be explored later as a stretch goal on top of deterministic audit results.

Thank you for maintaining OpenKruise and for creating this mentorship opportunity. I would be grateful for any guidance on whether this direction fits the project expectations, and I am happy to adjust my proposal based on the maintainers’ priorities :)

[mitraboga]

Hi there! My name is Mitra Boga, an aspiring engineer ready to get more impactful open-source experience. I applied to this Mentorship from LFX (Linux Foundation). How can I get started contributing to this project and get ahead?