@kaydash9999/banker-plugins 0.13.0 → 0.14.0

package/skills/all-in-one/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: all-in-one
-description: "(banker) 한 명령으로 합의 계획→검증 구현→독립 테스트 게이트를 연쇄(ralplan→ralph→ultraqa). 코딩 작업을 계획부터 통과까지 최대 rigor로 한 번에. 'all-in-one'/'all in one' 시 사용(한 줄 수정은 ralph, 아이디어 확장은 autopilot)."
+description: "(banker) 한 명령으로 합의 계획→검증 구현→독립 QA 게이트를 연쇄(ralplan→ralph→QA 게이트: Claude Code는 verify 순환, Codex는 ultraqa). 코딩 작업을 계획부터 통과까지 최대 rigor로 한 번에. 'all-in-one'/'all in one' 시 사용(한 줄 수정은 ralph, 아이디어 확장은 autopilot)."
 argument-hint: "[--short] [--checkpoint] [--critic=critic|architect|codex] [--qa=tests|build|lint|typecheck] [--no-deslop] <task description>"
 level: 4
 ---
@@ -9,18 +9,40 @@ level: 4
 
 [ALL-IN-ONE ACTIVATED — SEQUENTIAL 3-STAGE PIPELINE]
 
-## 0. Prerequisite: OMC (install first if missing)
-
-This skill orchestrates OMC's `ralplan` → `ralph` → `ultraqa`. **Check the dependency before running**; if it is missing, **guide installation first** rather than failing mid-pipeline:
-- Check: `command -v omc` and whether `/oh-my-claudecode:*` skills are available.
-- If missing: install via `/banker:setup` → oh-my-claudecode (or the `setup-omc` skill / `omc update`), then resume. On Codex the equivalent is OMX (`omx setup`).
-
-**런타임 매핑 (Claude Code ↔ Codex).** 이 스킬이 부르는 `ralplan`·`ralph`·`ultraqa`는 Claude Code에선 OMC 스킬이고 **Codex에선 oh-my-codex(OMX)가 제공하는 동명 스킬**이다. 아래 Execution의 `Skill("oh-my-claudecode:<name>")` 표기는 Claude Code 기준 — **Codex 런타임에선 OMC 대신 OMX의 해당 스킬(`ralplan`/`ralph`/`ultraqa`)을 적용**한다.
+## 0. Prerequisite: OMC 5 with a matching `omc` CLI (check first)
+
+This skill orchestrates OMC's `ralplan` → `ralph`, then a QA gate built on OMC's
+`verify` workflow. **Check the dependency before Stage 1**; if it is missing or
+stale, **guide installation first** rather than failing mid-pipeline. The `omc`
+check below is for Claude Code; on Codex check OMX instead (`omx --version`), whose
+`ralph` does not use the `omc` CLI.
+
+- **The `omc` CLI must have `ralph verify` (Claude Code).** OMC 5's `ralph` runs
+  `omc ralph verify` on its first iteration and stops when the command is
+  missing, and a global `omc` CLI older than the plugin (4.x) does not have it.
+  Judge by the output, not the exit code: given `--help`, a 4.x CLI prints its
+  general help and still exits 0. Keep the `--help`: without it, an unknown
+  command makes the CLI launch Claude Code.
+  ```bash
+  omc ralph verify --help 2>&1 | grep -q 'Usage: omc ralph verify' && echo "omc ok" || echo "omc CLI missing or too old"
+  ```
+  ```powershell
+  if ((omc ralph verify --help 2>&1 | Out-String) -match 'Usage: omc ralph verify') { 'omc ok' } else { 'omc CLI missing or too old' }
+  ```
+- **If the check fails:** stop before Stage 1 and guide the fix (`/banker:setup`
+  → oh-my-claudecode, the `setup-omc` skill, or
+  `npm install -g oh-my-claude-sisyphus@latest`), then resume. Do not start a
+  pipeline whose Stage 2 will stop.
+- **`ultraqa` does not exist in OMC 5** (removed in 5.0.0, no alias), so a call
+  to `oh-my-claudecode:ultraqa` fails. Stage 3 below runs in its place.
+- On Codex the equivalent framework is OMX (`omx setup`).
+
+**런타임 매핑 (Claude Code ↔ Codex).** Stage 1·2 의 `ralplan`·`ralph` 는 Claude Code에선 OMC 스킬이고 **Codex에선 oh-my-codex(OMX)가 제공하는 동명 스킬**이다. Stage 3 은 런타임마다 다르다: Claude Code(OMC 5)는 `ultraqa` 가 없어 아래 verify 순환을 직접 돌리고, **Codex는 OMX 가 아직 제공하는 `ultraqa`** 를 쓴다. 아래 `Skill("oh-my-claudecode:<name>")`·`Task(subagent_type="oh-my-claudecode:<name>")` 표기는 Claude Code 기준이다.
 
 ## Purpose
 
 Run one substantial coding task through three independent quality gates in a
-fixed order, each delegated to an existing OMC skill:
+fixed order:
 
 ```
 Stage 1  /ralplan --deliberate     consensus plan (Planner → Architect → Critic)
@@ -29,15 +51,18 @@ Stage 1  /ralplan --deliberate     consensus plan (Planner → Architect → Cri
 Stage 2  /ralph --critic=critic    PRD-driven persistent build, critic-verified
    │     → implementation + deslop + regression, then ralph self-cancels
    ▼
-Stage 3  /ultraqa --tests          independent test-cycling acceptance gate
-         → PASS, or honest STOPPED-with-diagnosis
+Stage 3  QA gate (--qa=tests)      fresh verifier → diagnose → fix, bounded cycle
+         → PASS, or honest STOPPED-with-diagnosis   (Codex: OMX /ultraqa)
 ```
 
 This skill is a **thin sequential orchestrator**. It does not implement, plan,
-or test directly, and it does **not** create its own persistence loop or state
-file — every loop, retry, and verification belongs to the sub-skill it
-delegates to. Its only job is to invoke the three skills in order, bridge their
-handoffs, gate each stage on the previous one's success, and report honestly.
+or test directly, and it does **not** create its own state file. Stages 1 and 2
+hand every loop, retry, and verification to the sub-skill they invoke. The one
+loop all-in-one owns is Stage 3's bounded verify → fix cycle: OMC 5 removed
+`ultraqa`, which used to own it, and its replacement `verify` gathers evidence
+but does not fix. Beyond that, its only job is to run the stages in order,
+bridge their handoffs, gate each stage on the previous one's success, and
+report honestly.
 
 ## Why three stages (and not just ralph)
 
@@ -50,23 +75,24 @@ modes, and each stage's reviewer is independent of the previous stage's author
 2. **A partial or unverified build declared "done"** → Stage 2's PRD
    story-by-story persistence + critic verification catch this.
 3. **Integration / regression breakage slipping past the builder's own checks**
-   → Stage 3's fresh, test-focused, fix-cycling loop catches this.
+   → Stage 3's fresh, test-focused, fix-cycling gate catches this.
 
 **On the apparent redundancy of Stage 3:** ralph (Stage 2) already runs its own
-Step-7 critic verification and Step-7.6 regression re-run on the changed-file
-set. ultraqa (Stage 3) is still worth running because it is *independent* (fresh
-agents, not the ones that built it), *test-suite-focused*, and *actively fixes*
-in a cycle. If ralph's regression already ran the full suite green, ultraqa
-usually confirms in cycle 1 (cheap); its value rises when the suite is broad,
-when changes touched many files, or when integration/flaky issues hide behind
-unit-level checks. Keeping it explicit gives a clean, separate PASS signal.
+Step-7 reviewer verification and Step-7.6 regression re-run (`omc ralph verify`
+against the baseline it recorded). Stage 3 is still worth running because it is
+*independent* (a fresh verifier agent, not the context that built the change),
+*test-suite-focused*, and *actively fixes* in a bounded cycle. If ralph's
+regression already ran the suite green, the gate usually passes in cycle 1
+(cheap); its value rises when the suite is broad, when changes touched many
+files, or when integration/flaky issues hide behind unit-level checks. Keeping
+it explicit gives a clean, separate PASS signal.
 
 ## When to use
 
 - A substantial, mostly-specified coding task you want carried from plan →
   verified implementation → green test gate in one step, with the most
   front-loaded rigor OMC offers.
-- You have been running `ralplan → ralph → ultraqa` by hand and want it as one
+- You have been running `ralplan → ralph →` a QA pass by hand and want it as one
   command.
 - The task is moderately under-specified — that's fine: Stage 1's consensus
   planning absorbs scoping, so all-in-one tolerates vaguer input than raw ralph.
@@ -75,8 +101,9 @@ unit-level checks. Keeping it explicit gives a clean, separate PASS signal.
 
 - **One-line fix or tiny change** → use `/ralph` or delegate to an executor;
   three heavy multi-agent loops is overkill.
-- **Pure exploration / brainstorming** → use `/oh-my-claudecode:plan` or the
-  brainstorming skill; nothing should be implemented yet.
+- **Pure exploration / brainstorming** → use `/oh-my-claudecode:ralplan` on its
+  own (it stops at a `pending approval` plan) or the brainstorming skill;
+  nothing should be implemented yet.
 - **A 2-3 line product idea needing requirements expansion** → use
   `/autopilot` (it expands the idea first) or `/deep-interview`.
 - **Frontend spec / reference-parity work** → use the specialized `/front-qa`.
@@ -88,7 +115,7 @@ unit-level checks. Keeping it explicit gives a clean, separate PASS signal.
 | `--short` | Stage 1 runs ralplan **without** `--deliberate` (skips pre-mortem + expanded test plan) for lower-risk work | off → deliberate |
 | `--checkpoint` | Insert an `AskUserQuestion` approval gate between Stage 1 (plan) and Stage 2 (implement) | off → auto-proceed |
 | `--critic=critic\|architect\|codex` | Reviewer passed to ralph's verification | `critic` |
-| `--qa=tests\|build\|lint\|typecheck` | Goal passed to ultraqa in Stage 3 | `tests` |
+| `--qa=tests\|build\|lint\|typecheck` | What the Stage 3 gate checks (Codex: the goal passed to ultraqa) | `tests` |
 | `--no-deslop` | Passed through to ralph (skip the post-review deslop pass) | off |
 
 Everything before the flags / after them that isn't a recognized flag is the
@@ -118,6 +145,21 @@ then **stops**.
   `APPROVE`): do not auto-proceed. Surface the best plan and ask the user how to
   proceed. Never build on an unapproved plan.
 
+### Before Stage 2 — record what already fails
+
+Run the command(s) of the `--qa` goal once on the unchanged tree and keep the
+failing items (test names, error lines) in this conversation. This
+**pre-change record** is the gate's baseline: it covers checks that are not
+among ralph's feedback commands, and on Codex it is the only baseline there is
+(OMX `ralph` keeps none). Never use `git stash` or `git reset` to get a
+pre-change state for it; if the tree already has changes, take the record from
+a clean copy of HEAD (`git worktree add --detach <tmp> HEAD`, run there, then
+`git worktree remove <tmp>`). A fresh worktree has no installed dependencies
+(`node_modules`, a venv): link or install them there first, and confirm the
+commands really ran — a record made only of "command not found" errors is no
+baseline. The record lives only in this conversation; if the session may
+compact or end before Stage 3, put it in the `ready-compact` note.
+
 ### Stage 2 — Implement: `/ralph`
 
 Precondition: a consensus plan exists and is approved (auto via the invocation,
@@ -131,33 +173,93 @@ its job is to turn the plan's stages into PRD stories and implement + verify
 them, not to re-plan. (This mirrors how autopilot consumes a ralplan plan and
 skips its own planning phase.)
 
-ralph runs its full loop on its own: PRD refinement → implement per story →
-verify acceptance criteria → Step-7 critic verification → Step-7.5 deslop →
-Step-7.6 regression → Step-8 `/oh-my-claudecode:cancel`.
+ralph runs its full loop on its own: feedback baseline (`omc ralph verify
+--write-baseline`) → PRD refinement → implement per story → verify acceptance
+criteria → Step-7 reviewer verification → Step-7.5 deslop → Step-7.6 regression
+→ Step-8 closeout and `/oh-my-claudecode:cancel`.
 
-> ralph's Step-8 cancel clears **ralph/ultrawork** session state — it ends the
+> ralph's Step-8 cancel clears **ralph's own** session state — it ends the
 > IMPLEMENTATION stage, not all-in-one. all-in-one is not a registered OMC mode,
 > so the cancel does not affect it. Let ralph fully finish (reviewer APPROVE +
-> deslop + regression + cancel) **before** Stage 3 — ralph and ultraqa share
-> mutually-exclusive session state, so they must not overlap.
-
+> deslop + regression + cancel) **before** Stage 3, so the gate checks the final
+> tree and no ralph continuation is still steering the session.
+
+- **Settle ralph's questions up front.** ralph 5.6.1 asks the user once for the
+  PRD's `repoQualityClass` (`prototype`, `production` or `library`) when the task
+  does not say. Infer it from repo signals (CI config, test depth, published
+  package metadata) and put it in the handoff; let ralph ask only when the
+  signals conflict.
+- **Give ralph feedback commands that print only failures.** OMC 5.6.1's
+  `omc ralph verify` fingerprints *every* output line of each feedback command,
+  and normalizes only durations written as `<number><unit>`, timestamps, `/tmp`
+  paths and hex ids. A line that changes between runs or when a story adds
+  tests therefore reads as a NEW failure: node:test's default reporter prints
+  `ℹ duration_ms 151.4` and `ℹ tests 8`, so its gate fails on every run with no
+  change at all. In the handoff, tell ralph to set the PRD's `feedbackCommands`
+  **before it records the baseline** to forms whose output is constant on
+  success and names each failure — for node:test,
+  `FORCE_COLOR=0 NODE_NO_WARNINGS=1 node --test --test-reporter=dot 2>&1 | grep -Ev '^[.X]+$'`
+  (the two variables keep color codes from slipping past the filter and
+  warnings with a process id out of the output; adapt the form on Windows);
+  keep build/lint commands that are silent on success. If the gate still flags
+  only such lines, fix the commands and re-record ralph's baseline on the
+  current tree (`omc ralph verify --write-baseline`) — the pre-change record
+  still tells old failures from new ones. Never edit the baseline file by
+  hand; never stash or reset.
+- **Carry the baseline forward.** ralph's own baseline (first iteration) also
+  lists failures that existed before the change; ralph treats them as noise
+  and reports them at Step 8. Note its session id (the `<id>` in its PRD path
+  `.omc/state/sessions/<id>/`) for Stage 3.
 - **If ralph reports a fundamental blocker** (same issue across 3+ iterations,
-  missing credentials, unclear requirement, external dependency down): stop and
-  report. Do **not** run Stage 3 on a broken or partial build and call it done.
-
-### Stage 3 — QA gate: `/ultraqa`
-
-Precondition: Stage 2's ralph has completed and self-cancelled (no session-state
-overlap).
-
-Invoke `Skill(oh-my-claudecode:ultraqa)` with args `--<qa goal>` (default
-`--tests`). ultraqa cycles run-QA → architect-diagnose → executor-fix → repeat
-(max 5; early-exit if the same failure appears 3×).
+  missing credentials, unclear requirement, external dependency down, or the
+  `omc ralph verify` command unavailable): stop and report. Do **not** run
+  Stage 3 on a broken or partial build and call it done.
+
+### Stage 3 — QA gate
+
+Precondition: Stage 2's ralph has completed and self-cancelled.
+
+**Claude Code (OMC 5):** run the bounded cycle that `ultraqa` used to own —
+the same shape as OMC 5's autopilot QA phase. No state file: the cycle count
+lives in this conversation.
+
+1. **Verify, independently.** `Task(subagent_type="oh-my-claudecode:verifier", ...)`
+   — a fresh context that did not build the change. Brief it to follow the
+   `oh-my-claudecode:verify` workflow for the `--qa` goal (`tests` by default;
+   `build`, `lint` or `typecheck` select that check), run the project's real
+   commands, and return **PASS** or **FAIL** with the commands, their output and
+   each failing item.
+   Whether a failure predates the change is not judged by eye. A failure is
+   **pre-existing only** when the pre-change record lists it, or — Claude
+   Code — when `omc ralph verify --session <ralph's session id> --json` leaves
+   it out of `newFailures` (cancel leaves the baseline in place; check that the
+   JSON reports `baselinePresent: true` — without a baseline it reports every
+   current failure as new). **Everything else is new**, and so is a
+   pre-existing failure that points at a file the change touched (as in ralph).
+   If ralph was run again in this session (a resumed run), its first iteration
+   rewrote that baseline on the half-changed tree; then judge by the
+   pre-change record alone.
+2. **PASS** → the gate is met; go to the final report.
+3. **FAIL** → `Task(subagent_type="oh-my-claudecode:architect", ...)` diagnoses
+   the root cause (read-only), then `Task(subagent_type="oh-my-claudecode:executor", ...)`
+   makes the smallest fix inside the change's scope. The next cycle verifies
+   again with a **fresh** verifier, never the one that saw the failure.
+
+Limits: at most 5 verifications. When the 5th still fails, stop without
+another fix (a fix nobody verified is not a result). Stop early when the same
+failure (same test, same error signature) comes back 3 times — that is a
+fundamental problem for the user, not for another cycle. Never fix a baseline
+failure inside this gate; report it.
+
+**Codex (OMX):** run OMX `$ultraqa` with the goal (OMX still ships it). OMX
+keeps no feedback baseline, so hand it the pre-change record, tell it not to
+fix those failures, and report them apart; treat its outcome the same way.
 
 Report the real outcome:
 - **Goal met** → "ALL-IN-ONE COMPLETE" with the cycle count.
-- **Max cycles / same failure 3×** → "STOPPED" with ultraqa's diagnosis. Do
-  **not** claim success if the gate did not reach goal-met.
+- **5 failed verifications / same failure 3×** → "STOPPED" with the verifier's
+  evidence and the architect's diagnosis. Do **not** claim success if the gate did not reach
+  goal-met.
 
 ## Orchestrator rules
 
@@ -165,8 +267,8 @@ Report the real outcome:
   next begins. No skipping, no reordering, no running two stages' loops at once.
 - Emit one clear progress line at each stage boundary so the user always knows
   where the pipeline is (`[all-in-one] Stage 1/3 — planning…`, etc.).
-- Do not add a competing persistence loop or all-in-one-specific state file; the
-  sub-skills own all looping and state.
+- Do not add an all-in-one state file or a second persistence loop. Stages 1–2
+  own their loops and state; Stage 3's bounded cycle is the only loop here.
 - Treat a sub-skill's internal "stop"/"cancel" as the end of *that stage*, never
   as the end of the pipeline (see the Stage 1 and Stage 2 notes above).
 
@@ -178,7 +280,8 @@ When the pipeline ends (complete or stopped), give a concise honest summary:
   (1 line).
 - **Implementation**: stories/stages completed, files changed, the ralph critic
   verdict.
-- **QA**: ultraqa goal, PASS after N cycles or STOPPED-with-diagnosis.
+- **QA**: the gate's goal, PASS after N cycles or STOPPED-with-diagnosis, and
+  the baseline failures that predate the change, listed apart.
 - **Unmet / scope-limited / deferred**: state plainly — never paper over a gate
   that did not pass.
 
@@ -205,21 +308,23 @@ first to expand it into a spec.
 
 ## Stop conditions
 
+- The `omc` CLI check in §0 fails → guide the install/update; do not start.
 - Stage 1 cannot reach consensus → surface best plan, ask the user (don't build).
 - Stage 2 ralph hits a fundamental blocker → stop and report (don't run QA).
-- Stage 3 ultraqa exhausts cycles / repeats a failure 3× → report the diagnosis
-  honestly (don't claim success).
+- Stage 3 fails its 5th verification / sees the same failure 3× → report the
+  diagnosis honestly (don't claim success).
 - User says "stop" / "cancel" / "abort" at any point → run
   `/oh-my-claudecode:cancel` and stop.
 
 ## Final checklist
 
+- [ ] §0: on Claude Code the `omc` CLI answered `omc ralph verify --help` with its usage (Codex: `omx --version`)
 - [ ] Stage 1 produced a consensus plan in `.omc/plans/` (or stopped honestly on
       no-consensus / checkpoint rejection)
 - [ ] Stage 2 received the plan path, completed all PRD stories, passed critic
       verification, and self-cancelled before Stage 3
-- [ ] Stages did not overlap (ralph fully ended before ultraqa began)
-- [ ] Stage 3 ran the chosen QA goal and reached goal-met (or reported STOPPED
-      with diagnosis)
+- [ ] Stages did not overlap (ralph fully ended before the gate began)
+- [ ] Stage 3: a fresh verifier reported the chosen goal met (or STOPPED with
+      diagnosis); baseline failures reported apart, not fixed
 - [ ] Final report states plan/implementation/QA outcomes and any unmet items
       plainly

package/skills/compact-copy/SKILL.md

@@ -1,17 +1,18 @@
 ---
 name: compact-copy
-description: "(banker) /ready-compact resume 프롬프트에서 코드펜스 본문만 뽑아 최종 메시지를 '프롬프트-only'로 출력(response.md 기록 → /copy로 클립보드에 담김). 'compact-copy'/'프롬프트만 복사'/'resume 프롬프트만' 시 사용."
+description: "(banker) 코드펜스로 감싼 resume 프롬프트(이전 형식 ready-compact 출력 등)에서 본문만 뽑아 최종 메시지를 '프롬프트-only'로 출력(response.md 기록 → /copy로 클립보드에 담김). 지금의 ready-compact 는 처음부터 프롬프트만 출력하므로 보통은 필요 없음. 'compact-copy'/'프롬프트만 복사'/'resume 프롬프트만' 시 사용."
 ---
 
 # compact-copy — resume 프롬프트만 추출 복사
 
-`/ready-compact` 출력은 「설명 + 코드펜스(resume 프롬프트) + 설명」 형태다. `/copy` 는 그
-**직전 어시스턴트 메시지 전체**를 클립보드와 `/tmp/claude-<uid>/response.md` 에 복사하므로
-설명까지 함께 담긴다. 이 스킬은 **코드펜스 안 프롬프트 본문만** 남겨, 파일과(이어지는 `/copy`
-로) 클립보드에 프롬프트-only 가 담기게 한다.
+`/ready-compact` 는 0.14.0 부터 **프롬프트 본문만** 출력하므로(`[RESUME]`/`[HANDOFF]`), 바로 `/copy` 하면 된다.
+이 스킬은 그 밖의 경우, 곧 「설명 + 코드펜스(resume 프롬프트) + 설명」 형태의 출력(0.13.0 이전 ready-compact,
+다른 도구가 낸 resume 프롬프트)에서 프롬프트만 뽑을 때 쓴다. `/copy` 는 **직전 어시스턴트 메시지 전체**를
+클립보드와 `/tmp/claude-<uid>/response.md` 에 복사하므로 설명까지 함께 담긴다. 이 스킬은 **코드펜스 안
+프롬프트 본문만** 남겨, 파일과(이어지는 `/copy` 로) 클립보드에 프롬프트-only 가 담기게 한다.
 
 ## 언제 쓰나
-- `/ready-compact` 로 resume 프롬프트를 만든 직후, 그 **프롬프트만** 복사하고 싶을 때.
+- 설명과 코드펜스가 섞인 resume 프롬프트 출력에서 그 **프롬프트만** 복사하고 싶을 때(지금의 `/ready-compact` 출력은 이미 프롬프트만이라 해당 없음).
 - `/copy` 로 전체를 저장한 뒤(response.md), 프롬프트만 남기고 싶을 때.
 
 ## 쓰지 않을 때
@@ -29,10 +30,10 @@ description: "(banker) /ready-compact resume 프롬프트에서 코드펜스 본
 ## 워크플로우
 
 ### 1) 프롬프트 본문 확보 (우선순위)
-1. **1순위 — 직전 컨텍스트**: 방금 이 대화에서 `/ready-compact` 로 resume 프롬프트(코드펜스
-   안 `[RESUME]…`)를 만들었다면 **그 본문을 그대로** 쓴다(가장 신선·정확).
+1. **1순위 — 직전 컨텍스트**: 방금 이 대화에서 resume 프롬프트(`[RESUME]…` 또는 `[HANDOFF]…`, 코드펜스
+   유무 무관)를 만들었다면 **그 본문을 그대로** 쓴다(가장 신선·정확).
 2. **폴백 — response.md(신선할 때만)**: 1순위가 없으면 `/tmp/claude-$(id -u)/response.md`
-   를 읽어 **첫 코드펜스 블록의 본문**을 추출한다. 블록이 여럿이면 `[RESUME]` 로 시작하는 블록
+   를 읽어 **첫 코드펜스 블록의 본문**을 추출한다. 블록이 여럿이면 `[RESUME]`·`[HANDOFF]` 로 시작하는 블록
    우선, 없으면 가장 큰 블록. ⚠️ `/ready-compact` 와 이 스킬 사이에 `/copy` 가 없었다면
    response.md 는 **stale**(과거 내용)일 수 있다 → 본문이 resume 프롬프트가 맞는지 확인하고,
    아니면 사용자에게 알리고 멈춘다.
@@ -43,18 +44,18 @@ description: "(banker) /ready-compact resume 프롬프트에서 코드펜스 본
 
 ### 3) 클립보드 — 메시지 셰이핑 (★ 핵심 불변식)
 - 이 스킬의 **최종 어시스턴트 메시지는 프롬프트 본문 그 자체만** 출력한다.
-- **외곽 코드펜스로 감싸지 말 것** — ready-compact 템플릿은 프롬프트를 펜스로 감싸지만
-  compact-copy 는 **감싸지 않는다**(펜스째 복사되면 붙여넣기가 오염된다).
+- **외곽 코드펜스로 감싸지 말 것** — 펜스째 복사되면 붙여넣기가 오염된다(지금의 ready-compact 도
+  같은 이유로 펜스 없이 출력한다).
 - **앞뒤 설명·보고를 같은 메시지에 넣지 말 것** — `/copy` 가 그 설명까지 통째로 복사한다.
   파일 기록·상태 확인은 **프롬프트를 내보내기 전**(도구 호출 단계)에 끝내고, 메시지에 마지막으로
   남는 것은 프롬프트뿐이게 한다.
 - 이후 사용자는 **`/copy` 한 번**으로 클립보드에 프롬프트-only 를 담는다(response.md 는 이미
-  프롬프트-only). 흐름: `/ready-compact` → `/compact-copy` → `/copy`.
+  프롬프트-only). 흐름: 설명이 섞인 출력이면 `/compact-copy` → `/copy`. 지금의 `/ready-compact` 출력이면 `/copy` 만으로 충분하다.
 
 ## 검증 (셀프체크)
 - response.md 가 **프롬프트 본문만** 담는가(설명·표·외곽 펜스 없음)?
 - 최종 메시지가 프롬프트와 동일하고 **외곽 펜스/전후 설명이 없는가**?
-- 프롬프트가 `[RESUME]` 로 시작하며 ready-compact 원문과 **내용 동일**한가(추출 변형 없음)?
+- 프롬프트가 `[RESUME]` 또는 `[HANDOFF]` 로 시작하며 원문과 **내용 동일**한가(추출 변형 없음)?
 - 경로를 `id -u` 로 계산했는가(**uid 숫자 하드코딩 금지**)?
 
 ## 함정

package/skills/curation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: curation
-description: "(banker) 의사결정을 {선택지·권고안·근거·확신수준(0.00~1.00)·확신근거}로 구조화해 제시. --perf는 결과물 품질·완성도를 효율보다 우선. 'curation'/'큐레이션'/'결정 정리'/'선택지 정리' 시 사용."
+description: "(banker) 의사결정을 {선택지·권고안·근거·확신수준(0.00~1.00)·확신근거}로 구조화해 제시. --perf는 결과물 품질·완성도를 효율보다 우선. --deep은 --perf에 더해 확신 0.80 이하 결정을 추가 조사·검토해 0.80 초과로 끌어올린 뒤 제시(끝내 못 넘으면 확신 미달로 표시하고 사용자 질문으로 전환). 'curation'/'큐레이션'/'결정 정리'/'선택지 정리' 시 사용."
 ---
 
 # curation — 결정 큐레이션 (선택지·권고·확신)
@@ -9,7 +9,8 @@ description: "(banker) 의사결정을 {선택지·권고안·근거·확신수
 "그냥 골라주기"가 아니라 **선택지 → 권고 → 근거 → 확신수준 → 확신 근거**를 명시해,
 사용자가 권고를 검증·재정(裁定)할 수 있게 한다.
 
-**런타임:** 이 스킬은 외부 도구·프레임워크 의존이 **전혀 없다**(순수 출력 규약).
+**런타임:** 이 스킬은 외부 도구·프레임워크 의존이 **전혀 없다**(기본·`--perf` 는 순수 출력 규약).
+`--deep` 은 그 런타임에 이미 있는 조사 수단(파일 읽기, 셸, 웹 검색, 하위 에이전트)을 쓰지만 별도 설치는 필요 없다.
 Claude Code(OMC)·Codex CLI(OMX) 양쪽에서 **동일하게** 동작한다.
 
 ## 언제 쓰나
@@ -54,6 +55,29 @@ Claude Code(OMC)·Codex CLI(OMX) 양쪽에서 **동일하게** 동작한다.
 `--perf`는 **후자(품질)로 기운다**. 권고 근거·확신근거에 이 기준이 어떻게 작용했는지 드러낸다.
 (기본 curation은 노력·품질·시간을 **균형** 있게 저울질한다.)
 
+## --deep (품질 우선 + 확신 하한)
+`curation --deep` 은 `--perf` 처럼 동작하되(위 채택 기준 포함), **확신수준이 0.80 이하인 결정을 그대로 내놓지 않는다.**
+조사와 검토를 충분히 더 해서 확신을 **0.80 초과**로 올린 뒤 제시한다.
+
+- **경계**: 0.80 이하 = 추가 조사 대상, 통과 = 0.80 초과. 0.80 정각도 조사 대상이다
+  ("0.80 이하이면 더 조사"와 "0.80 이상이 되도록"을 함께 만족하는 해석).
+- `--deep --perf` 는 `--deep` 과 같다.
+
+### 절차
+1. 모든 결정을 `--perf` 기준으로 1차 큐레이션하고 확신수준을 매긴다.
+2. 0.80 이하인 결정마다 **확신을 막는 변수**를 적는다. 무엇을 확인하면 확신이 오르거나 내리는가.
+3. 그 변수를 직접 겨냥해 **조사**와 **검토**를 한다.
+   - 조사: 저장소의 코드·설정·이력, 공식 문서와 1차 자료, 웹 검색(런타임에 있을 때), 안전한 재현·측정(읽기 전용 명령, 임시 디렉터리 실험).
+   - 검토: 권고에 가장 강하게 맞서는 선택지를 최선의 형태로 세워 반박해 본다. 가능하면 독립 검토자(읽기 전용 하위 에이전트 등)에게 권고와 근거를 넘겨 반론을 받는다.
+4. 새 증거로 권고안·근거·확신수준을 **다시 산정**한다. 증거가 권고를 뒤집으면 권고를 바꾼다. 확신 숫자만 올리지 않는다.
+5. 0.80 초과가 될 때까지 3~4를 반복한다. **결정마다 최대 3회차**이고, 새 증거가 나오지 않은 회차가 생기면 그 결정의 조사를 멈춘다.
+6. 그래도 0.80 이하로 남은 결정은 **확신을 부풀리지 않는다.** "확신 미달"로 표시하고, 남은 변수를 사용자가 답할 수 있는 질문(가능하면 선택형)으로 바꿔 함께 제시한다. 답을 받으면 그 결정만 다시 산정한다.
+
+### 출력 추가
+- 결정마다 **조사 이력**을 붙인다: 회차별로 확인한 것(출처·명령·파일), 그 결과, 확신 변화(예: `0.65 → 0.84`).
+- 처음부터 0.80 을 넘은 결정은 "추가 조사 불필요"로 한 줄만 남긴다.
+- 표 형식이면 `조사 이력` 열을 추가하고, 길면 표 아래에 결정 번호별로 적는다.
+
 ## 적용 범위
 - 호출 시점의 **현재 작업/요청에 걸린 결정들**에 이 형식을 적용한다.
 - 이후에도 같은 작업 맥락에서 결정이 나오면 형식을 유지한다(사용자가 바꾸라기 전까지).
@@ -71,10 +95,19 @@ Claude Code(OMC)·Codex CLI(OMX) 양쪽에서 **동일하게** 동작한다.
 - **확신수준**: 0.75
 - **확신수준 근거**: 질의·집계 요구가 확실하면 SQLite 우위가 뚜렷(↑). 단 로그량·배포 환경(임베디드 등)이 미확인이면 파일이 나을 여지(↓). `--perf`라 "싸고 대충"인 파일보다 완성도 높은 SQLite로 기울였다.
 
+**같은 질문을 `curation --deep` 으로 부르면**, 0.75 는 0.80 이하이므로 멈추지 않고 조사를 더 한다:
+- **확신을 막는 변수**: 로그량, 배포 환경, 질의 요구.
+- **조사 이력**:
+  - 1회차: 배포 설정과 기존 로그 코드 확인 → 서버 배포(임베디드 아님), 하루 약 2만 건, 대시보드가 기간별 집계를 요구 → `0.75 → 0.83`.
+  - 검토: 가장 강한 반대안(파일 + 회전, 집계는 배치)을 세워 봤으나 동시쓰기 내구성과 질의 요구를 못 넘음 → 권고 유지.
+- **확신수준**: 0.83 (0.80 초과라 제시)
+
 ## 함정
 - **선택지 억지 금지** — 결정이 없는데 형식을 씌우지 말 것.
 - **권고는 선택지 안에서** — 제3의 절충안을 슬쩍 끼우면 감사 가능성이 깨진다(정 필요하면 그것도 선택지로 명시).
 - **확신수준은 정직하게** — 높게 부풀리지 말 것. 미해결 변수가 있으면 낮추고 그 이유를 확신근거에 적는다.
 - **--perf ≠ 무조건 비싼 옵션** — 품질이 동등하면 효율적 옵션을 택한다. --perf는 품질이 갈릴 때의 **타이브레이커**다.
+- **--deep 은 확신을 사는 게 아니라 증거를 사는 것** — 근거 없이 숫자만 올리거나, 결정을 쪼개거나 조건부 권고로 바꿔 0.80 을 맞추지 않는다(필요하면 그것도 선택지로 명시).
+- **조사 명목의 위험 행위 금지** — 배포·삭제·외부 전송·되돌리기 어려운 실험은 하지 않는다. 필요하면 확신 미달 질문으로 돌린다.
 
-ARGUMENTS: [--perf] [결정 맥락/질문] (없으면 현재 작업의 결정 분기에 적용)
+ARGUMENTS: [--perf] [--deep] [결정 맥락/질문] (없으면 현재 작업의 결정 분기에 적용. --deep 은 --perf 를 포함)

package/skills/graceful_pause/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: graceful_pause
+description: "(banker) 진행 중인 작업을 지금 단계까지만 마무리하고 멈춘 뒤, 상태를 보고하고 사용자 중간 지시를 받을 준비를 함. cancel 과 달리 모드 상태와 계획을 지우지 않음. 작업 중 대기 입력으로 넣어 두면 읽히는 시점에 동작. 'graceful_pause'/'잠깐 멈춰'/'지금 단계만 끝내고 멈춰'/'중간 지시' 시 사용."
+argument-hint: "[멈춘 뒤 다룰 지시나 메모]"
+---
+
+# graceful_pause: 지금 단계만 끝내고 멈춤
+
+인자: `$ARGUMENTS`
+- 선택. 멈춘 뒤 다룰 지시나 메모
+- Codex: 사용자 메시지에서 읽음
+
+## 동작 시점
+
+- 작업 도중 사용자가 대기 입력으로 넣어 두면, 큐에서 넘어와 이 스킬을 읽는 시점에 동작
+- 즉시 끊는 장치 없음. 읽기 전에 끝난 동작은 되돌리지 않음
+- 바로 끊어야 하면 Esc. 이 스킬의 몫이 아님
+- 함께 들어온 다른 대기 입력: 이 스킬 먼저 처리. 나머지는 정지 보고의 "받은 지시"에 넣음
+- 이미 작업이 끝난 뒤에 읽혔으면 1단계와 2단계는 건너뛰고 정지 보고부터 시작
+
+## cancel 과 차이
+
+| 항목 | graceful_pause | cancel |
+|---|---|---|
+| 진행 중인 단계 | 끝까지 마무리 | 그 자리에서 중단 |
+| 켜져 있는 모드 | 그대로 둠 | 실행을 끝냄 |
+| 모드가 남기는 기록 | 손대지 않음 | 모드마다 다름. ralph 상태는 지우고, autopilot 진행 상황과 ultragoal 원장은 남김 |
+| 이후 | 지시를 받아 같은 흐름 재개 | 모드를 다시 시작해 남은 기록부터 이어 감 |
+
+## 절차
+
+1. 지금 단계 확인
+   - 지금 단계: 이미 시작한 도구 동작 하나와, 그 동작이 남긴 불일치를 닫는 최소 작업
+   - 예: 함수 이름을 바꾸던 중이면 그 이름을 쓰는 곳까지 바꿈
+   - 포함하지 않음: 스토리나 할 일 목록의 다음 항목
+2. 지금 단계 마무리
+
+   | 진행 중인 동작 | 처리 |
+   |---|---|
+   | 파일 수정 | 그 파일을 일관된 상태까지 수정. 반쯤 고친 파일을 남기지 않음 |
+   | 실행 중인 명령이나 테스트 | 결과 받기 |
+   | 백그라운드 작업 | 멈추지 않음. 이름과 출력 위치만 기록 |
+   | 이미 띄운 하위 에이전트 | 결과를 기다리거나 백그라운드로 둠. 새로 띄우지 않음 |
+
+3. 하지 않는 것
+   - 다음 단계 시작 (예: 다음 파일, 다음 스토리)
+   - 되돌리기 어려운 동작
+     - 커밋과 push
+     - 배포와 게시
+     - 삭제와 외부 전송
+   - 모드 상태와 계획 파일 삭제. `cancel` 실행
+4. 정지 보고. 대화에만 짧게
+
+   | 항목 | 내용 |
+   |---|---|
+   | 끝낸 단계 | 방금 마무리한 것 |
+   | 현재 상태 | 검증 결과와 커밋하지 않은 변경 |
+   | 진행 중인 것 | 실행 중인 백그라운드 작업과 켜져 있는 모드 |
+   | 다음 예정 단계 | 1개에서 3개 |
+   | 열린 결정 | 사용자 판단이 필요한 것 |
+   | 받은 지시 | 인자 메모와 함께 들어온 대기 입력. 그 지시가 계획에 주는 영향 |
+
+5. 지시 대기
+
+   | 런타임 | 방법 |
+   |---|---|
+   | Claude Code | `AskUserQuestion` 으로 질문. 선택지는 계획대로 계속, 지시 반영 후 계속(자유 입력), 상태를 둔 채 중단. 질문이 열려 있는 동안은 응답이 끝나지 않으므로 ralph 같은 지속 모드도 끼어들지 않음 |
+   | Codex | 구조화 질문 도구(`request_user_input` 등)가 있으면 사용. tmux 안이면 `omx question` 도 가능. 둘 다 없을 때는 아래 표 |
+
+   - Codex 에서 질문 도구가 없을 때
+
+     | 지속 모드 (ralph, ultraqa, team 등) | 처리 |
+     |---|---|
+     | 꺼짐 | 짧은 질문 하나로 응답 종료 |
+     | 켜짐 | 응답을 끝내도 그 모드의 Stop 훅이 작업을 다시 이어 가게 하므로 멈출 수 없음. 이 사실을 정지 보고에 적고, 계속할지 `cancel` 할지 묻기 |
+
+6. 재개
+
+   | 사용자 답 | 처리 |
+   |---|---|
+   | 계속 | 다음 예정 단계부터 진행 |
+   | 새 지시 | 영향받는 단계를 다시 계획. 범위가 바뀌면 바뀐 계획을 먼저 보여 주고 승인 뒤 진행 |
+   | 중단 | 상태를 둔 채 멈춤. 세션을 끝낼 예정이면 `ready-compact --hand-off` 로 새 세션용 노트와 프롬프트 준비를 안내 |
+   | 취소 | 사용자가 명시할 때만 `cancel` 실행 |
+
+   - 중단 중인 지속 모드
+     - Claude Code: 응답이 끝날 때마다 OMC Stop 훅이 한 번씩 계속하라는 메시지를 넣음. 사용자가 재개를 말할 때까지 작업을 진행하지 않고 정지 중이라는 한 줄만 답함
+     - 예외: 직전 출력이 `ready-compact` 의 resume 프롬프트였다면 그 한 줄 대신 같은 프롬프트를 그대로 다시 출력. 마지막 메시지가 프롬프트여야 `/copy` 가 맞는 것을 복사함
+     - 이 메시지까지 멈추려면 `cancel` 이 필요함을 알림. 그 모드가 남기는 기록은 위 표의 cancel 열
+
+## 함정
+
+- 정지 보고를 핑계로 다음 단계를 미리 하지 않음
+- 정지 중 받은 계속 신호(훅 메시지)는 사용자 승인이 아님. 사용자가 재개를 말할 때까지 모든 응답에 해당
+- 정지 중 도착한 백그라운드 작업 결과: 보고에 추가만 함. 후속 작업은 시작하지 않음