@uzysjung/agent-harness 26.152.0 → 26.154.0

package/templates/codex/hooks/session-start.sh

@@ -1,7 +0,0 @@
-#!/usr/bin/env bash
-# Placeholder — Phase C에서 `.claude/hooks/session-start.sh`로부터 포팅
-# stdin JSON 필드는 Claude Code와 호환 (ADR-002 v2 D5)
-# Codex event 매핑은 templates/codex/hooks/README.md 참조
-set -euo pipefail
-echo "not-yet-implemented (Phase C)" >&2
-exit 0

package/templates/codex/hooks/uncommitted-check.sh

@@ -1,7 +0,0 @@
-#!/usr/bin/env bash
-# Placeholder — Phase C에서 `.claude/hooks/uncommitted-check.sh`로부터 포팅
-# stdin JSON 필드는 Claude Code와 호환 (ADR-002 v2 D5)
-# Codex event 매핑은 templates/codex/hooks/README.md 참조
-set -euo pipefail
-echo "not-yet-implemented (Phase C)" >&2
-exit 0

package/templates/skills/clear-korean-communication/references/pre-send-checklist.md

@@ -1,37 +0,0 @@
-# Pre-send checklist
-
-Run this once against the finished draft, fix what fails, then re-check the items
-you touched. It is a self-check, not something to report — never append
-"검수했습니다" or "모든 항목을 확인했습니다" to the answer itself.
-
-## Lead and referent
-
-1. 첫 문장에 결과·현상 또는 추천이 있는가? (좌표·메커니즘으로 시작하지 않았는가)
-2. 코드를 읽지 않은 사람도 첫 문장을 이해할 수 있는가?
-3. 설명 대상과 지시 대상이 명확한가 — 같은 이름이 두 대상을 가리키지 않는가?
-4. 파일 경로·함수명이 주장보다 먼저 나오지 않는가?
-
-## Facts and evidence
-
-5. 발생 조건 · 시스템 동작 · 관찰된 결과가 서로 구분되는가?
-6. 확인된 사실 · 확인된 원인 · 해석 · 가설 · 예상 · 의견이 구분되는가?
-7. 측정하지 않은 수치나 효과를 만들지 않았는가? (없으면 "미측정"으로 표시)
-8. 영향받는 역할이 명확한가?
-9. 최종 사용자에게 직접 영향이 없는데 사용자 이득을 지어내지 않았는가?
-
-## Language
-
-10. 한국어에서 통용되지 않는 번역식 비유가 있는가?
-11. 코드나 시스템을 사람처럼 표현했는가? (의도·기억·판단을 부여하지 마라)
-12. 같은 결론을 도입부·표·결론에서 반복하지 않았는가?
-
-## Form
-
-13. 불필요한 표·ASIS→TOBE·제목·섹션을 쓰지 않았는가? (한두 문장으로 충분한 답에
-    표를 씌우는 것이 이 스킬의 가장 흔한 오용이다)
-14. 더 짧고 구체적인 문장으로 바꿀 수 있는가?
-
-## If it is a decision
-
-Additionally: 추천이 단정형인가 · 명시적 ask 가 있는가 · gap 이 정량화됐는가 ·
-추천안의 단점이 표에 있는가. 네 개 중 하나라도 없으면 Part 2 를 다시 읽어라.

package/templates/skills/clear-korean-communication/references/why-it-works.md

@@ -1,24 +0,0 @@
-# 왜 통하나 (근거, 선택적)
-
-Light support if you want to defend the format — not part of the body. Reason with
-each, don't just cite it.
-
-- **Lead with the recommendation**: BLUF (Bottom Line Up Front) — readers decide off
-  the conclusion, so the ask goes first even though it's item 2 in the four-part rule.
-- **Keep supporting reasons few (~3), one scannable table**: executive-decision-slide
-  and working-memory (~7±2) guidance — more dilutes and pushes the reader back into
-  analysis-mode. The same limit is why a referent collision has to be *drawn* rather
-  than narrated: prose makes the reader hold both objects in working memory while you
-  keep talking.
-- **Quantify the gap, list all consequences**: As-Is/To-Be gap analysis + ADR
-  (Nygard) — an unquantified or one-sided gap isn't a basis for deciding. ADR's
-  Consequences section is explicitly two-sided for the same reason.
-- **Pre-answer the objection inline**: Amazon Working Backwards PR/FAQ — collapses
-  the back-and-forth into one round. "왜 B가 아닌가" belongs in the first message,
-  not the second.
-- **Contested call? score on explicit criteria**: RICE (Intercom) — a small scoring
-  table is more defensible than prose advocacy, and it makes the override visible
-  when judgment beats the score.
-
-None of these outrank Step 1. A perfectly BLUF-formatted message about an ambiguous
-referent still fails — that is the observed case this skill was built from.

package/templates/skills/clear-korean-communication/references/worked-examples.md

@@ -1,89 +0,0 @@
-# Worked examples
-
-Two complete walkthroughs. The first repairs a failing *explanation* (Part 1);
-the second renders a *decision* (Part 2). Read the one that matches the message
-you are about to send.
-
----
-
-## 1. Explain — a failing draft, diagnosed and repaired
-
-**Input** (the failing draft): *"`update-mode.ts:53-78` の targets array lists
-rules/agents/commands/hooks. `skills` is absent, and `install-render.ts:431`
-iterates `updated`, so no row renders."*
-
-Every clause is true, and it does not land.
-
-**Diagnosis, in the order of Steps 1–4**
-
-| Step | Question | Verdict on this draft |
-|---|---|---|
-| 1 | Does a name point at two things? | Yes — `.claude/` means *this repo* and *the installed project*. The writer holds both; the reader cannot tell which is broken. |
-| 2 | Does it lead with who + what changes? | No — it opens with a coordinate (`update-mode.ts:53-78`). |
-| 3 | Is the evidence before or after the claim? | Before. There is no claim yet. |
-| 4 | What did the reader actually ask? | *"is this about installing, or about the project directory?"* → symptom row 1 = referent collision. |
-
-**Output** (after the diagnostic):
-
-> There are two `.claude/` directories, and I mixed them:
->
-> ```
-> ① this repo (we build here)    ② someone's project (installed here)
->    templates/skills/  ──npm──▶    .claude/skills/
-> ```
->
-> **The problem, in one sentence:** in ②, skills installed once never change
-> again, no matter how many times the user runs update.
->
-> Update refreshes rules, agents, commands, and hooks — but skills were left out
-> of that list, and the summary screen only prints directories that were
-> touched. So nothing on screen said anything was skipped.
->
-> Evidence: `update-mode.ts:53-78` (the target list), `install-render.ts:431`
-> (the render loop).
-
-Same facts, same precision, three lines to comprehension. Note what did **not**
-change: no softer tone, no shorter sentences, no "user perspective" rewrite. The
-repair was separating one name into two named things and putting the claim first.
-
----
-
-## 2. Decide — the four slots with a quantified gap
-
-**Input** (what you're tempted to send): *"The compat checker re-validates every
-asset on each run and it's gotten slow. I could cache results. Want me to?"*
-
-That is a decision hidden inside a status update. The reader has to reconstruct
-the options, the cost, and the ask.
-
-**Output** (the format):
-
-> **추천 + 이유:** `gen-compatibility` 의 검증 결과를 콘텐츠 해시 기준으로 캐싱하도록
-> 바꾸겠습니다 — 변경분만 재검증해 시간을 가장 크게 줄이고 CI 코어 변동에도 안정적이라.
-> **승인해 주세요 — 아니면 B(캐시 없이 병렬화만)도 가능합니다.**
->
-> **전후맥락:** 자산이 52개로 늘면서 매 실행마다 전 자산 재검증 → CI `gen-compat`
-> 스텝이 느려짐. 자산 내용은 거의 안 바뀌는데 매번 풀 재검증하는 게 병목.
->
-> | 항목 | ASIS (현재) | TOBE (제안: 해시 캐싱) | Gap |
-> |------|-------------|------------------------|-----|
-> | 전체 검증 시간 | ~140s (52자산 전수) | ~12s (변경분만) | **-128s / 실행** |
-> | 캐시 미스 시 | — | 풀 재검증 폴백 | 정확성 손실 0 |
-> | 추가 코드 | 없음 | 캐시 read/write + 무효화 (~40줄) | 유지보수 +α |
-> | 트레이드오프 | — | 해시 충돌 시 stale 위험 | 무효화 키 = 파일내용 해시로 차단 |
->
-> *왜 B(병렬화만)가 아닌가:* 병렬화는 시간을 ~3배만 줄이고(약 45s) 코어 수에 의존 —
-> 캐싱이 변경분만 검증해 더 크게(11배) 줄이고 CI 코어 변동에도 안정적이라 A 추천.
->
-> 승인 시 → feature 브랜치에서 캐시 레이어 + 무효화 테스트 추가 → 로컬 `npm run ci`
-> 통과 → PR.
-
-Notice: the user can say "go" after the first two lines, or push back on exactly
-one cell of the table. No essay, no buried recommendation, no hidden downside —
-the stale-cache risk is in the table, not omitted to make the proposal look
-cleaner.
-
-**The numbers are the point.** "느려짐 → 빨라짐" would have carried the same
-argument with none of the basis for deciding: ~140s → ~12s, -128s per run, 11×,
-and the rejected alternative's own number (~45s) are what let the reader judge
-the trade instead of trusting the recommender.