continuous-learning

continuous-learning is the skill that turns one session’s discoveries into the next session’s knowledge. It’s the editorial counterpart to the propose-knowledge-update hook: the hook captures signals automatically, this skill is what the user (or the /octopus:review-proposals flow) uses to draft, test, and promote them.

Why a learning system at all

Without one, every session re-discovers the same things — the same surprising file, the same naming convention, the same project-specific gotcha. The agent has no memory across sessions, and the human has no patience for re-explaining the same context twice.

A learning system is the project-level memory: rules in rules/common/, structural facts in knowledge/, behavioural preferences in CLAUDE.md. The skill’s job is to populate those homes deliberately rather than letting them grow ad hoc.

The lifecycle of a learning

Capture. Something happened that seems worth keeping. The hook captures it automatically (corrections, re-reads, re-greps); the user can also surface a learning manually (“remember that we always use X for Y”).
Draft. The skill writes a candidate entry in the appropriate genre — a rule for “always do X”, a knowledge file for “here’s how Y works”, a CLAUDE.md line for “the user prefers Z”.
Hypothesise. The draft includes the prediction: if this becomes a rule, the agent will stop doing W next time. The prediction is testable.
Test. The next session that hits the relevant context either follows the rule or doesn’t. The skill helps the user notice which.
Promote or retire. Confirmed patterns become real rules / knowledge / CLAUDE.md lines. Patterns that didn’t hold get archived without shame — half of captured signal turns out to be one-off context, and pretending otherwise just pollutes the knowledge base.

Team mode — fleet-wide review learning

Everything above is the default mode: a single developer’s session capture to knowledge/. Team mode lifts the same capture→promote loop to the team/review scope — so “the whole team keeps making mistake X” becomes a rule instead of a re-typed PR comment.

Capture is continuous and automatic. A Stop hook — review-log-capture — reads the session transcript, pulls review findings (the BLOCKING: / ADVISORY: / QUESTION: tags architect / security / mentor / pr-review emit), and appends them to .octopus/review-log/ (gitignored). No edits to the review skills.
Aggregation is operator-run, and fleet-aware. Team mode mines the review-log across the fleet (reusing the fleet.yml repos: list), groups findings by topic, and counts both occurrences and distinct-repo spread.
Spread routes the destination. A pattern across ≥ fleet_repos distinct repos (default 3) promotes to the shared workspace: rules — inherited by every repo; a single-repo pattern over local (default 5) stays that repo’s local rule. Thresholds are configurable in fleet.yml:
fleet.yml
```
learning:
  local: 5
  fleet_repos: 3
```
Promotion stays human-gated. Candidates land in .octopus/proposals/ and are promoted via /octopus:review-proposals — team mode never auto-edits a rule. The loop closes: review → review-log → fleet-wide pattern → workspace rule → every repo inherits it.

What it doesn’t do

It doesn’t auto-edit. Every promotion is a human disposition.
It doesn’t synthesise across sessions. Each captured signal is judged on its own; the skill doesn’t infer “you said X three times” without an explicit prompt.
It doesn’t write generic advice. “Use good variable names” goes in a coding-style rule, not a learning — learnings are project-specific.

Why multi-agent-ready

Knowledge captured under Claude should also flow to Copilot, Codex, Gemini, and OpenCode. The skill writes to the canonical Octopus locations (rules/, knowledge/, CLAUDE.md-equivalents per agent) so the project-wide manifest generation can pick them up. A learning isn’t trapped in one agent’s session memory.

Source: skills/continuous-learning/SKILL.md