Claude Skills tutorial series — Part 4: From measured to learning and orchestrating (L6 → L7)

In part 3 you took a skill from "feels right" to "measurably right" — Maturity Level 5. For most skills that's enough. But for a handful of skills you use daily, or that steer other skills, you want to go further: a skill that learns from its own executions (L6), and a skill that steers other agents inside a larger workflow (L7). This fourth part shows how you get there — and how the Hydra dashboard lets you monitor your whole skill library for maturity at once.

Recap: the 7 levels, and where we are now

Important: levels are cumulative in criteria but not always in practice. A skill can have an L7 architecture (spawns eight parallel agents) without having L5 evals — that's called structural L7, maturity L4. The architecture is there, the self-knowledge isn't. For real L7 you need L1 through L6 alongside it.

Level 6: Self-Improvement — skills that learn from their executions

An L5 skill is measured, but static. Each execution runs disconnected from the previous one; what you learned last week, the skill forgets tomorrow. L6 solves that with a learnings loop:

Execution  →  capture observations  →  learnings.md  →  consolidation  →  SKILL.md rules
                                          ↑                              │
                                          └──────────────────────────────┘

The ingredients

Three things make a skill L6-mature:

1. A learnings.md in the skill folder.
2. A "Capture Learnings" step at the end of SKILL.md — Claude is explicitly asked at the end of every execution whether anything in the run stood out that could help a future run.
3. A consolidation rhythm — typically at 80–100 entries you look back, remove outdated rules, merge duplicates, and promote validated principles into guardrails inside SKILL.md itself.

The format of learnings.md

Each entry is dated and atomic (one insight per bullet). The file has five fixed sections:

# Learnings — create-pr

## Patterns That Work
- 2026-03-15: Branch protection op `main` vraagt status checks — altijd eerst verifiëren dat ze bestaan.
- 2026-03-20: GitHub issue-nummer in PR-titel verbetert traceability.

## Mistakes to Avoid
- 2026-03-18: NIET een PR maken met uncommitted changes — onduidelijk wat er meegaat.
- 2026-03-22: composer.lock-conflict → lokaal `composer update` draaien, niet één kant accepteren.

## Domain Knowledge
- 2026-03-19: Conduction-repos gebruiken `development` als primaire integratie-branch, niet `main`.

## Open Questions
- Moeten PRs reviewers auto-assignen via CODEOWNERS?

## Consolidated Principles
- (gepromoot na 3+ bevestigingen)
- Draai altijd `composer check:strict` vóór PR-aanmaak — vangt 90% van review-feedback af.

The "Capture Learnings" step in SKILL.md

learnings.md doesn't fill itself — Claude only does that if you ask explicitly. The way to ask is a fixed step, all the way at the bottom of SKILL.md, after every execution step and before the guardrails. Below is an example as it sits in Conduction's create-pr skill — short, with the five sections stated up front so Claude doesn't forget them:

## Capture Learnings

After execution, review what happened and append new observations to
[learnings.md](learnings.md) under the appropriate section:

- **Patterns That Work** — approaches that produced good results
- **Mistakes to Avoid** — errors encountered and how they were resolved
- **Domain Knowledge** — facts discovered during this run
- **Open Questions** — unresolved items for future investigation

Each entry must include today's date. One insight per bullet.
**Skip if nothing new was learned** — do NOT invent learnings to fill the section.

Three things to notice:

1. It's a step, not a suggestion. By formatting it as a ## Capture Learnings section, it sits in the same "do this" mode as the other numbered steps. A non-committal sentence like "remember to write something down if you feel like it" gets skipped by Claude often.
2. "Skip if nothing new was learned" is crucial. Without that rule, Claude always produces something — pseudo-insights like "the skill executed successfully". That's exactly the kind of noise that quickly pollutes learnings.md and eats your context budget on every run.
3. Spell out the intent per section — not just the name. "Patterns That Work" alone triggers generic content; "approaches that produced good results" steers Claude into focused observational behaviour.

Variant for skills with a container/headless mode: add a table at the top of SKILL.md that explicitly says the Capture Learnings step is skipped in headless mode (a container filesystem is disposable — writing to learnings.md is wasted). The opsx-apply skill does it like this:

| Step | Interactive mode | Headless mode (CI) |
|---|---|---|
| Capture Learnings | Append to `learnings.md` | **Skip** — container filesystem is disposable |

The two-stage buffer (strongly recommended)

The naive pattern — writing every observation directly into learnings.md — fills the file with noise fast. A teammate reported something that "felt off" but on reflection was a coincidental fluctuation; now it's there, and Claude reads it on every run.

The fix is a two-stage buffer:

learning-candidates.md  →  (promotion criteria met?)  →  learnings.md  →  SKILL.md rules
        ↓ (no)
   removed after 30 days

Promotion criteria are deliberately strict:

• Observation confirmed at least 3 times in separate executions, or
• Observation fixes a measured eval failure from part 3.

That keeps learnings.md clean and stops context budget being wasted on one-off coincidences.

When do you consolidate?

Around ~80–100 entries learnings.md itself becomes a context load. That's when you trigger a consolidation round:

1. Outdated? — remove (the bug has been patched, the rule no longer applies).
2. Duplicates? — merge into one sharper bullet.
3. Cross-cutting pattern? — promote to the "Consolidated Principles" section.
4. Validated principle? — write it as a guardrail or step directly into SKILL.md, and remove the loose observations that led to it from learnings.md.

Level 7: AI Workforce — skills that steer other agents

L7 isn't a "better skill" — it's a different kind of skill. An L7 skill doesn't produce output itself; it coordinates a team of sub-agents, or sits inside a chain of skills that hand off to each other.

Criteria (on top of L6)

• Spawns sub-agents (parallel workers) or is itself invoked by a parent skill.
• Sits in a defined workflow chain with explicit hand-off points:

  opsx-new → opsx-ff → opsx-plan-to-issues → opsx-apply → opsx-verify → opsx-archive
  

• Passes context forward to the next skill (shows "Next step: run /opsx-verify").
• Uses isolated execution contexts where needed (git worktrees, Docker, sandbox).
• Has autonomy within a defined scope — not everything asks for confirmation.
• Does parallel work (eight agents at once, fan-out/fan-in).

Orchestration patterns in Hydra

Structural L7 ≠ mature L7

It's tempting to stand up an orchestrator and call your work done. But if that orchestrator has no evals (L5) and no learnings loop (L6), you have a complex machine without self-knowledge. It does a lot; you don't know how well.

That's called structural L7, maturity L4. The problem: once it fails, no one knows where in the chain things went wrong, and the error repeats tomorrow. For real L7 you need to close the L5 and L6 gaps — measure the chain as a whole and at the hand-off points, and let the orchestrator capture observations itself.

Monitoring the whole library: the skill-level-overview dashboard

Taking one skill to L6 or L7 is manageable. But once you have a library of ten, twenty, or (as in Hydra) ~70 skills, you want to see at a glance which skill sits at which level — and which ones are sliding back.

For that, the Conduction skill toolchain ships two files under .claude/skills/:

• skill-level-overview.html — a local, static HTML dashboard. One table per skill: current maturity (green dots), target maturity (badge), SKILL.md line count (coloured: green ≤200, yellow around 450, red >500), and orange rings for "structurally present but not yet mature". Sortable by column. You open it locally — xdg-open on Linux, open on macOS, or double-click in the file explorer.
• update-skill-overview.sh — a bash script that scans every skill folder, detects structural markers (frontmatter present, guardrails, evals with enough trigger tests, dated learnings, agent spawns), and writes the HTML back up to date. One ./update-skill-overview.sh and your dashboard is correct again.

What the script does automatically

The script detects:

A key design choice: L4 is never set automatically. Domain knowledge isn't detectable from file structure — only you can say whether a skill really knows your business. The script shouts for attention when L1–L3 are in place but L4 isn't confirmed yet.

How to set this up for your own project

The canonical skill-level-overview.html + update-skill-overview.sh live in Conduction's internal skill toolchain. Two paths to get going with it yourself:

• Ask for the files — email us via the CTA at the bottom of this page; we're happy to share the current version with customers and partners as a starting point. After that it's cp to <your-repo>/.claude/skills/ and run bash .claude/skills/update-skill-overview.sh.
• Build it yourself — the measurement rules in the table above are all you need. A few hours of bash and a simple HTML table template will already give you a working v1.

A natural place to run the script: before a release tag, in a pre-commit hook on the skills folder, or as a weekly cron. That way you see drift (a skill that grows to 520 lines and therefore loses L2) immediately.

Test yourself

Four short questions to check whether you got this part. Stuck? Click Hint. Curious about the answer? Click Answer.