[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NDDWRFFKHJFE7025AGSW9K":3,"skill-same:01M6NDDWRFFKHJFE7025AGSW9K":69},{"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":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M6NDDWRFFKHJFE7025AGSW9K","standard",null,"Standard harness evaluation — static analysis, dynamic testing, and checklist scoring in 2-3 minutes. Produces a detailed report with findings and improvement roadmap. Dynamic testing runs the target's hooks and tests after the user confirms. Pass --static-only for repositories you do not trust.","whchoi98\u002Fharness-eval","whchoi98","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F11262759?v=4","01M6NDBHK852X9V2A3S0MCSFXH","Woo Hyung Choi","01M6NDBHQRZ1X9VQ446F0ECDJJ",19,"MIT","https:\u002F\u002Fgithub.com\u002Fwhchoi98\u002Fharness-eval\u002Fblob\u002Fmain\u002Fplugins\u002Fharness-eval\u002Fskills\u002Fstandard\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"do","static","improvement","for","minutes","you","with","tests","scoring","testing","trust","checklist","hooks","roadmap","only","analysis","Evaluation","harness","report","2026-11-10 10:12:30",false,"---\nname: standard\ndescription: Standard harness evaluation — static analysis, dynamic testing, and checklist scoring in 2-3 minutes. Produces a detailed report with findings and improvement roadmap. Dynamic testing runs the target's hooks and tests after the user confirms. Pass --static-only for repositories you do not trust.\n---\n\nYou are performing a Standard harness evaluation. This combines static analysis, dynamic testing, and checklist scoring for a comprehensive assessment.\n\n## Trust boundary and mode selection\n\n**Read this before running anything.** Standard mode's dynamic analysis (Phase 2) *executes code from the target project* — its hook scripts and its test suite — on the evaluator's machine. A core use case for this tool is evaluating a repository you did not write (a teammate's project, a freshly cloned open-source repo). Running its hooks and tests can have side effects (network calls \u002F webhooks, file writes, environment changes) even on repositories you trust, and running them against crafted input is itself risky. Static analysis (Phases 1 and 3) only reads files and is always safe.\n\nDetermine the run mode from the invocation:\n\n- If the arguments include `--static-only` (or `--no-dynamic`), run **static-only mode**: skip Phase 2 entirely and run every other phase. In the report, mark every Dynamic Analysis subsection as `Skipped (static-only mode)`.\n- Otherwise (the default), run target code in Phase 2 only after the user confirms at the gate below, because the target may be a repository you did not write.\n\n## Phase 1: Static Analysis\n\nRun the static analysis script:\n```bash\nHARNESS_EVAL_ROOT=\"${CLAUDE_PLUGIN_ROOT}\" bash \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fstatic-analysis.sh\" \"$(pwd)\"\n```\n\nCapture the JSON output. Exit code 1 means issues were found and is a normal result; only exit code 2 is a script error. This checks:\n- **Correctness**: bash syntax, JSON validity, hook file mapping, permissions, model and effort settings (`model-config`), agent file format (`agent-format`)\n- **Safety**: tool scope analysis, deny list presence\n- **Completeness**: hook event coverage, CLAUDE.md existence\n- **Consistency**: frontmatter field consistency\n\n## Phase 2: Dynamic Analysis\n\n**Skip this entire phase in static-only mode** (see \"Trust boundary and mode selection\" above); mark each subsection below as `Skipped (static-only mode)` in the report and go straight to Phase 3.\n\n### Confirmation gate (required before any dynamic step)\n\nDynamic analysis runs code from the target project. Before executing anything, first enumerate what *would* run (list the hook script paths under `.claude\u002Fhooks\u002F` and the discovered test runner), then ask the user to confirm with a message like:\n\n> \"Standard dynamic analysis will EXECUTE code from the target project on this machine: the hook scripts listed above and its test suite. This can have side effects (network calls, file writes) even for trusted repos. Do you trust this repository and want to proceed? Reply to proceed, or re-run with `--static-only` to skip dynamic analysis.\"\n\nIf the user does not affirmatively confirm, fall back to static-only behavior: skip Phase 2 and note it as `Skipped (not confirmed)` in the report. Only proceed below once the user has confirmed.\n\n### Sandboxing guidance\n\nWhen you do run target code, minimize blast radius:\n- Run from a disposable copy of the project in a temporary directory (e.g. `cp -r` into a scratch dir) rather than the user's working tree, so writes cannot damage the original.\n- Strip inherited secrets\u002Fcredentials from the child environment (e.g. invoke via `env -i PATH=\"$PATH\" bash \u003Chook>`), so an exfiltrating hook has nothing to send.\n- Do not grant network access if your environment can withhold it; treat any hook that attempts outbound network calls as a finding, not as expected behavior.\n- Never pipe real secrets into hooks. Use only clearly-fake example values (as in 2b).\n\n### 2a. Hook Execution Testing\nFor each hook script found in `.claude\u002Fhooks\u002F` (after the gate above):\n1. Run with empty input: `echo \"\" | env -i PATH=\"$PATH\" bash \u003Chook>` — should not crash\n2. Run it with a sample payload for the event it is registered for (see the `hooks` section of `.claude\u002Fsettings.json`): for a PreToolUse\u002FPostToolUse hook on Bash, `echo '{\"tool_name\":\"Bash\",\"tool_input\":{\"command\":\"ls\"}}' | env -i PATH=\"$PATH\" bash \u003Chook>`. Record the exit code and what it prints. Silence is normal for many hooks; flag missing output only when the hook's purpose implies it should respond to this event.\n3. Check exit codes are 0 or 1 (Claude Code treats exit 2 as a block signal, not a script error; anything higher indicates a crash)\n\n### 2b. Secret Pattern Testing (if a secret-scanning hook exists)\nRead the hook first to see how it gets its input: a JSON hook event on stdin (e.g. `tool_input.command` or `tool_input.content`), raw stdin, or files it scans itself (such as git-staged files). Build one true-positive and one false-positive probe in that form, using only these fake values: `AKIAIOSFODNN7EXAMPLE` (AWS access key ID), `aws_secret_access_key = wJalrXUtnFEMI\u002FK7MDENG\u002FbPxRfiCYEXAMPLEKEY` (AWS secret key in its usual context), and `normal-base64-string-that-is-not-a-key` (should not trigger). For hooks that scan staged files, stage the probe only inside the disposable copy. If a probe cannot reach the hook, record it as `not testable this way`, not as a missed detection.\n\n### 2c. Existing Test Suite\nDiscover the target project's own test runner (do not assume a fixed name — it may be a top-level test script, a `Makefile` target, or a language-specific runner). Only run it after the confirmation gate:\n```bash\n# Discover candidate test entry points (examples — adapt to the project)\nls Makefile package.json tests\u002F*.sh test\u002F*.sh 2>\u002Fdev\u002Fnull\n# Run the discovered runner from a disposable copy where possible, e.g.:\n#   bash \u003Cdiscovered-test-script>\n```\nIf no test suite is found, record \"No test suite found\" and move on.\n\n## Phase 3: Scoring and History\n\nRun this phase from the target project root. If Phase 2 left the shell in the disposable copy, return to the project first, so the score and history describe the real project.\n\nPrepare the run directory. When `.harness-eval\u002F` has no `.gitignore`, this creates one containing `*`, so git ignores the evaluation files; an existing `.gitignore` (or a symlink by that name) is left untouched:\n```bash\nmkdir -p .harness-eval\u002Frun && { test -e .harness-eval\u002F.gitignore || test -L .harness-eval\u002F.gitignore || printf '*\\n' > .harness-eval\u002F.gitignore; }\n```\n\nRun the checklist scoring (`tee` shows you the JSON and keeps a copy for the history save):\n```bash\nHARNESS_EVAL_ROOT=\"${CLAUDE_PLUGIN_ROOT}\" bash \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fscoring.sh\" --mode standard \"$(pwd)\" | tee .harness-eval\u002Frun\u002Fstandard-score.json\n```\n\nThe pipeline's exit status is `tee`'s, so judge the result by its output: a JSON document with `scores` means scoring worked; an error on stderr with an empty `standard-score.json` means it failed (see Error Handling).\n\nThen save the result to history:\n```bash\nHARNESS_EVAL_ROOT=\"${CLAUDE_PLUGIN_ROOT}\" bash \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fhistory.sh\" \"$(pwd)\" save \u003C .harness-eval\u002Frun\u002Fstandard-score.json\n```\n\nIt prints `{\"id\":\"eval-YYYY-MM-DD-NNN\",\"saved\":true}`. That `id` names the report files in Phase 5.\n\n## Phase 4: Report Generation\n\nCombine all results into a **bilingual** (English + Korean) report. English section first, then `---`, then Korean section. Tables, scores, and code are identical — only prose differs.\n\n```\n# Harness Standard Evaluation\n\n**Score: {overall}\u002F10 ({grade})**\n**Date: {timestamp}**\n\n## Static Analysis Summary\n\n| Category | Pass | Warn | Fail |\n|----------|------|------|------|\n| Correctness | X | Y | Z |\n| Safety | X | Y | Z |\n| Completeness | X | Y | Z |\n| Consistency | X | Y | Z |\n\n## Static Analysis Findings\n(List each WARN and FAIL with details, file path, and suggestion)\n\n## Dynamic Analysis Results\n\n### Hook Execution\n(Results of hook testing — which hooks passed\u002Ffailed)\n\n### Secret Pattern Accuracy\n(TP\u002FFP results if applicable)\n\n### Test Suite Results\n(Results of running existing tests, or \"No test suite found\")\n\n## Checklist Results\n\n| Tier | Passed | Total | Status |\n|------|--------|-------|--------|\n| Basic (6.0+) | X | Y | ✓\u002F✗ |\n| Functional (7.0+) | X | Y | ✓\u002F✗ |\n| Robust (8.0+) | X | Y | ✓\u002F✗ |\n| Production (9.0+) | X | Y | ✓\u002F✗ |\n\n## Improvement Roadmap\n(Improvements in priority order: cover every FAIL and the WARNs worth fixing, without padding)\n\n---\n\n# 하네스 Standard 평가\n\n**점수: {overall}\u002F10 ({grade})**\n**날짜: {timestamp}**\n\n## 정적 분석 요약\n\n| 카테고리 | 통과 | 경고 | 실패 |\n|----------|------|------|------|\n| 정확성 | X | Y | Z |\n| 안전성 | X | Y | Z |\n| 완전성 | X | Y | Z |\n| 일관성 | X | Y | Z |\n\n## 정적 분석 발견 사항\n(각 WARN 및 FAIL 항목의 상세 내용, 파일 경로, 개선 제안)\n\n## 동적 분석 결과\n\n### 훅 실행\n(훅 테스트 결과 — 통과\u002F실패 항목)\n\n### 시크릿 패턴 정확도\n(해당되는 경우 TP\u002FFP 결과)\n\n### 테스트 스위트 결과\n(기존 테스트 실행 결과, 또는 \"테스트 스위트 없음\")\n\n## 체크리스트 결과\n\n| 단계 | 통과 | 전체 | 상태 |\n|------|------|------|------|\n| 기본 (6.0+) | X | Y | ✓\u002F✗ |\n| 기능적 (7.0+) | X | Y | ✓\u002F✗ |\n| 견고 (8.0+) | X | Y | ✓\u002F✗ |\n| 프로덕션 (9.0+) | X | Y | ✓\u002F✗ |\n\n## 개선 로드맵\n(영향도 순 개선 사항 — 모든 FAIL과 고칠 가치가 있는 WARN을 담되, 억지로 항목을 채우지 않음)\n```\n\n## Phase 5: Save Reports to Files\n\nSave the English and Korean reports as separate files in the target project:\n```bash\nmkdir -p .harness-eval\u002Freports\n```\n- English report: `.harness-eval\u002Freports\u002F{id}-standard-en.md`\n- Korean report: `.harness-eval\u002Freports\u002F{id}-standard-ko.md`\n\n`{id}` is the ID printed by the history save in Phase 3. If the save failed, name the files `eval-{YYYY-MM-DD}-unsaved-standard-en.md` and `eval-{YYYY-MM-DD}-unsaved-standard-ko.md` (UTC date of the scoring output's `timestamp`) and tell the user this run was not recorded in history. An unsaved file of that name can already exist from an earlier run the same day, and the Write tool refuses to overwrite a file it has not read, so Read an existing one first and then overwrite it.\n\nUse the Write tool to create each file. Then report the evaluation ID (or that there is none) and the saved report file paths to the user.\n\n## Error Handling\n\n- If static-analysis.sh fails with exit 2: report the error but continue with scoring\n- If scoring.sh fails (an error on stderr and an empty `.harness-eval\u002Frun\u002Fstandard-score.json`): show the error, suggest checking jq\u002Fdependencies, and skip the history save, since there is no score to record\n- If history.sh save fails: warn, use the unsaved report file names from Phase 5, and still deliver the report\n- If no `.claude\u002F` directory exists: the score will be very low. Suggest running `\u002Finit` in a Claude Code session to create a CLAUDE.md, then adding `.claude\u002Fsettings.json` with permissions and hooks.\n\n## Tone\n\nBe constructive: give a specific fix for each issue found, and order the improvement roadmap by impact.\n\n## Language\n\nAlways produce the report in both English and Korean. English section first, then a horizontal rule (---), then the Korean section. Tables, scores, file paths, and code blocks are identical in both sections — only the prose text differs.\n","You are performing a Standard harness evaluation. This combines static analysis, dynamic testing, and checklist scoring for a comprehensive assessment.\n\n## Trust boundary and mode selection\n\n**Read this before running anything.** Standard mode's dynamic analysis (Phase 2) *executes code from the target project* — its hook scripts and its test suite — on the evaluator's machine. A core use case for this tool is evaluating a repository you did not write (a teammate's project, a freshly cloned open-source repo). Running its hooks and tests can have side effects (network calls \u002F webhooks, file writes, environment changes) even on repositories you trust, and running them against crafted input is itself risky. Static analysis (Phases 1 and 3) only reads files and is always safe.\n\nDetermine the run mode from the invocation:\n\n- If the arguments include `--static-only` (or `--no-dynamic`), run **static-only mode**: skip Phase 2 entirely and run every other phase. In the report, mark every Dynamic Analysis subsection as `Skipped (static-only mode)`.\n- Otherwise (the default), run target code in Phase 2 only after the user confirms at the gate below, because the target may be a repository you did not write.\n\n## Phase 1: Static Analysis\n\nRun the static analysis script:\n```bash\nHARNESS_EVAL_ROOT=\"${CLAUDE_PLUGIN_ROOT}\" bash \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fstatic-analysis.sh\" \"$(pwd)\"\n```\n\nCapture the JSON output. Exit code 1 means issues were found and is a normal result; only exit code 2 is a script error. This checks:\n- **Correctness**: bash syntax, JSON validity, hook file mapping, permissions, model and effort settings (`model-config`), agent file format (`agent-format`)\n- **Safety**: tool scope analysis, deny list presence\n- **Completeness**: hook event coverage, CLAUDE.md existence\n- **Consistency**: frontmatter field consistency\n\n## Phase 2: Dynamic Analysis\n\n**Skip this entire phase in static-only mode** (see \"Trust boundary and mode selection\" above); mark each subsection below as `Skipped (static-only mode)` in the report and go straight to Phase 3.\n\n### Confirmation gate (required before any dynamic step)\n\nDynamic analysis runs code from the target project. Before executing anything, first enumerate what *would* run (list the hook script paths under `.claude\u002Fhooks\u002F` and the discovered test runner), then ask the user to confirm with a message like:\n\n> \"Standard dynamic analysis will EXECUTE code from the target project on this machine: the hook scripts listed above and its test suite. This can have side effects (network calls, file writes) even for trusted repos. Do you trust this repository and want to proceed? Reply to proceed, or re-run with `--static-only` to skip dynamic analysis.\"\n\nIf the user does not affirmatively confirm, fall back to static-only behavior: skip Phase 2 and note it as `Skipped (not confirmed)` in the report. Only proceed below once the user has confirmed.\n\n### Sandboxing guidance\n\nWhen you do run target code, minimize blast radius:\n- Run from a disposable copy of the project in a temporary directory (e.g. `cp -r` into a scratch dir) rather than the user's working tree, so writes cannot damage the original.\n- Strip inherited secrets\u002Fcredentials from the child environment (e.g. invoke via `env -i PATH=\"$PATH\" bash \u003Chook>`), so an exfiltrating hook has nothing to send.\n- Do not grant network access if your environment can withhold it; treat any hook that attempts outbound network calls as a finding, not as expected behavior.\n- Never pipe real secrets into hooks. Use only clearly-fake example values (as in 2b).\n\n### 2a. Hook Execution Testing\nFor each hook script found in `.claude\u002Fhooks\u002F` (after the gate above):\n1. Run with empty input: `echo \"\" | env -i PATH=\"$PATH\" bash \u003Chook>` — should not crash\n2. Run it with a sample payload for the event it is registered for (see the `hooks` section of `.claude\u002Fsettings.json`): for a PreToolUse\u002FPostToolUse hook on Bash, `echo '{\"tool_name\":\"Bash\",\"tool_input\":{\"command\":\"ls\"}}' | env -i PATH=\"$PATH\" bash \u003Chook>`. Record the exit code and what it prints. Silence is normal for many hooks; flag missing output only when the hook's purpose implies it should respond to this event.\n3. Check exit codes are 0 or 1 (Claude Code treats exit 2 as a block signal, not a script error; anything higher indicates a crash)\n\n### 2b. Secret Pattern Testing (if a secret-scanning hook exists)\nRead the hook first to see how it gets its input: a JSON hook event on stdin (e.g. `tool_input.command` or `tool_input.content`), raw stdin, or files it scans itself (such as git-staged files). Build one true-positive and one false-positive probe in that form, using only these fake values: `AKIAIOSFODNN7EXAMPLE` (AWS access key ID), `aws_secret_access_key = wJalrXUtnFEMI\u002FK7MDENG\u002FbPxRfiCYEXAMPLEKEY` (AWS secret key in its usual context), and `normal-base64-string-that-is-not-a-key` (should not trigger). For hooks that scan staged files, stage the probe only inside the disposable copy. If a probe cannot reach the hook, record it as `not testable this way`, not as a missed detection.\n\n### 2c. Existing Test Suite\nDiscover the target project's own test runner (do not assume a fixed name — it may be a top-level test script, a `Makefile` target, or a language-specific runner). Only run it after the confirmation gate:\n```bash\n# Discover candidate test entry points (examples — adapt to the project)\nls Makefile package.json tests\u002F*.sh test\u002F*.sh 2>\u002Fdev\u002Fnull\n# Run the discovered runner from a disposable copy where possible, e.g.:\n#   bash \u003Cdiscovered-test-script>\n```\nIf no test suite is found, record \"No test suite found\" and move on.\n\n## Phase 3: Scoring and History\n\nRun this phase from the target project root. If Phase 2 left the shell in the disposable copy, return to the project first, so the score and history describe the real project.\n\nPrepare the run directory. When `.harness-eval\u002F` has no `.gitignore`, this creates one containing `*`, so git ignores the evaluation files; an existing `.gitignore` (or a symlink by that name) is left untouched:\n```bash\nmkdir -p .harness-eval\u002Frun && { test -e .harness-eval\u002F.gitignore || test -L .harness-eval\u002F.gitignore || printf '*\\n' > .harness-eval\u002F.gitignore; }\n```\n\nRun the checklist scoring (`tee` shows you the JSON and keeps a copy for the history save):\n```bash\nHARNESS_EVAL_ROOT=\"${CLAUDE_PLUGIN_ROOT}\" bash \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fscoring.sh\" --mode standard \"$(pwd)\" | tee .harness-eval\u002Frun\u002Fstandard-score.json\n```\n\nThe pipeline's exit status is `tee`'s, so judge the result by its output: a JSON document with `scores` means scoring worked; an error on stderr with an empty `standard-score.json` means it failed (see Error Handling).\n\nThen save the result to history:\n```bash\nHARNESS_EVAL_ROOT=\"${CLAUDE_PLUGIN_ROOT}\" bash \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fhistory.sh\" \"$(pwd)\" save \u003C .harness-eval\u002Frun\u002Fstandard-score.json\n```\n\nIt prints `{\"id\":\"eval-YYYY-MM-DD-NNN\",\"saved\":true}`. That `id` names the report files in Phase 5.\n\n## Phase 4: Report Generation\n\nCombine all results into a **bilingual** (English + Korean) report. English section first, then `---`, then Korean section. Tables, scores, and code are identical — only prose differs.\n\n```\n# Harness Standard Evaluation\n\n**Score: {overall}\u002F10 ({grade})**\n**Date: {timestamp}**\n\n## Static Analysis Summary\n\n| Category | Pass | Warn | Fail |\n|----------|------|------|------|\n| Correctness | X | Y | Z |\n| Safety | X | Y | Z |\n| Completeness | X | Y | Z |\n| Consistency | X | Y | Z |\n\n## Static Analysis Findings\n(List each WARN and FAIL with details, file path, and suggestion)\n\n## Dynamic Analysis Results\n\n### Hook Execution\n(Results of hook testing — which hooks passed\u002Ffailed)\n\n### Secret Pattern Accuracy\n(TP\u002FFP results if applicable)\n\n### Test Suite Results\n(Results of running existing tests, or \"No test suite found\")\n\n## Checklist Results\n\n| Tier | Passed | Total | Status |\n|------|--------|-------|--------|\n| Basic (6.0+) | X | Y | ✓\u002F✗ |\n| Functional (7.0+) | X | Y | ✓\u002F✗ |\n| Robust (8.0+) | X | Y | ✓\u002F✗ |\n| Production (9.0+) | X | Y | ✓\u002F✗ |\n\n## Improvement Roadmap\n(Improvements in priority order: cover every FAIL and the WARNs worth fixing, without padding)\n\n---\n\n# 하네스 Standard 평가\n\n**점수: {overall}\u002F10 ({grade})**\n**날짜: {timestamp}**\n\n## 정적 분석 요약\n\n| 카테고리 | 통과 | 경고 | 실패 |\n|----------|------|------|------|\n| 정확성 | X | Y | Z |\n| 안전성 | X | Y | Z |\n| 완전성 | X | Y | Z |\n| 일관성 | X | Y | Z |\n\n## 정적 분석 발견 사항\n(각 WARN 및 FAIL 항목의 상세 내용, 파일 경로, 개선 제안)\n\n## 동적 분석 결과\n\n### 훅 실행\n(훅 테스트 결과 — 통과\u002F실패 항목)\n\n### 시크릿 패턴 정확도\n(해당되는 경우 TP\u002FFP 결과)\n\n### 테스트 스위트 결과\n(기존 테스트 실행 결과, 또는 \"테스트 스위트 없음\")\n\n## 체크리스트 결과\n\n| 단계 | 통과 | 전체 | 상태 |\n|------|------|------|------|\n| 기본 (6.0+) | X | Y | ✓\u002F✗ |\n| 기능적 (7.0+) | X | Y | ✓\u002F✗ |\n| 견고 (8.0+) | X | Y | ✓\u002F✗ |\n| 프로덕션 (9.0+) | X | Y | ✓\u002F✗ |\n\n## 개선 로드맵\n(영향도 순 개선 사항 — 모든 FAIL과 고칠 가치가 있는 WARN을 담되, 억지로 항목을 채우지 않음)\n```\n\n## Phase 5: Save Reports to Files\n\nSave the English and Korean reports as separate files in the target project:\n```bash\nmkdir -p .harness-eval\u002Freports\n```\n- English report: `.harness-eval\u002Freports\u002F{id}-standard-en.md`\n- Korean report: `.harness-eval\u002Freports\u002F{id}-standard-ko.md`\n\n`{id}` is the ID printed by the history save in Phase 3. If the save failed, name the files `eval-{YYYY-MM-DD}-unsaved-standard-en.md` and `eval-{YYYY-MM-DD}-unsaved-standard-ko.md` (UTC date of the scoring output's `timestamp`) and tell the user this run was not recorded in history. An unsaved file of that name can already exist from an earlier run the same day, and the Write tool refuses to overwrite a file it has not read, so Read an existing one first and then overwrite it.\n\nUse the Write tool to create each file. Then report the evaluation ID (or that there is none) and the saved report file paths to the user.\n\n## Error Handling\n\n- If static-analysis.sh fails with exit 2: report the error but continue with scoring\n- If scoring.sh fails (an error on stderr and an empty `.harness-eval\u002Frun\u002Fstandard-score.json`): show the error, suggest checking jq\u002Fdependencies, and skip the history save, since there is no score to record\n- If history.sh save fails: warn, use the unsaved report file names from Phase 5, and still deliver the report\n- If no `.claude\u002F` directory exists: the score will be very low. Suggest running `\u002Finit` in a Claude Code session to create a CLAUDE.md, then adding `.claude\u002Fsettings.json` with permissions and hooks.\n\n## Tone\n\nBe constructive: give a specific fix for each issue found, and order the improvement roadmap by impact.\n\n## Language\n\nAlways produce the report in both English and Korean. English section first, then a horizontal rule (---), then the Korean section. Tables, scores, file paths, and code blocks are identical in both sections — only the prose text differs.\n",{"name":5,"description":7},"main","820cf8d1b503efb55bdcef2f86515841579e54ab","plugins\u002Fharness-eval\u002Fskills\u002Fstandard",2,"https:\u002F\u002Fgithub.com\u002Fwhchoi98\u002Fharness-eval","https:\u002F\u002Fgithub.com\u002Fwhchoi98","2026-09-24 17:53:28",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add whchoi98\u002Fharness-eval --skill standard",{"tool":61,"command":62},"bunx","bunx skills add whchoi98\u002Fharness-eval --skill standard",{"tool":64,"command":65},"pnpm","pnpm dlx skills add whchoi98\u002Fharness-eval --skill standard","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fwhchoi98\u002Fharness-eval\u002Fblob\u002Fmain\u002Fplugins\u002Fharness-eval\u002Fskills\u002Fstandard\u002FSKILL.md",true,[],[70,84,93,114,127,151],{"skillNo":71,"name":72,"nameZh":6,"description":73,"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":79,"publishedAt":43},"01M6NDE0RRMR9EH3NX5KT6YRCY","summarize","Summarize a document using an alias and the max effort level","https:\u002F\u002Fgithub.com\u002Fwhchoi98\u002Fharness-eval\u002Fblob\u002Fmain\u002Fplugins\u002Fharness-eval\u002Ftests\u002Ffixtures\u002Fmodel-era-project\u002F.claude\u002Fskills\u002Fsummarize\u002FSKILL.md",[76],{"categoryNo":77,"categoryName":78,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[72,80,81,82,83],"sonnet","alias","max","document",{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":43},"01M6NDDAS3GH993YS98D37FE69","quick","Quick harness evaluation — checklist-based scoring in ~30 seconds. Runs deterministic checks against the target project and produces a score, grade, and improvement suggestions.","https:\u002F\u002Fgithub.com\u002Fwhchoi98\u002Fharness-eval\u002Fblob\u002Fmain\u002Fplugins\u002Fharness-eval\u002Fskills\u002Fquick\u002FSKILL.md",[],[86,35,26,91,32,92,40,41],"project","deterministic",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":102,"publishedAt":43},"01M6NDD5XJN68ATTM77DQ8VMYH","full","Full harness evaluation — multi-agent deep analysis across 12 dimensions (safety, completeness, design quality) with parallel evaluators and a synthesized report. Takes 5-10 minutes. Produces a scored report in English and Korean with an executive summary and improvement roadmap. Use when the user explicitly asks for a full, deep, or multi-agent harness evaluation. For a quick score use quick; for static plus dynamic checks use standard.","https:\u002F\u002Fgithub.com\u002Fwhchoi98\u002Fharness-eval\u002Fblob\u002Fmain\u002Fplugins\u002Fharness-eval\u002Fskills\u002Ffull\u002FSKILL.md",[99],{"categoryNo":100,"categoryName":101,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[95,103,104,37,105,106,39,107,40,41,108,109,110,111,25,26,27,86,112,113],"dimensions","korean","parallel","multi-agent","Safety","deep analysis","executive summary","design","across","english","deep",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":43},"01M6NDD366AHN40A7DMW0G3F95","compare","Compare harness evaluation history — shows score trends, per-tier deltas, diminishing returns detection, and next grade projection.","https:\u002F\u002Fgithub.com\u002Fwhchoi98\u002Fharness-eval\u002Fblob\u002Fmain\u002Fplugins\u002Fharness-eval\u002Fskills\u002Fcompare\u002FSKILL.md",[],[116,121,122,123,124,125,40,41,126],"deltas","trends","next","history","detection","returns",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":43},"01M6NDCK6VXG06S27GSQGR3163","sync-docs","Bring harness-eval's CLAUDE.md files, architecture docs, and manifests back in line with the current code. Use when the user asks to sync or audit docs, or after structural changes.","https:\u002F\u002Fgithub.com\u002Fwhchoi98\u002Fharness-eval\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsync-docs\u002FSKILL.md",[],[134,135,136,137,138,41,139,140,141,142,30,143,144,145,146,147,148,149,150],"sync docs","sync","docs","code","architecture","line","changes","manifests","bring","structural","audit docs","back","files","use","user","eval","audit",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":43},"01M6NDC0RPXHBXXA1BZJZ0ERAE","release","Cut a harness-eval release - bump the version in the three manifest fields and the README version badge, update CHANGELOG (EN+KO), tag. Use only when the user asks to release.","https:\u002F\u002Fgithub.com\u002Fwhchoi98\u002Fharness-eval\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Frelease\u002FSKILL.md",[],[153,158,159,160,161,162,163,164,165,38,147,148,166,149,167,168,41,169],"update","version","true","ko","cut","three","bump","en","README","update changelog","manifest","changelog"]