OPOS: Skill for Claude Code

task-update

When to use

Mid-execution, to record meaningful progress: a slice committed, a blocker encountered, a status flip (in_progress → blocked). NOT for chatty updates. Each invocation requires an idempotency --key so re-running the same update is a no-op.

Inputs

• message — the update body (required; markdown).
• key — idempotency key (required; e.g. a commit SHA or a slice number — anything stable).
• status — optional new status: in_progress | blocked | review. Default: leave the body status line unchanged.
• issue — optional override; default: read the active issue number from <repo-root>/.claude/.current-task. As of v0.7.0 .current-task is a newline-delimited array of active issue numbers; this skill auto-picks when exactly 1 is active and REQUIRES --issue when 2+ are active (see step 3).

Steps

1. (Removed in v0.21.0 — do NOT invoke check-for-updates.) Update checks belong to the SessionStart updater (shared/scripts/opos-session-update.mjs), which runs once a day for free. Invoking the skill here cost ~5 model requests per lifecycle call, each re-reading the whole session context. Step numbering is kept so the references below stay valid.
2. Resolve repo root via git rev-parse --show-toplevel.
3. Read $REPO_ROOT/.claude/.current-task as a newline-delimited array of active task issue numbers (v0.7.0 array semantics; v0.6.x single-task content parses as 1-element array — fully backwards-compatible). Apply defensive read-side filtering (drop non-digit lines per Risk 30). Then determine the target issue number:
   • If --issue <N> was provided → use it directly. (Works regardless of array size; lets a batch script or external caller target a specific issue without parsing the active list.)
   • Else if the array has EXACTLY 1 entry → use that entry. This preserves v0.6.x single-task workflow behavior; users who only ever work on one task at a time see no change.
   • Else if the array has >1 entries (multi-active parallel-session workflow as of v0.7.0) → ABORT with: Multiple active tasks: #<comma-list>. Pass --issue <N> to specify which one to update. Do not guess; the user must disambiguate.
   • Else (array empty / file absent) → ABORT with: No active task. Open one with task-register, or pass --issue <N> explicitly.
4. Read $REPO_ROOT/.claude/task-tracking.config.json. Validate repo.
5. gh issue view <number> --repo <repo> --json comments,state — abort if state is CLOSED (the user must reopen with gh issue reopen or invoke task-complete instead). 5b. Lease gate (v0.17.2). Take — or confirm you already hold — the lease on the task:

   node .claude/skills/lease/lease.mjs acquire --key "issue:<repo>#<number>" --intent "<one line: what this session is doing on the task>"
   

   acquire, not check, on purpose. If this session already holds the lease it is a no-op that exits 0. If the task is free it takes the lease, which posts the 🔒 claim comment on the issue so every other session and every human sees who is working on it. If another session holds it, it exits 2 in every enforcement mode — so two sessions can never both write to one task, even while issue: enforcement is still warn. check in warn mode would only have logged.