okstra 0.34.1 → 0.36.1

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

@@ -1,173 +0,0 @@
----
-name: okstra-logs
-description: Use when the user asks about okstra worker wrapper log files — listing, sizes, ages, disk usage, or wants to know what `*.log` sidecars exist for past dispatches and which ones are safe to clean up. Trigger words include "okstra logs", "로그 현황", "로그 파일", "log files", "log size", "log status", "로그 정리", "log cleanup".
----
-
-# OKSTRA Logs
-
-Read-only inventory of codex/gemini 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.
-
-## When to Use
-
-- The user wants to see how much disk space okstra wrapper logs consume.
-- The user wants to know which tasks / phases / workers have lingering log
-  sidecars from past dispatches.
-- The user is planning a cleanup and wants ready-to-run `find` commands
-  scoped by age, task-id, or task-group.
-
-## Background
-
-Codex/gemini wrappers (`okstra-codex-exec.sh`, `okstra-gemini-exec.sh`)
-write a sidecar log next to each prompt history file:
-
-```
-.project-docs/okstra/tasks/<task-group>/<task-id>/runs/<phase>/prompts/
-  <worker>-prompt-<phase>-<seq>.md    <-- prompt (git-tracked)
-  <worker>-prompt-<phase>-<seq>.log   <-- live stdout+stderr mirror
-```
-
-The log is truncated at each dispatch (`: > "$log_path"`) — only the latest
-run for a given seq is preserved. Different seqs (`-001`, `-002`, …) keep
-separate files. Long-running implementation dispatches can produce
-multi-MB logs; analysis-phase dispatches are typically smaller.
-
-## Step 0: Verify okstra runtime + project setup
-
-Before any other step, run each of the following commands as a **separate Bash tool call**. Each command starts with the literal token `okstra` so the `Bash(okstra:*)` permission match succeeds. Do **not** wrap any of them in `if`, `eval`, `export`, `$(...)`, `VAR=...`, `||`, or `&&`, and do **not** introduce a `$OKSTRA_CMD` variable or an `npx -y okstra@latest` fallback — those leading tokens defeat the permission match and force a confirmation prompt on every call. The LLM (you) inspects each command's output and decides what to do next in natural language — never in shell.
-
-1. `okstra ensure-installed`
-   If this exits non-zero, tell the user: "okstra not installed — run `npx okstra@latest install` once, then retry this skill." Then stop. Do **not** try to invoke `npx -y okstra@latest ...` as a fallback.
-
-2. `okstra check-project --json`
-   Reads the project from the current working directory. Parse the JSON from stdout. The shape is `{ok, projectRoot, projectJsonPath, projectId}`.
-
-   - `ok: false` → tell the user: "this project has no okstra setup. Run `/okstra-setup` first." Then stop.
-   - `ok: true` → carry `projectRoot` as a literal string and use it as the search root for the steps below.
-
-Subsequent `okstra <subcmd>` calls self-bootstrap their Python path, so this skill never needs `okstra paths --shell` / `export PYTHONPATH=...`.
-
-## Step 1: Inventory
-
-Find all wrapper log files and collect metadata. Use a single `find` to
-keep the I/O cost predictable, then format the results.
-
-Construct the logs root by appending `/.project-docs/okstra/tasks` to the literal `projectRoot` value parsed in Step 0, and paste it as a literal absolute path in place of `<LOGS_ROOT>` below (no shell variables, no `$(...)`):
-
-```bash
-find <LOGS_ROOT> -type f -path '*/runs/*/prompts/*.log' \
-  -printf '%s\t%T@\t%p\n' 2>/dev/null \
-  | sort -k1,1nr
-```
-
-The columns produced are `size_bytes | mtime_epoch | path`.
-
-On macOS, `find -printf` is unavailable. Fall back to `-exec stat` — again substitute the literal `<LOGS_ROOT>`. The `-exec ... {} +` form contains no shell variables and no `$(...)`, so the `Bash(find:*)` permission match holds:
-
-```bash
-find <LOGS_ROOT> -type f -path '*/runs/*/prompts/*.log' -exec stat -f '%z%t%m%t%N' {} + 2>/dev/null | sort -k1,1nr
-```
-
-If the result is empty, report `No wrapper log files found under <projectRoot>` and exit.
-
-## Step 2: Summary table
-
-Group results and emit two tables.
-
-### Table A — Top 20 largest logs
-
-| # | Task | Phase | Worker | Seq | Size | Age | Path |
-|---|------|-------|--------|-----|------|-----|------|
-
-Parse fields from the path:
-- task-group / task-id: from the `tasks/<task-group>/<task-id>/` segment
-- phase: from `runs/<phase>/`
-- worker: from filename prefix before `-prompt-`
-- seq: from filename suffix (last 3-digit segment)
-
-Format sizes as human-readable (KB / MB). Format age as `Nd` (days) or
-`Nh` (hours) from `mtime` relative to "now".
-
-### Table B — Per-task totals
-
-| Task Key | Files | Total Size | Oldest | Newest |
-|----------|-------|-----------:|--------|--------|
-
-Sort by total size descending. "Task Key" = `<project-id>:<task-group>:<task-id>` for consistency with other okstra skills.
-
-### Footer line
-
-```
-Total: N files, X.X MB across M tasks under <PROJECT_ROOT>
-```
-
-## Step 3: Suggested cleanup commands
-
-Emit a fenced bash block the user can copy-paste. Do NOT execute these.
-Each block pairs a dry-run preview (`-print`) with the destructive
-(`-delete`) command so the user can confirm the match set before
-committing.
-
-```markdown
-## Cleanup options (manual)
-
-# 7일 이상 된 로그만 삭제
-find <PROJECT_ROOT>/.project-docs/okstra/tasks \
-  -type f -path '*/runs/*/prompts/*.log' -mtime +7 -print    # dry-run
-find <PROJECT_ROOT>/.project-docs/okstra/tasks \
-  -type f -path '*/runs/*/prompts/*.log' -mtime +7 -delete
-
-# 30일 이상 된 로그만 삭제
-find <PROJECT_ROOT>/.project-docs/okstra/tasks \
-  -type f -path '*/runs/*/prompts/*.log' -mtime +30 -print   # dry-run
-find <PROJECT_ROOT>/.project-docs/okstra/tasks \
-  -type f -path '*/runs/*/prompts/*.log' -mtime +30 -delete
-
-# 특정 task-group 의 로그 일괄 삭제 (예: dev-9388)
-find <PROJECT_ROOT>/.project-docs/okstra/tasks/dev-9388 \
-  -type f -name '*.log' -print    # dry-run
-find <PROJECT_ROOT>/.project-docs/okstra/tasks/dev-9388 \
-  -type f -name '*.log' -delete
-
-# 특정 task-id 의 로그 일괄 삭제 (예: dev-9428)
-find <PROJECT_ROOT>/.project-docs/okstra/tasks/*/dev-9428 \
-  -type f -name '*.log' -print    # dry-run
-find <PROJECT_ROOT>/.project-docs/okstra/tasks/*/dev-9428 \
-  -type f -name '*.log' -delete
-
-# 전체 일괄 삭제 (주의)
-find <PROJECT_ROOT>/.project-docs/okstra/tasks \
-  -type f -path '*/runs/*/prompts/*.log' -print    # dry-run
-find <PROJECT_ROOT>/.project-docs/okstra/tasks \
-  -type f -path '*/runs/*/prompts/*.log' -delete
-```
-
-Substitute the literal `<PROJECT_ROOT>` with the resolved absolute path so
-the commands are directly copy-pasteable.
-
-## Step 4: Notes for the user
-
-End the response with these short reminders:
-
-- Logs are truncated on each re-dispatch of the same `seq`, so deleting an
-  in-flight run's log will cause the wrapper to recreate an empty file on
-  the next dispatch — no data loss beyond the current trace.
-- **If a dispatch is currently running, check `okstra status` first** and
-  avoid deleting logs for tasks in `in-progress` state — you will lose
-  the live trace for the active run.
-- Prompt history files (`.md`) are separate and are NOT touched by these
-  commands — only `.log` sidecars.
-- This skill **does not modify any external files itself**, including
-  `.gitignore`. If the project commits `.project-docs/okstra/`, the user
-  may want to add
-  `.project-docs/okstra/tasks/**/runs/**/prompts/*.log` to `.gitignore`
-  manually to keep large logs out of git.
-
-## What this skill is NOT
-
-- Does NOT delete log files. Only inventories and suggests commands.
-- Does NOT touch prompt history files (`.md`), worker results, manifests,
-  or any other okstra state.
-- Does NOT run on a schedule. Invoke explicitly when needed.

package/runtime/skills/okstra-report-finder/SKILL.md

@@ -1,111 +0,0 @@
----
-name: okstra-report-finder
-description: Use when the user provides a task key and needs to find the final report path, or wants to read a previous okstra report to continue work based on its findings. Trigger words include "find report", "show report for", "read the okstra report", "continue from report".
-user-invocable: false
----
-
-# OKSTRA Report Finder
-
-## When to Use
-
-- 사용자가 task-key를 주고 해당 최종 보고서를 찾을 때
-- 이전 okstra 보고서를 읽고 후속 작업을 진행할 때
-- 보고서 내용을 기반으로 구현, 수정, 추가 검증을 시작할 때
-
-## Step 0: Verify okstra runtime + project setup
-
-각 명령은 **별도 Bash tool call** 로 실행한다. 모든 명령은 리터럴 `okstra` 토큰으로 시작해 `Bash(okstra:*)` 권한 매칭을 통과해야 한다. `if`, `eval`, `export`, `$(...)`, `VAR=...`, `||`, `&&` 로 감싸지 말고, `$OKSTRA_CMD` 변수나 `npx -y okstra@latest` 폴백도 도입하지 않는다 — 첫 토큰이 비리터럴이면 권한 매칭이 깨져 호출마다 확인 프롬프트가 뜬다. 각 명령의 출력은 LLM(너) 이 보고 자연어로 분기 판단을 한다 — shell 분기는 쓰지 않는다.
-
-1. `okstra ensure-installed`
-   비정상 종료 → 사용자에게 그대로 안내: "okstra not installed — run `npx okstra@latest install` once, then retry this skill." 그리고 중단. 폴백으로 `npx -y okstra@latest ...` 를 호출하지 않는다.
-
-2. `okstra check-project --json`
-   현재 작업 디렉터리 기준 프로젝트를 읽는다. stdout 의 JSON shape: `{ok, projectRoot, projectJsonPath, projectId}`.
-
-   - `ok: false` → 사용자에게 "this project has no okstra setup. Run `/okstra-setup` first." 안내 후 중단.
-   - `ok: true` → `projectRoot` 를 리터럴 문자열로 들고 catalog/manifest 위치를 잡는다.
-
-후속 `okstra <subcmd>` 호출은 Python path 를 자체 부트스트랩하므로 본 스킬은 `okstra paths --shell` / `export PYTHONPATH=...` 를 필요로 하지 않는다.
-
-## Step 1: Task Key로 Report 경로 찾기
-
-task-key 형식: `<project-id>:<task-group>:<task-id>`
-
-**Normalization**: task-key 매칭은 lowercase 로 수행한다. 디스크상의 group/id 세그먼트는 slugify (lowercase + non-alphanumeric runs → `-`) 된다 (`scripts/lib/okstra/interactive.sh:147`). 따라서 catalog 조회는 case-insensitive 이지만 파일 경로를 만들 때는 slugified segment 를 사용해야 한다.
-
-### 방법 A: task-catalog.json (빠름)
-
-1. `.project-docs/okstra/discovery/task-catalog.json`을 읽는다.
-2. `tasks` 배열에서 `taskKey` 를 lowercase 비교로 매칭한다.
-3. `latestReportPath` 필드는 task-type 과 무관한 "가장 최근 보고서" 이다.
-
-### 방법 B: task-manifest.json (직접)
-
-task-catalog 가 없는 경우:
-
-1. task-key 에서 task-group / task-id 를 추출하고 slugify 한다.
-2. `.project-docs/okstra/tasks/<group-segment>/<id-segment>/task-manifest.json` 을 읽는다.
-3. `latestReportPath` 필드 (task-type 무관, 최신).
-
-### 방법 C: timeline.json (특정 run 의 보고서)
-
-특정 날짜나 run 의 보고서가 필요한 경우:
-
-1. `.project-docs/okstra/tasks/<group-segment>/<id-segment>/history/timeline.json` 을 읽는다.
-2. `runs[]` 배열에서 필터한다. 실제 필드:
-   - `runs[].runTimestamp` (ISO-8601 시작 시각)
-   - `runs[].status` (run 종료 상태)
-   - `runs[].taskType` (`requirements-discovery` 등 phase 이름)
-   - `runs[].reportPath` (해당 run 의 보고서 상대 경로)
-
-### 방법 D: 특정 task-type 의 최신 보고서 (fallback)
-
-`latestReportPath` (방법 A/B) 는 task-type 을 가리지 않는다. 사용자가 *특정* task-type (예: `implementation-planning`) 의 최신 보고서를 요청하면:
-
-1. 디렉토리: `.project-docs/okstra/tasks/<group-segment>/<id-segment>/runs/<task-type-segment>/reports/`
-2. 파일명 패턴: `final-report-<task-type-segment>-<NNN>.md` (`scripts/okstra_ctl/sequence.py:31`)
-3. seq 가 가장 큰 파일이 해당 task-type 의 최신 보고서.
-4. timeline.json 의 `runs[].taskType == <task-type>` 으로 교차검증 가능.
-
-## Step 2: Report 존재 확인
-
-1. `latestReportPath`가 비어있지 않고, 해당 경로의 파일이 실제로 존재하는지 확인한다.
-   - 두 신호 중 하나라도 보고서 존재를 가리키면 경로를 표시한다 (tolerant).
-2. 존재하면 경로를 표시하고 읽을지 사용자에게 확인한다.
-3. 존재하지 않으면 `task-manifest.json`에서 다음 신호를 확인한다:
-   - `latestReportPath`가 비어있거나 누락된 경우, 그리고
-   - `currentStatus`가 `completed`가 아니고, `workStatus`가 `done`이 아니며, `workflow.routingStatus`도 완료를 가리키지 않는 경우
-     → "이 task는 아직 완료되지 않았습니다 (currentStatus: `<currentStatus>`, workStatus: `<workStatus>`)."
-   - 위 신호 중 하나라도 완료를 가리키는데 파일만 없는 경우
-     → "보고서 파일이 존재하지 않습니다: `<path>`"
-
-워크플로 상태 enum은 `todo | in-progress | blocked | done` (workStatus) 와 `currentStatus`의 `completed` / `contract-violated` 등이다. `"completed"` 문자열은 `workStatus`에는 존재하지 않으므로 두 필드를 혼동하지 말 것.
-
-## Step 3: Report 읽기 및 후속 작업 안내
-
-보고서를 읽은 후 사용자에게 가능한 후속 작업을 안내한다:
-
-1. **구현 진행**: 보고서의 "권장 다음 단계" 섹션 기반으로 코드 수정
-2. **추가 검증**: 같은 task-key 로 새 okstra run 실행. 구체 커맨드:
-   ```bash
-   scripts/okstra.sh --task-key <task-key> --task-type <task-type>
-   ```
-   더 풍부한 옵션 (base-ref, workers, render-only 등) 이 필요하면 `okstra-history` 스킬을 사용한다.
-3. **관련 task 확인**: 보고서의 관련 task 참조가 있으면 해당 task 의 보고서도 조회
-
-## Output
-
-```markdown
-## Report for <task-key>
-
-| Field        | Value                                              |
-| ------------ | -------------------------------------------------- |
-| Status       | `<status>`                                         |
-| Task type    | `<task-type>`                                      |
-| Run seq      | `<NNN>`                                            |
-| Run date     | `<runTimestamp ISO-8601>`                          |
-| Report (rel) | `<relative-path-from-project-root>`                |
-| Report (abs) | `<absolute-path>`                                  |
-```
-
-이후 사용자 요청에 따라 보고서를 읽고 후속 작업을 진행한다.

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

@@ -1,246 +0,0 @@
----
-name: okstra-status
-description: Use when the user asks for overall okstra task status, current lifecycle phase, next recommended phase, blockers, approval state, status for a specific task key, OR wants to update a task's workStatus (todo / in-progress / blocked / done). Trigger words include "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> 완료".
----
-
-# OKSTRA Status
-
-## When to Use
-
-- When user wants to view the progress of the entire project
-- When user want to check the current phase, next phase, blockers, and resume points for a specific `task-key`
-- When user want to check which tasks are pending approval or which tasks can be resumed
-
-## Step 0: Verify okstra runtime + project setup
-
-Before any other step, run each of the following commands as a **separate Bash tool call**. Each command starts with the literal token `okstra` so the `Bash(okstra:*)` permission match succeeds. Do **not** wrap any of them in `if`, `eval`, `export`, `$(...)`, `VAR=...`, `||`, or `&&`, and do **not** introduce a `$OKSTRA_CMD` variable or an `npx -y okstra@latest` fallback — those leading tokens defeat the permission match and force a confirmation prompt on every call. The LLM (you) inspects each command's output and decides what to do next in natural language — never in shell.
-
-1. `okstra ensure-installed`
-   If this exits non-zero, tell the user: "okstra not installed — run `npx okstra@latest install` once, then retry this skill." Then stop. Do **not** try to invoke `npx -y okstra@latest ...` as a fallback.
-
-2. `okstra check-project --json`
-   Reads the project from the current working directory. Parse the JSON from stdout. The shape is `{ok, projectRoot, projectJsonPath, projectId}`.
-
-   - `ok: false` → tell the user: "this project has no okstra setup. Run `/okstra-setup` first." Then stop.
-   - `ok: true` → carry `projectRoot` as a literal string into the steps below; reuse it instead of re-resolving.
-
-Subsequent `okstra <subcmd>` calls self-bootstrap their Python path, so this skill never needs `okstra paths --shell` / `export PYTHONPATH=...`.
-
-## Step 1: Overall Project Status
-
-To view the overall project status, read `.project-docs/okstra/discovery/task-catalog.json`. The catalog is the authoritative source — every field listed below (including `workStatus`, `workStatusUpdatedAt`, `workStatusNote`) is projected directly from each `task-manifest.json` by `scripts/okstra_ctl/render.py :: render_task_catalog_discovery`. Do NOT re-open individual manifests for the overview.
-
-Extract the following fields from each task.
-
-| Field | Description |
-|------|------|
-| `taskKey` | `<project-id>:<task-group>:<task-id>` |
-| `taskType` | latest task type |
-| `workCategory` | bugfix / feature / improvement / refactor / ops-change / unknown. Display `unknown` as-is, but flag with `(unset)` annotation so the reader knows the requirements-discovery classification was skipped or no `--work-category` flag was passed. |
-| `currentStatus` | task-level status |
-| `currentPhase` | lifecycle current phase |
-| `currentPhaseState` | lifecycle phase state |
-| `nextRecommendedPhase` | next recommended phase |
-| `routingStatus` | routing decision status |
-| `awaitingApproval` | approval 대기 여부 |
-| `latestRunStatus` | latest run status |
-| `latestReportPath` | latest report path |
-| `latestResumeCommandPath` | latest resume command |
-| `workStatus` | user-managed work status (todo / in-progress / blocked / done; default in-progress) |
-| `updatedAt` | last update time |
-
-Sort by:
-
-1. `updatedAt` Descending
-2. Next, `taskKey`
-
-출력 형식:
-
-The overview table is intentionally narrow so it renders cleanly in a terminal. Only six columns are shown; for any task that needs a closer look (phase state, routing, approval gate, last run status, resume path, etc.) tell the user to run `okstra status <task-key>` for the detail view in Step 2.
-
-If `awaitingApproval` is true OR `routingStatus == "pending"`, append a `*` to the `Next` cell as a visual marker and explain the marker once below the table.
-
-```markdown
-## okstra Status — <project-id>
-
-| # | Task Key | Category | Phase | workStatus | Next |
-|---|----------|----------|-------|------------|------|
-| 1 | proj:group:id | bugfix | error-analysis | in-progress | implementation-planning |
-| 2 | proj:group:id2 | feature | requirements-discovery | done | pending-routing-decision* |
-
-`*` = awaiting user approval or pending routing decision. Run `okstra status <task-key>` for details.
-```
-
-## Step 2: Specific Task Status
-
-Given a specific `task-key` or `task-group + task-id`:
-
-1. If possible, quickly look it up in `task-catalog.json`.
-2. If necessary, read `.project-docs/okstra/tasks/<task-group>/<task-id>/task-manifest.json` directly.
-3. If you need the latest run information, read `history/timeline.json` along with the latest run manifest.
-
-Required fields:
-
-- `taskKey`
-- `taskType`
-- `workCategory`
-- `currentStatus`
-- `latestRunStatus`
-- `workflow.currentPhase`
-- `workflow.currentPhaseState`
-- `workflow.phaseStates`
-- `workflow.lastCompletedPhase`
-- `workflow.nextRecommendedPhase`
-- `workflow.awaitingApproval`
-- `workflow.routingStatus`
-- `workflow.lastSafeCheckpoint`
-- `workStatus`
-- `workStatusUpdatedAt`
-- `workStatusNote`
-- `latestReportPath`
-- `latestResumeCommandPath`
-- `historyTimelinePath`
-
-Output format:
-
-```markdown
-## okstra Task Status — <task-key>
-
-- Work category: `<category>`
-- Current phase: `<phase>`
-- Current phase state: `<phase-state>`
-- Last completed phase: `<phase-or-->`
-- Next recommended phase: `<phase>`
-- Awaiting approval: `<yes|no>`
-- Routing status: `<routing-status>`
-- Task status: `<task-status>`
-- Latest run status: `<run-status>`
-- Latest report: `<relative-path-or-->`
-- Resume command: `<relative-path-or-->`
-- workStatus: `<todo|in-progress|blocked|done>` (updated `<workStatusUpdatedAt-or-->`)
-- workStatus note: `<workStatusNote-or-->`
-
-### Phase States
-
-- `requirements-discovery`: `<state>`
-- `error-analysis`: `<state>`
-- `implementation-planning`: `<state>`
-- `implementation`: `<state>`
-- `final-verification`: `<state>`
-- `release-handoff`: `<state>`
-
-### Safe Resume Checkpoint
-
-- Label: `<checkpoint-label>`
-- Run manifest: `<relative-path-or-->`
-- Team state: `<relative-path-or-->`
-- Report: `<relative-path-or-->`
-- Resume command: `<relative-path-or-->`
-```
-
-## Step 3: Resume and Next-Step Guidance
-
-The status response always includes one of the following options:
-
-1. **Resume current run**
-- If `latestResumeCommandPath` exists, display that path.
-2. **Restart current phase**
-- Indicates whether the task can be re-run with the same `task-key` and the current `taskType`.
-3. **Start next phase**
-- If `workflow.nextRecommendedPhase` is one of `error-analysis`, `implementation-planning`, `implementation`, `final-verification`, or `release-handoff`, that phase is proposed as the next candidate for the Okstra run.
-- If `nextRecommendedPhase` is `pending-release-handoff`, the prior `final-verification` run completed but its verdict still has to be inspected before entering `release-handoff` — surface this as a verdict-gated next step and present `release-handoff` as a candidate only when the cited verdict is `accepted`.
-4. **Need more information**
-- If `nextRecommendedPhase` is `pending-routing-decision` or `routingStatus` is `pending`, this indicates that additional information is required.
-5. **Task complete (terminal)**
-- If `nextRecommendedPhase` is `done-or-follow-up`, the task lifecycle has reached its terminal signal. This is **not** a "next phase" — do not propose a new Okstra run. Surface the latest report and ask the user whether any follow-up task should be opened separately.
-
-## Step 4: Update workStatus
-
-The skill MUST recognize requests to change a task's `workStatus` and update the corresponding `task-manifest.json`.
-
-### Trigger Patterns (recognize both)
-
-**Natural language (Korean / English)**:
-- "DEV-6827 done으로 바꿔줘"
-- "PROD-1623을 blocked로 표시"
-- "DEV-9047 진행중"
-- "Mark DEV-6827 as done"
-
-**Explicit command**:
-- `okstra status set <task-id> <status>`
-- `okstra status set <task-group> <task-id> <status>` (used to disambiguate)
-- `okstra mark <task-id> <status>`
-- `okstra status set <task-id> <status> --note "<note>"`
-
-Accepted `<status>` values: `todo`, `in-progress`, `blocked`, `done`.
-
-### Procedure
-
-1. **Validate status value**. If not in the enum, output an error and the allowed values list. Do not modify any file.
-
-2. **Look up the task** in `.project-docs/okstra/discovery/task-catalog.json` by `task-id` (case-insensitive on both `task-id` and `task-group`).
-   - If the user provided `<task-group>` explicitly, scope the lookup to that group (case-insensitive).
-   - If a single match is found → proceed.
-   - If multiple matches across different `task-group` values → list the groups and ask the user to retry with the explicit form. Example output:
-     ```
-     <TASK-ID>은 여러 task-group에 존재합니다:
-       - <group1>
-       - <group2>
-     다음 형식으로 다시 시도하세요: okstra status set <task-group> <TASK-ID> <status>
-     ```
-     Stop without modifying any file.
-   - If no match → output `<TASK-ID>를 찾을 수 없습니다.` and stop.
-
-3. **Open the matching `task-manifest.json`** at `.project-docs/okstra/tasks/<task-group-segment>/<task-id-segment>/task-manifest.json`. Assemble the path from the catalog entry's `taskGroupPathSegment` and `taskIdPathSegment` fields (these are the filesystem-safe segments emitted by the renderer) — NOT from the raw user-supplied `<task-group>` / `<task-id>` strings, which may differ in case or contain characters that were normalized when the manifest was created. As a defensive shortcut, prefer the `taskManifestPath` field directly when present.
-
-4. **Update fields at the manifest root**:
-   - `workStatus` ← new status value
-   - `workStatusUpdatedAt` ← current ISO-8601 UTC timestamp (e.g. `2026-05-01T10:23:45Z`)
-   - `workStatusNote`:
-     - If `--note` is provided → set the field to its value.
-     - If `--note` is NOT provided → leave any existing `workStatusNote` field untouched (do not delete, do not blank). If the field did not exist before, do not create it.
-
-   **Manifest preservation rules** (critical to avoid silent corruption):
-   - Use a targeted in-place edit (e.g. the Edit tool with old_string/new_string anchors).
-   - Do NOT round-trip the file through `JSON.parse` + `JSON.stringify` — that reorders keys, drops trailing newlines, and normalizes spacing.
-   - Preserve the existing key order, indentation style, and trailing newline of the file exactly.
-
-5. **Confirm in Korean**:
-
-   ```
-   ✓ <TASK-ID> workStatus: <previous> → <new>
-   ✓ task-manifest.json 업데이트됨
-   ```
-
-   Use `<previous>` = `(없음)` if the field was absent before.
-
-### Default Value Convention
-
-If `workStatus` is missing or empty in any manifest, infer the display value from the lifecycle state — DO NOT default to a static `in-progress`:
-
-| Manifest state | Inferred display |
-|---|---|
-| `currentStatus == "completed"` AND `workflow.nextRecommendedPhase == "done-or-follow-up"` | `done` (inferred) |
-| `currentStatus == "completed"` AND `workflow.currentPhaseState == "completed"` | `phase-done` (inferred) |
-| `currentStatus == "contract-violated"` OR `workflow.currentPhaseState == "blocked"` | `blocked` (inferred) |
-| anything else | `in-progress` (default) |
-
-Annotate inferred values with `(inferred)` or `(default)` in the rendered output so the reader can see which value is user-set vs. system-inferred. Do not back-fill the field on read; only write it when the user explicitly issues an update.
-
-### Catalog Sync Note
-
-This skill updates `task-manifest.json` only. `discovery/task-catalog.json` may become stale until it is regenerated by another tool. Downstream consumers (e.g. `okstra-schedule`) should re-read each manifest directly to obtain the authoritative `workStatus`.
-
----
-
-## Output Rules
-
-- Responses should be concise and written in Korean.
-- Use project-relative paths whenever possible.
-- If there is no recent report, display `--`.
-- If a specific task does not exist, explicitly state that it cannot be found based on `task-catalog.json`.
-- If `awaitingApproval` is true, clearly indicate that the task is awaiting user approval.
-
-## Out-of-Scope Backlog
-
-- **Step 0 boilerplate duplication.** The `ensure-installed` + `check-project --json` preamble (literal-token-first, separate Bash calls) is near-identical across every user-facing okstra skill. The Claude Code skill framework has no include/snippet mechanism today, so each skill duplicates the prose. A future change should either (a) extract the preamble into a single `okstra preflight` subcommand the skill can call in one line, or (b) ship the block as a shared SKILL fragment if the framework gains include support. Not actionable inside this skill alone.