okstra 0.122.0 → 0.124.0

package/runtime/skills/okstra-inspect/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: okstra-inspect
 description: >-
-  Use this for everything that happens AFTER a single okstra task has already run — inspecting it or light bookkeeping on it, never launching new work. The tell is usually a named task id (PROD-1623, dev-9184), often dropped without the word "okstra." Reach for it when the user wants one task's: status, current/next phase, blockers, or approval gate; its final report — where it is or whether it passed (결론·통과); its elapsed time (소요 시간) or context/read cost (컨텍스트 비용); its run history, re-run, or resume; to mark it done / in-progress / blocked / todo; or a failed run's error logs gathered into a report (에러 리포트). Also bundles cross-project okstra errors into an anonymized feedback zip (에러 환류). Use it even for a bare "mark it done" or "where's the report." NOT for starting a run (okstra-run), rollups/schedules (okstra-rollup / okstra-schedule), a brief (okstra-brief-gen), setup (okstra-setup), or cross-project management (okstra-manager).
+  Use this for everything that happens AFTER a single okstra task has already run — inspecting it or light bookkeeping on it, never launching new work. The tell is usually a named task id (PROD-1623, dev-9184), often dropped without the word "okstra." Reach for it when the user wants one task's: status, current/next phase, blockers, or approval gate; its final report — where it is or whether it passed (verdict / pass); its elapsed time or context/read cost; its run history, re-run, or resume; to mark it done / in-progress / blocked / todo; or a failed run's error logs gathered into a report (error report). Also bundles cross-project okstra errors into an anonymized feedback zip (error feedback). Use it even for a bare "mark it done" or "where's the report." NOT for starting a run (okstra-run), rollups/schedules (okstra-rollup / okstra-schedule-gen), a brief (okstra-brief-gen), setup (okstra-setup), or cross-project management (okstra-manager).
 ---
 
 # OKSTRA Inspect
@@ -22,7 +22,9 @@ Single read-side entry point for okstra runtime inspection plus the one status m
 
 ## Step 0: Preflight (shared)
 
-Before any sub-command, run one Bash tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — a non-literal leading token defeats the `Bash(okstra:*)` permission match):
+<!-- BEGIN FRAGMENT: bash-invocation-rule -->
+Run one Bash tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — a non-literal leading token defeats the `Bash(okstra:*)` permission match):
+<!-- END FRAGMENT: bash-invocation-rule -->
 
 ```bash
 okstra preflight --runtime claude-code --json
@@ -32,13 +34,21 @@ The project check only sees the cwd of the Bash call. When the user is asking ab
 
 Branch on the stdout JSON:
 - `ok: true` → carry `projectRoot` as a literal string; it is the base for every sub-command step below.
-- `ok: false` → before concluding "no setup", ask whether the user pointed at a specific project directory. If they did, re-run targeting it: `okstra preflight --runtime claude-code --cwd <that-dir> --json` (`--cwd` is the sanctioned way to target a project — a leading `cd` would break the permission match). Only if this **also** returns `ok:false` do you tell the user: "this project has no okstra setup. Run `/okstra-setup` first." Then stop. If the call fails with `unknown command: preflight`, the `okstra` binary on PATH predates this skill — tell the user to update it (`npm i -g okstra@latest`), then stop (`/okstra-setup` does not update the binary).
+- `ok: false` → before concluding "no setup", ask whether the user pointed at a specific project directory. If they did, re-run targeting it: `okstra preflight --runtime claude-code --cwd <that-dir> --json` (`--cwd` is the sanctioned way to target a project — a leading `cd` would break the permission match). Only if this **also** returns `ok:false` do you tell the user: "this project has no okstra setup. Run `/okstra-setup` first." Then stop.
 
-Carry the resolved `projectRoot` into the sub-commands: read file artifacts under `<projectRoot>/.okstra/...`, and for sub-command CLIs that accept it (e.g. `recap`, `context-cost`) pass `--cwd <projectRoot>` / `--project-root <projectRoot>` so they target the same project rather than the Bash cwd. Subsequent `okstra <subcmd>` calls self-bootstrap their Python path, so this skill never needs `okstra paths --shell` / `export PYTHONPATH=...`.
+<!-- BEGIN FRAGMENT: preflight-outdated-cli -->
+If the call fails with `unknown command: preflight`, the `okstra` binary on PATH predates this skill — tell the user to update it (`npm i -g okstra@latest`), then stop (`/okstra-setup` does not update the binary).
+<!-- END FRAGMENT: preflight-outdated-cli -->
+
+Carry the resolved `projectRoot` into the sub-commands: read file artifacts under `<projectRoot>/.okstra/...`, and for sub-command CLIs that accept it (e.g. `recap`, `context-cost`) pass `--cwd <projectRoot>` / `--project-root <projectRoot>` so they target the same project rather than the Bash cwd.
+
+<!-- BEGIN FRAGMENT: python-bootstrap-note -->
+Every subsequent `okstra <subcmd>` call self-bootstraps its Python path, so this skill never needs `okstra paths --shell` / `export PYTHONPATH=...`.
+<!-- END FRAGMENT: python-bootstrap-note -->
 
 ## Step 1: Dispatch by intent
 
-Classify the user's request into one sub-command using the trigger table above. If ambiguous (e.g. "okstra 보여줘"), ask which facet — do not silently default. After routing, the chosen sub-command's section below governs the rest of the response.
+Classify the user's request into one sub-command using the trigger table above. If ambiguous (e.g. "show me okstra"), ask which facet — do not silently default. After routing, the chosen sub-command's section below governs the rest of the response.
 
 When you ask which facet, the option list is **authoritative**: enumerate every sub-command in the `Sub-command | What it does` table above as a numbered text list, in table order, each with its one-line description, and let the user pick by number or name. Never present a hand-picked subset — the AskUserQuestion 4-option cap is not a reason to drop facets; render the full menu as text in the question body so no facet (e.g. a newly added one) is ever hidden. The table is the single source of truth for this menu; adding a row there is all it takes for the facet to appear here.
 
@@ -48,7 +58,7 @@ When the user chains multiple facets in one message (e.g. "status, and then time
 
 ## status
 
-Trigger phrases: "okstra status", "task status", "current phase", "next phase", "what is pending", "resume point", "okstra status set", "okstra mark", "<task-id> done", "<task-id> in-progress", "<task-id> 진행중", "<task-id> 완료".
+Trigger phrases: "okstra status", "task status", "current phase", "next phase", "what is pending", "resume point", "okstra status set", "okstra mark", "<task-id> done", "<task-id> in-progress", "<task-id> in progress", "<task-id> complete".
 
 ### status.1 — Overall project status
 
@@ -64,7 +74,7 @@ Read `.okstra/discovery/task-catalog.json`. The catalog is the authoritative sou
 | `currentPhaseState` | lifecycle phase state |
 | `nextRecommendedPhase` | next recommended phase |
 | `routingStatus` | routing decision status |
-| `awaitingApproval` | approval 대기 여부 |
+| `awaitingApproval` | whether awaiting approval |
 | `latestRunStatus` | latest run status |
 | `latestReportPath` | latest report path |
 | `latestResumeCommandPath` | latest resume command |
@@ -149,7 +159,7 @@ Recognize requests to change a task's `workStatus` and update the corresponding
 
 **Trigger patterns** (recognize both):
 
-Natural language: "DEV-6827 done으로 바꿔줘", "PROD-1623을 blocked로 표시", "DEV-9047 진행중", "Mark DEV-6827 as done".
+Natural language: "change DEV-6827 to done", "mark PROD-1623 as blocked", "set DEV-9047 in progress", "Mark DEV-6827 as done".
 
 Explicit phrasing (recognized user utterances — normalize each to a `okstra set-work-status` call below):
 - `okstra status set <task-id> <status>`
@@ -166,14 +176,14 @@ okstra set-work-status <token> <status> --project-root <projectRoot> --json
 ```
 
 - `<token>` is a full task-key or a bare task-id. Add `--task-group <group>` to scope a duplicated id, `--note "<note>"` to set `workStatusNote` (flag omitted → any existing note is left untouched).
-- Branch on the stdout JSON: `ok: true` → confirm below. `stage: "ambiguous"` → list `matches[]` (with `_matchedVia`) via a 3-option picker and retry with the chosen full task-key. `stage: "not-found"` → `<TASK-ID>를 찾을 수 없습니다.` An invalid `<status>` makes the CLI exit 2 with the allowed-values list — surface it verbatim; nothing was modified.
+- Branch on the stdout JSON: `ok: true` → confirm below. `stage: "ambiguous"` → list `matches[]` (with `_matchedVia`) via a 3-option picker and retry with the chosen full task-key. `stage: "not-found"` → `<TASK-ID> cannot be found.` An invalid `<status>` makes the CLI exit 2 with the allowed-values list — surface it verbatim; nothing was modified.
 
 Confirm in Korean:
 ```
 ✓ <TASK-ID> workStatus: <previousWorkStatus> → <workStatus>
-✓ task-manifest.json 업데이트됨
+✓ task-manifest.json updated
 ```
-`<previousWorkStatus>` = `(없음)` when the JSON's `previousWorkStatus` is empty.
+`<previousWorkStatus>` = `(none)` when the JSON's `previousWorkStatus` is empty.
 
 **Default value convention:** if `workStatus` is missing or empty, infer the display value from lifecycle state (DO NOT default to a static `in-progress`):
 
@@ -186,13 +196,13 @@ Confirm in Korean:
 
 Annotate inferred values with `(inferred)` or `(default)`. Do not back-fill on read; only write when the user explicitly issues an update.
 
-**Catalog sync note:** the CLI updates `task-manifest.json` only. `discovery/task-catalog.json` may be stale until the next run regenerates it; downstream consumers (e.g. `okstra-schedule`) re-read each manifest directly.
+**Catalog sync note:** the CLI updates `task-manifest.json` only. `discovery/task-catalog.json` may be stale until the next run regenerates it; downstream consumers (e.g. `okstra-schedule-gen`) re-read each manifest directly.
 
 ---
 
 ## history
 
-Trigger phrases: "okstra history", "past runs", "run history", "re-run", "list tasks", "다시 실행", "resume", "이어서".
+Trigger phrases: "okstra history", "past runs", "run history", "re-run", "list tasks", "run again", "resume", "continue".
 
 **Re-run vs Resume — decide upfront.** Re-run = start a fresh run (new run-seq, new manifest, new report) reusing an old run's parameters → `history.3`. Resume = continue an interrupted Claude session for an existing run, no new run-seq → `history.4`. If the user is ambiguous, ask — defaulting to the wrong one either wastes a fresh run-seq or silently abandons a recoverable session.
 
@@ -293,7 +303,7 @@ Lookup methods (in priority order):
 
 A. **`task-catalog.json` (fast):** read `.okstra/discovery/task-catalog.json`, match `taskKey` lowercase. `latestReportPath` is task-type-agnostic "most recent report".
 
-B. **`task-manifest.json` (direct):** if catalog missing, slugify task-group / task-id, read `.okstra/tasks/<group-segment>/<id-segment>/task-manifest.json`, use `latestReportPath` (task-type-agnostic).
+B. **`task-manifest.json` (direct):** if catalog missing, slugify task-group / task-id, read `.okstra/tasks/<group-segment>/<task-id-segment>/task-manifest.json`, use `latestReportPath` (task-type-agnostic).
 
 C. **`timeline.json` (specific run):** for a specific date or run, read `.okstra/tasks/<group-segment>/<id-segment>/history/timeline.json`, filter `runs[]` by `runTimestamp` / `status` / `taskType`, use `runs[].reportPath`.
 
@@ -304,23 +314,23 @@ D. **Specific task-type (fallback):** `latestReportPath` is task-type-agnostic.
 1. Verify `latestReportPath` is non-empty AND the file exists on disk. Either signal indicates report presence (tolerant).
 2. If present, display the path and ask the user whether to read it.
 3. If absent, check `task-manifest.json` signals:
-   - `latestReportPath` empty/missing AND `currentStatus != completed` AND `workStatus != done` AND `workflow.routingStatus` not completion-like → `이 task는 아직 완료되지 않았습니다 (currentStatus: <currentStatus>, workStatus: <workStatus>).`
-   - Any signal indicates completion but the file is missing → `보고서 파일이 존재하지 않습니다: <path>`
+   - `latestReportPath` empty/missing AND `currentStatus != completed` AND `workStatus != done` AND `workflow.routingStatus` not completion-like → `This task is not yet complete (currentStatus: <currentStatus>, workStatus: <workStatus>).`
+   - Any signal indicates completion but the file is missing → `Report file does not exist: <path>`
 
 `workStatus` enum: `todo | in-progress | blocked | done`. `currentStatus`: `completed` / `contract-violated` etc. `"completed"` string does NOT exist in `workStatus` — do not confuse the two.
 
 ### report.3 — Read + next-step guidance
 
-Match the depth of read to the request — final reports routinely run 300+ lines / 50K+ tokens, so ingesting the whole file just to answer "핵심만 요약" is wasteful:
+Match the depth of read to the request — final reports routinely run 300+ lines / 50K+ tokens, so ingesting the whole file just to answer "just the gist" is wasteful:
 
-- **Summary / verdict intent** ("요약", "핵심만", "결론", "통과했어?", "verdict"): do **not** read the whole report first. Read the `final-<task-type-segment>-<NNN>.status` sidecar under `runs/<task-type-segment>/status/` (stage-isolated: `runs/<task-type-segment>/stage-<N>/status/`) for the machine verdict, then read only the report's leading summary block (the first "종합 판정" / "Executive" / verdict heading and its body) to quote the gist. Offer to read the full report if the user wants detail.
-- **Full-read intent** ("전체", "다 읽어", "본문"): ingest the resolved report file.
+- **Summary / verdict intent** ("summary", "just the key points", "conclusion", "did it pass?", "verdict"): do **not** read the whole report first. Read the `final-<task-type-segment>-<NNN>.status` sidecar under `runs/<task-type-segment>/status/` (stage-isolated: `runs/<task-type-segment>/stage-<N>/status/`) for the machine verdict, then read only the report's leading summary block (the first "Overall Verdict" / "Executive" / verdict heading and its body) to quote the gist. Offer to read the full report if the user wants detail.
+- **Full-read intent** ("the whole thing", "read it all", "full body"): ingest the resolved report file.
 
 After reading, surface follow-up options:
 
-1. **구현 진행:** based on the report's "권장 다음 단계" section.
-2. **추가 검증:** to launch a new okstra run with the same task-key, assemble the command through the `history` sub-command — it offers the full option set (base-ref, workers, render-only) and renders a host-correct invocation.
-3. **관련 task 확인:** if the report references related task-keys, fetch their reports too.
+1. **Proceed to implementation:** based on the report's "Recommended Next Steps" section.
+2. **Additional verification:** to launch a new okstra run with the same task-key, assemble the command through the `history` sub-command — it offers the full option set (base-ref, workers, render-only) and renders a host-correct invocation.
+3. **Check related tasks:** if the report references related task-keys, fetch their reports too.
 
 ### report — Output template
 
@@ -341,7 +351,7 @@ After reading, surface follow-up options:
 
 ## time
 
-Trigger phrases: "작업 시간", "소요 시간", "time summary", "duration", "elapsed", "얼마나 걸렸", "시간 분석".
+Trigger phrases: "work time", "elapsed time", "time summary", "duration", "elapsed", "how long did it take", "time analysis".
 
 Aggregate elapsed work time for a task, grouped by **task type** and broken down by **worker** (lead + each worker). The `time-report` CLI reads both data sources (`history/timeline.json` runs + each run's `team-state-*.json` usage blocks) and does **all** aggregation — cross-run sums, CPU-sum vs wall-clock, timestamp parsing, unavailable detection. You only resolve the task-key, call it, and render. **Never recompute durations by hand.**
 
@@ -368,7 +378,7 @@ Convert every `*Ms` to `HH:MM:SS` (zero-pad; never show raw ms). Task types in `
 
 - **By task type** — `| Task type | Runs | CPU sum | Lead | Workers |` from `byTaskType`, plus a `grandTotal` row. `CPU sum` (= Lead + Workers) overlaps because workers run inside the lead's window — it is *not* wall-clock. Surface wall-clock only when the user explicitly asks, from `perRunWallClock`.
 - **Per worker** (per task type) — `| Worker | Runs | Total | Avg/run |` from `perWorker`. Render the worker as bare `workerId` when `agents` is empty, else `workerId (agent1, agent2)`.
-- **Phase breakdown** — "단계별"/"stage별"/"어느 단계가 오래" in okstra most often means the **lifecycle stage (task-type)** view, which the *By task type* table above already answers — lead with that table, do not treat the request as unanswerable. Render the intra-run phase timeline only when the user clearly means within-a-run phases ("어느 phase가", "Phase 1~7", "phase timeline"): one table per run from `phaseTimelines`: `| Phase | Start | Wall to next |` using `firstAt`/`wallMsToNext` (`null` → `--`). When `phaseTimelines` is empty, do **not** headline "측정 불가" — the By-task-type table is the stage answer; mention the missing intra-run markers only as a trailing footnote.
+- **Phase breakdown** — "by stage"/"per stage"/"which stage took longest" in okstra most often means the **lifecycle stage (task-type)** view, which the *By task type* table above already answers — lead with that table, do not treat the request as unanswerable. Render the intra-run phase timeline only when the user clearly means within-a-run phases ("which phase", "Phase 1~7", "phase timeline"): one table per run from `phaseTimelines`: `| Phase | Start | Wall to next |` using `firstAt`/`wallMsToNext` (`null` → `--`). When `phaseTimelines` is empty, do **not** headline "not measurable" — the By-task-type table is the stage answer; mention the missing intra-run markers only as a trailing footnote.
 - If `unavailable[]` is non-empty, append a trailing note listing each run with its reason. Never fold them into totals.
 - Show the resolved `<task-key>` in the heading.
 
@@ -396,7 +406,7 @@ Convert every `*Ms` to `HH:MM:SS` (zero-pad; never show raw ms). Task types in `
 
 ## cost
 
-Trigger phrases: "okstra context-cost", "context cost", "context-cost", "컨텍스트 비용", "읽기 비용", "산출물 비용", "task bundle cost", "agent read cost".
+Trigger phrases: "okstra context-cost", "context cost", "context-cost", "context cost (Korean)", "read cost", "artifact cost", "task bundle cost", "agent read cost".
 
 Read-only estimate of how much file/context surface a prepared task bundle asks the lead, analysis workers, and report-writer to absorb. This sub-command does **not** mutate task artifacts.
 
@@ -423,11 +433,11 @@ okstra resolve-task-key <token> --project-root <projectRoot> --json
 ```
 
 Branch on the stdout JSON `matches[]` — this **standard 0/1/N rule** is referenced by `errors`/`recap` below:
-- **0개** → report the task cannot be found. Do not guess.
-- **1개** → use that entry's `taskKey`.
-- **N개** → list the candidate `taskKey`s (with `updatedAt`, and `_matchedVia` so the user sees which came from a task-id vs a task-group) and ask via a 3-option picker (1~2 추천 + `직접 입력`), then use the chosen `taskKey`.
+- **0** → report the task cannot be found. Do not guess.
+- **1** → use that entry's `taskKey`.
+- **N** → list the candidate `taskKey`s (with `updatedAt`, and `_matchedVia` so the user sees which came from a task-id vs a task-group) and ask via a 3-option picker (1–2 recommendations + `Enter directly`), then use the chosen `taskKey`.
 
-If the user asks generally ("컨텍스트 비용 보여줘") and does not name a task:
+If the user asks generally ("show me the context cost") and does not name a task:
 
 1. Read `.okstra/discovery/task-catalog.json`.
 2. If exactly one task exists, use it.
@@ -492,7 +502,7 @@ Interpretation rules:
 
 ## logs
 
-Trigger phrases: "okstra logs", "로그 현황", "로그 파일", "log files", "log size", "log status", "로그 정리", "log cleanup".
+Trigger phrases: "okstra logs", "log status", "log files", "log files", "log size", "log status", "log cleanup", "log cleanup".
 
 Read-only inventory of codex/antigravity wrapper log files written next to each prompt history file (`<prompt>.log`). Reports sizes, ages, totals, and suggests cleanup commands. **Does not delete** — the user runs whichever `find … -delete` line they like.
 
@@ -536,31 +546,31 @@ Emit a fenced bash block the user can copy-paste. Do NOT execute. Each block pai
 ```markdown
 ## Cleanup options (manual)
 
-# 7일 이상 된 로그만 삭제
+# Delete only logs older than 7 days
 find <PROJECT_ROOT>/.okstra/tasks \
   -type f -path '*/runs/*/prompts/*.log' -mtime +7 -print    # dry-run
 find <PROJECT_ROOT>/.okstra/tasks \
   -type f -path '*/runs/*/prompts/*.log' -mtime +7 -delete
 
-# 30일 이상 된 로그만 삭제
+# Delete only logs older than 30 days
 find <PROJECT_ROOT>/.okstra/tasks \
   -type f -path '*/runs/*/prompts/*.log' -mtime +30 -print   # dry-run
 find <PROJECT_ROOT>/.okstra/tasks \
   -type f -path '*/runs/*/prompts/*.log' -mtime +30 -delete
 
-# 특정 task-group 의 로그 일괄 삭제 (예: dev-9388)
+# Delete all logs for a specific task-group (e.g. dev-9388)
 find <PROJECT_ROOT>/.okstra/tasks/dev-9388 \
   -type f -name '*.log' -print    # dry-run
 find <PROJECT_ROOT>/.okstra/tasks/dev-9388 \
   -type f -name '*.log' -delete
 
-# 특정 task-id 의 로그 일괄 삭제 (예: dev-9428)
+# Delete all logs for a specific task-id (e.g. dev-9428)
 find <PROJECT_ROOT>/.okstra/tasks/*/dev-9428 \
   -type f -name '*.log' -print    # dry-run
 find <PROJECT_ROOT>/.okstra/tasks/*/dev-9428 \
   -type f -name '*.log' -delete
 
-# 전체 일괄 삭제 (주의)
+# Delete everything (caution)
 find <PROJECT_ROOT>/.okstra/tasks \
   -type f -path '*/runs/*/prompts/*.log' -print    # dry-run
 find <PROJECT_ROOT>/.okstra/tasks \
@@ -580,7 +590,7 @@ Substitute the literal `<PROJECT_ROOT>` with the resolved absolute path so the c
 
 ## errors
 
-Trigger phrases: "okstra errors", "error report", "에러 리포트", "에러 보고", "에러 모아줘", "실패 로그 정리".
+Trigger phrases: "okstra errors", "error report", "error report (Korean)", "error summary", "gather the errors", "clean up failure logs".
 
 Aggregate a task's okstra-run error logs (`runs/*/logs/errors-*.jsonl`, lead-observed + worker-reported) into a timestamped markdown report and summarize it. This sub-command renders a **read-derived artifact** (a `.md` file) but never mutates task state (`task-manifest.json`, catalog, timeline).
 
@@ -592,7 +602,7 @@ Accepted target forms (same as `cost`):
 2. Bare token (task-id or task-group) — resolve via `okstra resolve-task-key <token> --project-root <projectRoot> --json` and branch on `matches[]` using the standard 0/1/N rule from `cost.1` (0 = not found, 1 = use, N = picker).
 3. Task root path.
 
-사용자가 task 를 지정하지 않고 그냥 에러 리포트를 요청하면, `cost.1` 과 동일한 no-task fallback 을 적용한다 — 플레이스홀더 형식만 나열하고 되묻지 않는다: `.okstra/discovery/task-catalog.json` 을 읽어 task 가 1개면 그대로 사용하고, 여러 개면 `updatedAt` 최신 10개를 실제 task-key 로 나열해 물어본다(추측 금지).
+If the user asks for an error report without naming a task, apply the same no-task fallback as `cost.1` — list only the placeholder forms and do not ask back: read `.okstra/discovery/task-catalog.json`, use the single task as-is if there is one, and if there are several, list the latest 10 by `updatedAt` as real task-keys and ask (no guessing).
 
 ### errors.2 — Run the renderer
 
@@ -619,7 +629,7 @@ Parse the stdout JSON and report:
 | By agent | `byAgent[]` |
 | Parse-skipped lines | `parseSkipped` |
 
-- If `reportPath` is empty AND `totals.errorCount == 0`: report `이 task 에는 기록된 에러 로그가 없습니다.` and do not claim a file was written.
+- If `reportPath` is empty AND `totals.errorCount == 0`: report `This task has no recorded error logs.` and do not claim a file was written.
 - Otherwise show the `.md` path and offer to read it.
 - If `parseSkipped > 0`, surface it (do not silently hide malformed lines).
 
@@ -641,147 +651,143 @@ Parse the stdout JSON and report:
 |---|---:|
 | codex-worker | 2 |
 
-<If parseSkipped > 0: "⚠ 파싱 건너뛴 줄: <N>">
+<If parseSkipped > 0: "⚠ Parse-skipped lines: <N>">
 ```
 
 ---
 
 ## error-zip
 
-Trigger phrases: "okstra error-zip", "에러 zip", "에러 환류", "에러 번들", "cross-project 에러".
+Trigger phrases: "okstra error-zip", "error zip", "error feedback", "error bundle", "cross-project errors".
 
-머신 내 모든 타겟 프로젝트의 okstra 실행 에러(`runs/*/logs/errors-*.jsonl`)를 글로벌 run-index 로 수집·익명화해 `.zip`(집계 리포트 + 익명화 JSONL)으로 묶는다. 모든 타겟의 `.okstra/` 에 대해 read-only.
+Collect and anonymize the okstra run errors (`runs/*/logs/errors-*.jsonl`) of every target project on the machine into the global run-index, then bundle them as a `.zip` (aggregate report + anonymized JSONL). Read-only over every target's `.okstra/`.
 
-### error-zip.1 — 출력 경로 결정 (picker)
+### error-zip.1 — Decide the output path (picker)
 
-이전 출력 경로를 `~/.okstra/error-zip.json` 의 `lastOutputPath` 에서 읽는다. 그 값이 있으면 3-옵션 picker 로 제시:
+Read the previous output path from `lastOutputPath` in `~/.okstra/error-zip.json`. If that value exists, present it in a 3-option picker:
 
-1. (이전 경로 있음) `<lastOutputPath>` 재사용 — 추천, 첫 옵션.
-   (이전 경로 없음) 기본 경로 `~/okstra-error-feedback-<YYYY-MM-DD>.zip` 제안 — 추천.
-2. 직접 입력 (항상 마지막 옵션).
+1. (previous path exists) reuse `<lastOutputPath>` — recommended, first option.
+   (no previous path) propose the default path `~/okstra-error-feedback-<YYYY-MM-DD>.zip` — recommended.
+2. Enter directly (always the last option).
 
-`~/.okstra/error-zip.json` 읽기는 Read 로 직접 수행한다(없으면 이전 경로 없음으로 간주).
+Read `~/.okstra/error-zip.json` directly with Read (if absent, treat it as no previous path).
 
-### error-zip.2 — 렌더 실행
+### error-zip.2 — Run the renderer
 
 ```bash
-okstra error-zip --out <결정된 경로>
+okstra error-zip --out <resolved-path>
 ```
 
-### error-zip.3 — 요약 보고
+### error-zip.3 — Report the summary
 
-stdout JSON 을 파싱해 보고:
+Parse the stdout JSON and report:
 
-| 필드 | 출처 |
+| Field | Source |
 |---|---|
-| 출력 zip | `outPath` |
-| 총 에러 | `errorCount` |
-| 로그(run) | `runCount` |
-| 도달 불가 run | `unreachableRuns` |
-| 클러스터 수 | `clusterCount` |
-| 프로젝트 수 | `projectCount` |
+| Output zip | `outPath` |
+| Total errors | `errorCount` |
+| Logs (runs) | `runCount` |
+| Unreachable runs | `unreachableRuns` |
+| Cluster count | `clusterCount` |
+| Project count | `projectCount` |
 
-- `unreachableRuns > 0` 이면 표면화한다(침묵 누락 금지).
-- 끝에 다음 단계를 안내한다: "이 zip 으로 okstra 자신을 고치려면 `/okstra-brief-gen` 의 error-feedback variant 로 brief 를 만든 뒤 `okstra-run --task-type error-analysis` 를 okstra 레포에서 실행하세요."
+- If `unreachableRuns > 0`, surface it (no silent omission).
+- End with the next step: "To fix okstra itself with this zip, build a brief with the error-feedback variant of `/okstra-brief-gen`, then run `okstra-run --task-type error-analysis` in the okstra repo."
 
 ---
 
 ## recap
 
-Trigger phrases: "okstra recap", "recap", "작업 요약", "이 task 요약", "전후 요약", "이 작업 설명해줘", "task 질문".
+Trigger phrases: "okstra recap", "recap", "work summary", "summarize this task", "before/after summary", "explain this work", "task question".
 
-task-id 하나에 쌓인 `.okstra` 산출물 위에서 (a) 처리 전/후 요약을 내고, (b) 그 작업에 대한 자유 질문에 답한다. 기본은 `.okstra/` 서브트리만 읽는다(artifact 모드). 사용자가 명시적으로 코드 변경까지 봐 달라고 요청할 때만 code 모드로 확장한다. 이 sub-command 는 `recap/recap-log.jsonl` append 와 `notes/` 노트 작성(recap.5)만 수행하고 `task-manifest.json` / catalog / timeline 은 절대 mutate 하지 않는다.
+On top of the `.okstra` artifacts accumulated for a single task-id, (a) produce a before/after summary and (b) answer free-form questions about that work. By default it reads only the `.okstra/` subtree (artifact mode). It expands to code mode only when the user explicitly asks to look at the code changes too. This sub-command performs only the `recap/recap-log.jsonl` append and the `notes/` note authoring (recap.5); it never mutates `task-manifest.json` / catalog / timeline.
 
 ### recap.1 — Resolve target
 
-`cost` / `errors` 와 동일한 3형식: ① full task-key, ② bare token(task-id 또는 task-group → `okstra resolve-task-key <token> --project-root <projectRoot> --json`; `cost.1` 의 표준 0/1/N 분기), ③ task-root path.
-
-사용자가 task 를 지정하지 않고 그냥 recap 을 요청하면(예: "이 작업 요약해줘"), `cost.1` 과 동일한 no-task fallback 을 적용한다 — 절대 `<task-group>` 같은 플레이스홀더 형식만 나열하고 되묻지 않는다:
+The same three forms as `cost` / `errors`: ① full task-key, ② bare token (task-id or task-group → `okstra resolve-task-key <token> --project-root <projectRoot> --json`; the standard 0/1/N branch from `cost.1`), ③ task-root path.
 
-1. `.okstra/discovery/task-catalog.json` 을 읽는다.
-2. task 가 정확히 1개면 그 task 를 그대로 사용한다.
-3. 여러 개면 `updatedAt` 최신 10개를 실제 task-key 로 나열하고 어느 task 인지 물어본다(추측 금지).
+If the user asks for a recap without naming a task (e.g. "summarize this work"), apply the `cost.1` no-task fallback as-is — do not list only a placeholder form like `<task-group>` and ask back; read `.okstra/discovery/task-catalog.json`, use the single task as-is if there is one, and if there are several, list the latest 10 by `updatedAt` as real task-keys and ask (no guessing).
 
 ### recap.2 — Assemble the before/after summary
 
-CLI 출력을 source of truth 로 쓴다:
+Use the CLI output as the source of truth:
 
 ```bash
 okstra recap assemble <resolved-target> --project-root <projectRoot>
 ```
 
-stdout JSON(`{taskKey, runCount, transitions[], latestPhaseStates}`)을 파싱해 run 단위 전/후 전이를 서술한다. 각 `transitions[]` 항목의 `fromPhase → toPhase`(직전 run currentPhase → 이번 run currentPhase), `status`, `lastCompletedPhase`, `nextRecommendedPhase`, `reportPath` 를 시간순으로 보여준다. `runCount == 0` 이면 "이 task 에는 기록된 run 이 없습니다." 라고만 답하고 파일을 읽었다고 주장하지 않는다.
+Parse the stdout JSON (`{taskKey, runCount, transitions[], latestPhaseStates}`) and narrate the per-run before/after transitions. For each `transitions[]` entry, show `fromPhase → toPhase` (previous run currentPhase → this run currentPhase), `status`, `lastCompletedPhase`, `nextRecommendedPhase`, and `reportPath` in chronological order. If `runCount == 0`, answer only "This task has no recorded runs." and do not claim to have read any file.
 
-`reportPath` 가 있는 run 은 사용자가 더 깊은 요약을 원할 때만 해당 final-report 를 읽어 보강한다(자동으로 모두 읽지 않는다).
+For a run that has a `reportPath`, read that final-report to enrich the summary only when the user wants a deeper one (do not read them all automatically).
 
 ### recap.3 — Free-form Q&A loop
 
-요약 출력 뒤 사용자의 임의 질문을 받는다.
+After the summary output, take the user's free-form questions.
 
-- **artifact 모드(기본)**: `.okstra/` 산출물(timeline, task-manifest, 해당 run 의 final-report)만 근거로 답한다. 모든 사실 주장은 `.okstra` 파일 `path:line` 인용을 동반한다.
-- **code 모드(opt-in)**: 사용자가 "코드 변경까지 / diff 까지 봐줘" 류로 **명시적으로 요청**할 때만, 해당 task 의 worktree/브랜치에서 `git diff` · `git log` 를 추가로 읽어 코드 레벨로 답한다. recap 진입만으로는 절대 code 모드로 넘어가지 않는다.
+- **artifact mode (default)**: answer only from `.okstra/` artifacts (timeline, task-manifest, that run's final-report). Every factual claim is accompanied by a `path:line` citation to the `.okstra` file.
+- **code mode (opt-in)**: only when the user **explicitly asks** — "look at the code changes / the diff too" — additionally read `git diff` · `git log` from that task's worktree/branch and answer at the code level. Entering recap never by itself switches to code mode.
 
 ### recap.4 — Persist each turn
 
-요약 1건과 각 Q&A 답변을 로그에 남긴다(append-only):
+Log one summary and each Q&A answer (append-only):
 
 ```bash
 okstra recap record <resolved-target> --project-root <projectRoot> \
   --kind <summary|qa> --mode <artifact|code> \
-  --question "<질문 또는 생략>" --answer "<한두 줄 요약>" \
+  --question "<question or omit>" --answer "<one or two line summary>" \
   --citation "<path:line>" --citation "<path:line>"
 ```
 
-`--answer` 에는 전체 답변 전사가 아니라 한두 줄 요약을 넣는다. 인용이 여러 개면 `--citation` 을 반복한다. 기록 실패(비정상 종료)는 조용히 넘기지 말고 사용자에게 알린다.
+Put a one-or-two-line summary in `--answer`, not the full answer transcript. If there are multiple citations, repeat `--citation`. Do not silently swallow a recording failure (abnormal exit) — tell the user.
 
 ### recap — Output template
 
 ```markdown
 ## okstra Recap — <task-key>
 
-전/후 요약 (runs: <N>):
+Before/after summary (runs: <N>):
 
 | # | when | task-type | from → to | status | next |
 |---|---|---|---|---|---|
-| 1 | <ts> | requirements-discovery | (시작) → requirements-discovery | done | error-analysis |
+| 1 | <ts> | requirements-discovery | (start) → requirements-discovery | done | error-analysis |
 
-<이후 자유 질문을 받습니다. 코드 변경까지 보려면 "diff 까지 봐줘" 라고 요청하세요.>
+<Free-form questions follow. To include code changes, ask "also show me the diff".>
 ```
 
-### recap.5 — Agent 저작 노트 (`notes/`)
+### recap.5 — Agent-authored notes (`notes/`)
 
-recap 중에 네가 **okstra task 를 위해** 만든 산출물 — 검증 증거, 설계·decision 초안, 분석 노트 — 이 앞으로의 run 에 근거로 쓰일 수 있고, 그 내용이 **렌더된 report 도 아니고 사용자 결정도 아닐 때**만 `notes/` 에 남긴다.
+Leave something in `notes/` only when, during recap, you produced an artifact **for the okstra task** — verification evidence, a design/decision draft, an analysis note — that may serve as grounding for future runs, and whose content is **neither a rendered report nor a user decision**.
 
-**소유권으로 라우팅한다.** 지금 쓰려는 것이 아래 어디에 해당하는지 먼저 판별한다:
+**Route by ownership.** First determine which of the following the thing you are about to write belongs to:
 
-| 내용 | 레인(경로) | 저작 주체 |
+| Content | Lane (path) | Author |
 |---|---|---|
-| final report 본문 | `runs/<type>/reports/*.md` (`*.data.json` 에서 렌더) | okstra 렌더러 — 절대 수기 편집 금지 |
-| clarification 에 대한 사용자 답변 | `runs/<type>/user-responses/*.md` (`created-by: user`) | 사용자만 |
-| 확정된 ADR | `.okstra/decisions/NNNN-*.md` | 승격·관리됨 |
-| **Agent 증거 / 설계 초안 / 분석** | **`.okstra/tasks/<group>/<id>/notes/`** | 너(AI) |
+| final report body | `runs/<type>/reports/*.md` (rendered from `*.data.json`) | okstra renderer — never hand-edit |
+| user's answer to a clarification | `runs/<type>/user-responses/*.md` (`created-by: user`) | user only |
+| finalized ADR | `.okstra/decisions/NNNN-*.md` | promoted / managed |
+| **Agent evidence / design draft / analysis** | **`.okstra/tasks/<group>/<id>/notes/`** | you (the AI) |
 
-렌더 산출물도, 사용자 결정도 아닌 **너 자신의 근거·초안**이면 `notes/` 로 간다. 노트는 손으로 찍지 말고 CLI 로 쓴다 — 경로·frontmatter·날짜를 코드가 보장하고, 다음 run 에 넘길 인자를 출력해 준다:
+If it is **your own grounding/draft** — not a rendered artifact, not a user decision — it goes to `notes/`. Do not hand-stamp the note; write it via the CLI — code guarantees the path/frontmatter/date and prints the argument to pass into the next run:
 
 ```bash
 okstra recap note <resolved-target> --project-root <projectRoot> \
   --kind <verification-evidence|decision-draft|analysis-note> \
   --slug <short-topic-slug> \
-  --purpose "<한 줄 — 무엇이며 어느 run/decision 에 투입되는지>" \
-  --scope-note "<한 줄 — 무엇이 아닌지, 예: C-00x 에 대한 사용자 결정이 아님>" \
-  --body-file <노트 본문 마크다운 경로>
+  --purpose "<one line — what it is and which run/decision it feeds>" \
+  --scope-note "<one line — what it is NOT, e.g. not a user decision on C-00x>" \
+  --body-file <note-body markdown path>
 ```
 
-본문은 먼저 scratchpad 에 마크다운으로 쓴 뒤 `--body-file` 로 넘긴다(짧으면 `--body "<md>"` 인라인도 가능). CLI 는 `.okstra/tasks/<group>/<id>/notes/<slug>-<YYYY-MM-DD>.md` 를 생성하고 stdout JSON 으로 `notePath` 와 `clarificationResponseArg` 를 돌려준다.
+Write the body to the scratchpad as markdown first, then pass it with `--body-file` (if short, an inline `--body "<md>"` also works). The CLI creates `.okstra/tasks/<group>/<id>/notes/<slug>-<YYYY-MM-DD>.md` and returns `notePath` and `clarificationResponseArg` as stdout JSON.
 
-**self-check 규칙 (validator 가 없으니 스스로 지킨다):**
+**self-check rules (there is no validator, so you keep them yourself):**
 
-1. **렌더된 report 를 수기 편집하지 않는다** (`runs/*/reports/` 아래 `*.md` / `*.data.json` / `*.html`). `data.json` 에서 재생성되므로 편집은 덮어써지고 SSOT 와 어긋난다. 발견 내용은 `notes/` 에 쓴다.
-2. **`user-responses/` 파일을 작성하거나 `created-by: user` 를 달지 않는다.** 그건 사용자의 결정이며, 대신 쓰면 사용자가 내리지 않은 결정을 위조하는 것이다. 네 증거가 특정 답을 뒷받침하면 `notes/` 에 그렇게 적고 결정은 사용자에게 맡긴다. 단, `okstra-user-response` 스킬의 에코백 확인 흐름은 예외다 — 그 흐름에서는 사용자가 세션에서 직접 결정을 내리고 CLI 는 전사 채널일 뿐이므로, `write` 로 `created-by: user` sidecar 를 기록하는 것이 정당하다. 이 예외는 사용자가 명시적으로 "맞음" 을 확인한 뒤에만, verbatim 입력에 대해서만 성립한다.
-3. **okstra 관리 디렉토리에 쓰지 않는다** (`runs/`, `instruction-set/`, `history/`, `recap/`, `.okstra/decisions/`). `notes/` 만이 agent 소유 레인이다. `recap/recap-log.jsonl` 은 예외적으로 쓰되 손으로 편집하지 말고 `okstra recap record` CLI 로만 남긴다.
-4. **`notes/` 는 okstra 에 inert 하다** — 어떤 run 도 자동으로 읽지 않는다. 작성 후 CLI 가 출력한 `clarificationResponseArg`(예: `--clarification-response <notePath>`)를 사용자에게 그대로 알려, 다음 run 을 그 인자와 함께 실행해야만 반영된다는 것을 전한다.
+1. **Do not hand-edit a rendered report** (`*.md` / `*.data.json` / `*.html` under `runs/*/reports/`). Because it is regenerated from `data.json`, an edit is overwritten and diverges from the SSOT. Write findings to `notes/` instead.
+2. **Do not author a `user-responses/` file or apply `created-by: user`.** That is the user's decision, and writing it for them forges a decision the user never made. If your evidence supports a particular answer, write that in `notes/` and leave the decision to the user. The one exception is the echo-back confirmation flow of the `okstra-user-response` skill — there the user makes the decision in-session and the CLI is merely a transcription channel, so recording a `created-by: user` sidecar with `write` is legitimate. This exception holds only after the user has explicitly confirmed "correct", and only for verbatim input.
+3. **Do not write to okstra-managed directories** (`runs/`, `instruction-set/`, `history/`, `recap/`, `.okstra/decisions/`). `notes/` is the only agent-owned lane. `recap/recap-log.jsonl` is the exception — write it, but not by hand; only via the `okstra recap record` CLI.
+4. **`notes/` is inert to okstra** — no run reads it automatically. After writing, relay the `clarificationResponseArg` the CLI printed (e.g. `--clarification-response <notePath>`) to the user verbatim, telling them it only takes effect when the next run is executed with that argument.
 
-**Guardrail:** `.okstra/` 는 gitignored 다 — `notes/` 는 로컬 scratch 로 취급하고 절대 `git add` 하지 않는다. 새 노트 생성은 되돌리기 쉬우니(파일 삭제), 생성물이나 사용자 소유 파일을 편집하는 것보다 항상 이쪽을 택한다.
+**Guardrail:** `.okstra/` is gitignored — treat `notes/` as local scratch and never `git add` it. Creating a new note is easy to undo (delete the file), so always prefer it over editing a generated or user-owned file.
 
 ---
 

package/runtime/skills/okstra-manager/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: okstra-manager
-description: Use when the user wants to manage okstra work across multiple project roots, register or discover projects under a manager, create or update a shared manager task, sync project child-task status into manager state, or launch a child task from manager context. Trigger words include "okstra manager", "okstra-manager", "여러 프로젝트", "cross-project", "프로젝트 묶어서", "manager task".
+description: Use when the user wants to manage okstra work across multiple project roots, register or discover projects under a manager, create or update a shared manager task, sync project child-task status into manager state, or launch a child task from manager context. Trigger words include "okstra manager", "okstra-manager", "multiple projects", "cross-project", "group projects together", "manager task".
 ---
 
 # OKSTRA Manager

package/runtime/skills/okstra-memory/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: okstra-memory
-description: Use when the user wants to preserve, remember, store, recall, search, or archive AI/human conversation notes in okstra's global Memory Book. Trigger words include "okstra 에 정리해서 보관해", "memory-book", "기억해둬", "대화 저장", "정리해서 저장", "remember this", "store this conversation", "save this decision", "memory-book 검색", "저장한 메모 찾아줘", "recall a saved decision".
+description: Use when the user wants to preserve, remember, store, recall, search, or archive AI/human conversation notes in okstra's global Memory Book. Trigger words include "organize and store this in okstra", "memory-book", "remember this for me", "save the conversation", "summarize and save", "remember this", "store this conversation", "save this decision", "search the memory-book", "find the note I saved", "recall a saved decision".
 ---
 
 # okstra-memory
@@ -14,7 +14,7 @@ explicitly cites a memory entry later.
 
 ## When to use
 
-- The user says "okstra 에 정리해서 보관해", "기억해둬", "대화 저장",
+- The user says "organize and store this in okstra", "remember this for me", "save the conversation",
   "remember this", or similar.
 - The user asks to search, list, show, or archive stored conversation memory.
 - The user wants decisions, preferences, requirements, people/context notes,
@@ -58,7 +58,7 @@ searching so the rest of the skill can scope to it.
    ```
 
 2. Present a 3-option picker (most-used existing group, next existing group,
-   then always `직접 입력`). For a personal note, recommend `private` as the
+   then always `Enter directly`). For a personal note, recommend `private` as the
    first option. If `groups` is empty or the user makes no selection, the
    default group is `global` (the CLI default in `memory.mjs`).
 3. Carry the chosen group name into every `add` (`--project-group <name>`) and

package/runtime/skills/okstra-rollup/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: okstra-rollup
 description: |
-  Use when the user wants run results from MULTIPLE okstra tasks collected and summarized at once — a task-group digest or a whole-project roll-up, not a single task. Aggregates per-task run count, elapsed time, error count, and latest report path, plus group-level totals and status/category/phase tallies, then synthesizes a cross-task prose summary from the report files. Make sure to use this skill whenever the user mentions "okstra rollup", "롤업", "task-group 요약", "그룹 단위 리포트", "여러 task 결과 모아", "전체 task 현황 요약", "cross-task summary", "그룹 종합 리포트", "모든 task 정리", "run 결과 한꺼번에", even if they don't say "rollup". For a SINGLE task's report/time/errors/recap use okstra-inspect instead; for a forward-looking work plan over non-done tasks use okstra-schedule.
+  Use when the user wants run results from MULTIPLE okstra tasks collected and summarized at once — a task-group digest or a whole-project roll-up, not a single task. Aggregates per-task run count, elapsed time, error count, and latest report path, plus group-level totals and status/category/phase tallies, then synthesizes a cross-task prose summary from the report files. Make sure to use this skill whenever the user mentions "okstra rollup", "rollup", "task-group summary", "group-level report", "collect multiple task results", "whole-project task status summary", "cross-task summary", "consolidated group report", "organize all tasks", "run results all at once", even if they don't say "rollup". For a SINGLE task's report/time/errors/recap use okstra-inspect instead; for a forward-looking work plan over non-done tasks use okstra-schedule-gen.
 ---
 
 # OKSTRA Rollup
@@ -12,18 +12,24 @@ This skill is read-only. It never mutates task artifacts.
 
 ## Step 0: Preflight
 
-Run one Bash tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — a non-literal leading token defeats the `Bash(okstra:*)` permission match):
+<!-- BEGIN FRAGMENT: bash-invocation-rule -->
+Run one Bash tool call, starting with the literal token `okstra` (never wrapped in `if`/`eval`/`export`/`$(...)`/`VAR=...`/`||`/`&&`/`npx` — a non-literal leading token defeats the `Bash(okstra:*)` permission match):
+<!-- END FRAGMENT: bash-invocation-rule -->
 
 ```bash
 okstra preflight --runtime claude-code --json
 ```
 
-Parse the stdout JSON. `ok: true` → carry `projectRoot` as a literal string. `ok: false` → tell the user to run `/okstra-setup` first, then stop. If the call fails with `unknown command: preflight`, the `okstra` binary on PATH predates this skill — tell the user to update it (`npm i -g okstra@latest`), then stop (`/okstra-setup` does not update the binary).
+Parse the stdout JSON. `ok: true` → carry `projectRoot` as a literal string. `ok: false` → tell the user to run `/okstra-setup` first, then stop.
+
+<!-- BEGIN FRAGMENT: preflight-outdated-cli -->
+If the call fails with `unknown command: preflight`, the `okstra` binary on PATH predates this skill — tell the user to update it (`npm i -g okstra@latest`), then stop (`/okstra-setup` does not update the binary).
+<!-- END FRAGMENT: preflight-outdated-cli -->
 
 ## Step 1: Resolve scope
 
-- User named a task-group (e.g. "alpha 그룹 요약") → use it as `--task-group <group>`.
-- User asked for the whole project ("전체 task", "프로젝트 전체") or named no scope → omit `--task-group` (whole catalog).
+- User named a task-group (e.g. "summarize the alpha group") → use it as `--task-group <group>`.
+- User asked for the whole project ("all tasks", "the whole project") or named no scope → omit `--task-group` (whole catalog).
 - If genuinely ambiguous, ask once: one task-group, or the whole project? Do not silently guess a specific group.
 
 ## Step 2: Fetch the roll-up
@@ -62,7 +68,7 @@ Render `Report` as `✓` when `reportPath` is non-empty, else `—`. Build the s
 
 ## Step 4: Synthesize the digest (the summary)
 
-This is the skill's value-add over a bare table. When the user asked to "요약"/"summarize"/"digest"/"정리" (the common case), produce a short cross-task narrative:
+This is the skill's value-add over a bare table. When the user asked to "summarize"/"digest"/"organize" (the common case), produce a short cross-task narrative:
 
 1. For each task with a non-empty `reportPath` whose file exists under `<projectRoot>/<reportPath>`, read it and write a 1–2 line summary of what it accomplished and its recommended next step.
 2. Above the per-task lines, write a 2–4 sentence group-level synthesis: what was delivered across the group, where the open work sits (use `byWorkStatus`/`byCurrentPhase`), and any error hot-spots (tasks with high `errorCount`).