ops-wr

name	ops-wr
description	Operate the wr relationship ledger and paired Linear/Jira workflow; apply or inspect this repository's remote Cloudflare D1 migrations through Drizzle Kit with Wrangler authentication. Use for task/session/worktree/PR/workpad operations, D1/Drizzle migration history, remote migration application, or Wrangler credential setup.

Operate wr

Use wr only as a relationship ledger. Do not treat it as an orchestrator or dependency manager.

Check repository opt-in

Inspect enabled repositories before recording work:

wr config list

Enable or disable the current repository only when the user has requested that tracking state:

wr config enable .
wr config disable .
wr server open

If the repository is not enabled and the user has not authorized opt-in, report that condition instead of enabling it implicitly. Enabling any linked worktree enables the whole repository.

Inspect context

Run wr show to inspect the current session and checkout. Use an explicit reverse lookup when the current context is unavailable:

wr show --task MAL-123
wr show --worktree .
wr show --json
wr doctor
wr task list
wr pr list
wr repo list
wr run list
wr run sync
wr run list --pr 123
wr session list --task MAL-123
wr session tree --session claude:<session-id>
wr checkout list --session <session-id>
wr execution list --branch feature/foo
wr link list --pr 123
wr branch list --task MAL-123
wr terminal list --task MAL-123
wr run focus <session-id>

wr show --json は、関連 task と execution、PR、link をまとめた JSON を返す。 resource コマンドの --json FIELD,... や --jq FILTER とは異なり、フィールド指定は受け取らない。

Worktree の作成が必要な場合は wt add を使う。ヘルプは wt help で確認し、 対応していない wt add --help は使わない。

Use wr --help, wr help RESOURCE, or wr RESOURCE ACTION --help for command discovery. The link resource currently supports only workpads; it does not store arbitrary URLs such as Confluence links:

wr link workpad add ./workpad.md --task MAL-123

Resource list commands use the current repository inside Git and the global ledger outside Git. Use --global explicitly when a repository-local command needs global results. Filter tasks with wr task list --status active.

Use wr task list, wr session list, wr run list, wr checkout list, wr execution list, wr link list, wr pr list, wr branch list, wr terminal list, and wr repo list to choose the output resource. Filter any resource by a stored relationship with --task, --session, --run, --checkout, --execution, --link, --terminal, --repo, --worktree, --branch, or --pr. Pass the raw Codex thread ID, Claude session ID, or Devin session ID to --session, without a CLI prefix when the corresponding CLI environment is available. Otherwise pass the explicit devin:<session-id> form for Devin. --task accepts the Linear issue identifier. Use --limit NUMBER to bound ordered results, --json FIELD,... for structured output, and --jq EXPRESSION only when the installed jq command is available. Pass bare --json to discover fields.

wr session list refers to stable CLI sessions. wr run list refers to individual SessionRuns and wr run focus can focus a related iTerm2 pane. The human-readable session field uses claude:<session-id>, codex:<thread-id>, or devin:<session-id>.

Hooks collect every supported session ID inherited by a child process. To persist a direct parent only when it is known, a launcher skill may pass WR_PARENT_CLI_SESSION=<cli>:<id> to that one child launch. Do not infer a parent from ambient IDs, and leave the variable unset when it is ambiguous. wr session tree --session claude:<session-id> shows the ordered ancestor path and the target session's descendants; --json returns the same structure as ancestors and nested children.

Use wr run sync on each Device to end active runs whose recorded iTerm2 sessions no longer exist. It leaves runs without a terminal ID unchanged.

The previous plural resource commands, wr link workpad REF, and wr link remove workpad REF are temporary compatibility paths. Do not use them in new instructions; migrate existing callers because they will be removed later.

If session discovery fails, pass the existing session ID with --session. Do not override a discovered session with a conflicting explicit value. Mutating commands automatically register a discovered session and create an implicit session run and checkout when the context is not registered yet. Commands that name a task also register that task when the operation establishes or updates it, such as task done, task cancel, pr add --task, and link workpad add --task. Use $adopt-wr-session for full reconstruction of an already-running session with multiple remembered relationships.

Track task work

For substantive work, register the task in both systems before starting execution:

1. Find or create the corresponding Linear issue using the Linear skill.
2. Find or create the corresponding Jira issue using the available Jira/Atlassian skill. Reuse an existing Jira issue when one already represents the same work; do not create duplicates.
3. Record both issue keys in the task's workpad or the user-facing handoff. wr stores the Linear issue identifier as its task key and has no Jira field; do not invent a wr option for Jira.
4. Start and manage the wr relationship from the Linear issue key.

Start an execution after selecting the task and checkout:

wr task add MAL-122 --title "Queued task"
wr task start MAL-123 --title "Task title" --worktree .

Use wr task add to register unstarted work with open status. It does not require a CLI session and does not create an execution. Repeating it preserves the current status and only updates an explicitly provided title.

Complete only the selected task. If the named task is not registered, wr registers it before completing it:

wr task done MAL-123

Cancel a task only when work on it should stop, abandoning its active executions:

wr task cancel MAL-123

When completing or cancelling work, update both the Linear and Jira issues to the corresponding final state. If the Jira connector or project mapping is unavailable, stop before claiming task registration is complete and report the missing Jira registration.

Starting a completed task reopens it and reports that change. Completing a task finishes its execution in the current CLI session and abandons active executions for the same task in other sessions. It does not alter executions for other tasks.

Attach artifacts

Register a GitHub pull request from its checkout. This command calls gh, automatically registers a task named by --task when needed, and writes nothing if GitHub lookup fails:

wr pr add 122
wr pr add 123 --task MAL-123
wr pr add 124 --task MAL-124 --parent 123
wr pr remove 123 --task MAL-123
wr pr sync
wr pr sync --all
wr sync

wr pr add creates a task relationship only when --task is provided. It always records the current session run and checkout. Run wr pr sync to refresh GitHub state for registered pull requests without requiring a current session or repository. It checks unknown and open pull requests by default; --all also checks closed and merged pull requests. After creating, updating, or rebasing pull requests, run wr sync before the next user handoff or final report. That command records session run and checkout relationships without inferring tasks.

Register a workpad. A task named by --task is registered when needed:

wr link workpad add ./workpad.md
wr link workpad add MOQ-1291
wr link workpad add ./workpad.md --task MAL-123
wr link workpad remove MOQ-1291
wr link workpad remove ./workpad.md --task MAL-123

Workpad references may be existing paths or identifiers such as task IDs. Existing paths are normalized. Workpads are always associated with the current checkout and create a task relationship only when --task is provided.

Preserve boundaries

• Do not edit the relationship ledger storage directly. Use the wr CLI or Worker API.
• Do not call wr internal manually; session hooks own those commands.
• Do not enable repositories speculatively.
• Do not infer task dependencies or start workflows.
• Do not place wr sync in lifecycle hooks; invoke it after explicit GitHub work or before handoff.
• Report ambiguity or command failure instead of creating speculative relationships.

D1 Migrations

This repository uses Drizzle's __drizzle_migrations history, separate from Wrangler's d1_migrations history. Never apply schema or migration-history changes through wrangler d1 execute or wrangler d1 migrations apply. Use Wrangler only for read-only history inspection and for securely obtaining credentials for Drizzle Kit.

If bunx wrangler d1 migrations apply DB --remote reports historical migrations as pending on an existing remote DB with __drizzle_migrations, do not apply them. It uses the wrong history table and can replay an already-applied schema change.

Inspect both histories before deciding:

bunx wrangler d1 execute DB --remote --command "SELECT * FROM sqlite_schema WHERE name IN ('__drizzle_migrations','d1_migrations')"
bunx wrangler d1 execute DB --remote --command "SELECT * FROM __drizzle_migrations ORDER BY created_at"
bunx wrangler d1 execute DB --remote --command "SELECT * FROM d1_migrations ORDER BY applied_at"

Apply generated migrations only through Drizzle Kit:

env \
  CLOUDFLARE_ACCOUNT_ID="$(bunx wrangler whoami --json | jq -r '.accounts[0].id')" \
  CLOUDFLARE_DATABASE_ID="$(bunx wrangler d1 list --json | jq -r '.[] | select(.name == "wr") | .uuid')" \
  CLOUDFLARE_D1_TOKEN="$(bunx wrangler auth token --json | jq -r '.token')" \
  bun run db:migrate

The JSON form of wrangler auth token prevents the Wrangler banner from entering CLOUDFLARE_D1_TOKEN. Keep the token in command substitution or an environment variable; never print it. If credential acquisition or Drizzle migration fails, stop and report the failure. Do not substitute a direct D1 write.