[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7BPES23WM3022FP7JQJ75CM":3,"skill-same:01M7BPES23WM3022FP7JQJ75CM":45},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M7BPES23WM3022FP7JQJ75CM","maven-build-lifecycle",null,"Use when reproducing and repairing Maven CI build failures, especially legacy multi-module builds and Maven Invoker integration tests.","linyouxue\u002Fskill-repair-benchmark","linyouxue","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F216151464?v=4","01M7BJEVCXKD74KH6FG9CBVSQB","林宥学","01M7BJEVE02NP217V93BKZFC0J",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fcontrolled-skill-repair-experiments\u002Fresult\u002Fwml-claude4.7\u002Frepair\u002Fcandidates\u002Fsingle-fix-build-google-auto-RI-001\u002Fskills\u002Fmaven-build-lifecycle\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: maven-build-lifecycle\ndescription: Use when reproducing and repairing Maven CI build failures, especially legacy multi-module builds and Maven Invoker integration tests.\n---\n\n# Maven Build Lifecycle — Legacy CI Repair Workflow\n\n## Resolving the failed repository path\n\nThe task describes the failed checkout using a template such as\n`\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002F\u003Crepo>\u002F\u003Cid>` (for example `\u003Crepo>=google` and\n`\u003Cid>=auto` yields `\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002Fgoogle\u002Fauto`). Before issuing any\nbuild command:\n\n1. Read the task description to extract the concrete `\u003Crepo>` and `\u003Cid>`.\n2. Resolve `REPO_DIR=\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002F\u003Crepo>\u002F\u003Cid>` from those values.\n3. Use `REPO_DIR` as the Maven working directory and as the parent directory\n   for `patch_{i}.diff`. The `google\u002Fauto` paths that appear later in this\n   Skill are illustrative examples of that resolution, not hardcoded invariants.\n\n## Maven Invoker failures: debug the nested project, not just the reactor\n\n`maven-invoker-plugin` can launch independent Maven builds from files such as\n`src\u002Fit\u002F*\u002Fpom.xml`. Those nested builds have their own dependency mediation and\ncan fail even when the parent module's normal unit tests pass.\n\nIf Maven reports output similar to:\n\n```text\nThe following builds failed:\n*  functional\u002Fpom.xml\n```\n\nthen:\n\n1. Locate the exact integration-test POM named by the Invoker.\n2. Read the corresponding Invoker `build.log` or the surrounding CI output.\n3. Identify the *first concrete compiler\u002Ftest error* inside that nested build.\n4. Inspect the nested POM's direct dependencies and versions.\n6. Repair the nested dependency\u002Fconfiguration drift instead of broad-editing\n   unrelated top-level modules.\n\nDo not assume versions declared in the parent module automatically govern an\nInvoker integration-test POM. An integration-test POM copied or synchronized\nseparately can become stale.\n\n## Missing library classes usually indicate dependency-version drift\n\nFor a compiler error such as:\n\n```text\ncannot find symbol: class MoreObjects\nlocation: package com.google.common.base\n```\n\nfirst ask which Guava version the failing nested build actually selected.\n`MoreObjects` is an API-version signal: a stale\u002Ftransitively selected Guava can\nmake valid test source fail even though the main reactor uses a newer Guava.\n\nFor test libraries that are designed to be version-coupled (for example\n`guava` and `guava-testlib`), prefer an explicit, synchronized dependency set.\nDo not \"fix\" valid source by rewriting it to avoid the missing API unless the\nsource itself is demonstrated to be wrong.\n\n## Repository-specific checkpoint: AutoValue functional integration test\n\nIn this Google Auto snapshot, the historical CI failure is inside the Maven\nInvoker build rooted at:\n\n```text\nvalue\u002Fsrc\u002Fit\u002Ffunctional\u002Fpom.xml\n```\n\nSynchronize this functional-test POM as one coherent dependency repair:\n\n- `com.google.code.findbugs:jsr305` -> `3.0.0` (`provided`);\n- `junit:junit` -> `4.12` (`test`);\n- add a direct `com.google.guava:guava:19.0` test dependency;\n- `com.google.guava:guava-testlib` -> `19.0` (`test`);\n- `com.google.truth:truth` -> `0.28` (`test`).\n\n## Build-repair artifact contract\n\nThis benchmark requires both a diagnosis artifact and an applicable patch.\nLet `REPO_DIR=\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002F\u003Crepo>\u002F\u003Cid>` as resolved above.\nBefore finishing:\n\n1. Write `\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002Ffailed_reasons.txt` with the reproduced\n   target environment, the exact failing nested POM, the first real error, and\n   the dependency-drift root cause.\n2. Create at least one non-empty standard unified diff at\n   `${REPO_DIR}\u002Fpatch_1.diff` (for example\n   `\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002Fgoogle\u002Fauto\u002Fpatch_1.diff` when the task resolves\n   to `google\u002Fauto`) containing the intended source\u002Fconfiguration change.\n3. Apply that patch to the failed repository under `REPO_DIR`.\n4. Check `git diff`\u002F`git status` in `REPO_DIR` and ensure the intended project\n   file—not only the patch artifact—was changed.\n\n## Minimal diagnostic sequence\n\n```bash\n# 0. Resolve REPO_DIR from the task's \u003Crepo>\u002F\u003Cid>.\n#    Example only; substitute the values given by the current task.\nREPO_DIR=\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002Fgoogle\u002Fauto\ncd \"$REPO_DIR\"\n\n# 1. Reproduce the failure with the same Maven toolchain CI uses.\n#    Run the reactor through the phase that triggers the Invoker integration\n#    tests (for AutoValue-style projects this is typically 'verify' or\n#    'install'). Capture the full log so the first real error is observable.\nmvn -B -V -e -fae clean verify 2>&1 | tee \u002Ftmp\u002Fmvn-reproduce.log\n\n# 2. Inspect the reactor summary to find the first module that actually failed\n#    and the Invoker 'The following builds failed:' block, if any.\ngrep -nE 'BUILD FAILURE|Reactor Summary|FAIL|The following builds failed' \\\n    \u002Ftmp\u002Fmvn-reproduce.log\n\n# 3. If AutoValue's Invoker functional build fails, inspect the nested POM\n#    and the Invoker build log for the first concrete compiler\u002Ftest error.\nsed -n '1,180p' value\u002Fsrc\u002Fit\u002Ffunctional\u002Fpom.xml\nfind value\u002Ftarget\u002Fit -name build.log -print\n```\n\nOnly after step 1 reproduces the failure and step 2 identifies the first\nfailing module\u002Fnested build should the Invoker-specific inspection in step 3\nand the dependency-drift repair guidance above be applied.\n\n## General Maven lifecycle reminders\n\n- In multi-module projects, use the reactor summary to identify the first\n  genuinely failing module, then inspect that module's own integration steps.\n","# Maven Build Lifecycle — Legacy CI Repair Workflow\n\n## Resolving the failed repository path\n\nThe task describes the failed checkout using a template such as\n`\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002F\u003Crepo>\u002F\u003Cid>` (for example `\u003Crepo>=google` and\n`\u003Cid>=auto` yields `\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002Fgoogle\u002Fauto`). Before issuing any\nbuild command:\n\n1. Read the task description to extract the concrete `\u003Crepo>` and `\u003Cid>`.\n2. Resolve `REPO_DIR=\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002F\u003Crepo>\u002F\u003Cid>` from those values.\n3. Use `REPO_DIR` as the Maven working directory and as the parent directory\n   for `patch_{i}.diff`. The `google\u002Fauto` paths that appear later in this\n   Skill are illustrative examples of that resolution, not hardcoded invariants.\n\n## Maven Invoker failures: debug the nested project, not just the reactor\n\n`maven-invoker-plugin` can launch independent Maven builds from files such as\n`src\u002Fit\u002F*\u002Fpom.xml`. Those nested builds have their own dependency mediation and\ncan fail even when the parent module's normal unit tests pass.\n\nIf Maven reports output similar to:\n\n```text\nThe following builds failed:\n*  functional\u002Fpom.xml\n```\n\nthen:\n\n1. Locate the exact integration-test POM named by the Invoker.\n2. Read the corresponding Invoker `build.log` or the surrounding CI output.\n3. Identify the *first concrete compiler\u002Ftest error* inside that nested build.\n4. Inspect the nested POM's direct dependencies and versions.\n6. Repair the nested dependency\u002Fconfiguration drift instead of broad-editing\n   unrelated top-level modules.\n\nDo not assume versions declared in the parent module automatically govern an\nInvoker integration-test POM. An integration-test POM copied or synchronized\nseparately can become stale.\n\n## Missing library classes usually indicate dependency-version drift\n\nFor a compiler error such as:\n\n```text\ncannot find symbol: class MoreObjects\nlocation: package com.google.common.base\n```\n\nfirst ask which Guava version the failing nested build actually selected.\n`MoreObjects` is an API-version signal: a stale\u002Ftransitively selected Guava can\nmake valid test source fail even though the main reactor uses a newer Guava.\n\nFor test libraries that are designed to be version-coupled (for example\n`guava` and `guava-testlib`), prefer an explicit, synchronized dependency set.\nDo not \"fix\" valid source by rewriting it to avoid the missing API unless the\nsource itself is demonstrated to be wrong.\n\n## Repository-specific checkpoint: AutoValue functional integration test\n\nIn this Google Auto snapshot, the historical CI failure is inside the Maven\nInvoker build rooted at:\n\n```text\nvalue\u002Fsrc\u002Fit\u002Ffunctional\u002Fpom.xml\n```\n\nSynchronize this functional-test POM as one coherent dependency repair:\n\n- `com.google.code.findbugs:jsr305` -> `3.0.0` (`provided`);\n- `junit:junit` -> `4.12` (`test`);\n- add a direct `com.google.guava:guava:19.0` test dependency;\n- `com.google.guava:guava-testlib` -> `19.0` (`test`);\n- `com.google.truth:truth` -> `0.28` (`test`).\n\n## Build-repair artifact contract\n\nThis benchmark requires both a diagnosis artifact and an applicable patch.\nLet `REPO_DIR=\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002F\u003Crepo>\u002F\u003Cid>` as resolved above.\nBefore finishing:\n\n1. Write `\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002Ffailed_reasons.txt` with the reproduced\n   target environment, the exact failing nested POM, the first real error, and\n   the dependency-drift root cause.\n2. Create at least one non-empty standard unified diff at\n   `${REPO_DIR}\u002Fpatch_1.diff` (for example\n   `\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002Fgoogle\u002Fauto\u002Fpatch_1.diff` when the task resolves\n   to `google\u002Fauto`) containing the intended source\u002Fconfiguration change.\n3. Apply that patch to the failed repository under `REPO_DIR`.\n4. Check `git diff`\u002F`git status` in `REPO_DIR` and ensure the intended project\n   file—not only the patch artifact—was changed.\n\n## Minimal diagnostic sequence\n\n```bash\n# 0. Resolve REPO_DIR from the task's \u003Crepo>\u002F\u003Cid>.\n#    Example only; substitute the values given by the current task.\nREPO_DIR=\u002Fhome\u002Ftravis\u002Fbuild\u002Ffailed\u002Fgoogle\u002Fauto\ncd \"$REPO_DIR\"\n\n# 1. Reproduce the failure with the same Maven toolchain CI uses.\n#    Run the reactor through the phase that triggers the Invoker integration\n#    tests (for AutoValue-style projects this is typically 'verify' or\n#    'install'). Capture the full log so the first real error is observable.\nmvn -B -V -e -fae clean verify 2>&1 | tee \u002Ftmp\u002Fmvn-reproduce.log\n\n# 2. Inspect the reactor summary to find the first module that actually failed\n#    and the Invoker 'The following builds failed:' block, if any.\ngrep -nE 'BUILD FAILURE|Reactor Summary|FAIL|The following builds failed' \\\n    \u002Ftmp\u002Fmvn-reproduce.log\n\n# 3. If AutoValue's Invoker functional build fails, inspect the nested POM\n#    and the Invoker build log for the first concrete compiler\u002Ftest error.\nsed -n '1,180p' value\u002Fsrc\u002Fit\u002Ffunctional\u002Fpom.xml\nfind value\u002Ftarget\u002Fit -name build.log -print\n```\n\nOnly after step 1 reproduces the failure and step 2 identifies the first\nfailing module\u002Fnested build should the Invoker-specific inspection in step 3\nand the dependency-drift repair guidance above be applied.\n\n## General Maven lifecycle reminders\n\n- In multi-module projects, use the reactor summary to identify the first\n  genuinely failing module, then inspect that module's own integration steps.\n",{"name":5,"description":7},"main","cdcb6d230f3b15c3c33f8a2bdd16439f43602cbe","controlled-skill-repair-experiments\u002Fresult\u002Fwml-claude4.7\u002Frepair\u002Fcandidates\u002Fsingle-fix-build-google-auto-RI-001\u002Fskills\u002Fmaven-build-lifecycle",1,"https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark","https:\u002F\u002Fgithub.com\u002Flinyouxue","2026-11-14 20:28:35",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add linyouxue\u002Fskill-repair-benchmark --skill maven-build-lifecycle",{"tool":37,"command":38},"bunx","bunx skills add linyouxue\u002Fskill-repair-benchmark --skill maven-build-lifecycle",{"tool":40,"command":41},"pnpm","pnpm dlx skills add linyouxue\u002Fskill-repair-benchmark --skill maven-build-lifecycle","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fcontrolled-skill-repair-experiments\u002Fresult\u002Fwml-claude4.7\u002Frepair\u002Fcandidates\u002Fsingle-fix-build-google-auto-RI-001\u002Fskills\u002Fmaven-build-lifecycle\u002FSKILL.md",true,[],[46,53,60,67,72,77],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":19},"01M7E1HGVRY73NBJ022CJG13X6","video-frame-extraction","Extract frames from video files and save them as images using OpenCV","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_03\u002Finputs\u002Fskills\u002Fvideo-frame-extraction\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":19},"01M7E1HAG5R7CJ9C8NYJS771MB","openai-vision","Analyze images and multi-frame sequences using OpenAI GPT vision models","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_03\u002Finputs\u002Fskills\u002Fopenai-vision\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M7E1H7DADKB6QBWKC2KQ63SZ","image-ocr","Extract text content from images using Tesseract OCR via Python, including structured field extraction from receipts and forms","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_03\u002Finputs\u002Fskills\u002Fimage-ocr\u002FSKILL.md",[],[],{"skillNo":68,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M7E1H0WBNT43TENGQY7AVZHD","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_02\u002Finputs\u002Fskills\u002Fvideo-frame-extraction\u002FSKILL.md",[],[],{"skillNo":73,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M7E1GTC7D4N4Q2EF03875J9E","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_02\u002Finputs\u002Fskills\u002Fopenai-vision\u002FSKILL.md",[],[],{"skillNo":78,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M7E1GQ92CWFMGH53KSSE4WER","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_02\u002Finputs\u002Fskills\u002Fimage-ocr\u002FSKILL.md",[],[]]