session-learnings
Skill0 starsChanged 4 months agoMITView on GitHub
Extract recurring user corrections and tool failures from the current session, then make small, high-leverage updates to the appropriate guidance. Use when asked for session learnings, to reduce iteration, or to encode a newly discovered workflow or style constraint.
In this repository12 other files it gives its agents.
- englogSkill
- githubSkill
- git-repos-cleanupSkill
- gitSkill
- golang-developmentSkill
- pull-requestSkill
- python-developmentSkill
- review-claude-configSkill
- review-claude-settingsSkill
- review-pull-requestSkill
- triage-dependency-prsSkill
- untracked-secrets-scanSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Use the current conversation as the primary source.
- Distinctive: line 16
If none are present, say so.
- Distinctive: line 33
When in doubt, leave it out.
- Distinctive: line 42
Prefer the narrowest scope that prevents repetition.
- Distinctive: line 49
Before editing, confirm: is the rule useful beyond this session and does the selected file own this behavior?
- Distinctive: line 55
Keep additions to 1–6 bullets.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Session Learnings
Gather evidence
Use the current conversation as the primary source. Look for:
- Explicit user corrections or preferences.
- Tool failures, wrong syntax, or permission constraints.
- Work that had to be redone because a workflow step was missed.
If none are present, say so. Do not create guidance merely to produce a change.
Decide what to retain
Apply KISS/YAGNI before writing anything. A learning only earns a place in guidance if it passes all of:
- Recurring — likely to come up again, not a one-session quirk.
- Non-obvious to an agent — would the agent encounter this as a surprise, or can it be inferred from standard docs, normal error output, or the tool's default behavior? Environment-specific constraints (sandbox quirks, proxy TLS, denied paths) qualify; generic CLI usage and basic git hygiene don't.
- Scoped to the target file — local guidance (repo
CLAUDE.md,CLAUDE.local.md) may include repo-specific content; global guidance (~/.claude/CLAUDE.md, skills, commands) must apply across repos, not just the current project. - Not already self-describing — the error message or tool output already explains the fix clearly; no standing rule needed.
Reject a candidate when it is:
- A niche edge case unlikely to recur (e.g. one specific API field, one rare CLI flag combination).
- Verbose enough to need a long explanation — if it can't be stated in 1–2 lines, it's probably too situational.
- Already covered by the tool's own docs, error output, or a skill that owns that domain.
- Standard practice that any engineer would apply without a reminder.
When in doubt, leave it out. A shorter guidance file is more likely to be read and followed.
| Learning | Home |
| Tool behavior, command syntax, or repeatable workflow | The relevant skill or command guidance |
| Durable workflow shared across projects | User-level guidance (CLAUDE.md) |
| Repository or subsystem convention | The closest repository guidance |
| Personal preference or user context | Claude memory |
Prefer the narrowest scope that prevents repetition; do not duplicate across layers.
Resolve a skill's source with readlink before editing it. Never put employer-specific details in skills from a
public repo; keep them in user-level guidance or a private skill instead.
Apply the learning
Before editing, confirm: is the rule useful beyond this session and does the selected file own this behavior? If not, use a narrower home or omit.
When updating guidance:
- Fix misleading instructions instead of appending competing workarounds.
- Preserve existing structure and local conventions.
- Keep additions to 1–6 bullets.
Report
Return: (1) the learned rules and rationale, (2) each file changed and why, (3) any candidate deliberately not retained.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.