Menu
Use when extracting reusable patterns from session history to create skills, analyzing completed work to identify generalizable workflows, or when writing skill trigger descriptions that need to be concept-anchored rather than example-based.
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.
Based on SOC occupation classification
Use when removing dead code, renaming symbols, or refactoring — any change with no external consumers. Triggers on deprecating dead code, wrapper shims, compatibility aliases, TODO-future-cleanup, or refactors that patch structure instead of simplifying.
Use when configuring custom providers for OpenCode.
Use when writing new React components that involve state derived from props, event-driven side effects, or external subscriptions. Also use when auditing existing code for unnecessary useEffect calls, reviewing useEffect-heavy components, or refactoring to eliminate cascading renders. Applies to React 18+ codebases.
Use when about to make git commits, when tempted to bundle unrelated changes behind a single message, or when commit history needs to support git bisect, revert, and cherry-pick workflows. Also use when reviewing a branch before creating a PR. If you are writing a plan, specify that the executor must load this skill before start working.
Use when configuring or enhancing oxlint rules for a JavaScript/TypeScript project, when deciding which lint rules to enable beyond the default correctness category, or when evaluating whether a lint rule's autofix status and noise level make it worth enabling. Also use when bulk-enabling pedantic or style categories has produced excessive noise.
Use when a user provides examples prefixed by "for example", "such as", "e.g.", "like", or ends a list with "etc." / "and so on". For architecture/design tasks, abstract first to identify the concept, then enumerate. For research/clarification tasks, enumerate first — the concept organizes the output but the list is the deliverable.
| name | learn-from-session |
| description | Use when extracting reusable patterns from session history to create skills, analyzing completed work to identify generalizable workflows, or when writing skill trigger descriptions that need to be concept-anchored rather than example-based. |
| license | CC-BY-SA-4.0 |
Sessions contain concrete problem-solving patterns. When a workflow proves valuable, extract it into a reusable skill. This skill guides pattern identification from session history and skill document production.
Triggers:
Do NOT use when:
generalize skill)When writing skill descriptions, trigger lists, and documentation rules: name the underlying condition first; keep examples as symptoms. If trigger text lets a reader identify the user's examples as the use case, re-climb the abstraction ladder.
When examples remain recognizable, they anchor the output to the source case. Readers pattern-match the example instead of understanding the concept.
Example:
❌ Example-anchored: "Use when handling 401 errors on login" ✅ Concept-anchored: "Use when handling authentication failures across user-facing flows"
The second version covers login, signup, password reset, session refresh — all instances of the same concept. The first version only triggers when someone sees "401" and "login" together.
After writing a trigger description, verify:
Look for these patterns in session history:
| Pattern Type | Session Signals | Skill Opportunity |
|---|---|---|
| Repeated workflow | Same tool sequence across multiple tasks | Codify the sequence |
| Decision tree | "If X then Y, else Z" logic you followed | Capture the branching |
| Failure recovery | You tried A, failed, then B worked | Document the diagnostic path |
| Tool combination | Specific tools used together effectively | Create combo workflow |
| Validation sequence | Checks you ran before claiming completion | Standardize verification |
Step 1: Identify the trigger
What user request or situation initiated the valuable work?
Step 2: Trace the workflow
What did you actually do? Chronological steps:
Step 3: Abstract the concept
What capability does this workflow provide?
Step 4: Generalize the context
When else would this workflow apply?
Step 5: Structure the skill
Convert to skill document format:
---
name: [capability-name]
description: Use when [trigger patterns]. [One-line value prop].
---
# [Skill Name]
## Overview
[What this skill does, why it exists]
## When to Use
**Triggers:**
- [Specific request patterns - concept-anchored]
- [Context signals]
**Do NOT use when:**
- [Boundary conditions]
## Workflow
[Step-by-step process extracted from session]
## Validation
[How to verify the workflow succeeded]
## Examples
[Concrete cases from the session that inspired this]
Step 6: Validate
Test questions:
Rename-as-extract: Your "skill" is just the session transcript reformatted. Test: Remove all session-specific details. Does a general workflow remain?
Over-specific: Skill only applies to the exact case you just solved. Test: Can you name 3 other situations where this skill would apply?
Under-specific: Skill is too vague to execute. Test: Could someone follow this without asking clarifying questions?
Missing boundaries: Skill doesn't say when NOT to use it. Test: Can you identify cases where this skill would mislead?
Example-anchored triggers: Trigger description lets readers identify the source case. Test: Remove examples from trigger. Does it still clearly indicate when to use?