LLM Wiki

Appearance

Built 26/04/16 06:15commit dacb639

OpenClaw Field Note Capture Loop ​

中文 | English

Summary ​

This page records a more durable field-note model than direct wiki-first capture: log fresh lessons immediately into a local internal learnings system, then let recurring maintenance review that internal queue and promote only mature, reusable, sanitized lessons into the shared wiki operations section.

Why This Exists ​

A note-taking rule written only in chat is too weak, but direct wiki-first capture is also the wrong default. Shared documentation is too slow and too polished to be the first landing zone for every fresh lesson.

Durable behavior needs three layers working together:

  1. a local internal learnings system where fresh lessons are captured immediately
  2. a visible place in the repository where shared operator notes belong once they are mature
  3. a recurring maintenance prompt that reviews internal learnings and promotes only the entries that are ready to be shared

What Was Implemented ​

1. An internal-first learnings layer ​

Fresh lessons are now meant to be captured first in a local self-improvement system such as workspace .learnings/, while the exact debugging path is still fresh.

In the OpenClaw setup described here, that internal layer is provided by the self-improving-agent skill, which should be installed under ~/.openclaw/skills/self-improving-agent and used as the default local learning system.

Reference locations:

That internal layer can safely hold:

  • misdiagnosis paths
  • environment-specific checks
  • sharper local detail than a public or shared wiki should carry by default

2. A dedicated shared operations section ​

A section under wiki/operations/ remains the shared destination for real OpenClaw field notes, separate from wiki/sources/ and abstract topic pages.

Core pages:

3. Promotion rules instead of direct capture rules ​

The important change is that the wiki is no longer treated as the first place to write a fresh lesson.

The field-notes flow now works like this:

  • capture immediately into internal learnings
  • let the lesson mature there
  • promote only reusable, sanitized, clearly-shareable entries into wiki/operations/
  • make no change when nothing is mature enough yet

4. Explicit cron-prompt promotion review ​

The recurring llm-wiki maintenance jobs were updated so they do not rely on chat-memory reconstruction. Instead, they review the internal learnings file and promote only the entries that are clearly ready to be shared.

Why The Cron Layer Matters ​

This turns the promotion rule into an actual operational loop:

  • internal learnings preserve raw insight while context is fresh
  • documentation says where shared notes belong
  • the template says how to write them for reuse
  • recurring maintenance prompts ask whether any internal lesson is now ready for promotion

That combination is stronger than either memory, documentation, or delayed reconstruction alone.

How Another Operator Can Reuse This Pattern ​

  1. Install a local self-improvement skill. In this OpenClaw workflow, use self-improving-agent and store its learnings under workspace .learnings/.
  2. Create a dedicated operational-notes section in the wiki for shared notes.
  3. Add a short template that standardizes symptom, root cause, confirmation, and fix.
  4. Update one or more recurring maintenance prompts so they review internal learnings for promotion candidates.
  5. Keep promotion narrow: write notes only when they are mature enough, reusable enough, and sanitized enough to save future operators time.
  6. Prefer promoting one or two proven notes over generating broad retrospective dumps.

Guardrail ​

Do not force a note on every run. The point is to create a reliable promotion path for genuinely reusable lessons, not to turn either internal learnings or the shared wiki into maintenance noise.