/si:promote — Graduate Learnings to Rules
Graduate a proven pattern from auto-memory (MEMORY.md) to CLAUDE.md or .claude/rules/ for permanent enforcement.
How to use it
Claude Code
- Run the line below. It pulls the whole folder into
~/.claude/skills/promote, including the files SKILL.md points to. - Describe your job in plain words. Claude Code follows the skill from there.
npx degit alirezarezvani/claude-skills/engineering-team/self-improving-agent/skills/promote#main ~/.claude/skills/promoteFor one project only, change the path to .claude/skills/promote. This skill also uses MEMORY.md, pnpm-lock.yaml — copying SKILL.md alone won't be enough. See the folder on GitHub.
Claude (web or desktop app)
- On this page open ⋯ → Download .md.
- Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
- Pick the file and Save. Claude shows the name and description and runs a security scan.
- Check the skill is switched on.
- Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
- ChatGPT: make a Project and paste it into Instructions.
- Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
- Check which app you pasted it into — the steps above name the right one.
- Some skills need the paid tier of Claude or ChatGPT.
Paste into Claude, ChatGPT or Cursor.
Source of /si:promote — Graduate Learnings to Rules
Show the full text145 lines
| name | description |
|---|---|
| promote | Graduate a proven pattern from auto-memory (MEMORY.md) to CLAUDE.md or .claude/rules/ for permanent enforcement. Use when the user runs /si:promote or asks to make a learned behavior permanent. |
/si:promote — Graduate Learnings to Rules
Moves a proven pattern from Claude's auto-memory into the project's rule system, where it becomes an enforced instruction rather than a background note.
Usage
/si:promote <pattern description> # Auto-detect best target
/si:promote <pattern> --target claude.md # Promote to CLAUDE.md
/si:promote <pattern> --target rules/testing.md # Promote to scoped rule
/si:promote <pattern> --target rules/api.md --paths "src/api/**/*.ts" # Scoped with paths
Workflow
Step 1: Understand the pattern
Parse the user's description. If vague, ask one clarifying question:
- "What specific behavior should Claude follow?"
- "Does this apply to all files or specific paths?"
Step 2: Find the pattern in auto-memory
# Search MEMORY.md for related entries
MEMORY_DIR="$HOME/.claude/projects/$(pwd | sed 's|/|%2F|g; s|%2F|/|; s|^/||')/memory"
grep -ni "<keywords>" "$MEMORY_DIR/MEMORY.md"
Show the matching entries and confirm they're what the user means.
Step 3: Determine the right target
| Pattern scope | Target | Example |
|---|---|---|
| Applies to entire project | ./CLAUDE.md |
"Use pnpm, not npm" |
| Applies to specific file types | .claude/rules/<topic>.md |
"API handlers need validation" |
| Applies to all your projects | ~/.claude/CLAUDE.md |
"Prefer explicit error handling" |
If the user didn't specify a target, recommend one based on scope.
Step 4: Distill into a concise rule
Transform the learning from auto-memory's note format into CLAUDE.md's instruction format:
Before (MEMORY.md — descriptive):
The project uses pnpm workspaces. When I tried npm install it failed. The lock file is pnpm-lock.yaml. Must use pnpm install for dependencies.
After (CLAUDE.md — prescriptive):
## Build & Dependencies
- Package manager: pnpm (not npm). Use `pnpm install`.
Rules for distillation:
- One line per rule when possible
- Imperative voice ("Use X", "Always Y", "Never Z")
- Include the command or example, not just the concept
- No backstory — just the instruction
Step 5: Write to target
For CLAUDE.md:
- Read existing CLAUDE.md
- Find the appropriate section (or create one)
- Append the new rule under the right heading
- If file would exceed 200 lines, suggest using
.claude/rules/instead
For .claude/rules/:
- Create the file if it doesn't exist
- Add YAML frontmatter with
pathsif scoped - Write the rule content
---
paths:
- "src/api/**/*.ts"
- "tests/api/**/*"
---
# API Development Rules
- All endpoints must validate input with Zod schemas
- Use `ApiError` class for error responses (not raw Error)
- Include OpenAPI JSDoc comments on handler functions
Step 6: Clean up auto-memory
After promoting, remove or mark the original entry in MEMORY.md:
# Show what will be removed
grep -n "<pattern>" "$MEMORY_DIR/MEMORY.md"
Ask the user to confirm removal. Then edit MEMORY.md to remove the promoted entry. This frees space for new learnings.
Step 7: Confirm
✅ Promoted to {{target}}
Rule: "{{distilled rule}}"
Source: MEMORY.md line {{n}} (removed)
MEMORY.md: {{lines}}/200 lines remaining
The pattern is now an enforced instruction. Claude will follow it in all future sessions.
Promotion Decision Guide
Promote when:
- Pattern appeared 3+ times in auto-memory
- You corrected Claude about it more than once
- It's a project convention that any contributor should know
- It prevents a recurring mistake
Don't promote when:
- It's a one-time debugging note (leave in auto-memory)
- It's session-specific context (session memory handles this)
- It might change soon (e.g., during a migration)
- It's already covered by existing rules
CLAUDE.md vs .claude/rules/
| Use CLAUDE.md for | Use .claude/rules/ for |
|---|---|
| Global project rules | File-type-specific patterns |
| Build commands | Testing conventions |
| Architecture decisions | API design rules |
| Team conventions | Framework-specific gotchas |
Tips
- Keep CLAUDE.md under 200 lines — use rules/ for overflow
- One rule per line is easier to maintain than paragraphs
- Include the concrete command, not just the concept
- Review promoted rules quarterly — remove what's no longer relevant
| 1 | |
| 2 | name "promote" |
| 3 | description "Graduate a proven pattern from auto-memory (MEMORY.md) to CLAUDE.md or .claude/rules/ for permanent enforcement. Use when the user runs /si:promote or asks to make a learned behavior permanent." |
| 4 | |
| 5 | |
| 6 | # /si:promote — Graduate Learnings to Rules |
| 7 | |
| 8 | Moves a proven pattern from Claude's auto-memory into the project's rule system, where it becomes an enforced instruction rather than a background note. |
| 9 | |
| 10 | ## Usage |
| 11 | |
| 12 | |
| 13 | /si:promote <pattern description> # Auto-detect best target |
| 14 | /si:promote <pattern> --target claude.md # Promote to CLAUDE.md |
| 15 | /si:promote <pattern> --target rules/testing.md # Promote to scoped rule |
| 16 | /si:promote <pattern> --target rules/api.md --paths "src/api/**/*.ts" # Scoped with paths |
| 17 | |
| 18 | |
| 19 | ## Workflow |
| 20 | |
| 21 | ### Step 1: Understand the pattern |
| 22 | |
| 23 | Parse the user's description. If vague, ask one clarifying question: |
| 24 | "What specific behavior should Claude follow?" |
| 25 | "Does this apply to all files or specific paths?" |
| 26 | |
| 27 | ### Step 2: Find the pattern in auto-memory |
| 28 | |
| 29 | |
| 30 | # Search MEMORY.md for related entries |
| 31 | MEMORY_DIR="$HOME/.claude/projects/$(pwd | sed 's|/|%2F|g; s|%2F|/|; s|^/||')/memory" |
| 32 | grep -ni "<keywords>" "$MEMORY_DIR/MEMORY.md" |
| 33 | |
| 34 | |
| 35 | Show the matching entries and confirm they're what the user means. |
| 36 | |
| 37 | ### Step 3: Determine the right target |
| 38 | |
| 39 | | Pattern scope | Target | Example | |
| 40 | |---|---|---| |
| 41 | | Applies to entire project | `./CLAUDE.md` | "Use pnpm, not npm" | |
| 42 | | Applies to specific file types | `.claude/rules/<topic>.md` | "API handlers need validation" | |
| 43 | | Applies to all your projects | `~/.claude/CLAUDE.md` | "Prefer explicit error handling" | |
| 44 | |
| 45 | If the user didn't specify a target, recommend one based on scope. |
| 46 | |
| 47 | ### Step 4: Distill into a concise rule |
| 48 | |
| 49 | Transform the learning from auto-memory's note format into CLAUDE.md's instruction format: |
| 50 | |
| 51 | **Before** (MEMORY.md — descriptive): |
| 52 | > The project uses pnpm workspaces. When I tried npm install it failed. The lock file is pnpm-lock.yaml. Must use pnpm install for dependencies. |
| 53 | |
| 54 | **After** (CLAUDE.md — prescriptive): |
| 55 | |
| 56 | ## Build & Dependencies |
| 57 | - Package manager: pnpm (not npm). Use `pnpm install`. |
| 58 | |
| 59 | |
| 60 | **Rules for distillation:** |
| 61 | One line per rule when possible |
| 62 | Imperative voice ("Use X", "Always Y", "Never Z") |
| 63 | Include the command or example, not just the concept |
| 64 | No backstory — just the instruction |
| 65 | |
| 66 | ### Step 5: Write to target |
| 67 | |
| 68 | **For CLAUDE.md:** |
| 69 | Read existing CLAUDE.md |
| 70 | Find the appropriate section (or create one) |
| 71 | Append the new rule under the right heading |
| 72 | If file would exceed 200 lines, suggest using `.claude/rules/` instead |
| 73 | |
| 74 | **For `.claude/rules/`:** |
| 75 | Create the file if it doesn't exist |
| 76 | Add YAML frontmatter with `paths` if scoped |
| 77 | Write the rule content |
| 78 | |
| 79 | |
| 80 | |
| 81 | paths: |
| 82 | - "src/api/**/*.ts" |
| 83 | - "tests/api/**/*" |
| 84 | |
| 85 | |
| 86 | # API Development Rules |
| 87 | |
| 88 | - All endpoints must validate input with Zod schemas |
| 89 | - Use `ApiError` class for error responses (not raw Error) |
| 90 | - Include OpenAPI JSDoc comments on handler functions |
| 91 | |
| 92 | |
| 93 | ### Step 6: Clean up auto-memory |
| 94 | |
| 95 | After promoting, remove or mark the original entry in MEMORY.md: |
| 96 | |
| 97 | |
| 98 | # Show what will be removed |
| 99 | grep -n "<pattern>" "$MEMORY_DIR/MEMORY.md" |
| 100 | |
| 101 | |
| 102 | Ask the user to confirm removal. Then edit MEMORY.md to remove the promoted entry. This frees space for new learnings. |
| 103 | |
| 104 | ### Step 7: Confirm |
| 105 | |
| 106 | |
| 107 | ✅ Promoted to {{target}} |
| 108 | |
| 109 | Rule: "{{distilled rule}}" |
| 110 | Source: MEMORY.md line {{n}} (removed) |
| 111 | MEMORY.md: {{lines}}/200 lines remaining |
| 112 | |
| 113 | The pattern is now an enforced instruction. Claude will follow it in all future sessions. |
| 114 | |
| 115 | |
| 116 | ## Promotion Decision Guide |
| 117 | |
| 118 | ### Promote when: |
| 119 | Pattern appeared 3+ times in auto-memory |
| 120 | You corrected Claude about it more than once |
| 121 | It's a project convention that any contributor should know |
| 122 | It prevents a recurring mistake |
| 123 | |
| 124 | ### Don't promote when: |
| 125 | It's a one-time debugging note (leave in auto-memory) |
| 126 | It's session-specific context (session memory handles this) |
| 127 | It might change soon (e.g., during a migration) |
| 128 | It's already covered by existing rules |
| 129 | |
| 130 | ### CLAUDE.md vs .claude/rules/ |
| 131 | |
| 132 | | Use CLAUDE.md for | Use .claude/rules/ for | |
| 133 | |---|---| |
| 134 | | Global project rules | File-type-specific patterns | |
| 135 | | Build commands | Testing conventions | |
| 136 | | Architecture decisions | API design rules | |
| 137 | | Team conventions | Framework-specific gotchas | |
| 138 | |
| 139 | ## Tips |
| 140 | |
| 141 | Keep CLAUDE.md under 200 lines — use rules/ for overflow |
| 142 | One rule per line is easier to maintain than paragraphs |
| 143 | Include the concrete command, not just the concept |
| 144 | Review promoted rules quarterly — remove what's no longer relevant |
| 145 |
Discussion
Browse more free Claude skills or everything in Operations.