A harness is not a fixed artifact but an evolving system. This skill captures the delta of "what worked and what didn't work" and feeds it back into the harness, so that the next execution measurably improves.
초기 하네스 ──▶ 실 프로젝트 사용 ──▶ 현재 하네스
│
▼ (evolve로 델타 포착)
피드백 일반화 → 에이전트·스킬·오케스트레이터 반영
│
▼
변경 이력 갱신 → 다음 실행은 더 나은 초안에서 시작
Workflow
Phase 1: Delta Collection
.claude/agents/,.claude/skills/,CLAUDE.mdreads (the change history table)- If it is a git repository, query the change history of the harness files (
git log --oneline -- .claude/ CLAUDE.md) — identify what changed, when, and why compared to the initial configuration _workspace/If present, scan the intermediate artifacts of the most recent execution to confirm the actual execution traces:- Do the artifacts actually exist at the paths defined by the orchestrator (if not, the workflow was bypassed or is dead code)
- Does the artifact quality follow the format/criteria specified by the skill
- Ask the user for feedback (skip if feedback has already been provided):
- "Is there anything to improve in the results?"
- "Is there anything you'd like to change in the agent configuration or workflow?"
- If there is no feedback, do not force it. However, if the observation signals below are present, proactively suggest improvements
Observation-based evolution signals (suggest even without feedback):
- Traces of the same type of modification request repeated two or more times
- Patterns of an agent repeatedly failing/retrying
- Traces of the user bypassing the orchestrator and working manually (suspected orchestrator trigger failure → candidate for description expansion)
- v1 artifacts (TeamCreate/TeamDelete/experiment flags) remain in the orchestrator → guide the migration procedure of the harness skill
Phase 2: Classify Feedback Types and Map to Modification Targets
| Feedback Type | Modification Target | Example |
|---|---|---|
| Deliverable quality | The corresponding agent's skill | "The analysis is too superficial" → add depth criteria to the skill |
| Agent role | Agent definition .md |
"Security review is also needed" → guide adding an agent with the harness skill |
| Workflow order | Orchestrator skill | "Verification should come first" → change the Phase order |
| Team composition | Orchestrator + agents | "These two could probably be merged" → merge agents |
| Missing trigger | Skill description | "It doesn't work with this phrasing" → expand the description |
| Unsuitable execution mode | Orchestrator | "It's the same fan-out every time, but slow" → switch to workflow mode |
| Scale/Cost | Orchestrator | "It uses too many tokens" → reduce the default scale, add budget integration |
Scope judgment: If adding/removing agents or redesigning the architecture is needed, do not do it directly in this skill; instead guide to the harness skill (the existing configuration extension procedure in Phase 0). evolve focuses on adjustment of the existing configuration.
Phase 3: Generalization and Reflection
- Generalize the feedback — a narrow fix that fits only a specific case is overfitting. "The introduction was long in this report" → not "the introduction should be within 10% of the total," but find why it became long (absence of length allocation criteria in the skill) and fix it at the principle level
- Record the Why as well — the revised instruction is accompanied by the reason. If the reason is known, the agent judges correctly even in edge cases
- Apply changes one at a time, and run Phase 4 immediately after each change
- Regression prevention: If a fix is in a direction that reverts a previous fix in the existing change history, notify the user of the conflict and get confirmation (if it was reduced in the past for "too long" and this time it's "too short" — the correct answer is to find a criterion that satisfies both)
- Maintain the language of the existing file — sentences reflected in agents, skills, orchestrators, and
CLAUDE.mdare written in the language already used in the target file. Do not mix Korean sentences into a harness written in another language just because this skill document is in Korean
Phase 4: Update and Verify Change History
- CLAUDE.md의 Change history record in the table:
**변경 이력:**
| 날짜 | 변경 내용 | 대상 | 사유 |
|------|----------|------|------|
| 2026-07-19 | 톤 가이드 추가 | skills/content-creator | "너무 딱딱하다" 피드백 |
- Verify the structure of the modified file (frontmatter, reference consistency)
- If the description was modified, verify triggers (at least 3 each of should-trigger + near-miss)
- Final check of consistency between CLAUDE.md and the actual files
Phase 5: Evolution Report
Report to the user:
- Summary of captured deltas (initial configuration → current)
- Changes reflected this time and their generalization rationale
- Feedback decided not to reflect and the reason (if any)
- Expected improvements in the next run
Principles
- Deltas are assets — as the change history accumulates, building the next harness in the same domain starts from a "draft closer to a shipped state." Do not delete the history
- No reflection without generalization — adding one rule per case 1:1 turns the skill into a pile of rules. Compress into principles
- One at a time — applying multiple changes at once makes it impossible to know which change had the effect