{
  "schemaVersion": "1.0",
  "item": {
    "slug": "iterative-code-evolution",
    "name": "Iterative Code Evolution",
    "source": "tencent",
    "type": "skill",
    "category": "AI 智能",
    "sourceUrl": "https://clawhub.ai/aaronjmars/iterative-code-evolution",
    "canonicalUrl": "https://clawhub.ai/aaronjmars/iterative-code-evolution",
    "targetPlatform": "OpenClaw"
  },
  "install": {
    "downloadMode": "redirect",
    "downloadUrl": "/downloads/iterative-code-evolution",
    "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=iterative-code-evolution",
    "sourcePlatform": "tencent",
    "targetPlatform": "OpenClaw",
    "installMethod": "Manual import",
    "extraction": "Extract archive",
    "prerequisites": [
      "OpenClaw"
    ],
    "packageFormat": "ZIP package",
    "includedAssets": [
      "README.md",
      "SKILL.md"
    ],
    "primaryDoc": "SKILL.md",
    "quickSetup": [
      "Download the package from Yavira.",
      "Extract the archive and review SKILL.md first.",
      "Import or place the package into your OpenClaw setup."
    ],
    "agentAssist": {
      "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.",
      "steps": [
        "Download the package from Yavira.",
        "Extract it into a folder your agent can access.",
        "Paste one of the prompts below and point your agent at the extracted folder."
      ],
      "prompts": [
        {
          "label": "New install",
          "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete."
        },
        {
          "label": "Upgrade existing",
          "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run."
        }
      ]
    },
    "sourceHealth": {
      "source": "tencent",
      "status": "healthy",
      "reason": "direct_download_ok",
      "recommendedAction": "download",
      "checkedAt": "2026-04-30T16:55:25.780Z",
      "expiresAt": "2026-05-07T16:55:25.780Z",
      "httpStatus": 200,
      "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=network",
      "contentType": "application/zip",
      "probeMethod": "head",
      "details": {
        "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=network",
        "contentDisposition": "attachment; filename=\"network-1.0.0.zip\"",
        "redirectLocation": null,
        "bodySnippet": null
      },
      "scope": "source",
      "summary": "Source download looks usable.",
      "detail": "Yavira can redirect you to the upstream package for this source.",
      "primaryActionLabel": "Download for OpenClaw",
      "primaryActionHref": "/downloads/iterative-code-evolution"
    },
    "validation": {
      "installChecklist": [
        "Use the Yavira download entry.",
        "Review SKILL.md after the package is downloaded.",
        "Confirm the extracted package contains the expected setup assets."
      ],
      "postInstallChecks": [
        "Confirm the extracted package includes the expected docs or setup files.",
        "Validate the skill or prompts are available in your target agent workspace.",
        "Capture any manual follow-up steps the agent could not complete."
      ]
    },
    "downloadPageUrl": "https://openagent3.xyz/downloads/iterative-code-evolution",
    "agentPageUrl": "https://openagent3.xyz/skills/iterative-code-evolution/agent",
    "manifestUrl": "https://openagent3.xyz/skills/iterative-code-evolution/agent.json",
    "briefUrl": "https://openagent3.xyz/skills/iterative-code-evolution/agent.md"
  },
  "agentAssist": {
    "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.",
    "steps": [
      "Download the package from Yavira.",
      "Extract it into a folder your agent can access.",
      "Paste one of the prompts below and point your agent at the extracted folder."
    ],
    "prompts": [
      {
        "label": "New install",
        "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete."
      },
      {
        "label": "Upgrade existing",
        "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run."
      }
    ]
  },
  "documentation": {
    "source": "clawhub",
    "primaryDoc": "SKILL.md",
    "sections": [
      {
        "title": "Iterative Code Evolution",
        "body": "A structured methodology for improving code through disciplined reflect → mutate → verify → score cycles, adapted from the ALMA research framework for meta-learning code designs."
      },
      {
        "title": "When to Use This Skill",
        "body": "Iterating on code that isn't working well enough (performance, correctness, design)\nOptimizing an implementation across multiple rounds of changes\nDebugging persistent or recurring issues where simple fixes keep failing\nEvolving a system design through structured experimentation\nAny task where you've already tried 2+ approaches and need discipline about what to try next\nBuilding or improving prompts, pipelines, agents, or any \"program\" that benefits from iterative refinement"
      },
      {
        "title": "When NOT to Use This Skill",
        "body": "Simple one-shot code generation (just write it)\nMechanical tasks with clear solutions (refactoring, formatting, migrations)\nWhen the user has already specified exactly what to change"
      },
      {
        "title": "The Evolution Loop",
        "body": "Every improvement cycle follows this sequence:\n\n┌─────────────────────────────────────────────────────┐\n│  1. ANALYZE  — structured diagnosis of current code │\n│  2. PLAN     — prioritized, concrete changes        │\n│  3. MUTATE   — implement the changes                │\n│  4. VERIFY   — run it, check for errors             │\n│  5. SCORE    — measure improvement vs. baseline     │\n│  6. ARCHIVE  — log what was tried and what happened │\n│                                                     │\n│  Loop back to 1 with new knowledge                  │\n└─────────────────────────────────────────────────────┘"
      },
      {
        "title": "The Evolution Log",
        "body": "Track all iterations in .evolution/log.json at the project root. This is the memory that makes each cycle smarter than the last.\n\n{\n  \"baseline\": {\n    \"description\": \"Initial implementation before evolution began\",\n    \"score\": 0.0,\n    \"timestamp\": \"2025-01-15T10:00:00Z\"\n  },\n  \"variants\": {\n    \"v001\": {\n      \"parent\": \"baseline\",\n      \"description\": \"Added input validation and error handling\",\n      \"changes_made\": [\n        {\n          \"what\": \"Added type checks on all public methods\",\n          \"why\": \"Runtime crashes from malformed input in 3/10 test cases\",\n          \"priority\": \"High\"\n        }\n      ],\n      \"score\": 0.6,\n      \"delta\": \"+0.6 vs parent\",\n      \"timestamp\": \"2025-01-15T10:30:00Z\",\n      \"learned\": \"Input validation was the primary failure mode — most other logic was sound\"\n    },\n    \"v002\": {\n      \"parent\": \"v001\",\n      \"description\": \"Refactored parsing logic to handle edge cases\",\n      \"changes_made\": [\n        {\n          \"what\": \"Rewrote parse_input() to use state machine instead of regex\",\n          \"why\": \"Regex approach failed on nested structures (seen in test cases 7,8)\",\n          \"priority\": \"High\"\n        }\n      ],\n      \"score\": 0.85,\n      \"delta\": \"+0.25 vs parent\",\n      \"timestamp\": \"2025-01-15T11:00:00Z\",\n      \"learned\": \"State machine approach generalizes better than regex for this grammar\"\n    }\n  },\n  \"principles_learned\": [\n    \"Input validation fixes give the biggest early gains\",\n    \"Regex-based parsing breaks on recursive structures — prefer state machines\",\n    \"Small targeted changes score better than large rewrites\"\n  ]\n}"
      },
      {
        "title": "Phase 1: ANALYZE — Structured Diagnosis",
        "body": "Before changing anything, perform a structured analysis of the current code and its outputs. This is the most important phase — it prevents wasted mutations.\n\nStep 1 — Learn from past edits (skip on first iteration)\n\nReview the evolution log. For each previous change:\n\nDid the score improve or degrade?\nWhat pattern made it succeed or fail?\nExtract 2-3 principles to adopt and 2-3 pitfalls to avoid\n\nStep 2 — Component-level assessment\n\nFor each meaningful component (function, class, module, pipeline stage), label it:\n\nLabelMeaningWorkingProduces correct output, no issues observedFragileWorks on happy path but fails on edge cases or specific inputsBrokenProduces wrong output or errorsRedundantDuplicates logic found elsewhere, adds complexity without valueMissingA needed component that doesn't exist yet\n\nFor each label, write a one-line explanation of why — linked to specific test outputs or observed behavior.\n\nStep 3 — Quality and coherence check\n\nLook for cross-cutting issues:\n\nData flow: Do components pass structured data to each other, or rely on implicit state?\nError handling: Are errors caught and handled, or silently swallowed?\nDuplication: Is the same logic repeated in multiple places?\nHardcoding: Are there magic numbers, hardcoded paths, or environment-specific assumptions?\nGeneralization: Which parts would work on new inputs vs. which are overfitted to test cases?\n\nStep 4 — Produce prioritized suggestions\n\nBased on Steps 1-3, produce concrete changes. Each suggestion must have:\n\n- PRIORITY: High | Medium | Low\n- WHAT: Precise description of the change (code-level, not vague)\n- WHY: Link to a specific observation from Steps 1-3\n- RISK: What could go wrong if this change is made incorrectly\n\nRule: Every suggestion must link to an observation. No \"this might help\" suggestions — only changes grounded in something you actually saw in the code or outputs.\n\nRule: Limit to 3 suggestions per cycle. More than 3 changes at once makes it impossible to attribute improvement or regression to specific changes."
      },
      {
        "title": "Phase 2: PLAN — Select What to Change",
        "body": "Pick 1-3 suggestions from the analysis. Selection principles:\n\nHigh priority first — fix broken things before optimizing working things\nOne theme per cycle — don't mix unrelated changes (e.g., don't fix parsing AND refactor error handling in the same mutation)\nPrefer targeted over sweeping — a surgical change to one function beats a rewrite of three modules\nIf stuck, explore — if the last 2+ cycles showed diminishing returns on the same component, pick a different component to modify (this is the ALMA \"visit penalty\" principle — don't keep grinding on the same thing)"
      },
      {
        "title": "Phase 3: MUTATE — Implement Changes",
        "body": "Write the new code. Key discipline:\n\nChange only what the plan says. Resist the urge to \"fix one more thing\" while you're in there.\nPreserve interfaces. Don't change function signatures or return types unless the plan explicitly calls for it.\nComment the rationale. Add a brief comment near each change referencing the evolution cycle (e.g., # evo-v003: switched to state machine per edge case failures)"
      },
      {
        "title": "Phase 4: VERIFY — Run and Check",
        "body": "Execute the modified code against the same inputs/tests used for scoring.\n\nIf it crashes (up to 3 retries):\n\nUse the reflection-fix protocol:\n\nRead the full error traceback\nIdentify the root cause (not the symptom)\nFix only the root cause — do not make unrelated improvements\nRe-run\n\nAfter 3 failed retries, revert to parent variant and log the failure:\n\n{\n  \"attempted\": \"Description of what was tried\",\n  \"failure_mode\": \"The error that couldn't be resolved\",\n  \"learned\": \"Why this approach doesn't work\"\n}\n\nThis failure data is valuable — it prevents re-attempting the same broken approach.\n\nIf it runs but produces wrong output:\n\nDon't immediately retry. Go back to Phase 1 (ANALYZE) with the new outputs. The wrong output is diagnostic data."
      },
      {
        "title": "Phase 5: SCORE — Measure Improvement",
        "body": "Compare the new variant's performance against its parent (not just the baseline). Scoring depends on context:\n\nContextScore MethodTests existPass rate: tests_passed / total_testsPerformance optimizationMetric delta (latency, throughput, memory)Code qualityWeighted checklist (correctness, edge cases, readability)User feedbackBinary: better/worse/same per the user's judgmentLLM/prompt output qualitySample outputs graded against criteria\n\nAlways compute delta vs. parent. This is how you learn which changes help vs. hurt."
      },
      {
        "title": "Phase 6: ARCHIVE — Log and Learn",
        "body": "Update .evolution/log.json:\n\nRecord the new variant with parent, description, changes, score, delta\nWrite a learned field: one sentence about what this cycle taught you\nIf the score improved, add the underlying principle to principles_learned\nIf the score degraded, add the failure mode to principles_learned as a pitfall"
      },
      {
        "title": "When to Branch vs. Modify",
        "body": "Modify in place (same file, new version): When the change is clearly incremental (fixing a bug, adding a check, tuning a parameter)\nBranch (copy to a new file): When trying a fundamentally different approach (different algorithm, different architecture, different strategy)\n\nKeep branches in .evolution/variants/ with descriptive names. The evolution log tracks which is active."
      },
      {
        "title": "Selection: Which Variant to Iterate On",
        "body": "If you have multiple variants, pick the next one to improve using:\n\nscore(variant) = normalized_reward - 0.5 * log(1 + visit_count)\n\nWhere:\n\nnormalized_reward = variant score relative to baseline (0-1 range)\nvisit_count = how many times this variant has been selected for iteration\n\nThis balances exploitation (iterating on the best variant) with exploration (trying variants that haven't been touched recently). It prevents getting stuck in local optima."
      },
      {
        "title": "Quick Reference: Analysis Template",
        "body": "When performing Phase 1, structure your thinking as:\n\n## Evolution Cycle [N] — Analysis\n\n### Lessons from Previous Cycles\n- Cycle [N-1] changed [X], score went [up/down] by [amount]\n- Principle: [what we learned]\n- Pitfall: [what to avoid]\n\n### Component Assessment\n| Component | Status | Evidence |\n|-----------|--------|----------|\n| function_a() | Working | All test cases pass |\n| function_b() | Fragile | Fails on empty input (test #4) |\n| class_C | Broken | Returns None instead of dict |\n\n### Cross-Cutting Issues\n- [Issue 1 with specific evidence]\n- [Issue 2 with specific evidence]\n\n### Planned Changes (max 3)\n1. **[High]** WHAT: ... | WHY: ... | RISK: ...\n2. **[Medium]** WHAT: ... | WHY: ... | RISK: ..."
      },
      {
        "title": "Example: Full Evolution Cycle",
        "body": "Context: User asks to improve a web scraper that's failing on 40% of target pages.\n\nCycle 1 — Analysis:\n\nComponent assessment: parse_html() is Broken (crashes on pages with no <article> tag), fetch_page() is Working, extract_links() is Fragile (misses relative URLs)\nCross-cutting: No error handling — one bad page kills the entire batch\nPast edits: None (first cycle)\nPlan: [High] Add fallback selectors in parse_html() for pages without <article>\n\nCycle 1 — Mutate: Add cascading selector logic: try <article>, fall back to <main>, fall back to <body>.\n\nCycle 1 — Verify: Runs without crashes.\n\nCycle 1 — Score: Pass rate 40% → 72%. Delta: +32%.\n\nCycle 1 — Archive: Learned: \"Most failures were selector misses, not logic errors. Fallback chains are high-value.\"\n\nCycle 2 — Analysis:\n\nLessons: Fallback selectors gave +32%. Principle: handle structural variation before fixing logic.\nComponent assessment: parse_html() now Working. extract_links() still Fragile — relative URLs not resolved.\nPlan: [High] Resolve relative URLs using urljoin in extract_links()\n\nCycle 2 — Mutate: Add base URL resolution.\n\nCycle 2 — Score: 72% → 88%. Delta: +16%.\n\nCycle 2 — Archive: Learned: \"URL resolution was second-biggest failure mode. Always normalize URLs at extraction time.\""
      },
      {
        "title": "Key Principles",
        "body": "Every change must link to an observation — no speculative fixes\nMax 3 changes per cycle — attribute improvements accurately\nLog everything — failed attempts are as valuable as successes\nScore against parent, not just baseline — track marginal improvement\nExplore when stuck — if 2+ cycles on the same component show diminishing returns, move to a different component\nRevert on 3 failed retries — don't spiral; log the failure and try a different approach\nPrinciples compound — the evolution log's principles_learned list is the most valuable artifact; it encodes what works for this specific codebase"
      }
    ],
    "body": "Iterative Code Evolution\n\nA structured methodology for improving code through disciplined reflect → mutate → verify → score cycles, adapted from the ALMA research framework for meta-learning code designs.\n\nWhen to Use This Skill\nIterating on code that isn't working well enough (performance, correctness, design)\nOptimizing an implementation across multiple rounds of changes\nDebugging persistent or recurring issues where simple fixes keep failing\nEvolving a system design through structured experimentation\nAny task where you've already tried 2+ approaches and need discipline about what to try next\nBuilding or improving prompts, pipelines, agents, or any \"program\" that benefits from iterative refinement\nWhen NOT to Use This Skill\nSimple one-shot code generation (just write it)\nMechanical tasks with clear solutions (refactoring, formatting, migrations)\nWhen the user has already specified exactly what to change\nCore Concepts\nThe Evolution Loop\n\nEvery improvement cycle follows this sequence:\n\n┌─────────────────────────────────────────────────────┐\n│  1. ANALYZE  — structured diagnosis of current code │\n│  2. PLAN     — prioritized, concrete changes        │\n│  3. MUTATE   — implement the changes                │\n│  4. VERIFY   — run it, check for errors             │\n│  5. SCORE    — measure improvement vs. baseline     │\n│  6. ARCHIVE  — log what was tried and what happened │\n│                                                     │\n│  Loop back to 1 with new knowledge                  │\n└─────────────────────────────────────────────────────┘\n\nThe Evolution Log\n\nTrack all iterations in .evolution/log.json at the project root. This is the memory that makes each cycle smarter than the last.\n\n{\n  \"baseline\": {\n    \"description\": \"Initial implementation before evolution began\",\n    \"score\": 0.0,\n    \"timestamp\": \"2025-01-15T10:00:00Z\"\n  },\n  \"variants\": {\n    \"v001\": {\n      \"parent\": \"baseline\",\n      \"description\": \"Added input validation and error handling\",\n      \"changes_made\": [\n        {\n          \"what\": \"Added type checks on all public methods\",\n          \"why\": \"Runtime crashes from malformed input in 3/10 test cases\",\n          \"priority\": \"High\"\n        }\n      ],\n      \"score\": 0.6,\n      \"delta\": \"+0.6 vs parent\",\n      \"timestamp\": \"2025-01-15T10:30:00Z\",\n      \"learned\": \"Input validation was the primary failure mode — most other logic was sound\"\n    },\n    \"v002\": {\n      \"parent\": \"v001\",\n      \"description\": \"Refactored parsing logic to handle edge cases\",\n      \"changes_made\": [\n        {\n          \"what\": \"Rewrote parse_input() to use state machine instead of regex\",\n          \"why\": \"Regex approach failed on nested structures (seen in test cases 7,8)\",\n          \"priority\": \"High\"\n        }\n      ],\n      \"score\": 0.85,\n      \"delta\": \"+0.25 vs parent\",\n      \"timestamp\": \"2025-01-15T11:00:00Z\",\n      \"learned\": \"State machine approach generalizes better than regex for this grammar\"\n    }\n  },\n  \"principles_learned\": [\n    \"Input validation fixes give the biggest early gains\",\n    \"Regex-based parsing breaks on recursive structures — prefer state machines\",\n    \"Small targeted changes score better than large rewrites\"\n  ]\n}\n\nThe Process in Detail\nPhase 1: ANALYZE — Structured Diagnosis\n\nBefore changing anything, perform a structured analysis of the current code and its outputs. This is the most important phase — it prevents wasted mutations.\n\nStep 1 — Learn from past edits (skip on first iteration)\n\nReview the evolution log. For each previous change:\n\nDid the score improve or degrade?\nWhat pattern made it succeed or fail?\nExtract 2-3 principles to adopt and 2-3 pitfalls to avoid\n\nStep 2 — Component-level assessment\n\nFor each meaningful component (function, class, module, pipeline stage), label it:\n\nLabel\tMeaning\nWorking\tProduces correct output, no issues observed\nFragile\tWorks on happy path but fails on edge cases or specific inputs\nBroken\tProduces wrong output or errors\nRedundant\tDuplicates logic found elsewhere, adds complexity without value\nMissing\tA needed component that doesn't exist yet\n\nFor each label, write a one-line explanation of why — linked to specific test outputs or observed behavior.\n\nStep 3 — Quality and coherence check\n\nLook for cross-cutting issues:\n\nData flow: Do components pass structured data to each other, or rely on implicit state?\nError handling: Are errors caught and handled, or silently swallowed?\nDuplication: Is the same logic repeated in multiple places?\nHardcoding: Are there magic numbers, hardcoded paths, or environment-specific assumptions?\nGeneralization: Which parts would work on new inputs vs. which are overfitted to test cases?\n\nStep 4 — Produce prioritized suggestions\n\nBased on Steps 1-3, produce concrete changes. Each suggestion must have:\n\n- PRIORITY: High | Medium | Low\n- WHAT: Precise description of the change (code-level, not vague)\n- WHY: Link to a specific observation from Steps 1-3\n- RISK: What could go wrong if this change is made incorrectly\n\n\nRule: Every suggestion must link to an observation. No \"this might help\" suggestions — only changes grounded in something you actually saw in the code or outputs.\n\nRule: Limit to 3 suggestions per cycle. More than 3 changes at once makes it impossible to attribute improvement or regression to specific changes.\n\nPhase 2: PLAN — Select What to Change\n\nPick 1-3 suggestions from the analysis. Selection principles:\n\nHigh priority first — fix broken things before optimizing working things\nOne theme per cycle — don't mix unrelated changes (e.g., don't fix parsing AND refactor error handling in the same mutation)\nPrefer targeted over sweeping — a surgical change to one function beats a rewrite of three modules\nIf stuck, explore — if the last 2+ cycles showed diminishing returns on the same component, pick a different component to modify (this is the ALMA \"visit penalty\" principle — don't keep grinding on the same thing)\nPhase 3: MUTATE — Implement Changes\n\nWrite the new code. Key discipline:\n\nChange only what the plan says. Resist the urge to \"fix one more thing\" while you're in there.\nPreserve interfaces. Don't change function signatures or return types unless the plan explicitly calls for it.\nComment the rationale. Add a brief comment near each change referencing the evolution cycle (e.g., # evo-v003: switched to state machine per edge case failures)\nPhase 4: VERIFY — Run and Check\n\nExecute the modified code against the same inputs/tests used for scoring.\n\nIf it crashes (up to 3 retries):\n\nUse the reflection-fix protocol:\n\nRead the full error traceback\nIdentify the root cause (not the symptom)\nFix only the root cause — do not make unrelated improvements\nRe-run\n\nAfter 3 failed retries, revert to parent variant and log the failure:\n\n{\n  \"attempted\": \"Description of what was tried\",\n  \"failure_mode\": \"The error that couldn't be resolved\",\n  \"learned\": \"Why this approach doesn't work\"\n}\n\n\nThis failure data is valuable — it prevents re-attempting the same broken approach.\n\nIf it runs but produces wrong output:\n\nDon't immediately retry. Go back to Phase 1 (ANALYZE) with the new outputs. The wrong output is diagnostic data.\n\nPhase 5: SCORE — Measure Improvement\n\nCompare the new variant's performance against its parent (not just the baseline). Scoring depends on context:\n\nContext\tScore Method\nTests exist\tPass rate: tests_passed / total_tests\nPerformance optimization\tMetric delta (latency, throughput, memory)\nCode quality\tWeighted checklist (correctness, edge cases, readability)\nUser feedback\tBinary: better/worse/same per the user's judgment\nLLM/prompt output quality\tSample outputs graded against criteria\n\nAlways compute delta vs. parent. This is how you learn which changes help vs. hurt.\n\nPhase 6: ARCHIVE — Log and Learn\n\nUpdate .evolution/log.json:\n\nRecord the new variant with parent, description, changes, score, delta\nWrite a learned field: one sentence about what this cycle taught you\nIf the score improved, add the underlying principle to principles_learned\nIf the score degraded, add the failure mode to principles_learned as a pitfall\nVariant Management\nWhen to Branch vs. Modify\nModify in place (same file, new version): When the change is clearly incremental (fixing a bug, adding a check, tuning a parameter)\nBranch (copy to a new file): When trying a fundamentally different approach (different algorithm, different architecture, different strategy)\n\nKeep branches in .evolution/variants/ with descriptive names. The evolution log tracks which is active.\n\nSelection: Which Variant to Iterate On\n\nIf you have multiple variants, pick the next one to improve using:\n\nscore(variant) = normalized_reward - 0.5 * log(1 + visit_count)\n\n\nWhere:\n\nnormalized_reward = variant score relative to baseline (0-1 range)\nvisit_count = how many times this variant has been selected for iteration\n\nThis balances exploitation (iterating on the best variant) with exploration (trying variants that haven't been touched recently). It prevents getting stuck in local optima.\n\nQuick Reference: Analysis Template\n\nWhen performing Phase 1, structure your thinking as:\n\n## Evolution Cycle [N] — Analysis\n\n### Lessons from Previous Cycles\n- Cycle [N-1] changed [X], score went [up/down] by [amount]\n- Principle: [what we learned]\n- Pitfall: [what to avoid]\n\n### Component Assessment\n| Component | Status | Evidence |\n|-----------|--------|----------|\n| function_a() | Working | All test cases pass |\n| function_b() | Fragile | Fails on empty input (test #4) |\n| class_C | Broken | Returns None instead of dict |\n\n### Cross-Cutting Issues\n- [Issue 1 with specific evidence]\n- [Issue 2 with specific evidence]\n\n### Planned Changes (max 3)\n1. **[High]** WHAT: ... | WHY: ... | RISK: ...\n2. **[Medium]** WHAT: ... | WHY: ... | RISK: ...\n\nExample: Full Evolution Cycle\n\nContext: User asks to improve a web scraper that's failing on 40% of target pages.\n\nCycle 1 — Analysis:\n\nComponent assessment: parse_html() is Broken (crashes on pages with no <article> tag), fetch_page() is Working, extract_links() is Fragile (misses relative URLs)\nCross-cutting: No error handling — one bad page kills the entire batch\nPast edits: None (first cycle)\nPlan: [High] Add fallback selectors in parse_html() for pages without <article>\n\nCycle 1 — Mutate: Add cascading selector logic: try <article>, fall back to <main>, fall back to <body>.\n\nCycle 1 — Verify: Runs without crashes.\n\nCycle 1 — Score: Pass rate 40% → 72%. Delta: +32%.\n\nCycle 1 — Archive: Learned: \"Most failures were selector misses, not logic errors. Fallback chains are high-value.\"\n\nCycle 2 — Analysis:\n\nLessons: Fallback selectors gave +32%. Principle: handle structural variation before fixing logic.\nComponent assessment: parse_html() now Working. extract_links() still Fragile — relative URLs not resolved.\nPlan: [High] Resolve relative URLs using urljoin in extract_links()\n\nCycle 2 — Mutate: Add base URL resolution.\n\nCycle 2 — Score: 72% → 88%. Delta: +16%.\n\nCycle 2 — Archive: Learned: \"URL resolution was second-biggest failure mode. Always normalize URLs at extraction time.\"\n\nKey Principles\nEvery change must link to an observation — no speculative fixes\nMax 3 changes per cycle — attribute improvements accurately\nLog everything — failed attempts are as valuable as successes\nScore against parent, not just baseline — track marginal improvement\nExplore when stuck — if 2+ cycles on the same component show diminishing returns, move to a different component\nRevert on 3 failed retries — don't spiral; log the failure and try a different approach\nPrinciples compound — the evolution log's principles_learned list is the most valuable artifact; it encodes what works for this specific codebase"
  },
  "trust": {
    "sourceLabel": "tencent",
    "provenanceUrl": "https://clawhub.ai/aaronjmars/iterative-code-evolution",
    "publisherUrl": "https://clawhub.ai/aaronjmars/iterative-code-evolution",
    "owner": "aaronjmars",
    "version": "1.0.0",
    "license": null,
    "verificationStatus": "Indexed source record"
  },
  "links": {
    "detailUrl": "https://openagent3.xyz/skills/iterative-code-evolution",
    "downloadUrl": "https://openagent3.xyz/downloads/iterative-code-evolution",
    "agentUrl": "https://openagent3.xyz/skills/iterative-code-evolution/agent",
    "manifestUrl": "https://openagent3.xyz/skills/iterative-code-evolution/agent.json",
    "briefUrl": "https://openagent3.xyz/skills/iterative-code-evolution/agent.md"
  }
}