/ll

description: "Extract lessons learned from the current session. Scans conversation for error→fix patterns, user corrections, and discoveries, then saves structured lessons to the wiki."
argument-hint: "[\"topic hint\"] [--wiki <name>] [--local] [--dry-run] [--rules] [--include-archived]"
allowed-tools: Read, Write, Edit, Glob, Grep, Bash(ls:*), Bash(wc:*), Bash(date:*), Bash(mkdir:*)

Your task

**Resolve the wiki.** Do NOT search the filesystem or read reference files — follow these steps: 1. Read `$HOME/.config/llm-wiki/config.json`. If it has `hub_path`, expand leading `~` only (not tildes in `com~apple~CloudDocs`) and prefer that path; use `resolved_path` only as a fallback cache when the expanded `hub_path` is unavailable and `resolved_path` is initialized. If config has only `resolved_path`, use it. If the configured path can be statted but reading `wikis.json` or listing `topics/` fails with `Operation not permitted`, stop and ask the user to grant Full Disk Access/iCloud Drive access to the launcher; do not fall back to `~/wiki` or `resolved_path`. Do not write machine-specific `resolved_path` into shared configs. 2. If no config → read `$HOME/wiki/_index.md`. If it exists → HUB = `$HOME/wiki`. If nothing found, ask the user where to create the wiki. 3. **Wiki location** (first match): `--local` → `.wiki/` in CWD; `--wiki <name>` → `HUB/wikis.json` lookup with portable path resolution (`<HUB>`, `~`, absolute, or HUB-relative); if the registry path is stale, fall back to `HUB/topics/<name>`; CWD has `.wiki/` → use it; else → HUB. 4. Read `<wiki>/_index.md` to verify. If missing and no wiki matches the session topic → offer to create one with `--new-topic`; otherwise target the most relevant existing wiki.

Archive rule: lessons learned go to active topic wikis by default. Skip archived topics when auto-targeting by session topic. If `--wiki <name>` resolves to an archived topic, stop and ask the user to restore it or rerun with `--include-archived`; explicit archived writes must stay inside the archived topic path and keep it archived.

Extract lessons learned from the current session and save them to the wiki's knowledge pipeline.

Inventory awareness: if a lesson implies a durable follow-up, recurring watch item, or source/corpus candidate, suggest an inventory record in addition to the raw lesson note. Do not turn every lesson into inventory; only use it when there is status, priority, or a next action to track.

Parse $ARGUMENTS

• **topic hint** (positional, optional): A phrase describing what the session was about. If omitted, infer from conversation context.
• **--wiki <name>**: Target a specific topic wiki
• **--local**: Use project-local `.wiki/`
• **--dry-run**: Show extracted lessons without writing anything
• **--rules**: Also suggest CLAUDE.md / AGENTS.md rule additions
• **--include-archived**: Explicitly allow writing lessons to an archived

target wiki.

What This Command Does

Lessons-learned captures knowledge that was **learned by doing** — not by reading. The source material is the current session: errors hit, fixes discovered, corrections from the user, configuration changes, gotchas, and patterns that only emerged during implementation.

This differs from other commands:

• **ingest** takes external material in (URLs, files, text from outside)
• **compile** synthesizes raw sources into articles
• **ll** takes internal experience out (session context → structured knowledge)

Trigger Patterns (for router)

"learn this", "learn that lesson", "lesson learned", "lessons learned", "absorb this", "capture what we learned", "what did we learn", "session takeaways", "ll"

---

Stage 1: Session Scan

Read the conversation history and identify lesson-worthy events. Look for these signals, in priority order:

1a. Error→Fix Patterns

Sequences where something failed, was diagnosed, and fixed. Extract:

• **Symptom**: The error message or failure behavior
• **Assumption**: What was initially believed (if different from root cause)
• **Root cause**: The actual problem
• **Fix**: What was done to resolve it

1b. User Corrections

Moments where the user redirected the approach: "no, not that", "wrong profile", "use X instead", "that's the wrong file." Each correction implies a lesson about what the correct approach is.

1c. Discoveries

Things that worked unexpectedly, or where the solution required non-obvious knowledge. The test: "would this have been obvious to someone starting the same task?"

1d. Configuration Changes

Files that were created or modified during the session — especially dotfiles, settings, profiles, shell configs. These represent materialized decisions.

1e. Gotchas & Quirks

Platform-specific behaviors, tool-specific edge cases, or undocumented behaviors encountered. Things that would trip up the next person doing similar work.

---

Stage 2: Lesson Extraction

For each identified event, produce a structured lesson:

## Lesson N: <title>

**Category**: gotcha | pattern | rule | discovery | correction
**Context**: <what was being done when this was learned>
**Symptom**: <the error or failure, if applicable>
**Root cause**: <why it happened>
**Fix**: <what was done>
**Rule**: <the generalizable principle — one sentence that applies beyond this specific case>

Guidelines:

• **Deduplicate**: If multiple events teach the same lesson, merge them into one with the clearest example
• **Generalize**: The "Rule" field must be useful outside the specific session. "Add user_caches_macos to custom-codex profile" is a fix. "Each AI tool needs its own nono profile extending that tool's built-in profile" is a rule.
• **Be specific**: Include exact error messages, file paths, tool names. Vague lessons ("be careful with symlinks") are useless. Specific lessons ("nono resolves symlinks before checking access, so the target path must also be in the allowed list") are actionable.
• **Count**: A typical session yields