self-improvement
Self-Improvement Meta-Skill
This meta-skill enables the Cursor system to learn from GitHub PRs, issues, discussions, and user interactions to continuously improve guidance and prevent common mistakes.
When to Use
Use this skill when:
- Analyzing closed PRs to extract lessons learned
- Identifying patterns in rejected vs. accepted contributions
- Learning from user corrections and feedback
- Updating rules based on what worked or didn't work
- Creating new rules when patterns emerge
- Tracking effectiveness of existing rules
Key Capabilities
1. PR Analysis
Analyze closed PRs to extract patterns:
What to look for:
- Review comments and rejection reasons
- Common failure patterns (deprecated functions, architecture misunderstandings, missing context)
- Success patterns (what made PRs get merged)
- Code review feedback themes
- Testing and verification gaps
How to analyze:
- Fetch PR details via GitHub API or web fetch
- Parse review comments for actionable feedback
- Identify recurring themes
- Extract specific mistakes (e.g., "used deprecated function X")
- Map to existing rules or identify gaps
2. Issue Pattern Extraction
Learn from GitHub issues:
What to track:
- Common bug patterns
- Feature requests that reveal gaps
- User-reported issues that indicate misunderstandings
- Triage patterns (what gets prioritized)
How to extract:
- Analyze issue descriptions and labels
- Identify recurring themes
- Map to Omi layers (Capture/Understand/Memory/etc.)
- Extract lessons about what not to do
3. User Interaction Learning
Learn from direct user feedback:
What to track:
- User corrections ("No, don't do X")
- Rejected suggestions ("That's not what I meant")
- Clarification requests (reveals gaps in understanding)
- Preference patterns (user's coding style, preferred approaches)
- Success patterns (what user consistently approves)
How to learn:
- Monitor conversation for corrections and feedback
- Extract the lesson from each correction
- Identify patterns across multiple interactions
- Update rules or create new ones based on patterns
- Build user preference profile
4. Rule Generation and Updates
Create or update rules based on findings:
Process:
- Identify the pattern or mistake
- Check if existing rule covers it
- If yes, update the rule with new information
- If no, create a new rule
- Test rule effectiveness
Rule update format:
- Add to existing rule if it's the same category
- Create new rule if it's a new category
- Include specific examples from PRs/issues
- Reference the source (PR number, issue number)
5. Effectiveness Tracking
Track which rules are most effective:
Metrics:
- How often a rule prevents mistakes
- Reduction in PR rejections after rule creation
- User correction frequency
- Rule coverage (how many scenarios it covers)
Common Patterns to Extract
From PR #3567 (Rejected):
- ❌ Used deprecated
postprocess_conversationfunction - ❌ Didn't understand current audio storage flow
- ❌ Didn't provide enough context upfront
- ❌ Didn't verify end-to-end flow
- ✅ Good: Provided benchmarks and test results
- ✅ Good: Addressed code review feedback promptly
From Issues:
- Language settings not respected (#4394)
- Features only work when app is open (#4355)
- Missing conversations/processing issues (#4354, #4353)
From User Interactions:
- "No, don't use that function, it's deprecated" → Always check for deprecated functions
- "I need more context before you start coding" → User prefers planning phase
- "That's not how the system works" → Need to understand architecture better
Implementation Guidelines
Analyzing a PR
-
Fetch PR data:
# Use mcp_web_fetch or GitHub API pr_url = f"https://github.com/BasedHardware/omi/pull/{pr_number}" -
Extract key information:
- PR status (merged/rejected)
- Review comments
- Code changes
- Rejection reasons (if rejected)
-
Identify patterns:
- What mistakes were made?
- What feedback was given?
- What worked well?
-
Map to rules:
- Which existing rule should be updated?
- Is a new rule needed?
-
Update/create rules:
- Add examples to existing rules
- Create new rules for new patterns
Learning from User Feedback
-
Detect correction:
- User says "no", "don't", "that's wrong", etc.
- User provides different approach
-
Extract lesson:
- What was wrong?
- Why was it wrong?
- What should be done instead?
-
Update guidance:
- Add to relevant rule
- Create new rule if needed
- Update user preference profile
Creating New Rules
When a new pattern emerges:
- Identify the pattern: What mistake or gap does it address?
- Find examples: Collect 2-3 examples from PRs/issues/interactions
- Write the rule: Follow existing rule format
- Add to file structure: Place in appropriate
.cursor/rules/file - Link from related rules: Add references in other relevant rules
Related Cursor Resources
Rules
.cursor/rules/common-mistakes.mdc- Common mistakes to avoid.cursor/rules/pre-implementation-checklist.mdc- Pre-implementation verification.cursor/rules/verification.mdc- Self-checking guidelines.cursor/rules/context-communication.mdc- Communication best practices.cursor/rules/user-feedback-integration.mdc- Learning from user interactions
Commands
/learn-from-pr- Analyze a specific PR/learn-from-conversation- Learn from current conversation/self-improve- Analyze patterns and update rules
Skills
.cursor/skills/rule-updater/SKILL.md- Skill for updating rules programmatically
Best Practices
- Be specific: Extract concrete examples, not vague patterns
- Reference sources: Always note which PR/issue/interaction the lesson came from
- Test updates: Verify rule updates don't break existing guidance
- Prioritize: Focus on patterns that cause the most problems
- Iterate: Rules should improve over time as more data is collected
Example Usage
Analyzing a rejected PR:
User: "Learn from PR #3567"
Agent: [Uses this skill to]
1. Fetch PR #3567 details
2. Extract rejection reasons
3. Identify patterns (deprecated functions, missing context)
4. Update common-mistakes.mdc rule
5. Report findings
Learning from user correction:
User: "No, don't use postprocess_conversation, it's deprecated"
Agent: [Uses this skill to]
1. Extract lesson: Always check for deprecated functions
2. Update common-mistakes.mdc rule
3. Add to pre-implementation-checklist.mdc
4. Note in user preference profile
More from basedhardware/omi
local-dev
Start local development environment — backend, macOS app, or Flutter mobile in iOS simulator. Use when: 'run the app', 'start backend', 'run simulator', 'flutter run', 'local dev', 'start dev environment', 'run mobile app'.
45rotate-key
Rotate an API key or secret across all locations — local .env files, macOS Keychain, GCP Secret Manager, Kubernetes deployments, and Codemagic CI. Use when: 'rotate key', 'update key', 'key leaked', 'replace secret', 'new API key', 'update GEMINI key', 'rotate secret'.
26debug-mode
Debug mode workflows and best practices for troubleshooting bugs, regressions, and performance issues. Use when debugging tricky issues that standard agent interactions struggle with.
13docs-automation
Automate documentation updates when API endpoints, functions, or architecture change. Detects code changes that require doc updates, generates API reference from FastAPI routers, updates architecture diagrams, and syncs between internal and external docs.
13omi-flutter-patterns
Flutter Dart BLE device communication state management Provider backend integration localization cross-platform iOS Android
13rule-updater
Skill for programmatically reading, updating, and creating Cursor rules based on patterns and lessons learned
12