菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| 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?
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.