self-evolve

Name: self-evolve
Author: avibebuilder

109stars17forks

How to install self-evolve?

avibebuilder/claude-prime/self-evolve

$npx -y skills add avibebuilder/claude-prime --skill self-evolve

Installs into the current project.

Summary

The single config quality skill. Two modes: (1) Default — review/wire pending self-improvement proposals. (2) Audit — analyzes skills, rules, CLAUDE.md, project refs, hooks, and agents against the actual codebase to find inaccuracies, trigger overlaps, stale references, and weak

Files · 1

View on GitHub

SKILL.md

1	ultrathink.
2
3	## Wire Mode: Apply Self-Improvement Proposals
4
5	When scope is `(none)`, or when pending proposals exist and user says "ok":
6
7	Fetching proposals:
8	```bash
9	python3 .claude/hooks/self-improve/self_improve_db.py resolve list
10	```
11
12	### Step 0: Consolidate before showing
13
14	User attention is finite — showing 12 proposals when 4 are duplicates, 3 already exist in rules, and 2 are noise wastes their focus on what matters. Before presenting anything, read the existing config (`.claude/rules/`, CLAUDE.md, CLAUDE.local.md, active skills) to understand what's already there. Then filter: proposals already covered by existing rules, duplicates of each other, and low-value noise that wouldn't improve agent behavior. Merge proposals addressing the same pattern into one entry with the clearest rationale.
15
16	Tell the user what you filtered: "Showing X of Y proposals (Z filtered)."
17
18	After user finishes reviewing visible proposals, batch-reject the filtered ones:
19	```bash
20	python3 .claude/hooks/self-improve/self_improve_db.py resolve <id1>,<id2>,... rejected
21	```
22
23	For each shown proposal, ask the user to approve or reject.
24
25	### Step 1: Classify — where does it belong?
26
27	\| Test \| Question \| If Yes \|
28	\|------\|----------\|--------\|
29	\| Rule test \| "Will an agent still produce incorrect code without this, even with the skill active?" \| → Rule (`.claude/rules/`) \|
30	\| Skill test \| "Is this a repeatable process/workflow, not a constraint?" \| → Skill — rare \|
31	\| On-demand ref \| "Is this project-specific architecture/context, not a behavioral rule?" \| → Reference file pointed from CLAUDE.md \|
32	\| Personal pref \| "Is this specific to this user, not team-shared?" \| → `CLAUDE.local.md` (gitignored) \|
33	\| Default \| None clearly match? \| → Rule (safest default) \|
34
35	~80% of proposals become rules — the pipeline detects behavioral corrections, and corrections are rules by definition.
36
37	### Step 2: Read existing content, check for overlap
38
39	Read all files in the target location. Scan for semantic overlap — does an existing rule/section already cover this?
40
41	### Step 3: Place — merge or add
42
43	- If overlap exists: merge into existing entry — expand/refine/strengthen, don't create near-duplicates
44	- If distinct: add under the most relevant section header
45
46	Writing quality — proposals describe specific incidents, but rules must work for the general case:
47
48	1. Generalize from the incident. The proposal says "Claude changed the pass dot when user meant N/A dot." The rule should address the class: "When multiple UI elements match an ambiguous reference, confirm which one before changing any." Don't encode the specific incident — encode the pattern.
49	2. Ground in reasoning, not commands. "ALWAYS confirm ambiguous references" is brittle — the agent doesn't know when it applies. "Because acting on the wrong target wastes a correction cycle, confirm which element when multiple candidates match" gives the agent judgment for edge cases.
50	3. Trim while merging. When adding to an existing rule file, read what's already there. If existing entries are redundant with the new content or with each other, consolidate. The goal after merging is a tighter file, not a longer one.
51	4. Watch for accumulation. If 3+ proposals have landed in the same file or section, that's a restructuring signal — the section may need splitting, or the underlying skill needs fixing instead of piling on more rules.
52	5. Think from the agent's perspective. Before finalizing, ask: "If I were an agent reading this rule for the first time with no context about the incident, would I understand when and why to apply it?" If the answer requires knowledge of the original proposal, rewrite.
53	6. Re-read with fresh eyes. After merging, re-read the entire section (not just your addition). Does the new content flow with the existing entries, or does it feel bolted on? Revise for coherence.
54
55	### Step 4: Verify — smoke test
56
57	Use the proposal's `rationale` to construct a minimal replay prompt that would trigger the same mistake. Spawn a subagent with the new rule, give it the prompt, check if it avoids the failure. If it fails, revise once. If still fails, flag to user. Keep this fast — one prompt, one check.
58
59	### Step 5: Resolve
60
61	```bash
62	python3 .claude/hooks/self-improve/self_improve_db.

People who liked this also viewed

6 picks

Type

self-evolve

109stars17forks

View on GitHub

How to install self-evolve?

avibebuilder/claude-prime/self-evolve

$npx -y skills add avibebuilder/claude-prime --skill self-evolve

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	ultrathink.
2
3	## Wire Mode: Apply Self-Improvement Proposals
4
5	When scope is `(none)`, or when pending proposals exist and user says "ok":
6
7	Fetching proposals:
8	```bash
9	python3 .claude/hooks/self-improve/self_improve_db.py resolve list
10	```
11
12	### Step 0: Consolidate before showing
13
14	User attention is finite — showing 12 proposals when 4 are duplicates, 3 already exist in rules, and 2 are noise wastes their focus on what matters. Before presenting anything, read the existing config (`.claude/rules/`, CLAUDE.md, CLAUDE.local.md, active skills) to understand what's already there. Then filter: proposals already covered by existing rules, duplicates of each other, and low-value noise that wouldn't improve agent behavior. Merge proposals addressing the same pattern into one entry with the clearest rationale.
15
16	Tell the user what you filtered: "Showing X of Y proposals (Z filtered)."
17
18	After user finishes reviewing visible proposals, batch-reject the filtered ones:
19	```bash
20	python3 .claude/hooks/self-improve/self_improve_db.py resolve <id1>,<id2>,... rejected
21	```
22
23	For each shown proposal, ask the user to approve or reject.
24
25	### Step 1: Classify — where does it belong?
26
27	\| Test \| Question \| If Yes \|
28	\|------\|----------\|--------\|
29	\| Rule test \| "Will an agent still produce incorrect code without this, even with the skill active?" \| → Rule (`.claude/rules/`) \|
30	\| Skill test \| "Is this a repeatable process/workflow, not a constraint?" \| → Skill — rare \|
31	\| On-demand ref \| "Is this project-specific architecture/context, not a behavioral rule?" \| → Reference file pointed from CLAUDE.md \|
32	\| Personal pref \| "Is this specific to this user, not team-shared?" \| → `CLAUDE.local.md` (gitignored) \|
33	\| Default \| None clearly match? \| → Rule (safest default) \|
34
35	~80% of proposals become rules — the pipeline detects behavioral corrections, and corrections are rules by definition.
36
37	### Step 2: Read existing content, check for overlap
38
39	Read all files in the target location. Scan for semantic overlap — does an existing rule/section already cover this?
40
41	### Step 3: Place — merge or add
42
43	- If overlap exists: merge into existing entry — expand/refine/strengthen, don't create near-duplicates
44	- If distinct: add under the most relevant section header
45
46	Writing quality — proposals describe specific incidents, but rules must work for the general case:
47
48	1. Generalize from the incident. The proposal says "Claude changed the pass dot when user meant N/A dot." The rule should address the class: "When multiple UI elements match an ambiguous reference, confirm which one before changing any." Don't encode the specific incident — encode the pattern.
49	2. Ground in reasoning, not commands. "ALWAYS confirm ambiguous references" is brittle — the agent doesn't know when it applies. "Because acting on the wrong target wastes a correction cycle, confirm which element when multiple candidates match" gives the agent judgment for edge cases.
50	3. Trim while merging. When adding to an existing rule file, read what's already there. If existing entries are redundant with the new content or with each other, consolidate. The goal after merging is a tighter file, not a longer one.
51	4. Watch for accumulation. If 3+ proposals have landed in the same file or section, that's a restructuring signal — the section may need splitting, or the underlying skill needs fixing instead of piling on more rules.
52	5. Think from the agent's perspective. Before finalizing, ask: "If I were an agent reading this rule for the first time with no context about the incident, would I understand when and why to apply it?" If the answer requires knowledge of the original proposal, rewrite.
53	6. Re-read with fresh eyes. After merging, re-read the entire section (not just your addition). Does the new content flow with the existing entries, or does it feel bolted on? Revise for coherence.
54
55	### Step 4: Verify — smoke test
56
57	Use the proposal's `rationale` to construct a minimal replay prompt that would trigger the same mistake. Spawn a subagent with the new rule, give it the prompt, check if it avoids the failure. If it fails, revise once. If still fails, flag to user. Keep this fast — one prompt, one check.
58
59	### Step 5: Resolve
60
61	```bash
62	python3 .claude/hooks/self-improve/self_improve_db.

People who liked this also viewed

6 picks

Type