Skill: jayv29/strict-self-improvement (version 1.0.2)

--- name: self-improvement description: "Captures learnings, errors, and corrections to enable continuous improvement. Use when: (1) A command or operation fails unexpectedly, (2) User corrects Claude ('No, that's wrong...', 'Actually...'), (3) User requests a capability that doesn't exist, (4) An external API or tool fails, (5) Claude realizes its knowledge is outdated or incorrect, (6) A better approach is discovered for a recurring task. Also review learnings before major tasks." --- # 🦾 Self-Improving Agent (Strict Promotion Protocol) > **"Stop letting your AI agent pollute its own core instructions based on subjective feelings."** This is an industrial-grade, closed-loop **Self-Improvement System** for OpenClaw. It replaces the default subjective "agent feelings" with a rigid, quantitative pipeline: **The Rule of 3**. Instead of bloating your `SOUL.md` or `AGENTS.md` with every random bug the agent encounters, this skill forces the agent to merely *log* errors as pending. Only when an error recurs 3 times (linked via `See Also`) is it eligible for promotion. Includes a built-in bash script (`promote-review.sh`) to aggregate pending promotions for human approval. ## 🌟 Why install this? 1. **Zero Context Bloat**: Keeps your `SOUL.md` and 200K window pristine. 2. **Rule of 3 (Quantitative Trigger)**: Issues must happen 3 times before they can be considered a "Rule". 3. **Strict Domain Governance**: Mutually exclusive rules for what goes into SOUL (behavior), AGENTS (workflow), and TOOLS (CLI gotchas). 4. **Human-in-the-Loop Review**: Batch processing of promotions via a weekly aggregator script. --- ## 🚀 Quick Setup (OpenClaw) This skill is designed natively for the OpenClaw architecture. **Via ClawdHub CLI (1-Click Install):** ```bash clawhub install self-improving-agent ``` ### Workspace Structure OpenClaw injects these files into every session: ``` ~/.openclaw/workspace/ ├── AGENTS.md # Multi-agent workflows, delegation patterns ├── SOUL.md # Behavioral guidelines, personality, principles ├── TOOLS.md # Tool capabilities, integration gotchas ├── MEMORY.md # Long-term memory (main session only) ├── memory/ # Memory System (v4.0) │ ├── daily_raw/ │ ├── summaries/ │ ├── projects/ │ └── core/ # This skill's log files │ ├── learning.md │ ├── error.md │ └── features.md ``` ### Create Learning Files ```bash mkdir -p ~/.openclaw/workspace/memory/core ``` Then create the log files (or copy from `assets/`): - `learning.md` — corrections, knowledge gaps, best practices - `error.md` — command failures, exceptions - `features.md` — user-requested capabilities ### Promotion Targets When learnings prove broadly applicable, promote them to workspace files: | Learning Type | Promote To | Example | |---------------|------------|---------| | Behavioral patterns | `SOUL.md` | "Be concise, avoid disclaimers" | | Workflow improvements | `AGENTS.md` | "Spawn sub-agents for long tasks" | | Tool gotchas | `TOOLS.md` | "Git push needs auth configured first" | ### Inter-Session Communication OpenClaw provides tools to share learnings across sessions: - **sessions_list** — View active/recent sessions - **sessions_history** — Read another session's transcript - **sessions_send** — Send a learning to another session - **sessions_spawn** — Spawn a sub-agent for background work ### Optional: Enable Hook For automatic reminders at session start: ```bash # Copy hook to OpenClaw hooks directory cp -r hooks/openclaw ~/.openclaw/hooks/self-improvement # Enable it openclaw hooks enable self-improvement ``` See `references/openclaw-integration.md` for complete details. --- ## Generic Setup (Other Agents) For Claude Code, Codex, Copilot, or other agents, create `memory/core/` in your project: ```bash mkdir -p memory/core ``` Copy templates from `assets/` or create files with headers. ## Logging Format ### Learning Entry Append to `memory/core/learning.md`: ```markdown ## [LRN-YYYYMMDD-XXX] category **Logged**: ISO-8601 timestamp **Priority**: low | medium | high | critical **Status**: pending **Area**: frontend | backend | infra | tests | docs | config ### Summary One-line description of what was learned ### Details Full context: what happened, what was wrong, what's correct ### Suggested Action Specific fix or improvement to make ### Metadata - Source: conversation | error | user_feedback - Related Files: path/to/file.ext - Tags: tag1, tag2 - See Also: LRN-20250110-001 (if related to existing entry) --- ``` ### Error Entry Append to `memory/core/error.md`: ```markdown ## [ERR-YYYYMMDD-XXX] skill_or_command_name **Logged**: ISO-8601 timestamp **Priority**: high **Status**: pending **Area**: frontend | backend | infra | tests | docs | config ### Summary Brief description of what failed ### Error ``` Actual error message or output ``` ### Context - Command/operation attempted - Input or parameters used - Environment details if relevant ### Suggested Fix If identifiable, what might resolve this ### Metadata - Reproducible: yes | no | unknown - Related Files: path/to/file.ext - See Also: ERR-20250110-001 (if recurring) --- ``` ### Feature Request Entry Append to `memory/core/features.md`: ```markdown ## [FEAT-YYYYMMDD-XXX] capability_name **Logged**: ISO-8601 timestamp **Priority**: medium **Status**: pending **Area**: frontend | backend | infra | tests | docs | config ### Requested Capability What the user wanted to do ### User Context Why they needed it, what problem they're solving ### Complexity Estimate simple | medium | complex ### Suggested Implementation How this could be built, what it might extend ### Metadata - Frequency: first_time | recurring - Related Features: existing_feature_name --- ``` ## ID Generation Format: `TYPE-YYYYMMDD-XXX` - TYPE: `LRN` (learning), `ERR` (error), `FEAT` (feature) - YYYYMMDD: Current date - XXX: Sequential number or random 3 chars (e.g., `001`, `A7B`) Examples: `LRN-20250115-001`, `ERR-20250115-A3F`, `FEAT-20250115-002` ## Resolving Entries When an issue is fixed, update the entry: 1. Change `**Status**: pending` → `**Status**: resolved` 2. Add resolution block after Metadata: ```markdown ### Resolution - **Resolved**: 2025-01-16T09:00:00Z - **Commit/PR**: abc123 or #42 - **Notes**: Brief description of what was done ``` Other status values: - `in_progress` - Actively being worked on - `wont_fix` - Decided not to address (add reason in Resolution notes) - `promoted` - Elevated to CLAUDE.md, AGENTS.md, or .github/copilot-instructions.md ## 严格晋升机制 (Strict Promotion Protocol) **CRITICAL RULE**: The main agent is explicitly FORBIDDEN from writing directly to `SOUL.md`, `AGENTS.md`, or `TOOLS.md` during normal tasks. All new knowledge must be recorded in `memory/core/*.md` first. ### When to Trigger Promotion (Rule of 3) We utilize a strict quantitative counter rather than subjective feelings. 1. **Log the Issue**: If an issue occurs, log it to `memory/core/` (status: `pending`). 2. **Search Historical Logs**: ALWAYS search `memory/core/` for similar past issues using `grep`. 3. **Trigger Threshold**: ONLY if the current issue links to **3 or more** existing entries via `**See Also**`, you MUST change the status of the current entry to `**Status**: ready_for_promotion`. 4. **Wait for Review**: Do not write to workspace files. Leave it as `ready_for_promotion` for the weekly human review pipeline. ### Strict Domain Separation (Target Governance) If the weekly review script approves a promotion, it must strictly follow these mutually exclusive rules: | Target | Absolute Membership Criteria | |--------|------------------------------| | `SOUL.md` | **Strictly behavioral**. Only modify if changing the agent's core persona, communication tone, or adding global un-overrideable safety bans (e.g., "NEVER use cat to modify files"). | | `AGENTS.md` | **Strictly workflow orchestration**. Only modify if detailing the mandatory sequence of operations (e.g., "always clear cache before building") or sub-agent delegation chains. | | `TOOLS.md` | **Strictly 3rd-party tool quirks**. Only modify if documenting a specific bug or required flag for an external CLI or API (e.g., "jq requires -r for raw output"). | | `skills/` Dir | **Strictly multi-step autonomous logic**. If an issue requires 3+ steps to reliably fix (such as a full diagnosis script), DO NOT put it in SOUL/AGENTS. Run the extract-skill.sh script and make it a dedicated Skill. | ### Promotion Examples **Learning** (Accumulated 3+ times): > Project uses pnpm workspaces. Attempted npm install but failed 3 times across sessions. **In AGENTS.md** (After human approved `ready_for_promotion`): ```markdown ## Build Protocol - MANDATORY: Use `pnpm install`, NOT npm, for workspace root syncing. ``` ## Recurring Pattern Detection If logging something similar to an existing entry: 1. **Search first**: `grep -r "keyword" memory/core/` 2. **Link entries**: Add `**See Also**: ERR-20250110-001` in Metadata 3. **Bump priority** if issue keeps recurring 4. **Consider systemic fix**: Recurring issues often indicate: - Missing documentation (→ promote to CLAUDE.md or .github/copilot-instructions.md) - Missing automation (→ add to AGENTS.md) - Architectural problem (→ create tech debt ticket) ## Periodic Review Review `memory/core/` at natural breakpoints: ### When to Review - Before starting a new major task - After completing a feature - When working in an area with past learnings - Weekly during active development ### Quick Status Check ```bash # Count pending items grep -h "Status\*\*: pending" memory/core/*.md | wc -l # List pending high-priority items grep -B5 "Priority\*\*: high" memory/core/*.md | grep "^## \[" # Find learnings for a specific area grep -l "Area\*\*: backend" memory/core/*.md ``` ### Review Actions - Resolve fixed items - Promote applicable learnings - Link related entries - Escalate recurring issues ## Detection Triggers Automatically log when you notice: **Corrections** (→ learning with `correction` category): - "No, that's not right..." - "Actually, it should be..." - "You're wrong about..." - "That's outdated..." **Feature Requests** (→ feature request): - "Can you also..." - "I wish you could..." - "Is there a way to..." - "Why can't you..." **Knowledge Gaps** (→ learning with `knowledge_gap` category): - User provides information you didn't know - Documentation you referenced is outdated - API behavior differs from your understanding **Errors** (→ error entry): - Command returns non-zero exit code - Exception or stack trace - Unexpected output or behavior - Timeout or connection failure ## Priority Guidelines | Priority | When to Use | |----------|-------------| | `critical` | Blocks core functionality, data loss risk, security issue | | `high` | Significant impact, affects common workflows, recurring issue | | `medium` | Moderate impact, workaround exists | | `low` | Minor inconvenience, edge case, nice-to-have | ## Area Tags Use to filter learnings by codebase region: | Area | Scope | |------|-------| | `frontend` | UI, components, client-side code | | `backend` | API, services, server-side code | | `infra` | CI/CD, deployment, Docker, cloud | | `tests` | Test files, testing utilities, coverage | | `docs` | Documentation, comments, READMEs | | `config` | Configuration files, environment, settings | ## Best Practices 1. **Log immediately** - context is freshest right after the issue 2. **Be specific** - future agents need to understand quickly 3. **Include reproduction steps** - especially for errors 4. **Link related files** - makes fixes easier 5. **Suggest concrete fixes** - not just "investigate" 6. **Use consistent categories** - enables filtering 7. **Promote aggressively** - if in doubt, add to CLAUDE.md or .github/copilot-instructions.md 8. **Review regularly** - stale learnings lose value ## Gitignore Options **Keep learnings local** (per-developer): ```gitignore memory/core/ ``` **Track learnings in repo** (team-wide): Don't add to .gitignore - learnings become shared knowledge. **Hybrid** (track templates, ignore entries): ```gitignore memory/core/*.md !memory/core/memory-system-design.md ``` ## Hook Integration Enable automatic reminders through agent hooks. This is **opt-in** - you must explicitly configure hooks. ### Quick Setup (Claude Code / Codex) Create `.claude/settings.json` in your project: ```json { "hooks": { "UserPromptSubmit": [{ "matcher": "", "hooks": [{ "type": "command", "command": "./skills/self-improvement/scripts/activator.sh" }] }] } } ``` This injects a learning evaluation reminder after each prompt (~50-100 tokens overhead). ### Full Setup (With Error Detection) ```json { "hooks": { "UserPromptSubmit": [{ "matcher": "", "hooks": [{ "type": "command", "command": "./skills/self-improvement/scripts/activator.sh" }] }], "PostToolUse": [{ "matcher": "Bash", "hooks": [{ "type": "command", "command": "./skills/self-improvement/scripts/error-detector.sh" }] }] } } ``` ### Available Hook Scripts | Script | Hook Type | Purpose | |--------|-----------|---------| | `scripts/activator.sh` | UserPromptSubmit | Reminds to evaluate learnings after tasks | | `scripts/error-detector.sh` | PostToolUse (Bash) | Triggers on command errors | See `references/hooks-setup.md` for detailed configuration and troubleshooting. ## Automatic Skill Extraction When a learning is valuable enough to become a reusable skill, extract it using the provided helper. ### Skill Extraction Criteria A learning qualifies for skill extraction when ANY of these apply: | Criterion | Description | |-----------|-------------| | **Recurring** | Has `See Also` links to 2+ similar issues | | **Verified** | Status is `resolved` with working fix | | **Non-obvious** | Required actual debugging/investigation to discover | | **Broadly applicable** | Not project-specific; useful across codebases | | **User-flagged** | User says "save this as a skill" or similar | ### Extraction Workflow 1. **Identify candidate**: Learning meets extraction criteria 2. **Run helper** (or create manually): ```bash ./skills/self-improvement/scripts/extract-skill.sh skill-name --dry-run ./skills/self-improvement/scripts/extract-skill.sh skill-name ``` 3. **Customize SKILL.md**: Fill in template with learning content 4. **Update learning**: Set status to `promoted_to_skill`, add `Skill-Path` 5. **Verify**: Read skill in fresh session to ensure it's self-contained ### Manual Extraction If you prefer manual creation: 1. Create `skills/<skill-name>/SKILL.md` 2. Use template from `assets/SKILL-TEMPLATE.md` 3. Follow [Agent Skills spec](https://agentskills.io/specification): - YAML frontmatter with `name` and `description` - Name must match folder name - No README.md inside skill folder ### Extraction Detection Triggers Watch for these signals that a learning should become a skill: **In conversation:** - "Save this as a skill" - "I keep running into this" - "This would be useful for other projects" - "Remember this pattern" **In learning entries:** - Multiple `See Also` links (recurring issue) - High priority + resolved status - Category: `best_practice` with broad applicability - User feedback praising the solution ### Skill Quality Gates Before extraction, verify: - [ ] Solution is tested and working - [ ] Description is clear without original context - [ ] Code examples are self-contained - [ ] No project-specific hardcoded values - [ ] Follows skill naming conventions (lowercase, hyphens) ## Multi-Agent Support This skill works across different AI coding agents with agent-specific activation. ### Claude Code **Activation**: Hooks (UserPromptSubmit, PostToolUse) **Setup**: `.claude/settings.json` with hook configuration **Detection**: Automatic via hook scripts ### Codex CLI **Activation**: Hooks (same pattern as Claude Code) **Setup**: `.codex/settings.json` with hook configuration **Detection**: Automatic via hook scripts ### GitHub Copilot **Activation**: Manual (no hook support) **Setup**: Add to `.github/copilot-instructions.md`: ```markdown ## Self-Improvement After solving non-obvious issues, consider logging to `memory/core/`: 1. Use format from self-improvement skill 2. Link related entries with See Also 3. Promote high-value learnings to skills Ask in chat: "Should I log this as a learning?" ``` **Detection**: Manual review at session end ### OpenClaw **Activation**: Workspace injection + inter-agent messaging **Setup**: See "OpenClaw Setup" section above **Detection**: Via session tools and workspace files ### Agent-Agnostic Guidance Regardless of agent, apply self-improvement when you: 1. **Discover something non-obvious** - solution wasn't immediate 2. **Correct yourself** - initial approach was wrong 3. **Learn project conventions** - discovered undocumented patterns 4. **Hit unexpected errors** - especially if diagnosis was difficult 5. **Find better approaches** - improved on your original solution ### Copilot Chat Integration For Copilot users, add this to your prompts when relevant: > After completing this task, evaluate if any learnings should be logged to `memory/core/` using the self-improvement skill format. Or use quick prompts: - "Log this to learnings" - "Create a skill from this solution" - "Check memory/core/ for related issues"


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