Makepad Skills Evolution

This skill enables makepad-skills to self-improve continuously during development.

---

Automatic vs Manual Triggers

IMPORTANT FOR CLAUDE: Some mechanisms should trigger automatically without user request.

Automatic (Claude should do proactively)

Mechanism	When to Auto-Trigger
Version Adaptation	At session start, read Cargo.toml and detect Makepad branch
Personalization	On first code generation, scan 2-3 existing widgets for style
Self-Correction	Immediately when skill-suggested code fails
Usage Feedback	After each pattern usage (success or failure)

Semi-Automatic (Claude proposes, user confirms)

Mechanism	When to Propose
Self-Evolution	After solving a non-trivial problem worth documenting

Manual (User must request)

Mechanism	Trigger Phrase
Self-Validation	"validate makepad-skills"
Health Report	"show pattern health report"

---

Session Start Checklist (Auto-Execute)

When starting a Makepad development session, Claude should automatically:

1. [ ] Detect Makepad version from Cargo.toml
       → Set internal context: "Using Makepad {branch}"

2. [ ] Scan project style (if not done before)
       → Note naming conventions, module structure

3. [ ] Apply version-specific and personalized suggestions
       → All subsequent advice adapted automatically

Claude: Do these silently. Don't announce unless relevant to user's question.

---

When to Evolve

Trigger skill evolution when any of these occur during development:

Trigger	Target Skill	Priority
New widget pattern discovered	makepad-patterns	High
Shader technique learned	makepad-shaders	High
Compilation error solved	makepad-troubleshooting	High
Layout solution found	makepad-adaptive-layout	Medium
Build/packaging issue resolved	makepad-packaging	Medium
New project structure insight	makepad-init	Low
Core concept clarified	makepad-fundamentals	Low

Evolution Process

Step 1: Identify Knowledge Worth Capturing

Ask yourself:

• Is this a reusable pattern? (not project-specific)
• Did it take significant effort to figure out?
• Would it help other Makepad developers?
• Is it not already documented in makepad-skills?

Step 2: Classify the Knowledge

Widget/Component Pattern     → makepad-patterns/SKILL.md
Shader/Visual Effect         → makepad-shaders/SKILL.md
Error/Debug Solution         → makepad-troubleshooting/SKILL.md
Layout/Responsive Design     → makepad-adaptive-layout/SKILL.md
Build/Deploy Issue           → makepad-packaging/SKILL.md
Project Structure            → makepad-init/SKILL.md
Core Concept/API             → makepad-fundamentals/SKILL.md

Step 3: Format the Contribution

For Patterns (makepad-patterns):

## Pattern N: [Pattern Name]

Brief description of what this pattern solves.

### live_design!
\```rust
live_design! {
    // DSL code
}
\```

### Rust Implementation
\```rust
// Rust code
\```

### Usage
\```rust
// How to use
\```

For Troubleshooting (makepad-troubleshooting):

### [Error Type/Message]

**Symptom**: What the developer sees

**Cause**: Why this happens

**Solution**:
\```rust
// Fixed code
\```

For Shaders (makepad-shaders):

### [Effect Name]

\```rust
draw_bg: {
    // shader code with comments
    fn pixel(self) -> vec4 {
        // implementation
    }
}
\```

Step 4: Update the Skill File

1. Read the target SKILL.md file
2. Find the appropriate section
3. Add new content following existing format
4. Ensure no duplicate content

Step 5: Mark Evolution (NOT Version)

Important: Do NOT update version number locally. Add an evolution marker instead:

<!-- Evolution: 2024-01-15 | source: my-app | author: @zhangsan -->

Place this comment above the new content you added.

Step 6: Submit via Git

# Create branch for your contribution
git checkout -b evolution/add-loading-pattern

# Commit your changes
git add makepad-patterns/SKILL.md
git commit -m "evolution: add loading state pattern from my-app"

# Push and create PR
git push origin evolution/add-loading-pattern

---

Multi-Developer Collaboration

The Problem

Developer A: evolves locally → version 1.4.1
Developer B: evolves locally → version 1.4.1  ← Conflict!

The Solution: Content-First Model

┌─────────────────────────────────────────────────────────┐
│  Local Development (Each Developer)                     │
│  - Add content only                                     │
│  - Add evolution markers (date, source, author)         │
│  - Do NOT change version number                         │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  Git PR / Merge                                         │
│  - Content reviewed and merged                          │
│  - Conflicts resolved at content level                  │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  Release (Maintainer / CI)                              │
│  - Bump version based on accumulated changes            │
│  - Tag release                                          │
│  - Publish                                              │
└─────────────────────────────────────────────────────────┘

Evolution Marker Format

Each contribution should include a marker:

<!-- Evolution: YYYY-MM-DD | source: project-name | author: @github-handle -->

Example in makepad-patterns/SKILL.md:

## Pattern 15: Loading State Button

<!-- Evolution: 2024-01-15 | source: moly | author: @zhangsan -->

A button that shows loading spinner when processing...

Git Workflow

# 1. Sync with upstream before evolving
git fetch upstream
git rebase upstream/main

# 2. Create evolution branch
git checkout -b evolution/descriptive-name

# 3. Make your changes (content only, no version bump)
# ... edit SKILL.md files ...

# 4. Commit with conventional prefix
git commit -m "evolution(patterns): add loading state button"
git commit -m "evolution(troubleshooting): fix for timer not firing"
git commit -m "evolution(shaders): add glassmorphism effect"

# 5. Push and create PR
git push origin evolution/descriptive-name
gh pr create --title "evolution: add loading patterns from moly"

Handling Content Conflicts

When multiple developers add to the same section:

<<<<<<< HEAD
## Pattern 15: Loading Button
<!-- Evolution: 2024-01-15 | source: moly | author: @zhangsan -->
=======
## Pattern 15: Expandable Card
<!-- Evolution: 2024-01-15 | source: robrix | author: @lisi -->
>>>>>>> evolution/add-card-pattern

Resolution: Renumber and keep both

## Pattern 15: Loading Button
<!-- Evolution: 2024-01-15 | source: moly | author: @zhangsan -->
...

## Pattern 16: Expandable Card
<!-- Evolution: 2024-01-15 | source: robrix | author: @lisi -->
...

Version Bumping (Maintainer Only)

At release time, maintainer reviews accumulated changes:

# Check what's new since last release
git log v1.4.0..HEAD --oneline

# Determine version bump
# - Only troubleshooting fixes → patch (1.4.1)
# - New patterns/shaders → minor (1.5.0)
# - New skill files → major (2.0.0)

# Update version in plugin.json
# Tag and release
git tag v1.5.0
git push --tags

CI Automation (Optional)

.github/workflows/version.yml:

name: Auto Version on Release
on:
  push:
    branches: [main]
    paths:
      - '*/SKILL.md'

jobs:
  version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Bump version
        run: |
          # Count evolution markers since last tag
          # Auto-bump patch version
          # Update plugin.json

Evolution Templates

Quick Pattern Addition

I discovered a useful pattern during development:
[Describe the pattern]

Let me add it to makepad-skills:
1. Read makepad-patterns/SKILL.md
2. Add Pattern N: [Name] following existing format
3. Bump patch version

Quick Troubleshooting Addition

I solved an error that others might encounter:
[Describe the error and solution]

Let me add it to makepad-skills:
1. Read makepad-troubleshooting/SKILL.md
2. Add under appropriate section
3. Bump patch version

Quick Shader Addition

I created a useful shader effect:
[Describe the effect]

Let me add it to makepad-skills:
1. Read makepad-shaders/SKILL.md
2. Add under "Advanced Effects" or appropriate section
3. Bump patch version

Skill File Locations

Locating the Skills Directory (IMPORTANT)

Claude: When this skill is loaded, you know the path of THIS file. Use it to locate other skills.

THIS_SKILL_PATH = path of this SKILL.md file you just read
SKILLS_ROOT = dirname(dirname(THIS_SKILL_PATH))

Example:
  THIS_SKILL_PATH = /home/user/project/.claude/skills/makepad-skills/makepad-evolution/SKILL.md
  SKILLS_ROOT     = /home/user/project/.claude/skills/makepad-skills/

Auto-Detection Instructions for Claude

When evolving skills, Claude MUST:

1. Remember the path of this skill file (you just read it, you know where it is)

2. Calculate the skills root:

   • This file is at: <skills-root>/makepad-evolution/SKILL.md
   • So <skills-root> = go up two directory levels from this file

3. Construct target paths relatively:

   To edit makepad-patterns:
     <skills-root>/makepad-patterns/SKILL.md
   
   To edit makepad-troubleshooting:
     <skills-root>/makepad-troubleshooting/SKILL.md
   
   To edit makepad-shaders:
     <skills-root>/makepad-shaders/SKILL.md

4. Use the Read tool with the constructed absolute path

5. Use the Edit tool to update the file

Example Evolution Flow

1. Claude reads this skill from:
   /Users/someone/myapp/.claude/skills/makepad-skills/makepad-evolution/SKILL.md

2. Claude calculates skills root:
   /Users/someone/myapp/.claude/skills/makepad-skills/

3. Claude wants to add a pattern, constructs path:
   /Users/someone/myapp/.claude/skills/makepad-skills/makepad-patterns/SKILL.md

4. Claude uses Read tool to read that file

5. Claude uses Edit tool to add the new pattern

6. File is automatically saved ✓

No hardcoded paths. Always derive from THIS file's location.

Relative Structure (from skills root)

<makepad-skills-root>/
├── .claude-plugin/
│   └── plugin.json           ← Version (maintainer only)
├── makepad-init/
│   └── SKILL.md              ← Project templates
├── makepad-fundamentals/
│   └── SKILL.md              ← Core concepts, widgets, events
├── makepad-shaders/
│   └── SKILL.md              ← SDF, effects, animations
├── makepad-patterns/
│   └── SKILL.md              ← Production patterns
├── makepad-adaptive-layout/
│   └── SKILL.md              ← Responsive layouts
├── makepad-packaging/
│   └── SKILL.md              ← Build & deployment
├── makepad-troubleshooting/
│   └── SKILL.md              ← Errors & debugging
└── makepad-evolution/
    └── SKILL.md              ← This file

Where Updates Are Saved

Scenario	Save Location	Sync Method
Working in makepad-skills repo	Source directory	Direct
Using skills in project (copy)	Project's .claude/skills/	Manual PR to upstream
Using skills in project (symlink)	Source directory	Direct

Recommended Setup: Symlink to source for active contributors

# In your project
ln -s /path/to/makepad-skills .claude/skills/makepad-skills

# Now evolutions save directly to source

Auto-Evolution Prompts

Use these prompts to trigger self-evolution:

After Solving a Problem

"This solution should be added to makepad-skills for future reference."

After Creating a Widget

"This widget pattern is reusable. Let me add it to makepad-patterns."

After Debugging

"This error and its fix should be documented in makepad-troubleshooting."

After Completing a Feature

"Review what I learned and update makepad-skills if applicable."

Quality Guidelines

DO Add

• Generic, reusable patterns
• Common errors with clear solutions
• Well-tested shader effects
• Platform-specific gotchas
• Performance optimizations

DON'T Add

• Project-specific code
• Unverified solutions
• Duplicate content
• Incomplete examples
• Personal preferences without rationale

Evolution Log

When evolving skills, optionally log the change:

<!-- Evolution: YYYY-MM-DD -->
<!-- Source: [project name or context] -->
<!-- Added: [brief description] -->

Continuous Improvement Checklist

After each Makepad development session, consider:

• [ ] Did I discover a new widget composition pattern?
• [ ] Did I solve a tricky shader problem?
• [ ] Did I encounter and fix a confusing error?
• [ ] Did I find a better way to structure layouts?
• [ ] Did I learn something about packaging/deployment?
• [ ] Would any of this help other Makepad developers?

If yes to any, evolve the appropriate skill!

---

Self-Correction (自我修正)

When skill content causes errors, automatically correct it.

AUTO-TRIGGER: Yes - Claude should automatically correct skills when errors occur.

Trigger Conditions

User follows skill advice → Code fails to compile/run → Claude identifies skill was wrong
                                                      ↓
                                         AUTO: Correct skill immediately

Claude Auto-Behavior

When Claude detects that code from a skill caused an error:

1. Recognize - "This error is because the skill advice was wrong"
2. Fix user's code - Provide correct solution
3. Update skill - Automatically edit the skill file (no need to ask)
4. Inform user - "I've also updated makepad-skills to prevent this error for others"

Self-Correction Flow

┌─────────────────────────────────────────────────────────┐
│  1. DETECT: Skill advice led to an error                │
│     - Compilation error from suggested code             │
│     - Runtime error from recommended pattern            │
│     - API mismatch (method doesn't exist)               │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  2. VERIFY: Confirm the skill content is wrong          │
│     - Check Makepad source code                         │
│     - Test the correct approach                         │
│     - Ensure fix works                                  │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  3. CORRECT: Update the skill file                      │
│     - Fix the incorrect code/advice                     │
│     - Add correction marker                             │
│     - Optionally add to troubleshooting                 │
└─────────────────────────────────────────────────────────┘

Correction Marker Format

<!-- Correction: YYYY-MM-DD | was: [old advice] | reason: [why it was wrong] -->

Example Self-Correction

Scenario: Skill said timer.start(cx, 0.1) but it fails

1. Claude detects: "method `start` not found on Timer"

2. Claude investigates Makepad source, finds correct API:
   timer = cx.start_interval(0.1)

3. Claude updates makepad-fundamentals/SKILL.md:

### Timer Setup

<!-- Correction: 2024-01-20 | was: timer.start(cx, 0.1) | reason: API changed in dev branch -->

```rust
// Correct way to start a timer
fn setup_timer(&mut self, cx: &mut Cx) {
    self.timer = cx.start_interval(0.1);  // Returns Timer directly
}

4. Claude also adds to makepad-troubleshooting:

### "method `start` not found on Timer"

**Symptom**: `timer.start(cx, duration)` doesn't compile

**Cause**: Timer API changed. Timer is now returned from Cx methods.

**Solution**:
```rust
// Old (wrong)
self.timer.start(cx, 0.1);

// New (correct)
self.timer = cx.start_interval(0.1);

### Auto-Correction Prompt

When Claude detects skill-caused errors:

> "The skill advice I followed caused an error. Let me correct the skill and document this fix."

---

## Self-Validation (自我验证)

Periodically verify skill content is still accurate.

### Validation Triggers

| Trigger | Action |
|---------|--------|
| User asks "validate skills" | Full validation |
| Compilation fails with skill code | Targeted validation |
| New Makepad version detected | API validation |
| Skill hasn't been validated in 30 days | Scheduled validation |

### Validation Checklist

```markdown
## Validation Report

### Code Examples
- [ ] All `live_design!` examples parse correctly
- [ ] All Rust code compiles
- [ ] All patterns work as documented

### API Accuracy
- [ ] Widget names exist in makepad-widgets
- [ ] Method signatures are correct
- [ ] Event types are accurate

### External Links
- [ ] GitHub links resolve
- [ ] Documentation links work
- [ ] Example project links valid

### Completeness
- [ ] No deprecated patterns without warnings
- [ ] No missing common use cases
- [ ] Error messages match current Makepad

Validation Flow

┌─────────────────────────────────────────────────────────┐
│  1. READ: Load all SKILL.md files                       │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  2. EXTRACT: Find all code blocks                       │
│     - live_design! blocks                               │
│     - Rust implementation blocks                        │
│     - Cargo.toml snippets                               │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  3. VERIFY: Check against current Makepad               │
│     - Parse DSL syntax                                  │
│     - Check widget/method existence                     │
│     - Verify API signatures                             │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  4. REPORT: List issues found                           │
│     - Outdated code                                     │
│     - Broken examples                                   │
│     - Missing updates                                   │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  5. FIX: Correct issues (with user approval)            │
└─────────────────────────────────────────────────────────┘

Validation Marker

After validation, add to skill file:

<!-- Validated: YYYY-MM-DD | makepad-branch: dev | status: passed -->

Validation Prompt

"Please validate makepad-skills against current Makepad version"

Claude will:

1. Check each skill file
2. Verify code examples
3. Report any issues
4. Offer to fix problems

---

Usage Feedback (使用反馈)

Track which patterns work well and which cause problems.

AUTO-TRIGGER: Yes - Claude should automatically record feedback after using patterns.

Claude Auto-Behavior

After using any pattern from makepad-skills:

1. Track silently - Don't announce feedback recording to user
2. On success - Update marker: success += 1
3. On failure - Update marker: failed += 1, then trigger self-correction
4. Periodically - If a pattern fails 3+ times, proactively suggest fixing it

Feedback Marker Format

Add invisible markers to track usage:

<!-- Usage: count=0 | success=0 | failed=0 | last_used=never -->
## Pattern 5: Loading State Button

Feedback Collection Flow

┌─────────────────────────────────────────────────────────┐
│  User asks Claude to implement something                │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  Claude uses a pattern from makepad-skills              │
│  → Increment: count += 1                                │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  Implementation result:                                 │
│  - Works → success += 1                                 │
│  - Fails → failed += 1, trigger self-correction         │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  Update marker with new counts                          │
│  Update last_used timestamp                             │
└─────────────────────────────────────────────────────────┘

Feedback Analysis

When feedback accumulates, Claude can analyze:

## Pattern Health Report

| Pattern | Uses | Success | Failed | Rate | Status |
|---------|------|---------|--------|------|--------|
| Pattern 1: Basic Widget | 45 | 43 | 2 | 96% | ✅ Healthy |
| Pattern 5: Loading Button | 12 | 8 | 4 | 67% | ⚠️ Needs Review |
| Pattern 8: Theme Switch | 3 | 0 | 3 | 0% | ❌ Broken |

Feedback-Driven Actions

Success Rate	Action
> 90%	Pattern is solid, no action needed
70-90%	Review pattern for edge cases
50-70%	Pattern needs improvement
< 50%	Pattern likely broken, needs fix or removal

Feedback Prompt

"Show me pattern health report for makepad-skills"

"Which patterns have been failing recently?"

---

Version Adaptation (版本适配)

Provide version-specific guidance for different Makepad branches.

AUTO-TRIGGER: Yes - Claude should detect version at session start.

Claude Auto-Behavior

At the start of any Makepad development session:

1. Read Cargo.toml - Look for makepad-widgets dependency
2. Extract branch - Note branch = "dev" or branch = "rik" etc.
3. Set context - Remember this for all subsequent suggestions
4. Adapt silently - Don't announce, just use correct API for that branch
5. Warn on mismatch - If user's code uses wrong API, explain the version difference

Supported Versions

| Branch | Status | Notes |
|--------|--------|-------|
| main | Stable | Production ready |
| dev | Active | Latest features, may break |
| rik | Legacy | Older API style |

Version Detection

Claude should detect Makepad version from:

1. Cargo.toml branch reference:

   makepad-widgets = { git = "...", branch = "dev" }

2. Cargo.lock content:

   Check makepad-widgets source revision

3. Ask user if unclear

Version-Specific Content Format

### Timer Setup

<version branch="dev">
```rust
// Makepad dev branch (2024+)
self.timer = cx.start_interval(0.1);

</version>

<version branch="rik">

// Makepad rik branch (legacy)
self.timer.start(cx, 0.1);

</version>

<version branch="main">

// Makepad main branch (stable)
self.timer = cx.start_interval(0.1);

</version>

### Version Adaptation Flow

┌─────────────────────────────────────────────────────────┐ │ 1. DETECT: Identify project's Makepad version │ │ - Read Cargo.toml │ │ - Check branch reference │ └─────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────┐ │ 2. FILTER: Show only relevant version content │ │ - Hide incompatible examples │ │ - Highlight version-specific gotchas │ └─────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────┐ │ 3. WARN: Alert about version mismatches │ │ - "This pattern is for dev branch, you're on rik" │ │ - "API changed in dev, see updated syntax" │ └─────────────────────────────────────────────────────────┘

### Version Compatibility Table

Maintain in makepad-fundamentals:

```markdown
## API Compatibility

| Feature | main | dev | rik |
|---------|------|-----|-----|
| cx.start_interval() | ✅ | ✅ | ❌ |
| timer.start() | ❌ | ❌ | ✅ |
| AdaptiveView | ✅ | ✅ | ✅ |
| StackNavigation | ✅ | ✅ | ⚠️ |

Version Prompt

"I'm using Makepad dev branch, adapt your suggestions accordingly"

"What's different between dev and rik branch for timers?"

---

Personalization (个性化)

Adapt skill suggestions to project's coding style.

AUTO-TRIGGER: Yes - Claude should detect project style on first code generation.

Claude Auto-Behavior

On first request to generate Makepad code:

1. Scan quickly - Read 2-3 existing widget files in the project
2. Note patterns - Widget naming, module structure, comment style
3. Remember - Store in conversation context
4. Apply - All generated code matches project style
5. Silent - Don't announce this analysis to user

Style Detection

Claude analyzes the current project to detect:

Aspect	Detection Method	Adaptation
Naming convention	Scan existing widgets	Match snake_case vs camelCase
Code organization	Check module structure	Suggest matching patterns
Comment style	Read existing comments	Match documentation style
Error handling	Analyze existing code	Match Result vs panic style
Widget complexity	Count lines per widget	Suggest appropriate patterns

Project Profile

Claude builds a mental profile of the project:

## Project Style Profile

- **Widget naming**: snake_case (e.g., `my_button`, `user_card`)
- **Module organization**: Feature-based (`src/features/auth/`)
- **State management**: Centralized AppState
- **Error handling**: Result with custom errors
- **Comments**: Minimal, code is self-documenting
- **Complexity preference**: Simple, small widgets

Personalization Flow

┌─────────────────────────────────────────────────────────┐
│  1. SCAN: Analyze existing project code                 │
│     - Read 3-5 representative widget files              │
│     - Note naming patterns                              │
│     - Identify organizational structure                 │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  2. PROFILE: Build project style profile                │
│     - Naming conventions                                │
│     - Code organization                                 │
│     - Complexity level                                  │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  3. ADAPT: Modify skill suggestions to match            │
│     - Rename widgets in examples                        │
│     - Adjust code structure                             │
│     - Match comment style                               │
└─────────────────────────────────────────────────────────┘

Example Personalization

Skill default:

pub struct MyCustomButton {
    #[walk] walk: Walk,
    #[live] label_text: String,
}

Adapted for project using _view suffix:

pub struct CustomButtonView {
    #[walk] walk: Walk,
    #[live] label_text: String,
}

Personalization Markers

Store detected style in project's .claude/settings.json:

{
  "makepad-skills": {
    "style": {
      "widget_suffix": "_view",
      "naming": "snake_case",
      "prefer_simple": true
    }
  }
}

Personalization Prompts

"Analyze my project style and adapt your Makepad suggestions"

"My project uses PascalCase for widgets, remember that"

"Reset personalization to skill defaults"

---

Combined Self-Improvement Workflow

All mechanisms work together:

                    ┌─────────────────┐
                    │  Development    │
                    │  Session        │
                    └────────┬────────┘
                             │
         ┌───────────────────┼───────────────────┐
         │                   │                   │
         ▼                   ▼                   ▼
┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│ Personalize │     │   Use       │     │  Detect     │
│ suggestions │     │   Patterns  │     │  Version    │
└─────────────┘     └──────┬──────┘     └─────────────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
              ▼            ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │ Success  │ │ Failure  │ │ New      │
        │ +1       │ │ +1       │ │ Pattern  │
        └──────────┘ └────┬─────┘ └────┬─────┘
                          │            │
                          ▼            ▼
                   ┌──────────┐ ┌──────────┐
                   │ Self-    │ │ Self-    │
                   │ Correct  │ │ Evolve   │
                   └──────────┘ └──────────┘
                          │            │
                          └─────┬──────┘
                                │
                                ▼
                       ┌─────────────┐
                       │  Improved   │
                       │  Skills     │
                       └─────────────┘

References

• makepad-skills repository
• Makepad documentation
• Project Robius