AI Newsletter Digest improvements: fixed QP soft line break decoding, URL extraction, and content cleaning
This commit is contained in:
Krilly
103
archive/inactive-skills/reflect-learn/README.md
Normal file
103
archive/inactive-skills/reflect-learn/README.md
Normal file
@@ -0,0 +1,103 @@
|
||||
# Reflect - Agent Self-Improvement Skill
|
||||
|
||||
> "Correct once, never again."
|
||||
|
||||
Transform your AI assistant into a continuously improving partner. The reflect skill analyzes conversations for corrections and successful patterns, permanently encoding learnings into agent definitions.
|
||||
|
||||
## Features
|
||||
|
||||
- **Signal Detection**: Automatically identifies corrections with confidence levels (HIGH/MEDIUM/LOW)
|
||||
- **Category Classification**: Routes learnings to appropriate agent files (Code Style, Architecture, Process, Domain, Tools)
|
||||
- **Skill Generation**: Creates new skills from non-trivial debugging discoveries
|
||||
- **Metrics Tracking**: Quantifies improvement with acceptance rates and statistics
|
||||
- **Human-in-the-Loop**: All changes require explicit approval
|
||||
- **Git Integration**: Full version control with easy rollback
|
||||
|
||||
## Installation
|
||||
|
||||
### Via ClawdHub CLI
|
||||
|
||||
```bash
|
||||
clawdhub install reflect
|
||||
```
|
||||
|
||||
### Manual Installation
|
||||
|
||||
Copy the `reflect/` folder to your skills directory:
|
||||
- Claude Code: `~/.claude/skills/reflect/`
|
||||
- Clawdbot: `~/.clawdbot/skills/reflect/`
|
||||
|
||||
## Usage
|
||||
|
||||
### Basic Reflection
|
||||
|
||||
Just say "reflect" or "review session" to trigger analysis:
|
||||
|
||||
```
|
||||
User: reflect
|
||||
Agent: [Analyzes conversation, presents learnings for approval]
|
||||
```
|
||||
|
||||
### Toggle Auto-Reflection
|
||||
|
||||
```
|
||||
User: reflect on
|
||||
Agent: Auto-reflection enabled. Will analyze before context compaction.
|
||||
|
||||
User: reflect off
|
||||
Agent: Auto-reflection disabled.
|
||||
```
|
||||
|
||||
### Check Status
|
||||
|
||||
```
|
||||
User: reflect status
|
||||
Agent:
|
||||
Sessions analyzed: 42
|
||||
Signals detected: 156
|
||||
Changes accepted: 89 (78%)
|
||||
Skills created: 5
|
||||
```
|
||||
|
||||
### Review Pending
|
||||
|
||||
```
|
||||
User: reflect review
|
||||
Agent: [Shows low-confidence learnings awaiting validation]
|
||||
```
|
||||
|
||||
## How It Works
|
||||
|
||||
1. **Scan**: Analyzes conversation for correction signals
|
||||
2. **Classify**: Maps signals to categories and target files
|
||||
3. **Propose**: Generates diffs for agent updates or new skills
|
||||
4. **Review**: Presents changes for user approval
|
||||
5. **Apply**: Commits approved changes with descriptive messages
|
||||
|
||||
## Signal Detection
|
||||
|
||||
| Confidence | Triggers | Examples |
|
||||
|------------|----------|----------|
|
||||
| HIGH | Explicit corrections | "never", "always", "wrong", "stop" |
|
||||
| MEDIUM | Approved approaches | "perfect", "exactly", "that's right" |
|
||||
| LOW | Observations | Patterns that worked, not validated |
|
||||
|
||||
## Configuration
|
||||
|
||||
Set custom state directory:
|
||||
|
||||
```bash
|
||||
export REFLECT_STATE_DIR=/path/to/state
|
||||
```
|
||||
|
||||
Default locations:
|
||||
- `~/.reflect/` (portable)
|
||||
- `~/.claude/session/` (Claude Code)
|
||||
|
||||
## License
|
||||
|
||||
MIT
|
||||
|
||||
## Author
|
||||
|
||||
Claude Code Toolkit
|
||||
260
archive/inactive-skills/reflect-learn/SKILL.md
Normal file
260
archive/inactive-skills/reflect-learn/SKILL.md
Normal file
@@ -0,0 +1,260 @@
|
||||
---
|
||||
name: reflect
|
||||
description: Self-improvement through conversation analysis. Extracts learnings from corrections and success patterns, permanently encoding them into agent definitions. Philosophy - Correct once, never again.
|
||||
version: "2.0.0"
|
||||
user-invocable: true
|
||||
triggers:
|
||||
- reflect
|
||||
- self-reflect
|
||||
- review session
|
||||
- what did I learn
|
||||
- extract learnings
|
||||
- analyze corrections
|
||||
allowed-tools:
|
||||
- Read
|
||||
- Write
|
||||
- Edit
|
||||
- Grep
|
||||
- Glob
|
||||
- Bash
|
||||
metadata:
|
||||
clawdbot:
|
||||
emoji: "🪞"
|
||||
config:
|
||||
stateDirs: ["~/.reflect"]
|
||||
---
|
||||
|
||||
# Reflect - Agent Self-Improvement Skill
|
||||
|
||||
Transform your AI assistant into a continuously improving partner. Every correction becomes a permanent improvement that persists across all future sessions.
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Command | Action |
|
||||
|---------|--------|
|
||||
| `reflect` | Analyze conversation for learnings |
|
||||
| `reflect on` | Enable auto-reflection |
|
||||
| `reflect off` | Disable auto-reflection |
|
||||
| `reflect status` | Show state and metrics |
|
||||
| `reflect review` | Review pending learnings |
|
||||
|
||||
## When to Use
|
||||
|
||||
- After completing complex tasks
|
||||
- When user explicitly corrects behavior ("never do X", "always Y")
|
||||
- At session boundaries or before context compaction
|
||||
- When successful patterns are worth preserving
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Scan Conversation for Signals
|
||||
|
||||
Analyze the conversation for correction signals and learning opportunities.
|
||||
|
||||
**Signal Confidence Levels:**
|
||||
|
||||
| Confidence | Triggers | Examples |
|
||||
|------------|----------|----------|
|
||||
| **HIGH** | Explicit corrections | "never", "always", "wrong", "stop", "the rule is" |
|
||||
| **MEDIUM** | Approved approaches | "perfect", "exactly", "that's right", accepted output |
|
||||
| **LOW** | Observations | Patterns that worked but not explicitly validated |
|
||||
|
||||
See [data/signal_patterns.md](data/signal_patterns.md) for full detection rules.
|
||||
|
||||
### Step 2: Classify & Match to Target Files
|
||||
|
||||
Map each signal to the appropriate target:
|
||||
|
||||
| Category | Target Files |
|
||||
|----------|--------------|
|
||||
| Code Style | `code-reviewer`, `backend-developer`, `frontend-developer` |
|
||||
| Architecture | `solution-architect`, `api-architect`, `architecture-reviewer` |
|
||||
| Process | `CLAUDE.md`, orchestrator agents |
|
||||
| Domain | Domain-specific agents, `CLAUDE.md` |
|
||||
| Tools | `CLAUDE.md`, relevant specialists |
|
||||
| New Skill | Create new skill file |
|
||||
|
||||
See [data/agent_mappings.md](data/agent_mappings.md) for mapping rules.
|
||||
|
||||
### Step 3: Check for Skill-Worthy Signals
|
||||
|
||||
Some learnings should become new skills rather than agent updates:
|
||||
|
||||
**Skill-Worthy Criteria:**
|
||||
- Non-obvious debugging (>10 min investigation)
|
||||
- Misleading error (root cause different from message)
|
||||
- Workaround discovered through experimentation
|
||||
- Configuration insight (differs from documented)
|
||||
- Reusable pattern (helps in similar situations)
|
||||
|
||||
**Quality Gates (must pass all):**
|
||||
- [ ] Reusable: Will help with future tasks
|
||||
- [ ] Non-trivial: Requires discovery, not just docs
|
||||
- [ ] Specific: Can describe exact trigger conditions
|
||||
- [ ] Verified: Solution actually worked
|
||||
- [ ] No duplication: Doesn't exist already
|
||||
|
||||
### Step 4: Generate Proposals
|
||||
|
||||
Present findings in structured format:
|
||||
|
||||
```markdown
|
||||
# Reflection Analysis
|
||||
|
||||
## Session Context
|
||||
- **Date**: [timestamp]
|
||||
- **Messages Analyzed**: [count]
|
||||
|
||||
## Signals Detected
|
||||
|
||||
| # | Signal | Confidence | Source Quote | Category |
|
||||
|---|--------|------------|--------------|----------|
|
||||
| 1 | [learning] | HIGH | "[exact words]" | Code Style |
|
||||
|
||||
## Proposed Changes
|
||||
|
||||
### Change 1: Update [agent-name]
|
||||
**Target**: `[file path]`
|
||||
**Section**: [section name]
|
||||
**Confidence**: HIGH
|
||||
|
||||
```diff
|
||||
+ New rule from learning
|
||||
```
|
||||
|
||||
## Review Prompt
|
||||
Apply these changes? (Y/N/modify/1,2,3)
|
||||
```
|
||||
|
||||
### Step 5: Apply with User Approval
|
||||
|
||||
**On `Y` (approve):**
|
||||
1. Apply each change using Edit tool
|
||||
2. Commit with descriptive message
|
||||
3. Update metrics
|
||||
|
||||
**On `N` (reject):**
|
||||
1. Discard proposed changes
|
||||
2. Log rejection for analysis
|
||||
|
||||
**On `modify`:**
|
||||
1. Present each change individually
|
||||
2. Allow editing before applying
|
||||
|
||||
**On selective (e.g., `1,3`):**
|
||||
1. Apply only specified changes
|
||||
2. Commit partial updates
|
||||
|
||||
## State Management
|
||||
|
||||
State is stored in `~/.reflect/` (configurable via `REFLECT_STATE_DIR`):
|
||||
|
||||
```yaml
|
||||
# reflect-state.yaml
|
||||
auto_reflect: false
|
||||
last_reflection: "2026-01-26T10:30:00Z"
|
||||
pending_reviews: []
|
||||
```
|
||||
|
||||
### Metrics Tracking
|
||||
|
||||
```yaml
|
||||
# reflect-metrics.yaml
|
||||
total_sessions_analyzed: 42
|
||||
total_signals_detected: 156
|
||||
total_changes_accepted: 89
|
||||
acceptance_rate: 78%
|
||||
confidence_breakdown:
|
||||
high: 45
|
||||
medium: 32
|
||||
low: 12
|
||||
most_updated_agents:
|
||||
code-reviewer: 23
|
||||
backend-developer: 18
|
||||
skills_created: 5
|
||||
```
|
||||
|
||||
## Safety Guardrails
|
||||
|
||||
### Human-in-the-Loop
|
||||
- NEVER apply changes without explicit user approval
|
||||
- Always show full diff before applying
|
||||
- Allow selective application
|
||||
|
||||
### Incremental Updates
|
||||
- ONLY add to existing sections
|
||||
- NEVER delete or rewrite existing rules
|
||||
- Preserve original structure
|
||||
|
||||
### Conflict Detection
|
||||
- Check if proposed rule contradicts existing
|
||||
- Warn user if conflict detected
|
||||
- Suggest resolution strategy
|
||||
|
||||
## Output Locations
|
||||
|
||||
**Project-level (versioned with repo):**
|
||||
- `.claude/reflections/YYYY-MM-DD_HH-MM-SS.md` - Full reflection
|
||||
- `.claude/skills/{name}/SKILL.md` - New skills
|
||||
|
||||
**Global (user-level):**
|
||||
- `~/.reflect/learnings.yaml` - Learning log
|
||||
- `~/.reflect/reflect-metrics.yaml` - Aggregate metrics
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Code Style Correction
|
||||
|
||||
**User says**: "Never use `var` in TypeScript, always use `const` or `let`"
|
||||
|
||||
**Signal detected**:
|
||||
- Confidence: HIGH (explicit "never" + "always")
|
||||
- Category: Code Style
|
||||
- Target: `frontend-developer.md`
|
||||
|
||||
**Proposed change**:
|
||||
```diff
|
||||
## Style Guidelines
|
||||
+ * Use `const` or `let` instead of `var` in TypeScript
|
||||
```
|
||||
|
||||
### Example 2: Process Preference
|
||||
|
||||
**User says**: "Always run tests before committing"
|
||||
|
||||
**Signal detected**:
|
||||
- Confidence: HIGH (explicit "always")
|
||||
- Category: Process
|
||||
- Target: `CLAUDE.md`
|
||||
|
||||
**Proposed change**:
|
||||
```diff
|
||||
## Commit Hygiene
|
||||
+ * Run test suite before creating commits
|
||||
```
|
||||
|
||||
### Example 3: New Skill from Debugging
|
||||
|
||||
**Context**: Spent 30 minutes debugging a React hydration mismatch
|
||||
|
||||
**Signal detected**:
|
||||
- Confidence: HIGH (non-trivial debugging)
|
||||
- Category: New Skill
|
||||
- Quality gates: All passed
|
||||
|
||||
**Proposed skill**: `react-hydration-fix/SKILL.md`
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**No signals detected:**
|
||||
- Session may not have had corrections
|
||||
- Check if using natural language corrections
|
||||
|
||||
**Conflict warning:**
|
||||
- Review the existing rule cited
|
||||
- Decide if new rule should override
|
||||
- Can modify before applying
|
||||
|
||||
**Agent file not found:**
|
||||
- Check agent name spelling
|
||||
- May need to create agent file first
|
||||
6
archive/inactive-skills/reflect-learn/_meta.json
Normal file
6
archive/inactive-skills/reflect-learn/_meta.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"ownerId": "kn76g5m73ja7q4gbhrh8h7v0h97zffvw",
|
||||
"slug": "reflect-learn",
|
||||
"version": "2.0.0",
|
||||
"publishedAt": 1769445465505
|
||||
}
|
||||
285
archive/inactive-skills/reflect-learn/data/agent_mappings.md
Normal file
285
archive/inactive-skills/reflect-learn/data/agent_mappings.md
Normal file
@@ -0,0 +1,285 @@
|
||||
# Agent Mappings Reference
|
||||
|
||||
Maps learning categories to target agent files for updating.
|
||||
|
||||
## Agent Directory Structure
|
||||
|
||||
```
|
||||
~/.claude/agents/
|
||||
├── universal/
|
||||
│ ├── backend-developer.md
|
||||
│ ├── frontend-developer.md
|
||||
│ └── superstar-engineer.md
|
||||
├── engineering/
|
||||
│ ├── api-architect.md
|
||||
│ ├── architecture-reviewer.md
|
||||
│ ├── code-reviewer.md
|
||||
│ ├── security-agent.md
|
||||
│ ├── test-writer-fixer.md
|
||||
│ └── ...
|
||||
├── design/
|
||||
│ └── ui-designer.md
|
||||
├── orchestrators/
|
||||
│ ├── tech-lead-orchestrator.md
|
||||
│ └── ...
|
||||
└── meta/
|
||||
└── agentmaker.md
|
||||
```
|
||||
|
||||
## Category to Agent Mapping
|
||||
|
||||
### Code Style
|
||||
|
||||
| Learning Type | Primary Agent | Secondary Agents |
|
||||
|--------------|---------------|------------------|
|
||||
| Naming conventions | `code-reviewer` | `backend-developer`, `frontend-developer` |
|
||||
| Formatting rules | `code-reviewer` | Project's `.editorconfig` or linter config |
|
||||
| TypeScript/JavaScript style | `frontend-developer` | `code-reviewer` |
|
||||
| Python style | `backend-developer` | `code-reviewer` |
|
||||
| Go style | `backend-developer` | `code-reviewer` |
|
||||
| Rust style | `backend-developer` | `code-reviewer` |
|
||||
|
||||
**Section in Agent File:**
|
||||
```markdown
|
||||
## Code Style
|
||||
## Style Guidelines
|
||||
## Heuristics > Style
|
||||
```
|
||||
|
||||
### Architecture
|
||||
|
||||
| Learning Type | Primary Agent | Secondary Agents |
|
||||
|--------------|---------------|------------------|
|
||||
| Design patterns | `solution-architect` | `architecture-reviewer` |
|
||||
| API design | `api-architect` | `backend-developer` |
|
||||
| Database patterns | `backend-developer` | `migration` |
|
||||
| Frontend patterns | `frontend-developer` | `architecture-reviewer` |
|
||||
| System structure | `solution-architect` | `tech-lead-orchestrator` |
|
||||
|
||||
**Section in Agent File:**
|
||||
```markdown
|
||||
## Architecture Patterns
|
||||
## Design Patterns
|
||||
## Heuristics > Architecture
|
||||
```
|
||||
|
||||
### Process
|
||||
|
||||
| Learning Type | Primary Agent | Global Config |
|
||||
|--------------|---------------|---------------|
|
||||
| Git workflow | `CLAUDE.md` | Commit hygiene section |
|
||||
| CI/CD | `devops-automator` | Pipeline config |
|
||||
| Code review | `code-reviewer` | Review checklist |
|
||||
| Testing workflow | `test-writer-fixer` | Testing philosophy |
|
||||
| Deployment | `release-manager` | Release process |
|
||||
|
||||
**Section in Agent File:**
|
||||
```markdown
|
||||
## Workflow
|
||||
## Process Guidelines
|
||||
## Heuristics > Process
|
||||
```
|
||||
|
||||
### Domain
|
||||
|
||||
| Learning Type | Primary Target | Notes |
|
||||
|--------------|----------------|-------|
|
||||
| Business rules | Project `.claude/agents/` | Domain-specific agent |
|
||||
| Terminology | `CLAUDE.md` | Glossary section |
|
||||
| Constraints | Project-specific agent | Validation rules |
|
||||
| User requirements | `CLAUDE.md` | User preferences section |
|
||||
|
||||
**Section in Agent File:**
|
||||
```markdown
|
||||
## Domain Rules
|
||||
## Business Logic
|
||||
## Terminology
|
||||
```
|
||||
|
||||
### Tools
|
||||
|
||||
| Learning Type | Primary Target | Notes |
|
||||
|--------------|----------------|-------|
|
||||
| CLI preferences | `CLAUDE.md` | Tool usage section |
|
||||
| Editor config | `.editorconfig` | Format settings |
|
||||
| Docker usage | `devops-automator` | Container settings |
|
||||
| Git settings | `CLAUDE.md` | Commit hygiene |
|
||||
|
||||
**Section in Agent File:**
|
||||
```markdown
|
||||
## Tool Usage
|
||||
## CLI Preferences
|
||||
## Environment Setup
|
||||
```
|
||||
|
||||
### Security
|
||||
|
||||
| Learning Type | Primary Agent | Secondary Agents |
|
||||
|--------------|---------------|------------------|
|
||||
| Input validation | `security-agent` | `code-reviewer` |
|
||||
| Authentication | `security-agent` | `api-architect` |
|
||||
| Authorization | `security-agent` | `backend-developer` |
|
||||
| Encryption | `security-agent` | `backend-developer` |
|
||||
| OWASP rules | `security-agent` | `code-reviewer` |
|
||||
|
||||
**Section in Agent File:**
|
||||
```markdown
|
||||
## Security Heuristics
|
||||
## Review Heuristics > Security
|
||||
## Validation Rules
|
||||
```
|
||||
|
||||
## Section Identification
|
||||
|
||||
When adding a learning to an agent file, identify the correct section:
|
||||
|
||||
### Pattern Matching for Sections
|
||||
|
||||
```regex
|
||||
## Heuristics
|
||||
## Style
|
||||
## Guidelines
|
||||
## Patterns
|
||||
## Rules
|
||||
## Best Practices
|
||||
## Review Checklist
|
||||
```
|
||||
|
||||
### Section Priority
|
||||
|
||||
1. Most specific matching section (e.g., "Security" for security rules)
|
||||
2. Generic "Heuristics" section
|
||||
3. "Guidelines" or "Rules" section
|
||||
4. Create new section if none match
|
||||
|
||||
### Addition Format
|
||||
|
||||
Always add as a bullet point under the appropriate section:
|
||||
|
||||
```markdown
|
||||
## Heuristics
|
||||
|
||||
* Existing rule 1
|
||||
* Existing rule 2
|
||||
* **New learning from reflection** ← Add here
|
||||
```
|
||||
|
||||
Use bold for newly added rules to distinguish them.
|
||||
|
||||
## Conflict Detection
|
||||
|
||||
Before adding a new rule, check for conflicts:
|
||||
|
||||
### Contradiction Patterns
|
||||
|
||||
```regex
|
||||
# Opposite directives
|
||||
"never use X" vs "always use X"
|
||||
"prefer Y" vs "avoid Y"
|
||||
"use Z" vs "don't use Z"
|
||||
|
||||
# Conflicting versions
|
||||
"use library v1" vs "use library v2"
|
||||
"Node 18" vs "Node 20"
|
||||
```
|
||||
|
||||
### Resolution Strategy
|
||||
|
||||
1. **Newer wins**: If the new learning contradicts an old rule, flag for review
|
||||
2. **Higher confidence wins**: HIGH > MEDIUM > LOW
|
||||
3. **More specific wins**: "Never use var in TypeScript" > "Avoid var"
|
||||
4. **User decision**: When equal, ask user to resolve
|
||||
|
||||
## File Paths
|
||||
|
||||
### Global Agents (User-level)
|
||||
|
||||
```
|
||||
~/.claude/agents/universal/backend-developer.md
|
||||
~/.claude/agents/universal/frontend-developer.md
|
||||
~/.claude/agents/engineering/code-reviewer.md
|
||||
~/.claude/agents/engineering/api-architect.md
|
||||
~/.claude/agents/engineering/solution-architect.md
|
||||
~/.claude/agents/engineering/security-agent.md
|
||||
~/.claude/agents/engineering/test-writer-fixer.md
|
||||
~/.claude/agents/design/ui-designer.md
|
||||
```
|
||||
|
||||
### Project Agents (Project-level)
|
||||
|
||||
```
|
||||
.claude/agents/{name}.md
|
||||
```
|
||||
|
||||
### Global Instructions
|
||||
|
||||
```
|
||||
~/.claude/CLAUDE.md
|
||||
```
|
||||
|
||||
### Project Instructions
|
||||
|
||||
```
|
||||
.claude/CLAUDE.md
|
||||
CLAUDE.md
|
||||
```
|
||||
|
||||
## Skill Creation vs Agent Update
|
||||
|
||||
Decide whether to create a new skill or update an agent:
|
||||
|
||||
| Criteria | Create Skill | Update Agent |
|
||||
|----------|--------------|--------------|
|
||||
| One-off solution to specific error | Yes | No |
|
||||
| General preference | No | Yes |
|
||||
| Debugging workaround | Yes | No |
|
||||
| Code style rule | No | Yes |
|
||||
| Configuration trick | Yes | Sometimes |
|
||||
| Process preference | No | Yes |
|
||||
|
||||
## Example Mappings
|
||||
|
||||
### Example 1: Code Style
|
||||
|
||||
**Signal**: "Never use `var` in TypeScript, always use `const` or `let`"
|
||||
**Confidence**: HIGH
|
||||
**Category**: Code Style
|
||||
|
||||
**Mapping**:
|
||||
- Primary: `~/.claude/agents/universal/frontend-developer.md`
|
||||
- Section: `## Style Guidelines`
|
||||
- Addition: `* Use \`const\` or \`let\` instead of \`var\` in TypeScript`
|
||||
|
||||
### Example 2: Architecture
|
||||
|
||||
**Signal**: "Prefer cursor-based pagination for APIs"
|
||||
**Confidence**: MEDIUM
|
||||
**Category**: Architecture
|
||||
|
||||
**Mapping**:
|
||||
- Primary: `~/.claude/agents/engineering/api-architect.md`
|
||||
- Section: `## Design Patterns`
|
||||
- Addition: `* Prefer cursor-based pagination over offset-based for large datasets`
|
||||
|
||||
### Example 3: Security
|
||||
|
||||
**Signal**: "Always validate inputs on the server, never trust client validation"
|
||||
**Confidence**: HIGH
|
||||
**Category**: Security
|
||||
|
||||
**Mapping**:
|
||||
- Primary: `~/.claude/agents/engineering/security-agent.md`
|
||||
- Section: `## Validation Rules`
|
||||
- Addition: `* Always validate inputs server-side; client validation is for UX only`
|
||||
- Secondary: `~/.claude/agents/engineering/code-reviewer.md`
|
||||
- Section: `## Review Heuristics > Security`
|
||||
|
||||
### Example 4: New Skill
|
||||
|
||||
**Signal**: "Fixed React hydration mismatch by ensuring server and client render same content"
|
||||
**Confidence**: HIGH
|
||||
**Category**: New Skill
|
||||
|
||||
**Mapping**:
|
||||
- Create: `.claude/skills/react-hydration-mismatch-fix/SKILL.md`
|
||||
- Include: Error message, symptoms, step-by-step fix, verification
|
||||
281
archive/inactive-skills/reflect-learn/data/signal_patterns.md
Normal file
281
archive/inactive-skills/reflect-learn/data/signal_patterns.md
Normal file
@@ -0,0 +1,281 @@
|
||||
# Signal Detection Patterns
|
||||
|
||||
Comprehensive reference for detecting correction signals and learning opportunities in conversations.
|
||||
|
||||
## Confidence Levels
|
||||
|
||||
### HIGH Confidence (Explicit Corrections)
|
||||
|
||||
These patterns indicate the user is explicitly stating a rule or correction. Always apply these learnings.
|
||||
|
||||
#### Negative Directives
|
||||
|
||||
| Pattern | Type | Example |
|
||||
|---------|------|---------|
|
||||
| `never` | correction | "Never use var in TypeScript" |
|
||||
| `don't` / `do not` | correction | "Don't commit directly to main" |
|
||||
| `stop doing` | correction | "Stop doing manual deployments" |
|
||||
| `wrong` | correction | "That's wrong, use snake_case" |
|
||||
| `not like that` | correction | "Not like that, indent with tabs" |
|
||||
| `incorrect` | correction | "That's incorrect syntax" |
|
||||
| `should not` / `shouldn't` | prohibition | "You shouldn't use eval()" |
|
||||
| `must not` / `mustn't` | prohibition | "Must not expose secrets" |
|
||||
|
||||
**Regex Pattern:**
|
||||
```regex
|
||||
\b(never|don't|do not|stop doing|wrong|not like that|incorrect|should not|shouldn't|must not|mustn't)\b
|
||||
```
|
||||
|
||||
#### Positive Directives
|
||||
|
||||
| Pattern | Type | Example |
|
||||
|---------|------|---------|
|
||||
| `always` | requirement | "Always validate inputs" |
|
||||
| `must` | requirement | "You must use parameterized queries" |
|
||||
| `required` | requirement | "It's required to have tests" |
|
||||
| `the rule is` | explicit_rule | "The rule is no console.log in prod" |
|
||||
| `correct way` | explicit_rule | "The correct way is to use hooks" |
|
||||
|
||||
**Regex Pattern:**
|
||||
```regex
|
||||
\b(always|must|required|the rule is|correct way)\b
|
||||
```
|
||||
|
||||
#### Frustration Markers
|
||||
|
||||
These indicate repeated corrections - highest priority learnings.
|
||||
|
||||
| Pattern | Type | Example |
|
||||
|---------|------|---------|
|
||||
| `I already told you` | frustration | "I already told you about this" |
|
||||
| `again?` | frustration | "Wrong again?" |
|
||||
| `not again` | frustration | "Oh not again" |
|
||||
| `how many times` | frustration | "How many times do I need to say..." |
|
||||
|
||||
**Regex Pattern:**
|
||||
```regex
|
||||
(I already told you|again\?|not again|how many times)
|
||||
```
|
||||
|
||||
#### Explicit Rules
|
||||
|
||||
| Pattern | Type | Example |
|
||||
|---------|------|---------|
|
||||
| `the rule is` | explicit_rule | "The rule is we use ESLint" |
|
||||
| `you should know` | explicit_rule | "You should know we use Prettier" |
|
||||
| `remember that` | explicit_rule | "Remember that we're on Node 20" |
|
||||
| `don't forget` | explicit_rule | "Don't forget the error handling" |
|
||||
|
||||
**Regex Pattern:**
|
||||
```regex
|
||||
(the rule is|you should know|remember that|don't forget)
|
||||
```
|
||||
|
||||
### MEDIUM Confidence (Approved Approaches)
|
||||
|
||||
These patterns indicate the user approved a specific approach. Apply with reasonable confidence.
|
||||
|
||||
#### Approval Markers
|
||||
|
||||
| Pattern | Type | Example |
|
||||
|---------|------|---------|
|
||||
| `perfect` | approval | "Perfect, that's what I wanted" |
|
||||
| `exactly` | approval | "Exactly right" |
|
||||
| `that's right` | approval | "That's right, keep it" |
|
||||
| `yes, like that` | approval | "Yes, like that" |
|
||||
| `correct` | approval | "Correct implementation" |
|
||||
|
||||
**Regex Pattern:**
|
||||
```regex
|
||||
\b(perfect|exactly|that's right|yes, like that|correct)\b
|
||||
```
|
||||
|
||||
#### Positive Feedback
|
||||
|
||||
| Pattern | Type | Example |
|
||||
|---------|------|---------|
|
||||
| `good` | positive_feedback | "Good approach" |
|
||||
| `great job` | positive_feedback | "Great job on the refactor" |
|
||||
| `well done` | positive_feedback | "Well done with the tests" |
|
||||
| `nice` | positive_feedback | "Nice solution" |
|
||||
| `excellent` | positive_feedback | "Excellent work" |
|
||||
|
||||
**Regex Pattern:**
|
||||
```regex
|
||||
\b(good|great job|well done|nice|excellent)\b
|
||||
```
|
||||
|
||||
#### Continuation Markers
|
||||
|
||||
| Pattern | Type | Example |
|
||||
|---------|------|---------|
|
||||
| `keep doing` | continuation | "Keep doing it this way" |
|
||||
| `continue with` | continuation | "Continue with this approach" |
|
||||
| `stick with` | continuation | "Stick with React hooks" |
|
||||
|
||||
**Regex Pattern:**
|
||||
```regex
|
||||
\b(keep doing|continue with|stick with)\b
|
||||
```
|
||||
|
||||
### LOW Confidence (Observations)
|
||||
|
||||
These patterns suggest preferences but require validation before encoding as rules.
|
||||
|
||||
#### Suggestions
|
||||
|
||||
| Pattern | Type | Example |
|
||||
|---------|------|---------|
|
||||
| `maybe` | suggestion | "Maybe try TypeScript" |
|
||||
| `perhaps` | suggestion | "Perhaps use a different library" |
|
||||
| `might want to` | suggestion | "You might want to add caching" |
|
||||
| `consider` | suggestion | "Consider using memoization" |
|
||||
|
||||
**Regex Pattern:**
|
||||
```regex
|
||||
\b(maybe|perhaps|might want to|consider)\b
|
||||
```
|
||||
|
||||
#### Observations
|
||||
|
||||
| Pattern | Type | Example |
|
||||
|---------|------|---------|
|
||||
| `seems like` | observation | "Seems like this works" |
|
||||
| `appears to` | observation | "Appears to be faster" |
|
||||
| `looks like` | observation | "Looks like a good pattern" |
|
||||
|
||||
**Regex Pattern:**
|
||||
```regex
|
||||
\b(seems like|appears to|looks like)\b
|
||||
```
|
||||
|
||||
## Category Detection
|
||||
|
||||
### Code Style
|
||||
|
||||
Patterns indicating code style preferences:
|
||||
|
||||
```regex
|
||||
\b(naming|convention|style|format|indent|case|camelCase|snake_case|PascalCase)\b
|
||||
\b(variable|function|class|method|parameter)\s+name
|
||||
\b(semicolon|quote|single quote|double quote|tabs|spaces)\b
|
||||
```
|
||||
|
||||
Examples:
|
||||
- "Use snake_case for Python variables"
|
||||
- "We prefer single quotes for strings"
|
||||
- "Indent with 2 spaces, not tabs"
|
||||
|
||||
### Architecture
|
||||
|
||||
Patterns indicating architectural decisions:
|
||||
|
||||
```regex
|
||||
\b(pattern|architecture|design|structure|module|component|service)\b
|
||||
\b(separation|coupling|cohesion|dependency|layer|abstraction)\b
|
||||
\b(microservice|monolith|serverless|event-driven)\b
|
||||
```
|
||||
|
||||
Examples:
|
||||
- "Use dependency injection for services"
|
||||
- "Keep components loosely coupled"
|
||||
- "Follow the repository pattern"
|
||||
|
||||
### Process
|
||||
|
||||
Patterns indicating workflow preferences:
|
||||
|
||||
```regex
|
||||
\b(workflow|process|step|procedure|protocol|practice)\b
|
||||
\b(commit|branch|merge|review|deploy|test|ci|cd)\b
|
||||
\b(pr|pull request|code review|approval)\b
|
||||
```
|
||||
|
||||
Examples:
|
||||
- "Always run tests before commit"
|
||||
- "Use conventional commits"
|
||||
- "Squash commits on merge"
|
||||
|
||||
### Domain
|
||||
|
||||
Patterns indicating business logic:
|
||||
|
||||
```regex
|
||||
\b(business|domain|logic|rule|requirement|constraint)\b
|
||||
\b(customer|user|client|account|order|payment|invoice)\b
|
||||
\b(validate|verify|check|ensure|confirm)\b
|
||||
```
|
||||
|
||||
Examples:
|
||||
- "Orders must be validated before processing"
|
||||
- "Users need email verification"
|
||||
- "Payments require two-factor auth"
|
||||
|
||||
### Tools
|
||||
|
||||
Patterns indicating tool preferences:
|
||||
|
||||
```regex
|
||||
\b(tool|cli|command|terminal|shell|editor|ide)\b
|
||||
\b(git|npm|yarn|pnpm|docker|kubernetes)\b
|
||||
\b(config|setting|environment|variable|env)\b
|
||||
```
|
||||
|
||||
Examples:
|
||||
- "Use pnpm instead of npm"
|
||||
- "Configure ESLint with these rules"
|
||||
- "Run Docker in production"
|
||||
|
||||
### New Skill
|
||||
|
||||
Patterns indicating skill-worthy discoveries:
|
||||
|
||||
```regex
|
||||
\b(workaround|trick|hack|solution|fix|debug|resolve)\b
|
||||
\b(error|bug|issue|problem)\s+(was|is|fixed|solved|resolved)\b
|
||||
(took|spent)\s+\d+\s*(min|minute|hour|day)
|
||||
\b(finally|after trying|turns out|the issue was)\b
|
||||
```
|
||||
|
||||
Examples:
|
||||
- "The workaround is to clear the cache first"
|
||||
- "After 2 hours debugging, found the issue was..."
|
||||
- "Turns out the error message was misleading"
|
||||
|
||||
## Edge Cases
|
||||
|
||||
### False Positives to Avoid
|
||||
|
||||
Some patterns may match but don't indicate learnings:
|
||||
|
||||
- Rhetorical questions: "Why would you never do X?" (not a directive)
|
||||
- Hypotheticals: "If you never use Y, then..." (conditional)
|
||||
- Quotes/references: "The docs say never..." (not user's directive)
|
||||
- Negations: "It's not wrong to..." (opposite meaning)
|
||||
|
||||
### Context Sensitivity
|
||||
|
||||
Consider surrounding context:
|
||||
|
||||
- "That's not wrong" - NOT a correction
|
||||
- "That's not right" - IS a correction
|
||||
- "Never mind" - NOT a directive about future behavior
|
||||
- "Always" in a loop - NOT a behavioral directive
|
||||
|
||||
## Combining Patterns
|
||||
|
||||
When multiple patterns match:
|
||||
|
||||
1. Use the highest confidence pattern
|
||||
2. If equal confidence, use the most specific category
|
||||
3. Prefer explicit rules over implied preferences
|
||||
4. Prioritize frustration markers (indicate repeated issue)
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
The `signal_detector.py` script implements these patterns. To update patterns:
|
||||
|
||||
1. Add pattern to appropriate `*_PATTERNS` list
|
||||
2. Run `python signal_detector.py --test` to verify
|
||||
3. Add test case for new pattern
|
||||
4. Update this documentation
|
||||
49
archive/inactive-skills/reflect-learn/skill.json
Normal file
49
archive/inactive-skills/reflect-learn/skill.json
Normal file
@@ -0,0 +1,49 @@
|
||||
{
|
||||
"name": "Reflect - Agent Self-Improvement",
|
||||
"emoji": "🪞",
|
||||
"description": "Self-improvement through conversation analysis. Extracts learnings from corrections, success patterns, and session outcomes. Encodes learnings permanently into agent definitions for continuous improvement across all future sessions.",
|
||||
"category": "meta",
|
||||
"author": "Claude Code Toolkit",
|
||||
"version": "2.0.0",
|
||||
"readme": "README.md",
|
||||
"tags": [
|
||||
"reflection",
|
||||
"self-improvement",
|
||||
"learning",
|
||||
"meta",
|
||||
"agent-development",
|
||||
"continuous-improvement"
|
||||
],
|
||||
"features": [
|
||||
"Signal detection with confidence levels (HIGH/MEDIUM/LOW)",
|
||||
"Automatic category classification (Code Style, Architecture, Process, Domain, Tools)",
|
||||
"Agent file updates with version control",
|
||||
"New skill generation from debugging discoveries",
|
||||
"Metrics tracking and improvement statistics",
|
||||
"Human-in-the-loop approval workflow"
|
||||
],
|
||||
"repository": "https://github.com/stevengonsalvez/ai-coder-rules",
|
||||
"license": "MIT",
|
||||
"keywords": [
|
||||
"reflect",
|
||||
"self-improvement",
|
||||
"learning",
|
||||
"agent",
|
||||
"corrections",
|
||||
"patterns",
|
||||
"meta-cognition"
|
||||
],
|
||||
"defaults": {
|
||||
"state_dir": "~/.reflect",
|
||||
"auto_reflect": false,
|
||||
"confidence_threshold": "medium"
|
||||
},
|
||||
"clawdbot": {
|
||||
"triggers": [
|
||||
"reflect",
|
||||
"self-reflect",
|
||||
"review session",
|
||||
"extract learnings"
|
||||
]
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user