Trim harness docs and state templates

.agents/skills/harness-plan/SKILL.md

@@ -12,8 +12,8 @@ Codex에서 Claude Code `/harness-plan`에 해당하는 절차를 직접 수행
 
 1. `AGENTS.md`, `CLAUDE.md`, `agents/quality-gates.md`, `tasks/index.json`, `Plans.md`, 필요한 기획 문서를 읽는다.
 2. `python3 scripts/build_planning_context.py`로 planning context를 만든다.
-3. `harness.toml [plan].decomposer_command`가 있으면 그 명령으로 proposal을 만든다.
-4. 명령이 없거나 실패하고 `allow_inline_fallback = true`이면, 현재 Codex 세션이 `agents/task-decomposer.md` 기준으로 같은 proposal 파일 계약을 채운다.
+3. 현재 Codex 세션이 `agents/task-decomposer.md` 기준으로 proposal 파일 계약을 채운다.
+4. `harness.toml [plan].decomposer_command`가 명시되어 있으면 외부 명령으로 proposal 생성을 위임할 수 있다. 실패하면 쉬운 실패 로그를 남기고 inline fallback으로 돌아온다.
 5. `python3 scripts/validate_task_proposal.py ...`로 proposal을 검증한다.
 6. 통과한 경우에만 `python3 scripts/apply_task_proposal.py ...`로 `tasks/index.json`에 반영한다.
 7. `python3 scripts/sync_plans.py`로 `Plans.md`를 재생성하고 `python3 scripts/validate_tasks.py`로 확인한다.

.agents/skills/harness-work/SKILL.md

@@ -22,10 +22,13 @@ Codex에서 Claude Code `/harness-work`에 해당하는 절차를 직접 수행
 ## 완료 기준
 
 - Acceptance와 관련 테스트가 통과해야 한다.
+- `.harness/tasks/<task-key>/RUN_REPORT.md`에 변경 요약, 주요 결정 근거,
+  Acceptance/test evidence, 남은 위험을 짧게 남긴다.
 - Acceptance와 관련 테스트 통과 후 에이전트가 `tasks/index.json`의 대상 Task를
   `done`으로 갱신하고 `Plans.md`를 재생성한다. GitHub Actions는 Task 상태를
   전환하지 않는다.
 - 새 파일이나 역할 변경은 `.harness/CONTEXT_INDEX.md`에 반영한다.
-- 루트 `.harness/STATE.md`, `HANDOFF.md`, `TASKS.md`, `LOG.md`, `CHECKPOINTS.md`는 템플릿이므로 실제 진행 상태를 쓰지 않는다.
+- 루트 `.harness/STATE.md`, `HANDOFF.md`, `TASKS.md`, `LOG.md`, `CHECKPOINTS.md`,
+  `RUN_REPORT.md`는 템플릿이므로 실제 진행 상태를 쓰지 않는다.
 - ponytail/caveman Codex plugin 자동 동작을 가정하지 않는다. Codex에서는
   `agents/quality-gates.md`를 직접 적용한다.

.agents/skills/harness-yagni-trimmer/SKILL.md

@@ -0,0 +1,197 @@
+---
+name: harness-yagni-trimmer
+description: Harness template or harness system YAGNI review for solo builders. Use when the user asks to review, trim, simplify, archive, or reduce a harness/template/system where documentation, progress tracking, logs, reports, workflows, prompts, skills, or task/state files feel too heavy; especially when the goal is complexity reduction rather than feature addition.
+---
+
+# harness-yagni-trimmer
+
+Review a harness template from the position of a solo builder. The goal is not to add capability. The goal is to leave only the structure that helps someone quickly resume, code, verify, and move on.
+
+## Core Standard
+
+First answer this before judging files:
+
+```text
+What is this harness template's minimum successful flow?
+```
+
+Example:
+
+```text
+1. Start a new project.
+2. Write the goal in one paragraph.
+3. Ask Codex to implement.
+4. Run the result.
+5. If it fails, record only the error and next action.
+6. If it succeeds, record changed files and usage.
+```
+
+Treat anything not directly helping that flow as suspicious.
+
+## Scan Targets
+
+Prioritize these surfaces:
+
+- `README.md`, `CLAUDE.md`, `AGENTS.md`, `SKILL.md`
+- `.codex/`, `.claude/`, `.cursor/`, `.agents/`
+- `docs/`, `specs/`, `memory/`, `logs/`, `reports/`, `tasks/`, `workflows/`
+- `scripts/`, `templates/`, `prompts/`
+- `Makefile`, `package.json`, `pyproject.toml`
+- CI/CD configuration files
+
+## Classification
+
+Classify each important file or feature as one of:
+
+- `KEEP`: directly needed in the current solo-builder flow; removing it often blocks work.
+- `SIMPLIFY`: needed, but too long, repetitive, or heavy; shorten the format.
+- `REMOVE`: not needed now; looks useful but does not change today's work.
+- `ARCHIVE`: maybe useful as reference, but should not be in the default harness path.
+
+Default stance: ask "why keep this?" If the answer is weak, mark it `REMOVE` or `ARCHIVE`.
+
+## Preferred Minimal Docs
+
+Reduce default documentation toward these files when safe:
+
+- `README.md`: what this is, how to run it, key commands, current state. Target under 100 lines.
+- `WORKING_STATE.md`: current goal, done, next, blockers, last updated.
+- `DECISIONS.md`: only hard-to-reverse structural or technical decisions.
+- `ERRORS.md`: only recurring errors with symptom, cause, fix, and command.
+
+Do not add these files just to satisfy the pattern if the repo already has a smaller effective equivalent. Consolidate only when it reduces real reading and writing burden.
+
+## Removal Priority
+
+Trim in this order:
+
+1. Duplicate status docs such as `STATUS.md`, `PROGRESS.md`, `TASKS.md`, `REPORT.md`, `WORKING_STATE.md`.
+2. Reporting docs such as long completion reports, generated summaries, heavy review logs, retrospectives.
+3. Unused expansion structures such as provider abstractions, plugin registries, hook systems, policy layers, generic executors, template engines.
+4. Mandatory checklists that do not prevent real mistakes within 30 seconds.
+5. Logs that are not failure cause, reproduction command, or next action.
+
+## Workflow
+
+1. Scan the repository and report:
+
+```md
+## Harness Surface Area
+
+- 문서 파일 수:
+- workflow 파일 수:
+- prompt/skill 파일 수:
+- logs/reports/tasks 관련 파일 수:
+- 의심되는 중복 영역:
+```
+
+2. Diagnose briefly:
+
+```md
+## Diagnosis
+
+현재 harness는 다음 문제가 있다.
+
+1. 과한 문서화:
+2. 중복 상태 추적:
+3. 아직 필요 없는 확장 구조:
+4. solo builder 흐름 방해 요소:
+5. 삭제해도 안전해 보이는 것:
+```
+
+3. Apply YAGNI questions to major components:
+
+```md
+## YAGNI Questions
+
+### 대상: 파일 또는 기능 이름
+
+- 지금 실제로 쓰는가?
+- 없으면 오늘 작업이 막히는가?
+- 다음 행동을 더 쉽게 만드는가?
+- 같은 내용을 다른 곳에서도 기록하는가?
+- 미래 대비라는 이유만으로 존재하는가?
+
+판정:
+- KEEP / SIMPLIFY / REMOVE / ARCHIVE
+
+이유:
+- 짧게 작성
+```
+
+4. Show a trim plan before risky deletion:
+
+```md
+## Trim Plan
+
+### KEEP
+
+- 유지할 것
+
+### SIMPLIFY
+
+- 줄일 것
+- 어떻게 줄일 것
+
+### REMOVE
+
+- 삭제할 것
+- 삭제해도 되는 이유
+
+### ARCHIVE
+
+- 옮길 것
+- 이동 위치
+```
+
+5. Apply clearly safe reductions without waiting for extra confirmation. Safe examples: merging duplicate docs, deleting empty templates, archiving unused examples, shortening long docs, consolidating duplicate state docs.
+
+6. Do not directly apply risky reductions. Propose first when a change removes execution scripts, CI/CD behavior, real code paths, active hooks, or agent execution rules.
+
+## Final Report
+
+After edits, report exactly in this shape:
+
+```md
+# Harness Trim Result
+
+## 한 줄 결론
+
+이번 변경으로 harness가 더 가벼워졌는지 한 문장으로 설명.
+
+## 제거한 것
+
+- 항목:
+  - 이유:
+
+## 줄인 것
+
+- 항목:
+  - 기존:
+  - 변경:
+
+## 남긴 것
+
+- 항목:
+  - 이유:
+
+## 아직 무거운 부분
+
+- 항목:
+  - 왜 아직 무거운지:
+  - 다음에 줄이는 방법:
+
+## 다음 작업
+
+1. 가장 먼저 할 일
+2. 그 다음 할 일
+3. 보류할 일
+```
+
+## Guardrails
+
+- Do not add new harness structures because they look useful.
+- Do not create interfaces, providers, plugin registries, or logging frameworks for future use.
+- Do not solve documentation bloat by adding more documentation files.
+- Do not keep anything only because it might be useful later.
+- Judge success by whether the next solo-builder action is easier, not by whether the file count is lower.

.agents/skills/harness-yagni-trimmer/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Harness YAGNI Trimmer"
+  short_description: "Review and reduce harness template complexity for solo builders."
+  default_prompt: "이 프로젝트의 harness template을 YAGNI 관점에서 리뷰하고 줄여줘."

.agents/skills/rescue-from-main/SKILL.md

@@ -5,68 +5,28 @@ description: main/master에서 만든 변경사항을 안전하게 작업 브랜
 
 # rescue-from-main
 
-`main`/`master`에서 실수로 작업한 변경사항을 내용 기반 작업 브랜치로 옮기고
-`commit -> push -> draft PR`까지 이어간다. 자동 reset이나 강제 push는 하지 않는다.
-
-## Preflight
-
-1. `git status --short --branch`로 현재 브랜치와 변경분을 확인한다.
-2. `git branch --show-current`, `git branch -vv`, `git remote -v`로 현재 브랜치,
-   upstream, remote를 확인한다.
-3. `gh auth status` 또는 `gh pr view`로 GitHub CLI 사용 가능 여부를 확인한다.
-   인증/권한 오류는 원문을 요약하고 중단한다.
-4. `git diff --stat`, `git diff --name-status`를 읽는다. staged 변경이 있으면
-   `git diff --cached --stat`, `git diff --cached --name-status`도 읽는다.
-5. 변경분이 없고 현재 브랜치에만 push되지 않은 commit도 없으면 중단한다.
-
-## 변경 분석과 브랜치명
-
-1. 변경 파일, diff 요약, staged diff, 필요 시 최근 commit 제목을 근거로 짧은
-   `{change-slug}`를 만든다.
-2. Task ID가 명확하면 `task/{task-id}-{change-slug}`를 사용한다. Task가 없으면
-   `work/{change-slug}`를 사용한다.
-3. `{change-slug}`는 diff 내용에서 2-5개 단어를 뽑아 kebab-case로 만든다.
-4. `fix`, `update`, `changes`, `misc`, `wip`처럼 내용이 불명확한 단독 slug는 금지한다.
-5. `git branch --list {branch}`와 `git ls-remote --heads origin {branch}`로 충돌을
-   확인한다. 충돌하면 `-{n}` suffix를 붙인다.
-
-## 브랜치 처리
-
-1. 현재 브랜치가 `main`/`master`이고 uncommitted 변경이 있으면
-   `git switch -c {branch}`로 새 브랜치를 만든다. Git은 변경분을 그대로 보존한다.
-2. 현재 브랜치가 `main`/`master`이고 upstream보다 앞선 local commit이 있으면
-   자동으로 옮기거나 reset하지 않고 중단한다. 새 브랜치에 commit을 보존하는 작업과
-   `main` 복구는 사용자에게 별도 승인받은 뒤 진행한다.
-3. 이미 작업 브랜치면 브랜치명이 변경 내용과 맞는지 확인한다. 맞으면 그대로 진행하고,
-   불명확하면 rename 여부를 사용자에게 확인한다.
-
-## Commit
-
-1. `tasks/index.json`에서 대상 Task가 있으면 DoD/Acceptance를 확인한다.
-2. `git add {files}` 또는 `git add -A`로 변경분을 stage한다. 사용자 요청 범위 밖
-   파일이 섞여 있으면 제외하거나 중단하고 보고한다.
-3. 커밋 메시지는 Task가 있으면 `task {task-id}: {summary}`, 없으면 `{summary}`를
-   사용한다.
-4. `git commit -m "{message}"`를 실행한다.
-
-## Push와 Draft PR
-
-1. `git push -u origin {branch}`를 실행한다. 강제 push는 사용하지 않는다.
-2. Acceptance command와 관련 테스트 결과를 PR 본문에 적는다.
-3. `gh pr create --draft`로 draft PR을 만든다.
-4. PR 본문에는 다음 항목을 포함한다.
-   - 변경 요약
-   - 검증 결과
-   - Acceptance evidence
-   - residual risk
-   - Task `gh` 값이 `#N`이면 `Closes #N`
+`main`/`master`에서 실수로 작업한 변경사항을 내용 기반 작업 브랜치로 옮긴다. 자동 reset이나 강제 push는 하지 않는다.
+
+## 절차
+
+1. `git status --short --branch`, `git branch --show-current`, `git branch -vv`, `git remote -v`를 확인한다.
+2. `gh auth status` 또는 `gh pr view`로 GitHub CLI 사용 가능 여부를 확인한다.
+3. `git diff --stat`, `git diff --name-status`를 읽는다. staged 변경이 있으면 cached diff도 읽는다.
+4. 변경분이 없고 현재 브랜치에만 push되지 않은 commit도 없으면 중단한다.
+5. diff 내용에서 2-5개 단어의 kebab-case `{change-slug}`를 만든다. `fix`, `update`, `changes`, `misc`, `wip` 단독 이름은 쓰지 않는다.
+6. Task ID가 명확하면 `task/{task-id}-{change-slug}`, 없으면 `work/{change-slug}`를 사용한다.
+7. `git branch --list {branch}`와 `git ls-remote --heads origin {branch}`로 충돌을 확인하고, 필요하면 `-{n}` suffix를 붙인다.
+8. 현재 브랜치가 `main`/`master`이고 uncommitted 변경이 있으면 `git switch -c {branch}`로 새 브랜치를 만든다.
+9. 현재 브랜치가 `main`/`master`이고 upstream보다 앞선 local commit이 있으면 중단한다. 보존과 main 복구는 별도 승인 후 처리한다.
+10. 이미 작업 브랜치면 브랜치명이 변경 내용과 맞는지 확인하고 진행한다.
+11. 범위 밖 파일이 섞여 있지 않은지 확인한 뒤 `git add`로 stage한다.
+12. Task가 있으면 `task {task-id}: {summary}`, 없으면 `{summary}`로 commit한다.
+13. `git push -u origin {branch}` 후 `gh pr create --draft`를 실행한다.
+14. PR 본문에는 변경 요약, 검증 결과, Acceptance evidence, residual risk, 연결 이슈가 있으면 `Closes #N`을 포함한다.
 
 ## 제한
 
-- `git reset --hard`, `git checkout --`, `git push --force`, `git push --force-with-lease`는
-  실행하지 않는다.
-- `main`/`master`에 local commit이 있으면 자동 복구하지 않는다.
-- 브랜치명은 반드시 diff 내용을 근거로 만든다. 날짜, 사용자명, `wip` 단독 이름은
-  사용하지 않는다.
-- PR 생성 전 Acceptance evidence가 없으면 draft PR 본문에 미실행 사유를 명확히
-  적거나, 사용자가 요구한 경우 중단한다.
+- `git reset --hard`, `git checkout --`, `git push --force`, `git push --force-with-lease`는 실행하지 않는다.
+- 사용자 변경은 되돌리지 않는다.
+- 인증, 권한, remote 오류는 원문을 요약하고 멈춘다.
+- Acceptance evidence가 없으면 draft PR 본문에 미실행 사유를 적거나, 사용자가 요구한 경우 중단한다.

.claude/commands/branch-checkout.md

@@ -5,20 +5,10 @@ allowed-tools: Bash(git status:*), Bash(git branch:*), Bash(git switch:*), Bash(
 
 # /branch-checkout
 
-별도 작업 브랜치를 만들거나 체크아웃한다. 사용자가 지정한 브랜치명이 있으면 사용하고,
-없으면 대상 Task ID와 제목을 바탕으로 `task/{task-id}-{short-slug}` 형식을 제안한다.
+절차 원본은 `.agents/skills/branch-checkout/SKILL.md`다. 이 command는 Claude Code 호출용 wrapper다.
 
-## 절차
-
-1. `git status --short`와 `git branch --show-current`로 현재 상태를 확인한다.
-2. 변경분이 있으면 사용자 변경을 덮지 않도록 요약하고, 그대로 브랜치를 전환해도 되는지 확인한다.
-3. 필요하면 `git fetch origin`으로 원격 기준을 최신화한다.
-4. 기존 브랜치면 `git switch {branch}`를 실행한다.
-5. 새 브랜치면 기본 브랜치 기준을 확인한 뒤 `git switch -c {branch}`를 실행한다.
-6. 전환 후 현재 브랜치와 남은 변경분을 보고한다.
-
-## 주의
-
-- `git checkout --`, `git reset --hard`, 강제 push는 실행하지 않는다.
-- Task 브랜치는 `CLAUDE.md`의 GitHub 플로우에 맞춰 `task/{task-id}-{짧은-설명}`을 선호한다.
-- 인자: `$ARGUMENTS`
+1. `.agents/skills/branch-checkout/SKILL.md`를 읽고 같은 절차를 따른다.
+2. `git status --short`와 `git branch --show-current`를 먼저 확인한다.
+3. 사용자 변경은 되돌리지 않는다.
+4. `git reset --hard`, `git checkout --`, 강제 push는 실행하지 않는다.
+5. 인자: `$ARGUMENTS`

.claude/commands/git-push.md

@@ -5,20 +5,10 @@ allowed-tools: Bash(git status:*), Bash(git branch:*), Bash(git remote:*), Bash(
 
 # /git-push
 
-현재 브랜치를 원격에 push한다. push 전에 브랜치, 변경분, upstream을 확인하고
-강제 push는 하지 않는다.
+절차 원본은 `.agents/skills/git-push/SKILL.md`다. 이 command는 Claude Code 호출용 wrapper다.
 
-## 절차
-
-1. `git status --short`와 `git branch --show-current`를 확인한다.
-2. 현재 브랜치가 `main`/`master`면 push하지 말고 사용자에게 확인을 요청한다.
-3. 커밋되지 않은 변경분이 있으면 push 대상이 아님을 알리고 중단한다.
-4. upstream이 있으면 `git push`를 실행한다.
-5. upstream이 없으면 `git push -u origin {current-branch}`를 실행한다.
-6. push 결과와 다음 단계(PR 작성 여부)를 보고한다.
-
-## 주의
-
-- `--force`, `--force-with-lease`는 사용하지 않는다.
-- 인증 실패나 remote 없음은 원문 에러를 보고하고 멈춘다.
-- 인자: `$ARGUMENTS`
+1. `.agents/skills/git-push/SKILL.md`를 읽고 같은 절차를 따른다.
+2. `git status --short`와 `git branch --show-current`를 먼저 확인한다.
+3. `main`/`master` push와 커밋되지 않은 변경분 push는 중단하고 보고한다.
+4. `--force`, `--force-with-lease`는 사용하지 않는다.
+5. 인자: `$ARGUMENTS`