Self Improving Agent
Wire session and tool-use hooks so your coding agent logs behavior and applies learned patterns (e.g. PRD structure) across future runs.
Overview
Self-improving-agent is a journey-wide agent skill that hooks tool use and sessions to log behavior and reuse learned patterns—usable whenever a solo builder needs to harden agent workflows before committing to the same
Install
npx skills add https://github.com/charon-fan/agent-playbook --skill self-improving-agentWhat is this skill?
- Bash hooks for PreToolUse, PostToolUse, and session end with structured stderr logging
- Pattern store (JSON) capturing recurring fixes such as 4-file PRD separation for complex specs
- Confidence-scored patterns sourced from user feedback for reuse
- Designed for Agent Playbook-style continuous improvement without replacing your main coding skills
- Example pattern documents 4-file PRD separation for non-trivial specs
- Example pattern confidence score 0.95 in bundled catalog
Adoption & trust: 30.1k installs on skills.sh; 58 GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your coding agent repeats the same structural and tooling mistakes because nothing persists lessons from past sessions or tool failures.
Who is it for?
Builders customizing agent playbooks with shell-accessible hooks who want incremental, human-curated self-improvement rather than one-off chat fixes.
Skip if: Users who only need a single task skill with no hook setup, or teams that require fully automated ML-based agent tuning without maintaining pattern JSON.
When should I use this skill?
When configuring Agent Playbook hooks or curating reusable patterns after user feedback on agent outputs.
What do I get? / Deliverables
Hooked sessions produce auditable tool traces and a growing pattern library you can apply on the next task—such as splitting complex PRDs into four purpose-specific files.
- Hook script integration
- Curated patterns catalog entries
- Session and tool-use audit logs on stderr
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Register PostToolUse logging to capture failed test-runner exits and feed them into your pattern file.
Apply the document-separation pattern so a 500-line mixed PRD becomes four focused markdown files before build.
Review session-end logs to see which tools dominated a long fix cycle and add a new pattern for the next sprint.
Encode task-plan versus prd conventions so the agent stops merging tracking tables into product narrative.
Use consistent hook output as context when asking the agent to summarize what changed across a review session.
How it compares
Agent-runtime hook and pattern ledger, not a replacement for brainstorming, plans, or domain-specific implementation skills.
Common Questions / FAQ
Who is self-improving-agent for?
It is for solo and indie developers operating agentic coding environments who can install PreToolUse/PostToolUse/session scripts and want durable playbooks built from real corrections.
When should I use self-improving-agent?
Use it during Build when wiring agent-tooling, during Operate when debugging recurring tool failures, and across Validate/Build when you want PRD and planning artifacts to improve after user feedback—not only on greenfield features.
Is self-improving-agent safe to install?
The skill runs bash hooks that observe tool names and inputs and may log outputs to stderr; treat that as sensitive in shared logs. Review the Security Audits panel on this Prism page before enabling hooks in production repos.
SKILL.md
READMESKILL.md - Self Improving Agent
#!/usr/bin/env bash set -euo pipefail tool_output="${1:-}" exit_code="${2:-0}" echo "[self-improving-agent] PostToolUse: exit=${exit_code}" >&2 if [[ -n "${tool_output}" ]]; then echo "[self-improving-agent] Output: ${tool_output}" >&2 fi #!/usr/bin/env bash set -euo pipefail tool_name="${1:-unknown}" tool_input="${2:-}" echo "[self-improving-agent] PreToolUse: ${tool_name}" >&2 if [[ -n "${tool_input}" ]]; then echo "[self-improving-agent] Input: ${tool_input}" >&2 fi #!/usr/bin/env bash set -euo pipefail echo "[self-improving-agent] Session ended" >&2 { "patterns": { "prd_document_separation": { "id": "pat-2025-01-11-001", "name": "Document Separation for Complex PRDs", "source": "user_feedback", "confidence": 0.95, "applications": 0, "created": "2025-01-11", "category": "prd_structure", "pattern": "For non-trivial PRDs, split into 4 files with clear purposes", "problem": "Single large PRD file (~500 lines) with mixed product/technical content is hard to follow", "solution": { "files": [ { "name": "{name}-notes.md", "purpose": "Thinking process, options analysis", "audience": "Self + future reviewers" }, { "name": "{name}-task-plan.md", "purpose": "Project tracking, phases, progress", "audience": "PM + development lead" }, { "name": "{name}-prd.md", "purpose": "Product requirements (what & why)", "audience": "PM + stakeholders + developers" }, { "name": "{name}-tech.md", "purpose": "Technical design (how)", "audience": "Developers + architects" } ] }, "quality_rules": [ "PRD focuses on problem, goals, scope, user flows", "Tech doc focuses on API, data flow, implementation", "Notes document architecture options with A/B/C analysis", "Task plan has checkboxes with timestamps", "PRD references tech doc, doesn't duplicate" ], "target_skills": ["prd-planner", "architecting-solutions"] }, "state_monitoring_over_callbacks": { "id": "pat-2025-01-11-002", "name": "Direct State Monitoring vs Callbacks", "source": "implementation_review", "confidence": 0.90, "applications": 0, "created": "2025-01-11", "category": "react_patterns", "pattern": "Prefer direct state monitoring over callback chains for side effects", "problem": "Callback chains passed through multiple layers are hard to trace and debug", "solution": { "anti_pattern": "useActionQueue({ onRefresh: () => { /* refresh logic */ } });", "pattern": "const pendingCount = requests.length;\nconst prevPendingCount = usePrevious(pendingCount);\nuseEffect(() => {\n if (pendingCount < prevPendingCount) {\n triggerDataRefresh({ reason: 'completed' });\n }\n}, [pendingCount, prevPendingCount]);" }, "when_to_use": [ "State changes need to trigger side effects", "Callback chain would be 3+ layers deep", "Multiple components need to react to same state change" ], "quality_rules": [ "Use usePrevious to detect state changes instead of callbacks when feasible", "Keep state monitoring close to where state is consumed", "Use callbacks only for cross-component boundaries" ], "target_skills": ["debugger", "refactoring-specialist"] }, "state_machine_over_booleans": { "id": "pat-2025-01-11-003", "name": "State Machine Over Boolean Flags", "source": "implementation_review", "confidence": 0.85, "applications": 0, "created": "2025-01-11", "category": "async_patterns", "pattern": "Use state machines for async operations with multiple phases", "problem": "Simple boolean flags can't represent 'waiti