OPOS: Skill for Claude Code

task-register

When to use

At the start of a NEW task — NOT a fix or continuation of in-flight work.

The steward invokes this itself; it is not a command the user is expected to type. When chief-of-staff goal-decomposition classifies an opening message as a NEW task, it runs this skill at Notice tier (do it, mention it) — see the steward's "Goal decomposition pattern" step 2. A user MAY still invoke /task-register "<title>" --depts <comma-list> [--plan-file <path>] [--goal "<text>"] directly, but nothing depends on them doing so.

Multi-active tasks are first-class (v0.7.0). An existing .claude/.current-task does NOT block a new registration — the pre-v0.7.0 refuse-guard was removed (see step 4); parallel sessions each open their own task without colliding.

Inputs may be gathered conversationally over multiple AskUserQuestion turns before the GitHub call — the skill doesn't require them all in one CLI invocation. In practice, the calling agent (chief-of-staff) often clarifies title, depts, and goal interactively before making the actual gh issue create call.

Inputs

• title — short title for the GitHub issue (required).
• depts — comma-separated department names; lowercased for label normalization (required).
• plan_file — optional path to a plan file (e.g. under ~/.claude/plans/).
• goal — optional one-paragraph goal. Default: prompt user inline.
• quiet_label_creation — optional bool, default false. When true, suppress per-label warnings from steps 6-7 and emit a single summary line at the end instead ("Auto-created N labels: dept:engineering, dept:company, task").

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: REPO_ROOT=$(git rev-parse --show-toplevel). All file paths in this skill are anchored to $REPO_ROOT.
3. Read $REPO_ROOT/.claude/task-tracking.config.json. Validate repo is non-empty.
4. Parse current active-task array. Read $REPO_ROOT/.claude/.current-task as a newline-delimited array of integers (v0.7.0 array semantics; v0.6.x single-task content parses as 1-element array — fully backwards-compatible). If file is absent or empty → CURRENT_TASKS = []. Apply defensive read-side filtering: drop any line that isn't pure digits (handles partial-write garbage from the rare intra-machine concurrent-register race documented in RISKS Risk 30; v0.8.x candidate is proper flock). Continue regardless of count — multi-active tasks are first-class as of v0.7.0; parallel Claude sessions can each open a fresh task without colliding. The pre-v0.7.0 "refuse if .current-task already exists" guard is REMOVED; the new duplicate check happens at step 10 against the candidate issue number after gh issue create.
5. gh repo view <repo> --json visibility — if visibility is public, print a WARNING to stdout (do not block).
6. Normalize each --depts value: trim whitespace and tr A-Z a-z (lowercase). For each normalized dept name, ensure label dept:<name> exists; create with gh label create dept:<name> --description "Auto-created by task-register" if missing. Warning behavior depends on quiet_label_creation: when false (default), print one warning line per created label AND record each in the history-entry body. When true, accumulate the created labels in a list and defer the announcement to step 11's summary; still record in the history-entry body.
7. Ensure flat label task exists; create if missing (same warning behavior — per quiet_label_creation).
8. Render the issue body from shared/templates/task-issue.md.tmpl, substituting {{TITLE}}, {{DEPARTMENTS}} (joined human-friendly list), {{INITIATED_BY}} (= chief-of-staff + ISO date), {{PLAN_LINK}}, {{GOAL}}. Leave the <!-- progress-log --> marker intact (it serves as an anchor for the optional v1 body-insertion approach; v0 uses comments).
9. Create the issue and capture the URL from stdout. gh issue create does NOT support --json (only gh issue view / gh issue list do — this was a documented-but-wrong pattern in v0.1.x–v0.2.0 fixed in v0.3.0 after issue #6's task-register run hit the bug). The working pattern:

   URL=$(gh issue create --repo "$REPO" --title "$TITLE" --body-file /tmp/body.md \
          --label task $(printf -- '--label dept:%s ' "${DEPTS[@]}"))
   ISSUE_NUM=$(basename "$URL")
   

   Prefer --body-file over --body "$RENDERED" to avoid shell-quoting hell with multi-line bodies. The URL capture is the bare gh issue create stdout (one line, just the URL — stable across recent gh versions); basename parses the trailing /N segment. 9b. Take the lease on the new issue (v0.17.0). This is what makes the task visible as in progress to every other session, on every machine — .current-task never could:

   node .claude/skills/lease/lease.mjs acquire --key "issue:<repo>#$ISSUE_NUM" --intent "<title>"
   

   Handle the exit code exactly as in the lease skill's "Calling the lease from another skill" table: 0 proceed · 9 the company has not opted in to leases — print lease: not configured, gate skipped and proceed exactly as before · anything else STOP. The issue already exists at this point, so on a non-zero exit say so plainly ("issue #N created, but NOT leased: "), finish the remaining steps, and record outcome: partial. Exit 3 (stale clone) means run git pull --ff-only and re-acquire — never work on a task from a clone that is behind.