Skill: mmyg11/agent-reflect-temp (version 1.0.0)

--- 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 [signal_patterns.md](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 [agent_mappings.md](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

path: agent_mappings.md
content: # 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


path: README.md
content: # 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


path: signal_patterns.md
content: # 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


path: skill.json
content: {
  "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"
    ]
  }
}


path: _meta.json
content: {
  "owner": "stevengonsalvez",
  "slug": "agent-reflect-local",
  "displayName": "Reflect",
  "latest": {
    "version": "2.0.0",
    "publishedAt": 1769436057230,
    "commit": "https://github.com/clawdbot/skills/commit/3394b0b6608efffdd57feb20787ee5b61cd5a217"
  },
  "history": []
}


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)