srs/openclaw/skills/srs-learn/SKILL.md

---
name: srs-learn
description: For developers who want to become SRS contributors or maintainers — learn SRS or any of its modules (ST, protocols, media) in depth, understand detailed code and implementation, media architecture, and the underlying knowledge behind it all. The learning path for anyone who wants to touch, modify, or extend the codebase.
---

# SRS Learn

## Purpose
Turn SRS knowledge base docs into hands-on learning sessions:
- Start from `memory/srs-*.md`
- Let the user choose what to learn
- Teach with real source code
- Default: create a new, standalone unit test file for the learner
- If the user explicitly requests reusing/modifying a specific existing utest file, follow the user's request instead of forcing a new file
- Build and run it successfully before moving on
- Teach workflow and debugging until the topic is understood

## Setup
Before starting a learning session:
- Resolve `SRS_ROOT` dynamically:
  1. If `SRS_ROOT` env is set and contains `trunk/src`, use it.
  2. Else, if current workspace (or its git root) contains `trunk/src`, use that.
  3. Else, if `~/git/srs/trunk/src` exists, use `~/git/srs`.
  4. Else, ask the user for SRS repo root.
- Confirm knowledge base files exist in workspace: `memory/srs-*.md`.
- Identify the matching specialized skill for the topic (e.g. `st-develop` for ST/coroutines). A specialized skill is **required** — if none exists, abort (see Step 3).

## Learning Workflow
Follow this sequence every time.

1. Identify the target knowledge base.
2. Summarize concrete sections and let the user choose.
3. Find the matching specialized skill — abort if none exists.
4. Teach the section with code + new utest file (build success + run success required).
5. Explain utest workflow and debugging.
6. Confirm mastery and propose the next step.

Do not skip user choice steps.

## Step 1: Select Knowledge Base
List all matching files: `memory/srs-*.md`.

Ask the user:
- Which KB file to learn now?
- What is the goal (overview, deep internals, debugging, implementation)?
- Preferred depth (quick, normal, deep)?

If the user already specifies the KB, proceed directly.

## Step 2: Summarize Concrete Learning Sections
Read the selected KB fully.

Extract concrete, teachable sections and present them as a numbered menu. For each item, include:
- Section/topic name
- What the learner will master
- Main source files/functions to inspect
- A candidate utest demo idea

Keep the menu concise and actionable (typically 3-8 items).

Ask the user to select one item before continuing.

## Step 3: Find Specialized Skill (Required)
After the user picks a section, identify the matching specialized skill.

srs-learn **cannot** create, build, or run utests on its own. It relies entirely on the specialized skill for:
- Loading the correct source code context
- Creating utest files in the right location with the right patterns
- Building and running utests

Example: for ST/coroutine topics, use `st-develop`.

**If no matching specialized skill exists for the selected topic, abort the learning task.** Tell the user which topic/module lacks a skill and that one needs to be created before this topic can be learned through srs-learn.

## Step 4: Teach with Code + New Unit Test
Read and follow the specialized skill identified in Step 3. It owns the build/test workflow.

After completing build/run for a lesson, always run the specialized skill's required verifier (if defined) before declaring completion.

By default, create a **new, standalone utest file** so each lesson has a clean, isolated artifact to study. If the user explicitly asks to continue in a specific existing utest file, modify that file instead.

Teach in this order:

1. Explain the concept briefly from KB (what and why).
2. Walk through the concrete code path (entry → core logic → output/effect).
3. Create a new utest file that demonstrates one specific behavior from the section.
4. Build the utest — confirm zero build errors.
5. Run the utest — confirm it passes.
6. Explain why the test passes based on code logic.

Both **build success** and **run success** are required before the lesson is considered complete. If either fails, debug and fix, then retry. If blocked, explicitly report the blocker and current failure output.

Unit test guidelines:
- Keep the scope narrow (one behavior per test).
- Use clear naming tied to the concept.
- Prefer deterministic inputs and assertions.
- Reuse existing utest patterns from the repository.

## Step 5: Explain Utest Workflow
After running the test, explicitly teach the workflow:
- How test setup/fixtures map to module state
- What action triggers the behavior
- What assertions validate correctness
- How this test connects to production code flow

Then give a debugging walkthrough:
- Where to set breakpoints/logs
- Which variables/state transitions matter most
- Common failure signatures
- How to isolate regressions quickly

## Step 6: Mastery Check and Iteration
Ask short mastery-check questions:
- "What does this test prove?"
- "Which function is the true decision point?"
- "If this assertion fails, where do we debug first?"

If the user wants more practice:
- Propose an extension exercise (new edge case or variation)
- Create a new utest file for it (same rules: build success + run success), unless the user explicitly asks to continue in an existing utest file
- Discuss results

## Output Format During Sessions
Use this response structure during learning sessions:

1. Selected section and objective
2. Code map (files/functions)
3. Unit test plan
4. Utest implementation + build/run results (must include test file path and explicit pass evidence)
5. Workflow explanation
6. Debugging checklist
7. Mastery check + next step

Keep explanations technical and direct. Prioritize concrete code behavior over abstract theory.