okstra 0.88.1 → 0.88.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "okstra",
-  "version": "0.88.1",
+  "version": "0.88.2",
   "description": "Multi-agent cross-verification orchestrator runtime + Claude Code skills.",
   "license": "MIT",
   "author": "devonshin",

package/runtime/BUILD.json

@@ -1,5 +1,5 @@
 {
-  "package": "0.88.1",
-  "builtAt": "2026-06-17T05:43:28.195Z",
+  "package": "0.88.2",
+  "builtAt": "2026-06-17T07:14:48.667Z",
   "repoRoot": "/home/runner/work/okstra/okstra"
 }

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

@@ -176,9 +176,20 @@ Order of operations:
    paths under `<task-group>/sub.../`, and those paths cannot be formed
    until `task_group` is known. Without this preflight the recursive walk
    would either stall mid-collection or invent a placeholder group.
+
+   **Sequential, never batched.** Run Step 2a as its **own**
+   `AskUserQuestion` call here, then ask sub-step 1's ticket question in a
+   **separate** call. Do NOT combine the task-group question and the
+   ticket-ref question into one `AskUserQuestion` — they are asked one at a
+   time, task group first (this preflight), ticket ref second. When you
+   relay this preflight, tell the user in one line *why* task group comes
+   before the ticket (it scopes where this ticket's brief — and any
+   sub-ticket briefs — are written).
 1. `AskUserQuestion` (free text):
    `"Ticket key or URL (e.g. LIN-1234, PROJ-42, https://linear.app/..., https://your.atlassian.net/browse/...)"` →
-   `ticket_ref`.
+   `ticket_ref`. Issue this only **after** Step 2a's task-group answer is in
+   hand — never in the same `AskUserQuestion` call as the task-group
+   question.
 2. Auto-detect the tracker by URL host or key prefix (`linear.app` → Linear,
    `atlassian.net` or `JIRA_*` pattern → Jira, `github.com/.../issues/` →
    GitHub, `notion.so` → Notion). If detection fails, ask once more via
@@ -335,12 +346,38 @@ Once validation passes, jump to Step 2 (task key).
 
 ### 2a. Task group
 
-`AskUserQuestion` (free text):
+Offer existing groups as recommendations before accepting a new one — never
+ask a bare free-text question that forces the user to retype an existing
+group from memory. First collect the project's known task groups (each
+command is its own Bash call starting with the literal token `okstra`, per
+Step 0):
+
+```bash
+okstra task-list
+```
+
+Parse the JSON `tasks[]` array; collect the **distinct** `taskGroup` values
+ordered by `updatedAt` descending. Take the **2 most-recent** distinct
+groups as recommendations.
+
+`AskUserQuestion` (single-select):
+
+- **Label**: `"Task group?"`
+- **Options** (recommendations first, `직접 입력` always last):
+  1. (and 2.) each recommended existing group, most-recent first —
+     label `<group> (기존)` (e.g. `uploadfont (기존)`).
+  3. `직접 입력` — free-text for a new or other group.
+
+When the user picks an existing group, use its value verbatim. When they
+pick `직접 입력`, take a free-text value via a follow-up question.
 
-- `"Task group (e.g. backend-api, INV-1234, refactor)"` → `task_group`
+If `okstra task-list` returns an empty `tasks[]` (no prior tasks), skip the
+picker and ask one free-text question:
+`"Task group (e.g. backend-api, INV-1234, refactor)"` → `task_group`.
 
 Slug rule: same as `okstra-run` Step 3 — slugify, must have at least one
-alphanumeric character.
+alphanumeric character. Note that an existing group's value is already a
+slug; a `직접 입력` value is slugified before use.
 
 If `task_group` was already collected by Step 1b sub-step 0 (tracker
 preflight), reuse that value silently — do NOT ask again.