What does this skill do, and when should you use it?
This skill is for systems that optimize the harness, scaffold, workflow, or context mechanism itself. It covers failure-driven self-edits, meta-harness search, evolutionary scaffold search, context-mechanism evolution, and acceptance gates for self-modifying systems. Its central rule is to keep evaluation, permissions, instrumentation, and budgets outside the editable loop while testing candidates on held-in and held-out data. It is a fit for teams with reliable automated feedback and a need for iterative agent-system improvement, not for one-shot prompt tuning without dependable execution signals.
It guides teams to cluster failed traces by verifier cause, agent responsibility, and reusable mechanism; declare editable surfaces and require each proposal to record its target, expected effect, and regression risks; evaluate candidates repeatedly on held-in and held-out splits; store candidate source, scores, raw execution traces, diffs, lineage, and decisions in a filesystem archive; preserve search diversity through archive-based selection, offspring-count discounting, and near-duplicate rejection; and enforce permissions, budgets, and sandbox boundaries in the runtime outside the loop.
- A harness engineer wants to generate bounded self-edits from recurring failure traces and validate regressions before merging.
- A research team is searching over workflow graphs, harness programs, or optimizer code with a meta-agent proposer.
- A context engineer wants an itemized playbook or context-producing skill to evolve incrementally from execution feedback.
- An evaluation engineer needs two-split acceptance gates, repeated trials, and protections against evaluator gaming.
- An agent platform team is diagnosing reward hacking, diversity collapse, context collapse, or silent stagnation in an improvement loop.
How do you install this skill?
- This is a low-confidence static assessment; examples, code, and repository CI were not executed.
- The cited numbers and research conclusions are marked as volatile and should be revalidated before adoption.
- A host runtime must still implement isolation, immutable evaluation, rollback, and human approval; the skill text alone cannot guarantee those controls.
- Chinese interaction and mainland-China network reachability are not specified; accessibility should be checked wherever external papers, sites, or remote infrastructure are required.
- Shell / CLI
- Local filesystem
Copy the complete skills/self-improvement-loops directory into a compatible skills directory, for example: mkdir -p .codex/skills && cp -R skills/self-improvement-loops .codex/skills/. The README also documents .claude/skills/, .cursor/skills/, and .agents/skills/ as installation locations. Preserve the directory layout; do not flatten the skill into a single markdown file. The source does not document a standalone executable installer or turnkey runtime for this skill.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/self-improvement-loops" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- Design a self-improvement loop that mines failure traces, proposes bounded harness edits, applies held-in/held-out acceptance, and archives raw traces.
On a host that loads Agent Skills, use a task such as: “Design a self-improvement loop that mines failure traces, proposes bounded harness edits, applies held-in/held-out acceptance, and archives raw traces.” Before enabling self-modification, verify that a fast deterministic evaluator, an unseen held-out split, runtime sandboxing, explicit editable surfaces, and full candidate lineage are available.
What are this skill's strengths and limitations?
- Provides a six-rung optimization ladder from instruction prompts to optimizer code, helping teams fix failures at the lowest suitable level.
- Clearly separates mutable optimization surfaces from evaluation, instrumentation, permissions, and budget enforcement.
- Treats candidate source and raw traces as first-class evidence instead of relying only on scores or model-written summaries.
- Offers concrete patterns for failure mining, two-split acceptance, diversity preservation, and incremental context merging.
- Requires a fast, deterministic, automatable evaluator; slow, ambiguous, or judge-only domains are poor fits.
- The skill provides design guidance and Python pseudocode examples, not a complete self-modifying runtime or deployable implementation.
- Adoption requires filesystem archives, runtime sandboxing, permission boundaries, and preferably an independent evaluator.
- The source provides no standalone test suite or cross-platform benchmark results for this individual skill.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Self-Improvement Loops this page | 58 · Recommended | ★ 18k | 16d ago | MIT |
| Context Engineering for Production Agents | 44 · Not recommended | ★ 18k | 16d ago | MIT |
| Harness Creator: Harness Engineering for AI Coding Agents | 56 · Use with care | ★ 20k | 27d ago | MIT |
| Autonomous Agent Harness | 49 · Use with care | ★ 18k | 16d ago | MIT |
| Agents Best Practices | 61 · Recommended | ★ 2.4k | 15d ago | MIT |
Compared with harness-engineering, this skill focuses on optimizing the control surfaces themselves; harness-engineering governs a single autonomous loop's locked surfaces, logs, rollback, and approval boundaries. evaluation and advanced-evaluation own evaluator and judge design, while context-optimization focuses on one-shot context efficiency rather than evolving the context mechanism over time.
How did FollowSkills review this skill?
The document specifies runtime-enforced budgets and permissions, external evaluators, sandboxing, human approval points, candidate archives, lineage, and failed-candidate retention, reducing overreach and irrecoverable self-modification risk. It does not concretely define sensitive-data handling, user-confirmation flows, a general rollback implementation, or dependency-security controls, so 9 points are deducted.
The guidance is internally coherent and covers capability validation, stagnation detection, two-split acceptance, reward-hacking failures, and intelligible trace feedback, with readable pseudocode and archive examples. However, this is a static review; the selected skill has no accompanying executable tests or scripts reproducing its key paths, and several controls depend on external implementation, so 12 points are deducted.
Activation scenarios, non-fit boundaries, optimization levels, and routing to adjacent skills are clearly stated for several self-improvement use cases. Inputs and output contracts, empirical semantic-trigger coverage, Chinese-language support, and mainland-China environment fit are not established, so 3 points are deducted.
The skill has layered sections, a readiness checklist, examples, integration guidance, an internal evidence reference, version and update metadata, and repository-level MIT licensing. Maintenance ownership, changelog practice, dependency/install guidance, and a concrete update path are incomplete; authorship is attributed only to a contributor group, so 4 points are deducted.
The optimization ladder, failure-driven loop, acceptance gate, archive layout, and routing example are directly useful for design work and address common failure modes. The selected skill remains a conceptual and pseudocode guide without a runnable implementation or verified representative outputs, leaving substantial engineering work, so 1 point is deducted.
Key claims carry claim IDs, and the internal reference records dates plus papers or reports and experimental details, while also disclosing revalidation limits. Evidence is still primarily documentary and relayed from external sources; no independent reproduction, skill-specific test coverage, or broad corroboration is present in the supplied files, so the static-review ceiling of 5 applies.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →