lesson

Stars13

Forks2

UpdatedMarch 13, 2026 at 07:07

Record a lesson learned after fixing a bug or discovering a pattern. Updates domain memory files and checks for contradictions. Use after resolving non-trivial issues.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

Embassy-of-the-Free-Mind

Embassy-of-the-Free-Mind/sourcelibrary-v2

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	lesson
description	Record a lesson learned after fixing a bug or discovering a pattern. Updates domain memory files and checks for contradictions. Use after resolving non-trivial issues.

Record a Lesson Learned

After fixing a bug, resolving an incident, or discovering an important pattern, record it for future sessions.

Steps

Classify the domain. Determine which memory file this belongs to:
- Pipeline/cron/Lambda/workers → memory/pipeline-ops.md
- Data quality/known bugs → memory/data-quality.md
- UI/frontend/navigation → memory/ui-navigation.md
- MCP server/CLI → memory/mcp-server.md
- Cross-cutting/general → memory/lessons-learned.md
- If it's a critical safety rule → also add to MEMORY.md (keep under 200 lines)
Check for contradictions. Read the target memory file and check:
- Does this contradict an existing entry? → Update the old entry, don't duplicate.
- Does this make an existing entry obsolete? → Remove or update it.
- Is there already an entry for this? → Strengthen it with new detail, don't duplicate.
Write the entry. Format:
```
- **Short description (YYYY-MM-DD):** What happened, what the fix was, and the general rule to follow going forward.
```
- Always include the date.
- State the rule (what to do), not just the story (what happened).
- Keep it to 1-2 lines. Link to files/docs if details are needed.
Check staleness nearby. While editing, scan neighboring entries:
- Any entry with a date older than 30 days → verify it's still accurate or mark (verify).
- Any entry referencing a file path → quick-check the file still exists.
- Any entry with stats/counts → mark as (snapshot, may be stale) if not already marked.
Report. Tell the user what was added, what was updated, and any stale entries found.

Examples

Good entry:

- **Lambda timeout on large books (2026-03-13):** Books with >500 pages can exceed Lambda 15min timeout. Split into chunks of 400 pages max. See `src/lib/lambda-queue.ts:128`.

Bad entry (no date, no rule):

- Fixed the Lambda timeout issue.

When NOT to use this

Trivial fixes (typos, one-line changes) — not worth recording
Session-specific context — use handoffs instead
Speculative conclusions from reading one file — verify first

More from this repository

same repository

qa-eval

Embassy-of-the-Free-Mind/sourcelibrary-v2

Run OCR and translation quality evaluations across scripts and languages. Produces research-grade reports with MCR, cross-model agreement, embedding-space hallucination detection, and corpus readiness scores.

2026-07-1913

glass-bead-game

Embassy-of-the-Free-Mind/sourcelibrary-v2

Run a Glass Bead Game session — a parlor game played against the Source Library corpus. Players connect verified passages from different books, times, and traditions into a growing string of 'beads,' with Claude as librarian, verifier, and scribe. Trigger when the user says 'glass bead game,' 'let's play beads,' or asks to start/resume/publish a game session. Claude runs the search-verify-display loop; humans do the noticing, choosing, and judging.

2026-07-1813

ft-verify

Embassy-of-the-Free-Mind/sourcelibrary-v2

Stage-2 verification of first-translation flips using INDEPENDENT Claude subagents (subscription, not API key) with full evidence capture. Use to verify proposed badge changes (demotes/promotes) before writing any public claim — the binding step that catches AI-fabricated priors. Each subagent reports its actual search queries + sources, persisted to the first_translation_attempts provenance log.

2026-07-1313

feedback

Embassy-of-the-Free-Mind/sourcelibrary-v2

Triage and respond to the user-feedback queue — pull open feedback, detect items already fixed but never marked, route translation-requests and metadata-corrections, mark items resolved, and (on approval) email submitters. Use when asked to check/triage/answer/clear feedback, "what are people saying?", or "respond to feedback."

2026-07-0613

promote-lessons

Embassy-of-the-Free-Mind/sourcelibrary-v2

Sweep Claude's private per-machine memory for team-relevant operational knowledge and propose moving it into the shared repo (or the private ops repo) as draft PRs. Use to promote lessons that accreted privately, or run on a schedule. Never auto-merges; never leaks.

2026-06-3013

metrics

Embassy-of-the-Free-Mind/sourcelibrary-v2

One-shot audience & usage report — signups, DAU/MAU, time on-site, traffic, top content, search behavior, referrers, countries, and user journeys. Use when asked "what's our usage?", "how many signups?", "time on site?", "traffic?", or any audience/engagement metrics question.

2026-06-2813

Record a Lesson Learned

After fixing a bug, resolving an incident, or discovering an important pattern, record it for future sessions.

Steps

Classify the domain. Determine which memory file this belongs to:

Pipeline/cron/Lambda/workers → memory/pipeline-ops.md
Data quality/known bugs → memory/data-quality.md
UI/frontend/navigation → memory/ui-navigation.md
MCP server/CLI → memory/mcp-server.md
Cross-cutting/general → memory/lessons-learned.md
If it's a critical safety rule → also add to MEMORY.md (keep under 200 lines)

Check for contradictions. Read the target memory file and check:

Does this contradict an existing entry? → Update the old entry, don't duplicate.
Does this make an existing entry obsolete? → Remove or update it.
Is there already an entry for this? → Strengthen it with new detail, don't duplicate.

Write the entry. Format:

- **Short description (YYYY-MM-DD):** What happened, what the fix was, and the general rule to follow going forward.

Always include the date.
State the rule (what to do), not just the story (what happened).
Keep it to 1-2 lines. Link to files/docs if details are needed.

Check staleness nearby. While editing, scan neighboring entries:

Any entry with a date older than 30 days → verify it's still accurate or mark (verify).
Any entry referencing a file path → quick-check the file still exists.
Any entry with stats/counts → mark as (snapshot, may be stale) if not already marked.

Report. Tell the user what was added, what was updated, and any stale entries found.

Examples

Good entry:

- **Lambda timeout on large books (2026-03-13):** Books with >500 pages can exceed Lambda 15min timeout. Split into chunks of 400 pages max. See `src/lib/lambda-queue.ts:128`.

Bad entry (no date, no rule):

- Fixed the Lambda timeout issue.

When NOT to use this

Trivial fixes (typos, one-line changes) — not worth recording

Session-specific context — use handoffs instead

Speculative conclusions from reading one file — verify first