LearnFrom

Extract reusable learnings from the current session and apply them as updates to rules, skills, and agents in the current repo.

Workflow Routing

Analyze the Session

Review the current conversation and identify:

1. Patterns discovered — reusable conventions, architectural decisions, workflow improvements
2. Corrections made — wrong assumptions that were fixed, pitfalls encountered
3. Tool behaviors learned — CLI flags, API quirks, platform constraints
4. Process improvements — better ways to do things discovered during work

For each item, apply the reusability test: will I encounter this again? If no, skip it.

Scan Existing Artifacts FIRST

Before drafting any proposal, list every file in

rules/

skills/

agents/

Concrete signals you should be editing not creating:

• Topic overlap: existing rule covers the same domain (git, bash, markdown, ADRs)
• Adjacent guidance: existing skill mentions the same tool or workflow
• Sibling concept: existing rule covers the inverse or a related case

Only create a new file when the learning is genuinely orthogonal to everything that exists. If you find yourself writing a rule shorter than ~3 sentences, it almost certainly belongs as a paragraph in an existing file.

Determine the target artifact. The categorization decision matters — rules cost tokens every session; skills cost tokens only when invoked.

rules/

skills/*/SKILL.md

paths:

**/*.sh

skills/*/

agents/

If the guidance only matters when working on certain files (shell scripts, Python, Markdown), make it a skill with

paths:

rules/

Draft Proposals

For each identified learning, draft a concrete proposal in this priority order:

1. Append to existing rule — one paragraph added to an in-topic file
2. Append to existing skill body — for skill-scoped guidance
3. Edit existing agent instructions — for agent-specific behavior
4. New rule or skill — only when no existing artifact fits

Show the existing-file scan result alongside each proposal so the user can see what was considered and rejected.

Rules must fire on a concrete trigger. Abstract principles ("be careful with X") don't change behavior; concrete signals do ("when you're about to write Y, check Z"). Iterate the wording with the user — first drafts are usually too abstract OR too tied to one specific case. Filename should match the final framing — rename if the concept shifts during iteration.

Interactive Review

Present proposals in batches via AskUserQuestion (4 questions max per call).

For each proposal, show the target file and proposed change with a

preview

For "Adjust": ask what to change, then re-present.

After the first batch, dig deeper before declaring done. Most sessions have 2-3 obvious learnings and several non-obvious ones surfaced only by re-scanning corrections, pushback, and stuck moments. Ask yourself "what else did the user have to correct?" before stopping.

Apply Changes

For each confirmed proposal:

• New rules: write to

  rules/

  using the Write tool
• Updates: use the Edit tool on the target file
• New skills/agents: write to

  skills/

  or

  agents/

  using the Write tool

After writing, verify the file exists and has correct content.

Summary

List what was captured: rules created or updated, skills updated, agents updated, items skipped.

Constraints

• Scan existing

  rules/

  ,

  skills/

  , and

  agents/

  BEFORE drafting — a new file is the last resort, not the first instinct
• A learning shorter than ~3 sentences belongs in an existing file as an appended paragraph
• Keep rules concise (max 120 words per section per the rules

  .mdschema

  )
• New rules follow the

  .mdschema

  in

  rules/

  if present
• Apply the reusability filter strictly — session-specific fixes are not rules
• Validate against the target directory's

  .mdschema

  before writing