SRS

With codebase map, AI refined and polished the skills with specified doc, finally the evaluation show that improved 12.7% comparing to without skill.

Finished the codebase map for guiding AI to figure out the correct files or folders of code searching. It results less tokens consumed, and eventually more accurate.

@EvanDataForge Good question. We don’t have this issues right now since we mainly run on macOS and Linux, and we don’t support Windows yet. We’re planning to rewrite the project in Go, which will likely introduce cross-platform concerns. But that’s something we’ll handle when we get there.

@srs_server Nice! Consistent context across tools eliminates 'works on my machine' bugs. When all agents share the same CWD root, tracing file operations becomes much clearer. Helps with debugging and token/cost audits. How're you handling path normalization for different OSes?

I have refined the directors for AI tools: OpenClaw, Claude Code, Codex, Kiro CLI. Now all of them can find files from the current working directory. This makes the writing skills very straightforward and simple, because you don't have to consider the directory problem.

How to Setup OpenClaw for SRS. youtu.be/6MHFIokTS9A How to setup Claude Code for SRS. youtu.be/jmFdt1cHjxw How to setup Codex for SRS. youtu.be/bcV0TnCmULI

I changed the SRS project structure from C++ to Go and C++ by OpenClaw, which used ACP to leverage ClaudeCode and Codex to do the jobs. In future, all the new code should be written by AI in Go. OpenClaw is the orchestrator, which works with other AI tools support ACP.

SRS community robot is online now: t.me/+RiynvKOxpQ42M… I trained this robot with skills and knowledge base. So it works very well much better than the common AI.

Opus 4.6 enables 1m context window. It also uses subagents when evaluating the skills, which consumes less tokens. As a result, when I evaluated 12 questions and answers, it only consumed 7% of the context window. Nice. 👍

Skill is very powerful, but how to test and assure you get a stable skill over time? Claude Code supports the evaluation for skills, which is very useful. It is just a evals.json, which describe the Q&A covering the skill. It is powerful, but only supported by Claude Code.

Finished the ST knowledge base with my two AI contributors: claude and codex. And, gh (github cli) is so powerful that almost AI can do everything you can do, be careful to grant access to gh. github.com/ossrs/srs/comm…

@Steven_Liu_Qi Nop, I use VSCode to launch OpenClaw tui, and I setup the OpenClaw agent workspace to ~/git/srs/openclaw, so it is able to access the SRS. The KB and skills can also be used by other AI like claude code, not limited to OpenClaw.

@srs_server Is the third picture an app launched by Openclaw itself?

It's a easy and fantastic experience to study the code with OpenClaw, which creates utest, setup the cmake, and enable debugging for utest.

An very interesting discover: Knowledge-base enables AI to write utests with logic that can be understand by human developer. Without the KB, AI sometimes just output some garbage utest code, in order to improve the coverage rate. But this type of utest doesn't make sense.

3 Pitfalls of Using OpenClaw as Your Personal Assistant open.substack.com/pub/winlinvip/…

I find agent skills very useful because they turn "you asking questions" into "the AI asking you questions." For example, when I need AI to review or correct a document, I have to tell it which document and which section. But with skills, the AI asks me instead — I just pick the right document and section. Because when the AI uses a skill, it has already loaded the required context. So if the AI asks the right questions, I know the context is correct. And that's part of the workflow. This is why skills are so popular — they really help me communicate with AI more effectively.

I found that AI agent skills behave very consistently, similar to a programmed workflow. For example, every time I use a skill to review a section of a knowledge base, it always works correctly and uses the right matching skill. This improved my workflow and made my work more efficient, without repetitive prompts. However, keep in mind that AI skills are not programs — they don't work with 100% precision, and they only work for fixed workflows.

I'm writing a knowledge base for ST. About one-third of it is based on background knowledge from my own experience; the rest is code summaries generated by AI. I told AI to summarize specific modules and workflows — for example, the coroutine thread creation workflow. Then I change the thinking level from low to medium, to review the code summary again. This is interesting: AI is able to find errors in documents generated by AI itself. However, I still need to review the knowledge base line by line to make sure it's correct and accurate.

I'm building the knowledge base about coroutines in ST with OpenClaw, and I found a comment regarding the aarch64 register SP: Register '31' is one of two registers depending on the instruction context: For instructions dealing with the stack, it is the stack pointer, named rsp. AI told me that there's no register 31 — there's only the SP register. Then I let AI check the ST code and asked ChatGPT deep research about this issue. I confirmed this: In AArch64, register number 31 in the instruction encoding is used to represent either SP or ZR (zero register) depending on the instruction context. The problem comes from the comment in the code, which is a little vague and confusing. This is also a source of AI hallucination — a form of context poisoning.

I'm working on the knowledge base for ST (state threads), the coroutine library used in the SRS media server. It's been a long time since I last worked on this coroutine library, so I only have a general idea of it — not much detail. Still, I managed to write a brief overview of the library. Then I asked OpenClaw to read my previous blog posts, which were partly about this library, and the AI worked well — it added more information to the document. Finally, I asked OpenClaw to load the entire ST codebase (~5k lines), understand the code, and then review the document I'd generated. What surprised me was that it found several problems — parts of the document that were inaccurate or incorrect. This is what I call "context poisoning," and this is where it comes from.

🧠 Key insight from building AI-assisted open source: kills ≠ Knowledge Base. Skills LOAD the knowledge base. Published an SRS skill to @ClawHub — when you ask about SRS, it automatically loads the codebase, docs, and design decisions into context. The result? Not a generic AI guessing from stale training data — an AI that knows every detail of YOUR project, up-to-date. The knowledge base is the real asset: code + docs + the background reasoning that lives in the maintainer's head, not in the repo. Skills are just the workflow that delivers it. This is how open source scales: every developer gets an AI assistant trained with the maintainer's knowledge. No team needed. Try it 👉 clawhub.ai/winlinvip/srs-…