By Li Yong
OpenAnolis community SkillHub, an AI Agent skill platform focused on the Infra layer, has already collected several hundred skills, which we are publishing in batches. Each week we also receive best-practice write-ups from skill contributors. This time we're featuring an article by Li Yong on his experience with the Anolis KDev Engineering Memory Mechanism (kdev-memory) and Standardized Development Flow Orchestration (kdev-standardized-dev-flow) Skills. Here's what he learned:
When I first started using an AI coding Agent, I was as impressed as everyone else. Give it a single instruction and it reads the code, edits files, runs tests, and finishes the whole job in one go. It felt like having an intern who never sleeps — willing to do anything, as long as you walk it through every step.
It went fine at first. But the longer I used it, the more one thing grated on me: the same project conventions, the same coding standards, the same traps — I had to explain all of it from scratch at the start of every new session. A trap we hit yesterday was gone the moment I closed the session, and the next day the Agent walked straight into it again. Spending half an hour rebuilding its context was more work than writing the code myself.
One day I opened three sessions back to back, and each time I explained again that "this project uses test-driven development (TDD)," that "test files go in this folder," that "commit messages follow this format." By the third round it hit me: I wasn't using the Agent to work faster. I was being the Agent's parrot.
That's when I thought: wouldn't it be great if something could make the Agent remember these rules on its own?
In June I started contributing to OpenAnolis community SkillHub. Its premise was exactly what I needed — package the engineering experience you keep repeating into a Skill the Agent can invoke by itself. So I began turning all those "I have to say this every time" items into Skills, writing our engineering conventions and procedures in Markdown so the Agent could pull them up and execute them at the right moment.
The first time a Skill triggered correctly and ran the full development loop without another word from me, I finally saw the point: however smart the model gets, it can't do the job of turning our engineering experience into knowledge it can execute.
If you use an Agent on medium or large projects, you've most likely run into these two problems:
1. The Agent's "amnesia". Close the session or compress the context, and the Agent forgets the traps it hit yesterday, the decisions it made, the technical approach you settled on. Open it the next day and it looks at you blankly — "So what are we building?" You're not collaborating with an Agent; you're onboarding a brand-new intern every single day.
2. Strong capability, but no discipline. The model is very capable but works without constraints: it starts writing code before the requirements are settled, declares the job done before the tests pass, and skips testing because the change looks small. These are human failings too, but here they're worse, because you can't even correct them through feedback.
One problem calls for memory, the other for flow. I built two Skills, one after the other, on a single idea: turn experience into memory that can be persisted to disk, and turn rules into gates that actually execute.
The kdev-memory Skill tackles the biggest pain point in Agent coding — amnesia.
The idea behind kdev-memory is to give the Agent persistent engineering memory. Every step it finishes, every trap it hits, every decision it makes gets persisted to disk in real time to the right file. It carries state across sessions, rolls up daily, archives on a schedule, and can distill the memory and export it as a training corpus.
Put simply, the Agent now keeps an engineering diary. Every time it finishes a piece of work, it writes down what it did that day, what tripped it up, and what comes next. The next day a new session opens, the Agent reads the diary first, and within seconds it's back where we left off.
It used to go like this:
New session starts → "What were we working on last time?" → Agent draws a blank → you spend 20 minutes recapping the background → "Right, last time we decided on option B, because…" → "OK, let's continue"Now it goes like this:
New session starts → Agent reads memory/ automatically → "Last time we finished module XX and left two open issues: 1. …… 2. …… I suggest we handle issue 1 first, because……" → straight to workThat's the part my colleagues rate most highly: in a new session you ask one question — "where did we get to last time?" — and the Agent reports where things stand and lists every loose end, instead of making you supply the background yourself.
This Skill was itself built with Agent coding, and I hit plenty of traps along the way. A few lessons are worth spelling out.
Lesson 1: "persist to disk in real time" can't rely on the Agent's good intentions. Early versions only said in SKILL.md "record immediately after each step." In a long session with continuous discussion, I measured the result: only 2 of 6 work units were written to disk — a persistence rate of just 33%. This isn't a model capability problem. A long session offers no natural pause to act as a signal, and the Agent's attention stays pulled along by the conversation. I then added hooks as a backstop: SessionStart injects a progress summary, SessionStop checks for missed records, and SessionEnd writes a warning file. Only then did missed records really come down. Any design that asks the Agent to "keep remembering to do something" should assume it will forget, and use deterministic external signals as the backstop.
Lesson 2: passing tests don't mean the spec is right. One hook script never actually worked after it shipped, and it took weeks to notice — it read the field as camelCase toolInput, while the real payload was tool_input. The accompanying tests all passed, because the model had written them by reading the code under test and working backwards. So we set a rule: tests must be written from the official documentation, never reverse-engineered from our own code.
Lesson 3: check the code first, then the documents. The Agent is quick to treat statements in a design document as fact, and this burned us twice in the same session. So we made it an iron rule: before you mark anything "done," inspect the implementation code and confirm that the thing really exists.
We developed kdev-memory entirely with TDD, bootstrapping it on the very mechanism it provides. The development repository accumulated 51 test files and more than 600 automated test cases, and every version's CHANGELOG records which trap was involved, how it was fixed, and how many tests came with the fix.
That wasn't a deliberate goal. Once you have a reliable memory mechanism, TDD just follows — every improvement has tests behind it, and every fix gets remembered.
The kdev-standardized-dev-flow Skill tackles the other pain point: the model is very capable but works without constraints, so it starts writing code before the requirements are settled and declares the job done before the tests pass.
kdev-standardized-dev-flow orchestrates three-tier requirement decomposition and the seven-step TDD execution into a two-phase flow driven by a state machine. A few points about the design are worth sharing.
This Skill only tracks flow state, requires the external specialist skills to be invoked at the right boundaries (brainstorming, writing-plans, test-driven-development, requesting-code-review — general-purpose skills from the Agent client ecosystem, not distributed with this Skill), gates document deliverables, and recovers after an interruption. It doesn't reimplement what the specialist skills already do. In practice, a Skill with a single responsibility is much easier to compose and reuse.
This is the design I most want to share. The Agent has one habit that really gets to you — it invents reasons to skip steps.
"This feature change is tiny, we can skip the tests, right?" "The requirement is clear enough, let's skip decomposition and write the code." "The tests passed a moment ago, no need to run them again." Every one of these sounds reasonable, doesn't it? But every skipped step adds risk.
So we built hard gate rules into the Skill, plus a rebuttal table for the common skip excuses: the user must confirm before any state transition, no progress until deliverables are written to disk, and tests must fail first and then pass. Whatever reason the Agent comes up with, a gate is a gate — if it doesn't pass, it doesn't pass.
Building this constraint into the flow framework itself is far less work than reviewing after the fact.
All flow state is written to state.md, so if a session is interrupted, a new session can read the file and pick up from the breakpoint. It lives in the same namespace as kdev-memory's memory/.
Both Skills I'm sharing today follow the same idea: build reliability on state persisted to disk, not on whatever the context happens to be holding.
Shipping a Skill is just the start. What really makes it better is honest feedback from the people who use it.
After we rolled kdev-memory out internally, the most praised capability was "a new session picks up the progress in seconds" — but we also got some sharp feedback. The most pointed comment: self-scoring skews toward flattery. Ask the Agent to score the steps it has just completed and it hands itself full marks. Everybody's happy, and the inflated score tells you nothing.
In response we moved to a two-track scheme: self-scoring stays, but every round must name at least one deduction, and the final score comes from an independent Agent that reviews the work. That keeps the Agent from being both player and referee.
This improvement is exactly where community collaboration pays off — problems you've stopped noticing in your own use get exposed the moment someone else tries it.
OpenAnolis community SkillHub launched in June. The community had just set up skill hosting and review, so I adapted the two Skills I'd been refining on a long-running project to the community specifications and submitted them to the anolis-skills repository.
Adapting them took more work than I expected: following the review comments, I added prerequisite self-checks, runnable Samples, and a fallback path for when a sub-skill is missing, and I had to get authentication working end to end. kdev-memory completed its first round of merging in late June and was listed on SkillHub in early July; the merge request for kdev-standardized-dev-flow was merged in late July. Only after going through submit → review → adapt → merge did my personal experience really become an Asset the community can reuse.
When a note about a trap stops being a personal memo and becomes a rule that every Agent in the community avoids automatically, the point of open source collaboration shows itself: what you contribute isn't only Code, it's the experience itself — and a Skill turns that experience into something directly executable and directly distributable.
Going from Agent user to Skill contributor, my strongest takeaway is this: teaching an Agent to work forces you to think through your engineering constraints and write them down clearly. Judgments you made "by feel" have to become checkable specs; experience you held as "I remember" has to become memory that can be persisted to disk; hunches that "this should work" have to become verifiable gates. It isn't only the Agent that gets sharpened — it's the person writing the Skill.
If you're interested in Agent coding, come join the OpenAnolis community and help build SkillHub. Package the traps you've hit and the workflows you rely on as Skills, and contribute them. Every turn of that loop — from problem to contribution — moves the Agent coding ecosystem a little further forward.
Anolis KDev Engineering Memory Mechanism Skill Link:
https://skillhub.openanolis.cn/skill/kdev-memory
Standardized Development Flow Orchestration Skill Link:
https://skillhub.openanolis.cn/skill/kdev-standardized-dev-flow
SkillHub official site:
https://skillhub.openanolis.cn
Anolis SkillHub Picks: Deploy and Manage a PG Cluster in One Sentence
126 posts | 6 followers
FollowOpenAnolis - October 19, 2026
OpenAnolis - November 2, 2026
Alibaba Cloud Native Community - August 26, 2026
Alibaba Cloud Community - July 17, 2026
Johnny Mai - October 7, 2026
Alibaba Cloud Native Community - August 12, 2026
126 posts | 6 followers
Follow
Alibaba Cloud Linux
Alibaba Cloud Linux is a free-to-use, native operating system that provides a stable, reliable, and high-performance environment for your applications.
Learn More
Managed Service for Prometheus
Multi-source metrics are aggregated to monitor the status of your business and services in real time.
Learn More
Qwen
Full-range, open-source, multimodal, and multi-functional
Learn More
Token Plan
Build more, spend less. One plan, every modality.
Learn MoreMore Posts by OpenAnolis