@brainervirus/workit-core 0.8.9 → 0.8.11

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@brainervirus/workit-core",
-  "version": "0.8.9",
+  "version": "0.8.11",
   "private": false,
   "description": "Workit — workflow rails for agentic coding: specs, plans, YouTrack, CI-gated commits (shared core)",
   "keywords": [

package/scripts/sync-release-manifests.ts

@@ -0,0 +1,72 @@
+#!/usr/bin/env bun
+// Post-release manifest sync (AR-15): semantic-release bumps package versions
+// only inside the ephemeral CI checkout, so the committed manifests stay frozen
+// while tags march on. This script aligns every tracked manifest with the
+// latest released tag and is safe to re-run — a fully synced tree changes
+// nothing. The workflow step wraps it with a `[skip ci]` commit so main always
+// carries the released version after a release.
+import { execFileSync } from "node:child_process";
+import { readFileSync, writeFileSync } from "node:fs";
+import { resolve } from "node:path";
+
+export const SYNC_MANIFEST_PATHS = [
+  "package.json",
+  "packages/workit-core/package.json",
+  "packages/workit-opencode/package.json",
+  "packages/workit-cursor/package.json",
+  "packages/workit-cli/package.json",
+  // Kept in lockstep with packages/workit-core/package.json by contract test.
+  "packages/workit-cursor/.cursor-plugin/plugin.json",
+];
+
+export type ManifestSyncResult = { version: string; changed: string[] };
+
+/**
+ * Write `version` (a bare semver or a leading-v git tag) into every tracked
+ * manifest under `root`. Idempotent: manifests already at the target version
+ * are left byte-untouched and omitted from `changed`. Throws on a value that
+ * is not a plain release version (`latest`, branches, ranges).
+ */
+export function syncManifests(root: string, tagOrVersion: string): ManifestSyncResult {
+  const match = /^v?(\d+\.\d+\.\d+(?:[-+][0-9A-Za-z.-]+)?)$/.exec(tagOrVersion.trim());
+  if (!match) throw new Error(`invalid version tag: ${JSON.stringify(tagOrVersion)}`);
+  const version = match[1];
+  const changed: string[] = [];
+  for (const rel of SYNC_MANIFEST_PATHS) {
+    const file = resolve(root, ...rel.split("/"));
+    const parsed = JSON.parse(readFileSync(file, "utf8"));
+    if (parsed.version === version) continue;
+    parsed.version = version;
+    writeFileSync(file, `${JSON.stringify(parsed, null, 2)}\n`, "utf8");
+    changed.push(rel);
+  }
+  return { version, changed };
+}
+
+/** The newest `v*` tag by descending semver refname order (empty repo throws). */
+export function latestReleaseTag(cwd?: string): string {
+  const out = execFileSync("git", ["tag", "--list", "v*", "--sort=-v:refname"], {
+    cwd,
+    encoding: "utf8",
+    stdio: ["pipe", "pipe", "pipe"],
+  })
+    .split("\n")
+    .map((line) => line.trim())
+    .filter(Boolean);
+  const tag = out[0];
+  if (!tag) throw new Error("no v* release tag found — run after the first semantic-release");
+  return tag;
+}
+
+if (import.meta.main) {
+  const root = process.argv[3]
+    ? resolve(process.argv[3])
+    : resolve(import.meta.dir, "..", "..", "..");
+  const tag = process.argv[2] ?? latestReleaseTag(root);
+  const { version, changed } = syncManifests(root, tag);
+  console.log(
+    changed.length > 0
+      ? `synced ${changed.length} manifest(s) to ${version}: ${changed.join(", ")}`
+      : `manifests already at ${version}`,
+  );
+}

package/skills/wk-changelog/SKILL.md

@@ -6,10 +6,10 @@ description: Preview and apply a Keep a Changelog update.
 # Changelog
 
 1. Load this skill explicitly through OpenCode's `skill` tool.
-2. Call the read-only `workflow_changelog_context` context tool; its result is ground truth.
+2. Call the read-only `workit_changelog_context` context tool; its result is ground truth.
 3. Draft the exact insertion preview, including target heading, categories, and bullets.
 4. Use native `question` with concise choices and allow a custom answer before changing the file.
-5. Call `workflow_changelog_apply` only after approval with `confirmed: true`.
+5. Call `workit_changelog_apply` only after approval with `confirmed: true`.
 6. Report the structured success, failure stage, or partial result; never infer success.
 
 Target `## [Unreleased]` unless the user requests a release. Use only Added, Changed, Deprecated, Removed, Fixed, or Security; group user-visible behavior and skip internal-only work. The apply tool must merge into existing category headings, preserve all unrelated lines, and skip duplicate bullets. If normalization is needed, include it in the same preview and approval. Do not hand-edit the changelog, version packages, tag, or commit. `todowrite` and `task` are unnecessary here.

package/skills/wk-commit/SKILL.md

@@ -7,10 +7,10 @@ disable-model-invocation: true
 # Commit
 
 1. Load this skill explicitly through OpenCode's `skill` tool.
-2. Call the read-only `workflow_git_context` context tool with any selected paths; its result is ground truth.
+2. Call the read-only `workit_git_context` context tool with any selected paths; its result is ground truth.
 3. Draft the exact Conventional Commit message and the already-staged file set.
 4. Use native `question` with concise choices and allow a custom answer before committing.
-5. Call `workflow_commit` only after approval with `confirmed: true` and the reviewed `message`.
+5. Call `workit_commit` only after approval with `confirmed: true` and the reviewed `message`.
 6. Report the structured success, failure stage, or partial result; never infer success.
 
-Never stage files automatically: `workflow_commit` commits the current index only. Stop for an empty index, partial staging ambiguity, unrelated staged files, secrets, protected branches, or failed hooks. Never push, bypass hooks, use `--no-verify`, or claim files were committed unless the result proves it. Keep related code, tests, and docs in one coherent commit; do not invent extra commit groups. `todowrite` and `task` are unnecessary here.
+Never stage files automatically: `workit_commit` commits the current index only. Stop for an empty index, partial staging ambiguity, unrelated staged files, secrets, protected branches, or failed hooks. Never push, bypass hooks, use `--no-verify`, or claim files were committed unless the result proves it. Keep related code, tests, and docs in one coherent commit; do not invent extra commit groups. `todowrite` and `task` are unnecessary here.

package/skills/wk-docs-refresh/SKILL.md

@@ -6,10 +6,10 @@ description: Refresh stale repository documentation from structured change conte
 # Docs refresh
 
 1. Load this skill explicitly through OpenCode's `skill` tool.
-2. Call the read-only `workflow_docs_context` context tool; its result is ground truth.
+2. Call the read-only `workit_docs_context` context tool; its result is ground truth.
 3. Draft the smallest factual documentation edit from structured facts.
 4. Use native `question` with concise choices and allow a custom answer only if the requested edit scope is ambiguous.
-5. Apply approved edits with normal OpenCode file tools, then call `workflow_verify`.
+5. Apply approved edits with normal OpenCode file tools, then call `workit_verify`.
 6. Report the structured success, failure stage, or partial result; never infer success.
 
 Prefer README changes when stale, then directly related tracked documentation. Preserve tone and structure; do not invent features, commands, environment variables, screenshots, or install steps. Do not make stylistic rewrites, commit, or modify product code. Report verification exactly. Use `todowrite` only when multiple requested documents need tracking; `task` is unnecessary.

package/skills/wk-handoff/SKILL.md

@@ -7,13 +7,13 @@ disable-model-invocation: true
 # Handoff
 
 1. Load this skill explicitly through OpenCode's `skill` tool.
-2. Call the automatic `workflow_handoff_session` tool with the full user message as `message`; its result is ground truth.
+2. Call the automatic `workit_handoff_session` tool with the full user message as `message`; its result is ground truth.
 3. The tool resolves the tracked spec, plan, and SDD context and seeds the continuation session.
 4. This workflow needs no `question`: the explicit invocation is approval.
 5. Pass only `message`; the tool itself recognizes an exact `--stay` flag and otherwise selects the new session.
 6. Report the structured success, failure stage, or partial result; never infer success.
-7. After any `workflow_handoff_session` result—success, partial, or failure—end the originating turn immediately after one status message. Never create todos, execute the plan inline, modify files, retry handoff, or call another tool.
-8. A destination run that executes the plan must still end with `workflow_plan_complete` (or the CLI `workit flow complete`) once the SDD ledger is complete and repository verification passes, and never finish the run while the plan is still `active`.
+7. After any `workit_handoff_session` result—success, partial, or failure—end the originating turn immediately after one status message. Never create todos, execute the plan inline, modify files, retry handoff, or call another tool.
+8. A destination run that executes the plan must still end with `workit_plan_complete` (or the CLI `workit flow complete`) once the SDD ledger is complete and repository verification passes, and never finish the run while the plan is still `active`.
 
 Handoff titles continuation sessions `Workit: <slug>` (never `Continue <slug>`). OpenCode's native `Continue opencode -s <session-id>` epilogue is the valid manual recovery command when host selection is unavailable (`stage: "select"`): `selected: false` with a `sessionID` is a partial success — use `opencode -s <session-id>` to resume, not a Workit bug.
 

package/skills/wk-implement/SKILL.md

@@ -11,14 +11,14 @@ The parent agent is coordinator-only. It must not edit product code or perform d
 ## Native setup
 
 1. Load this skill explicitly through OpenCode's `skill` tool.
-2. Call read-only `workflow_plan_tasks` and `workflow_sdd_context`; their structured results are ground truth.
-3. Call `workflow_flow_status` with the plan path and hard-stop unless `spec.status === "approved"`, `plan.status === "approved"`, and `menu.presented === true`. If any gate is missing, run the required approval flow (`workflow_spec_approve`/`workflow_plan_approve` after the user's native-question approval, `workflow_plan_menu` after the post-plan menu) and re-check — never start tasks on a draft or unapproved plan.
+2. Call read-only `workit_plan_tasks` and `workit_sdd_context`; their structured results are ground truth.
+3. Call `workit_flow_status` with the plan path and hard-stop unless `spec.status === "approved"`, `plan.status === "approved"`, and `menu.presented === true`. If any gate is missing, run the required approval flow (`workit_spec_approve`/`workit_plan_approve` after the user's native-question approval, `workit_plan_menu` after the post-plan menu) and re-check — never start tasks on a draft or unapproved plan.
 4. Initialize native `todowrite` from returned tasks and mark ledger-completed task IDs completed.
-5. Call `workflow_resolve_branch`, then show the current branch, target branch, and stash behavior before any branch checkout/setup mutation.
+5. Call `workit_resolve_branch`, then show the current branch, target branch, and stash behavior before any branch checkout/setup mutation.
 6. Always use native `question` before that mutation. For a clean tree, ask whether to proceed or cancel. For a dirty tree, add the stash choice and state what will be stashed; allow a custom answer.
-7. Call `workflow_branch_setup` with `confirmed: true` only after approval; never use worktrees. Flow-tool confirmations are never agent-typed booleans and never caller-supplied evidence: the plugin records your native-`question` answer as a host-observed one-use receipt (`attested: true`, `callID`, `selectedLabel`, `recordedAt`) consumed by the approval/menu tools — no evidence argument exists. Delegated worker status comes from host session parentage (`parentID`), never a caller `role` field.
+7. Call `workit_branch_setup` with `confirmed: true` only after approval; never use worktrees. Flow-tool confirmations are never agent-typed booleans and never caller-supplied evidence: the plugin records your native-`question` answer as a host-observed one-use receipt (`attested: true`, `callID`, `selectedLabel`, `recordedAt`) consumed by the approval/menu tools — no evidence argument exists. Delegated worker status comes from host session parentage (`parentID`), never a caller `role` field.
 8. Report any setup failure stage or partial result; never infer success.
-9. Fill specs/plans from the quality templates: `templates/spec-template.md` for specs, `templates/plan-template.md` for plans. After `workflow_docs_validate`, surface the returned `quality` findings: hard findings (missing required section, missing CA-XX) block task start unless the user explicitly waives them; warnings are advisory.
+9. Fill specs/plans from the quality templates: `templates/spec-template.md` for specs, `templates/plan-template.md` for plans. After `workit_docs_validate`, surface the returned `quality` findings: hard findings (missing required section, missing CA-XX) block task start unless the user explicitly waives them; warnings are advisory.
 
 Working state lives only in gitignored `docs/<slug>/sdd/` — never `.superpowers/sdd`, never an extra nested slug level. Load the package-neutral execution contract by name, not an installation-specific path.
 
@@ -27,21 +27,21 @@ Working state lives only in gitignored `docs/<slug>/sdd/` — never `.superpower
 For every plan task whose ID is absent from `completed_task_ids`:
 
 1. Mark it `in_progress` with `todowrite`.
-2. Create its brief with `workflow_sdd_task_brief` using `confirmed: true` and the parsed `section_text`.
+2. Create its brief with `workit_sdd_task_brief` using `confirmed: true` and the parsed `section_text`.
 3. Use `task` with the built-in `explore` agent for read-only discovery when needed, then a fresh built-in `general` agent to implement from the brief. The parent remains coordinator-only.
 4. Require product changes to follow TDD: failing check first, minimal implementation, passing focused check.
-5. Create the review package with `workflow_sdd_review_package` using `confirmed: true`.
-6. Dispatch separate `general` agents for spec-compliance review and code-quality review. **Blocking findings** (Critical, Important, or spec-compliance) may trigger at most **two** fix+re-review rounds per task. **Advisory** findings (Minor, style, YAGNI, taste) never pause the loop — append them with `workflow_sdd_append_advisory` (`--task <id> --text <text>`) using `confirmed: true`.
-7. Append the validated ledger line with `workflow_sdd_append_progress` using `confirmed: true`, then mark the task completed with `todowrite`.
+5. Create the review package with `workit_sdd_review_package` using `confirmed: true`.
+6. Dispatch separate `general` agents for spec-compliance review and code-quality review. **Blocking findings** (Critical, Important, or spec-compliance) may trigger at most **two** fix+re-review rounds per task. **Advisory** findings (Minor, style, YAGNI, taste) never pause the loop — append them with `workit_sdd_append_advisory` (`--task <id> --text <text>`) using `confirmed: true`.
+7. Append the validated ledger line with `workit_sdd_append_progress` using `confirmed: true`, then mark the task completed with `todowrite`.
 
 Each task lands exactly one contiguous non-empty commit range (`base..head`): fix rounds append commits to that range and never rewrite/amend an active review range; each progress line records the task's real base..head shas.
 
 Never redispatch completed task IDs. Pass task briefs and review diffs to agents; do not make them reparse the plan. Keep commits on the in-place feature/bugfix branch.
 
-Delegated authority is direct-child-only: a worker is the session whose host `parentID` exactly equals the activating coordinator's recorded `coordinator_session_id`; missing, mismatched, or multi-owner lineage fails closed with `delegation_lineage_denied`, and nested `opencode` launches are denied during active delegated work. An authorized child receives only the compact worker contract — execute the supplied brief, follow TDD, land one contiguous non-empty commit range, report results — never coordinator guidance, `wk-implement`, or ledger management. Coordinator bookkeeping (briefs, review packages, progress, advisories via `workflow_sdd_*`) stays with the coordinator session.
+Delegated authority is direct-child-only: a worker is the session whose host `parentID` exactly equals the activating coordinator's recorded `coordinator_session_id`; missing, mismatched, or multi-owner lineage fails closed with `delegation_lineage_denied`, and nested `opencode` launches are denied during active delegated work. An authorized child receives only the compact worker contract — execute the supplied brief, follow TDD, land one contiguous non-empty commit range, report results — never coordinator guidance, `wk-implement`, or ledger management. Coordinator bookkeeping (briefs, review packages, progress, advisories via `workit_sdd_*`) stays with the coordinator session.
 
 ## Final gate
 
-After all remaining tasks, dispatch a final full-branch code review, run `workflow_verify`, and report exact per-check results. Present the full `<SDD_DIR>/advisories.md` roll-up once, then use native `question` so the user can choose which advisory items to fix, discuss, or discard. Only then may advisory fixes run. Use `workflow_git_context` for the final commit preview and the `wk-commit` skill for any approved commit. If a tracked stash reference exists, preview reapplication with `question`, then call `workflow_branch_setup` with `confirmed: true` only after approval.
+After all remaining tasks, dispatch a final full-branch code review, run `workit_verify`, and report exact per-check results. Present the full `<SDD_DIR>/advisories.md` roll-up once, then use native `question` so the user can choose which advisory items to fix, discuss, or discard. Only then may advisory fixes run. Use `workit_git_context` for the final commit preview and the `wk-commit` skill for any approved commit. If a tracked stash reference exists, preview reapplication with `question`, then call `workit_branch_setup` with `confirmed: true` only after approval.
 
-**Mandatory:** end the run by calling `workflow_plan_complete` (OpenCode/Cursor) or the CLI `workit flow complete` (CLI host) after the final task once the SDD ledger is complete (all task IDs appended) and `workflow_verify` passes — a complete ledger and green verification are the tool's gates. Never finish the run while the plan is still `active`.
+**Mandatory:** end the run by calling `workit_plan_complete` (OpenCode/Cursor) or the CLI `workit flow complete` (CLI host) after the final task once the SDD ledger is complete (all task IDs appended) and `workit_verify` passes — a complete ledger and green verification are the tool's gates. Never finish the run while the plan is still `active`.

package/skills/wk-issue-update/SKILL.md

@@ -9,10 +9,10 @@ disable-model-invocation: true
 Read [references/youtrack-update-style.md](references/youtrack-update-style.md) before drafting. Chat follows the user's language; the comment body is manager-friendly Spanish (`es-CL`).
 
 1. Load this skill explicitly through OpenCode's `skill` tool.
-2. Ask in plain prose for the user-provided issue URL or ID, call `workflow_youtrack_parse_issue`, then read-only `workflow_youtrack_context`; structured results are ground truth.
-3. Gather the user's notes, call `workflow_youtrack_parse_duration`, polish only supported facts, and call `workflow_youtrack_draft` for the exact comment preview.
+2. Ask in plain prose for the user-provided issue URL or ID, call `workit_youtrack_parse_issue`, then read-only `workit_youtrack_context`; structured results are ground truth.
+3. Gather the user's notes, call `workit_youtrack_parse_duration`, polish only supported facts, and call `workit_youtrack_draft` for the exact comment preview.
 4. Use native `question` with concise choices and allow a custom answer to approve the reviewed comment and time entry.
-5. Call `workflow_youtrack_post` only after approval with `confirmed: true`, `issueId`, `markdown`, and `minutes`.
+5. Call `workit_youtrack_post` only after approval with `confirmed: true`, `issueId`, `markdown`, and `minutes`.
 6. Report the structured success, failure stage, or partial result; never infer success.
 
 Never guess the issue, compute minutes, pass a date, expose tokens, or post Git/file details as the update. Never present a clickable `question` option whose label is an instruction to type free text (e.g. "Type the issue URL/ID"): clicking an option returns the label literal, not the typed value, so ask for free text in prose instead, with the custom answer field enabled. Preserve the user's paragraph voice, explain technical terms plainly, and avoid robotic status bullets. `todowrite` and `task` are unnecessary here.
@@ -21,7 +21,7 @@ Consume the standard Result envelope:
 
 - If `result.ok` is true, report only effects proven by `result.data`.
 - If false, use `result.data.postedComment` and `result.data.loggedMinutes` to distinguish completed effects.
-- If `result.data.retry === "workflow_youtrack_post"`, use native `question` to ask whether to retry the unchanged reviewed `issueId`, `markdown`, and `minutes`. On approval, call `workflow_youtrack_post` with `confirmed: true` at most once; never loop.
-- If `result.data.retry === "workflow_youtrack_log_time"`, use native `question` to ask whether to retry the same `issueId` and `minutes`. On approval, call `workflow_youtrack_log_time` with `confirmed: true`, `issueId`, `minutes` at most once; never repost a known posted comment.
+- If `result.data.retry === "workit_youtrack_post"`, use native `question` to ask whether to retry the unchanged reviewed `issueId`, `markdown`, and `minutes`. On approval, call `workit_youtrack_post` with `confirmed: true` at most once; never loop.
+- If `result.data.retry === "workit_youtrack_log_time"`, use native `question` to ask whether to retry the same `issueId` and `minutes`. On approval, call `workit_youtrack_log_time` with `confirmed: true`, `issueId`, `minutes` at most once; never repost a known posted comment.
 - If the second attempt fails, stop and report its structured result. Never switch retry tools or infer that either effect succeeded.
 - If outcome is `unknown` or `result.data.retry` is absent, show `result.data.instructions` when present, reconcile manually, and do not retry either mutation.

package/skills/wk-issue-update/references/youtrack-update-style.md

@@ -1,6 +1,6 @@
 # YouTrack update style (Cristhofer / es-CL)
 
-Use when writing or polishing the comment body before `workflow_youtrack_draft`. **Preserve the author's voice** — like the ChatGPT revision thread: grammar, flow, and light structure, not a changelog.
+Use when writing or polishing the comment body before `workit_youtrack_draft`. **Preserve the author's voice** — like the ChatGPT revision thread: grammar, flow, and light structure, not a changelog.
 
 ## Audience
 

package/skills/wk-meetings/SKILL.md

@@ -7,11 +7,11 @@ disable-model-invocation: true
 # Meetings
 
 1. Load this skill explicitly through OpenCode's `skill` tool.
-2. Call read-only `workflow_youtrack_context` with `mode: "meetings"`; its sole configured target is ground truth.
-3. Ask for duration text, call `workflow_youtrack_parse_duration`, and draft the exact IRPT-12 time entry only.
+2. Call read-only `workit_youtrack_context` with `mode: "meetings"`; its sole configured target is ground truth.
+3. Ask for duration text, call `workit_youtrack_parse_duration`, and draft the exact IRPT-12 time entry only.
 4. Use native `question` with concise choices and allow a custom answer to approve the shown issue, minutes, and work-item text.
-5. Call `workflow_youtrack_log_time` only after approval with `confirmed: true`, `issueId`, `minutes`, `text`.
-6. If `result.data.outcome` is `unknown`, tell the user to reconcile manually and do not retry. Retry `workflow_youtrack_log_time` at most once only when `result.data.outcome` is `not_applied` and `result.data.retry` names that tool; follow `result.data.instructions` and correct invalid input before retrying.
+5. Call `workit_youtrack_log_time` only after approval with `confirmed: true`, `issueId`, `minutes`, `text`.
+6. If `result.data.outcome` is `unknown`, tell the user to reconcile manually and do not retry. Retry `workit_youtrack_log_time` at most once only when `result.data.outcome` is `not_applied` and `result.data.retry` names that tool; follow `result.data.instructions` and correct invalid input before retrying.
 7. Report the structured success or failure stage; never infer success.
 
-Use the configured meeting issue even if its default label is IRPT-12. Never compute minutes, pass a date, ask for a meeting type, post a comment, or call `workflow_youtrack_post`. `todowrite` and `task` are unnecessary here.
+Use the configured meeting issue even if its default label is IRPT-12. Never compute minutes, pass a date, ask for a meeting type, post a comment, or call `workit_youtrack_post`. `todowrite` and `task` are unnecessary here.

package/skills/wk-pr/SKILL.md

@@ -7,16 +7,16 @@ disable-model-invocation: true
 # Pull request
 
 1. Load this skill explicitly through OpenCode's `skill` tool.
-2. Call the read-only `workflow_pr_context` context tool for branch-exclusive commits and changes; its result is ground truth.
-3. Call `workflow_verify`, then draft the exact title, body, base, head, and draft state from structured facts.
+2. Call the read-only `workit_pr_context` context tool for branch-exclusive commits and changes; its result is ground truth.
+3. Call `workit_verify`, then draft the exact title, body, base, head, and draft state from structured facts.
 4. **Show** the exact title and body in chat before any create question.
 5. Use native `question` with concise choices and allow a custom answer before creation.
-6. Call `workflow_pr_create` only after approval with `confirmed: true` and the reviewed fields.
+6. Call `workit_pr_create` only after approval with `confirmed: true` and the reviewed fields.
 7. Report the structured success, failure stage, or partial result; never infer success.
 
 ## GitHub issue linking
 
-When the resolved workspace is github with `link_on_pr` — the `workflow_pr_context` tool's `vcs_config` returns `issues_provider: "github"` and `link_on_pr: true` — and no issue is derivable (no `WORKFLOW_GH_ISSUE` env, no numeric branch id like `feature/42-title`, which auto-links without asking), ask with native `question` before creation, exactly three options:
+When the resolved workspace is github with `link_on_pr` — the `workit_pr_context` tool's `vcs_config` returns `issues_provider: "github"` and `link_on_pr: true` — and no issue is derivable (no `WORKFLOW_GH_ISSUE` env, no numeric branch id like `feature/42-title`, which auto-links without asking), ask with native `question` before creation, exactly three options:
 
 1. **Use an existing issue** — the user provides the number (extract it from a URL if pasted); verify it exists with `gh issue view <n>` before proceeding.
 2. **Create a new issue** — via `gh issue create --title "<title>" --body "<body>"`; on success pass the returned number. Reuse the missing-CLI guard: if `gh` is not installed, surface the structured error with the install link and ask the user to confirm once installed.

package/skills/wk-release-notes/SKILL.md

@@ -6,7 +6,7 @@ description: Draft user-facing release notes for an explicit range.
 # Release notes
 
 1. Load this skill explicitly through OpenCode's `skill` tool.
-2. Require an exact version, tag, or commit range, then call the read-only `workflow_release_notes_context`; its result is ground truth.
+2. Require an exact version, tag, or commit range, then call the read-only `workit_release_notes_context`; its result is ground truth.
 3. Draft notes from structured facts and include both requested and resolved range metadata.
 4. Use native `question` only when the exact range must be supplied or corrected; allow a custom answer.
 5. This workflow has no mutation tool.

package/skills/wk-verify/SKILL.md

@@ -1,16 +1,16 @@
 ---
 name: wk-verify
-description: Discover and run project validation with workflow_verify.
+description: Discover and run project validation with workit_verify.
 disable-model-invocation: true
 ---
 
 # Verify
 
 1. Load this skill explicitly through OpenCode's `skill` tool.
-2. Call the read-only `workflow_verify` context tool with `dry_run: true`; its result is ground truth.
+2. Call the read-only `workit_verify` context tool with `dry_run: true`; its result is ground truth.
 3. Draft the discovered checks and the proposed selected run from structured facts.
 4. When the user must choose checks, use native `question` with concise choices and allow a custom answer.
-5. Call `workflow_verify` with `dry_run: false` only for the approved run.
+5. Call `workit_verify` with `dry_run: false` only for the approved run.
 6. Report the structured success, failure stage, or partial result; never infer success.
 
 Do not edit files or fix failures. Report every check exactly as pass, fail, or skipped, including its command, exit code, and skip reason. Success requires every executed check to exit 0. If the user's message says `--dry-run`, stop after discovery.

package/src/core/branch.ts

@@ -303,7 +303,7 @@ export const branchSetup = ({
       if (stash !== "yes") {
         return {
           error:
-            "dirty working tree — ask with native question, then call workflow_branch_setup with stash=yes",
+            "dirty working tree — ask with native question, then call workit_branch_setup with stash=yes",
         };
       }
       try {

package/src/core/detector.ts

@@ -13,7 +13,7 @@ export const detectConfigGapError = (text: string): boolean => text.includes(CON
 
 const COMPLETION_CLAIMS = /\b(?:done|fixed|passing|green|complete|all set)\b/i;
 const VERIFICATION_EVIDENCE =
-  /\bbun run check\b|\bworkflow_verify\b|\bbun test\b|\bchecks?\s+pass(?:es|ing)?\b|\btests?\s+pass(?:es|ing)?\b/i;
+  /\bbun run check\b|\bworkit_verify\b|\bbun test\b|\bchecks?\s+pass(?:es|ing)?\b|\btests?\s+pass(?:es|ing)?\b/i;
 
 // Claims completion without verification-command evidence in the same text.
 export const detectVerificationClaim = (text: string): boolean =>

package/src/core/docs-repo.ts

@@ -126,7 +126,7 @@ export const promoteSpec = (
   if (!resolved.ok) return { ok: false, error: resolved.error };
   const workspaceRootCanonical = resolved.layout.workspace;
   const repoPath = docsRepoPath();
-  if (!repoPath) return { ok: false, error: "docs repo not linked — run workflow_docs_repo_link" };
+  if (!repoPath) return { ok: false, error: "docs repo not linked — run workit_docs_repo_link" };
   const repoValid = validateDocsRepo(repoPath);
   if (!repoValid.ok) return { ok: false, error: repoValid.error };
   const specRel = path.posix.join("docs", slug, "spec.md");

package/src/core/flow-state.ts

@@ -501,7 +501,7 @@ const readFlowStrict = (root: string, slug: string): StrictRead => {
   if (!existsSync(file)) {
     return err(
       "flow_not_activated",
-      `flow not activated for ${slug} — run workflow_flow_status first`,
+      `flow not activated for ${slug} — run workit_flow_status first`,
     );
   }
   let text: string;
@@ -2103,13 +2103,13 @@ export const assertHandoffReady = (root: string, planPath: string): FlowGateResu
   if (state.spec.status !== "approved") {
     return err(
       "spec_not_approved",
-      `spec not approved (status: ${state.spec.status}). Run workflow_spec_approve after the user's approval.`,
+      `spec not approved (status: ${state.spec.status}). Run workit_spec_approve after the user's approval.`,
     );
   }
   if (state.plan.status !== "approved") {
     return err(
       "plan_not_approved",
-      `plan not approved (status: ${state.plan.status}). Run workflow_plan_approve after the user's approval.`,
+      `plan not approved (status: ${state.plan.status}). Run workit_plan_approve after the user's approval.`,
     );
   }
   if (state.handoff_destination) {
@@ -2143,19 +2143,19 @@ export const assertFlowGates = (
   if (state.spec.status !== "approved") {
     return err(
       "spec_not_approved",
-      `spec not approved (status: ${state.spec.status}). Run workflow_spec_approve after the user's approval.`,
+      `spec not approved (status: ${state.spec.status}). Run workit_spec_approve after the user's approval.`,
     );
   }
   if (state.plan.status !== "approved") {
     return err(
       "plan_not_approved",
-      `plan not approved (status: ${state.plan.status}). Run workflow_plan_approve after the user's approval.`,
+      `plan not approved (status: ${state.plan.status}). Run workit_plan_approve after the user's approval.`,
     );
   }
   if (opts.requireMenu && !state.menu.presented) {
     return err(
       "menu_not_presented",
-      "post-plan menu not presented. Ask the native question menu (Subagent-driven/Inline/Handoff/Review spec/Review plan) and record the answer with workflow_plan_menu.",
+      "post-plan menu not presented. Ask the native question menu (Subagent-driven/Inline/Handoff/Review spec/Review plan) and record the answer with workit_plan_menu.",
     );
   }
   return { ok: true };
@@ -2187,19 +2187,19 @@ export const assertProductGates = (
   if (state.spec.status !== "approved") {
     return err(
       "spec_not_approved",
-      `spec not approved (status: ${state.spec.status}). Run workflow_spec_approve after the user's approval.`,
+      `spec not approved (status: ${state.spec.status}). Run workit_spec_approve after the user's approval.`,
     );
   }
   if (state.plan.status !== "approved") {
     return err(
       "plan_not_approved",
-      `plan not approved (status: ${state.plan.status}). Run workflow_plan_approve after the user's approval.`,
+      `plan not approved (status: ${state.plan.status}). Run workit_plan_approve after the user's approval.`,
     );
   }
   if (opts.requireMenu && !state.menu.presented) {
     return err(
       "menu_not_presented",
-      "post-plan menu not presented. Record the native question answer with workflow_plan_menu.",
+      "post-plan menu not presented. Record the native question answer with workit_plan_menu.",
     );
   }
   if (opts.requireDocs) {
@@ -2237,19 +2237,19 @@ export const assertSddControlGates = (
   if (state.spec.status !== "approved") {
     return err(
       "spec_not_approved",
-      `spec not approved (status: ${state.spec.status}). Run workflow_spec_approve after the user's approval.`,
+      `spec not approved (status: ${state.spec.status}). Run workit_spec_approve after the user's approval.`,
     );
   }
   if (state.plan.status !== "approved") {
     return err(
       "plan_not_approved",
-      `plan not approved (status: ${state.plan.status}). Run workflow_plan_approve after the user's approval.`,
+      `plan not approved (status: ${state.plan.status}). Run workit_plan_approve after the user's approval.`,
     );
   }
   if (opts.requireMenu && !state.menu.presented) {
     return err(
       "menu_not_presented",
-      "post-plan menu not presented. Record the native question answer with workflow_plan_menu.",
+      "post-plan menu not presented. Record the native question answer with workit_plan_menu.",
     );
   }
   if (opts.requireDocs) {
@@ -2318,18 +2318,18 @@ export const COORDINATOR_WRITE_TOOLS: readonly string[] = [
   "chown",
   // workit product/config/external mutation tools (SDD control tools are
   // coordinator-owned and routed through assertSddControlGates, not this set)
-  "workflow_commit",
-  "workflow_pr_create",
-  "workflow_rule_edit",
-  "workflow_template_edit",
-  "workflow_changelog_apply",
-  "workflow_branch_setup",
+  "workit_commit",
+  "workit_pr_create",
+  "workit_rule_edit",
+  "workit_template_edit",
+  "workit_changelog_apply",
+  "workit_branch_setup",
   "workit_init_apply",
-  "workflow_docs_promote",
-  "workflow_docs_layout",
-  "workflow_docs_repo_link",
-  "workflow_youtrack_post",
-  "workflow_youtrack_log_time",
+  "workit_docs_promote",
+  "workit_docs_layout",
+  "workit_docs_repo_link",
+  "workit_youtrack_post",
+  "workit_youtrack_log_time",
 ];
 
 /**
@@ -2987,10 +2987,10 @@ export const subagentDrivenInterception = (input: {
     }
     if (
       [
-        "workflow_sdd_task_brief",
-        "workflow_sdd_review_package",
-        "workflow_sdd_append_progress",
-        "workflow_sdd_append_advisory",
+        "workit_sdd_task_brief",
+        "workit_sdd_review_package",
+        "workit_sdd_append_progress",
+        "workit_sdd_append_advisory",
       ].includes(input.tool)
     ) {
       return err(

package/src/core/reminder.ts

@@ -15,7 +15,7 @@ export const REMINDER_TEXT = `<workflow-contract-reminder>
 - Bounded user choices → call the native \`question\` tool (never A/B/C or 1/2/3 lists in prose).
 - After a plan is approved → native \`question\` menu with exactly: ${SOURCE_MENU_LABELS_DISPLAY.join(", ")}.
 - Tools with \`confirmed\` → call them; never fabricate their result.
-- Before the first \`workflow_spec_approve\`/\`workflow_plan_approve\` (self-review) run the superpowers writing-plans Self-Review checklist: spec coverage (every spec requirement maps to a task), placeholder scan, type consistency; fix findings inline.
+- Before the first \`workit_spec_approve\`/\`workit_plan_approve\` (self-review) run the superpowers writing-plans Self-Review checklist: spec coverage (every spec requirement maps to a task), placeholder scan, type consistency; fix findings inline.
 - Delivering docs → clickable markdown link \`[spec.md](docs/<slug>/spec.md)\` + 3-5 bullet summary.
 </workflow-contract-reminder>`;
 
@@ -29,7 +29,7 @@ export const DESTINATION_REMINDER_TEXT = `<workflow-contract-reminder>
 - Bounded user choices → call the native \`question\` tool (never A/B/C or 1/2/3 lists in prose).
 - This session is a handoff destination: present the post-plan menu with exactly: ${DESTINATION_MENU_LABELS.join(", ")}.
 - Tools with \`confirmed\` → call them; never fabricate their result.
-- Before the first \`workflow_spec_approve\`/\`workflow_plan_approve\` (self-review) run the superpowers writing-plans Self-Review checklist: spec coverage (every spec requirement maps to a task), placeholder scan, type consistency; fix findings inline.
+- Before the first \`workit_spec_approve\`/\`workit_plan_approve\` (self-review) run the superpowers writing-plans Self-Review checklist: spec coverage (every spec requirement maps to a task), placeholder scan, type consistency; fix findings inline.
 - Delivering docs → clickable markdown link \`[spec.md](docs/<slug>/spec.md)\` + 3-5 bullet summary.
 ${HANDOFF_DESTINATION_MARKER}
 </workflow-contract-reminder>`;
@@ -78,7 +78,7 @@ A tool failed with a config-gap error (\`workflow config missing\`). Never confi
 </workflow-config-guard>`;
 
 export const VERIFICATION_TEXT = `<workflow-verification-rail>
-Skill: verification-before-completion. NO completion claims without fresh verification evidence — run the check command (e.g. \`bun run check\` / \`workflow_verify\`) and show its output before claiming done/fixed/passing. If you haven't run the verification command in this message, you cannot claim it passes.
+Skill: verification-before-completion. NO completion claims without fresh verification evidence — run the check command (e.g. \`bun run check\` / \`workit_verify\`) and show its output before claiming done/fixed/passing. If you haven't run the verification command in this message, you cannot claim it passes.
 </workflow-verification-rail>`;
 
 export const TDD_TEXT = `<workflow-tdd-rail>

package/src/core/repo-context.ts

@@ -330,7 +330,7 @@ const CHANGELOG_RULES = `- Use an [Unreleased] section.
 - Entries should be human-readable and user-facing.
 - Do not use raw commit messages as changelog bullets.
 - MERGE into existing ### Category under [Unreleased] — never append a second ### Added / ### Fixed block.
-- Apply with the native workflow_changelog_apply tool only (not hand-edits under Unreleased).
+- Apply with the native workit_changelog_apply tool only (not hand-edits under Unreleased).
 - If Unreleased already has duplicate category headings, normalize_only first.`;
 
 /** Port of changelog-context.sh — changelog update context. */

package/src/core/sdd.ts

@@ -183,7 +183,7 @@ export function sddContext({
     flow: { spec: flow.spec, plan: flow.plan, menu: flow.menu },
     todowrite_required: true,
     todowrite_hint:
-      "REQUIRED: Call OpenCode todowrite with todos from this result so the native task list shows progress. Before each task set status in_progress; after workflow_sdd_append_progress set it completed.",
+      "REQUIRED: Call OpenCode todowrite with todos from this result so the native task list shows progress. Before each task set status in_progress; after workit_sdd_append_progress set it completed.",
   };
 }
 

package/src/core/youtrack-tools.ts

@@ -102,7 +102,7 @@ type PostData = {
   loggedMinutes: number;
   outcome?: "unknown" | "not_applied";
   instructions?: string;
-  retry?: "workflow_youtrack_post" | "workflow_youtrack_log_time";
+  retry?: "workit_youtrack_post" | "workit_youtrack_log_time";
 };
 
 const notApplied = (value: LegacyValue): value is NotApplied =>
@@ -129,7 +129,7 @@ export async function postUpdate(
         postedComment: false,
         loggedMinutes: 0,
         outcome: "not_applied",
-        retry: "workflow_youtrack_post",
+        retry: "workit_youtrack_post",
       });
     unwrap(comment);
   } catch (error) {
@@ -156,7 +156,7 @@ export async function postUpdate(
           postedComment: true,
           loggedMinutes: 0,
           outcome: "not_applied",
-          retry: "workflow_youtrack_log_time",
+          retry: "workit_youtrack_log_time",
         });
       unwrap(time);
     } catch (error) {
@@ -189,7 +189,7 @@ export async function logTimeUpdate(
         issueId: input.issueId,
         loggedMinutes: 0,
         outcome: "not_applied",
-        retry: "workflow_youtrack_log_time",
+        retry: "workit_youtrack_log_time",
       });
     return ok(unwrap(value));
   } catch (error) {

package/src/core/youtrack.ts

@@ -711,7 +711,7 @@ export async function postUpdate(
         postedComment: true,
         loggedMinutes: 0,
         error: time.error,
-        retry: "workflow_youtrack_log_time",
+        retry: "workit_youtrack_log_time",
       };
     }
     return { ok: true, issueId, postedComment: true, loggedMinutes: minutes };

package/templates/execution-contract.md

@@ -20,48 +20,48 @@ This session is a handoff destination for a continued plan. The originating sess
 ## Hard gates
 
 - The parent is coordinator-only: it does not edit product code or perform delegated exploration.
-- Never use a worktree. Branch changes are in-place through `workflow_branch_setup` on `feature/*` or `bugfix/*`; never commit on protected branches.
-- Working state, briefs, ledgers, and review diffs live only under gitignored `<SDD_DIR>` in `docs/<slug>/sdd/` and use `workflow_sdd_*` tools.
+- Never use a worktree. Branch changes are in-place through `workit_branch_setup` on `feature/*` or `bugfix/*`; never commit on protected branches.
+- Working state, briefs, ledgers, and review diffs live only under gitignored `<SDD_DIR>` in `docs/<slug>/sdd/` and use `workit_sdd_*` tools.
 - Use native `todowrite` for visible task state as well as the gitignored ledger.
 - Use native `question` for branch/stash choices and guarded external mutations; call mutation tools only after approval with `confirmed: true` (grounded in the recorded NativeChoiceEvidence).
-- Flow-tool confirmations are never agent-typed booleans and never caller-supplied evidence objects: on OpenCode the plugin records the user's native-`question` answer as a host-observed one-use receipt (`attested: true`, `callID`, `selectedLabel`, `recordedAt`) consumed by `workflow_spec_approve` / `workflow_plan_approve` / `workflow_plan_menu` — no evidence argument exists, and delegated worker status comes from host session parentage (`parentID`), never a caller `role` field. On Cursor, confirmations are policy-only (`attested: false`) and subagent-driven execution is rejected as unsupported.
-- Delegated authority is direct-child-only: a worker is the session whose host `parentID` exactly equals the activating coordinator's recorded `coordinator_session_id`; missing, mismatched, or multi-owner lineage fails closed with `delegation_lineage_denied`, and nested `opencode` launches are denied during active delegated work. An authorized child receives only the compact worker contract (execute the supplied brief, follow TDD, land one contiguous non-empty commit range, report results) — never coordinator guidance, `wk-implement`, or ledger management; coordinator bookkeeping via `workflow_sdd_*` stays with the coordinator session.
-- On Cursor, for every repository-scoped `workflow_*` call, pass the active Cursor workspace as `workspace_root`; never rely on the MCP process default.
+- Flow-tool confirmations are never agent-typed booleans and never caller-supplied evidence objects: on OpenCode the plugin records the user's native-`question` answer as a host-observed one-use receipt (`attested: true`, `callID`, `selectedLabel`, `recordedAt`) consumed by `workit_spec_approve` / `workit_plan_approve` / `workit_plan_menu` — no evidence argument exists, and delegated worker status comes from host session parentage (`parentID`), never a caller `role` field. On Cursor, confirmations are policy-only (`attested: false`) and subagent-driven execution is rejected as unsupported.
+- Delegated authority is direct-child-only: a worker is the session whose host `parentID` exactly equals the activating coordinator's recorded `coordinator_session_id`; missing, mismatched, or multi-owner lineage fails closed with `delegation_lineage_denied`, and nested `opencode` launches are denied during active delegated work. An authorized child receives only the compact worker contract (execute the supplied brief, follow TDD, land one contiguous non-empty commit range, report results) — never coordinator guidance, `wk-implement`, or ledger management; coordinator bookkeeping via `workit_sdd_*` stays with the coordinator session.
+- On Cursor, for every repository-scoped `workit_*` call, pass the active Cursor workspace as `workspace_root`; never rely on the MCP process default.
 - Use native `task` with only the built-in `explore` and `general` agents.
 
 ## Flow gates (HARD)
 
 - `wk-implement` refuses to run unless the plan is `approved` (flow.json) and the post-plan menu was presented.
 - `wk-handoff` refuses to run unless both spec and plan are `approved`.
-- Sequence is enforced by tools: `workflow_spec_approve`, `workflow_plan_approve`, `workflow_plan_menu` — never skip a step (the spec/plan self-review runs automatically inside the transition; only the final approval asks for your confirmation).
+- Sequence is enforced by tools: `workit_spec_approve`, `workit_plan_approve`, `workit_plan_menu` — never skip a step (the spec/plan self-review runs automatically inside the transition; only the final approval asks for your confirmation).
 
 ## Setup
 
-0. Call `workflow_docs_validate` with the linked spec/plan paths. Hard-fail on any error before todos or branch setup.
-1. Call `workflow_sdd_context` with `<PLAN_PATH>` and initialize `todowrite` from returned tasks.
-2. Call `workflow_plan_tasks`; cache each top-level task's `section_text`.
+0. Call `workit_docs_validate` with the linked spec/plan paths. Hard-fail on any error before todos or branch setup.
+1. Call `workit_sdd_context` with `<PLAN_PATH>` and initialize `todowrite` from returned tasks.
+2. Call `workit_plan_tasks`; cache each top-level task's `section_text`.
 3. Mark IDs in `completed_task_ids` completed and never redispatch them.
-4. Call `workflow_resolve_branch`, then show the current branch, target branch, and stash behavior before any in-place checkout/setup mutation.
+4. Call `workit_resolve_branch`, then show the current branch, target branch, and stash behavior before any in-place checkout/setup mutation.
 5. Always use `question`: for a clean tree ask whether to proceed or cancel; for a dirty tree add the stash choice and describe what will be stashed.
-6. Call `workflow_branch_setup` with `confirmed: true` only after approval.
+6. Call `workit_branch_setup` with `confirmed: true` only after approval.
 
 ## Remaining-task loop
 
 For each top-level task absent from `completed_task_ids`:
 
 1. Mark it `in_progress` with `todowrite`.
-2. Create a working-state brief with `workflow_sdd_task_brief` and `confirmed: true`.
+2. Create a working-state brief with `workit_sdd_task_brief` and `confirmed: true`.
 3. Delegate read-only discovery, when needed, to an `explore` agent. Delegate implementation to a fresh `general` agent. Product changes follow TDD.
-4. Create a working-state diff with `workflow_sdd_review_package` and `confirmed: true`.
+4. Create a working-state diff with `workit_sdd_review_package` and `confirmed: true`.
 5. Delegate spec-compliance review and code-quality review to separate `general` agents.
-6. **Blocking** findings (Critical, Important, or spec-compliance) may trigger at most **two** fix+re-review rounds per task. **Advisory** findings (Minor, style, YAGNI, taste) never pause the loop — append them with `workflow_sdd_append_advisory` (`--task <id> --text <text>`, `confirmed: true`) instead of an unrestricted file edit.
-7. Append the validated ledger entry with `workflow_sdd_append_progress` and `confirmed: true`; mark the todo completed.
+6. **Blocking** findings (Critical, Important, or spec-compliance) may trigger at most **two** fix+re-review rounds per task. **Advisory** findings (Minor, style, YAGNI, taste) never pause the loop — append them with `workit_sdd_append_advisory` (`--task <id> --text <text>`, `confirmed: true`) instead of an unrestricted file edit.
+7. Append the validated ledger entry with `workit_sdd_append_progress` and `confirmed: true`; mark the todo completed.
 
 ## Final gate
 
-Run a separate full-branch code review, then `workflow_verify`. Present the full `<SDD_DIR>/advisories.md` roll-up once, then use native `question` so the user can choose which advisory items to fix, discuss, or discard. Report exact check results and never infer success. Use `workflow_git_context` for a commit preview and load `wk-commit` through `skill` for an approved commit. If working state contains a stash reference, preview reapplication through `question`, then call `workflow_branch_setup` with `confirmed: true` after approval.
+Run a separate full-branch code review, then `workit_verify`. Present the full `<SDD_DIR>/advisories.md` roll-up once, then use native `question` so the user can choose which advisory items to fix, discuss, or discard. Report exact check results and never infer success. Use `workit_git_context` for a commit preview and load `wk-commit` through `skill` for an approved commit. If working state contains a stash reference, preview reapplication through `question`, then call `workit_branch_setup` with `confirmed: true` after approval.
 
-**Mandatory:** end the run by calling `workflow_plan_complete` (OpenCode/Cursor) or the CLI `workit flow complete` (CLI host) after the final task once the SDD ledger is complete (all task IDs appended) and `workflow_verify` passes — a complete ledger and green verification are the tool's gates. Never finish the run while the plan is still `active`.
+**Mandatory:** end the run by calling `workit_plan_complete` (OpenCode/Cursor) or the CLI `workit flow complete` (CLI host) after the final task once the SDD ledger is complete (all task IDs appended) and `workit_verify` passes — a complete ledger and green verification are the tool's gates. Never finish the run while the plan is still `active`.
 
 ## Task order
 
@@ -70,4 +70,4 @@ Run a separate full-branch code review, then `workflow_verify`. Present the full
 ## Quality gate (HARD)
 
 - Specs/plans are written from `templates/spec-template.md` / `templates/plan-template.md`.
-- After `workflow_docs_validate`, surface `quality` findings (spec scan). Hard findings (missing required section, missing CA-XX) block task start unless the user explicitly waives them. Warnings are advisory.
+- After `workit_docs_validate`, surface `quality` findings (spec scan). Hard findings (missing required section, missing CA-XX) block task start unless the user explicitly waives them. Warnings are advisory.

package/templates/plan-template.md

@@ -10,7 +10,7 @@
 ## Global Constraints
 
 - Each task lands exactly one contiguous non-empty commit range (`base..head`): fix rounds append commits to that range and never rewrite/amend an active review range; each progress line records the task's real base..head shas.
-- The final task ends execution with `workflow_plan_complete` (or the CLI `workit flow complete`) once the SDD ledger is complete and repository verification passes — a run never finishes while the plan is still `active`.
+- The final task ends execution with `workit_plan_complete` (or the CLI `workit flow complete`) once the SDD ledger is complete and repository verification passes — a run never finishes while the plan is still `active`.
 - <project-wide requirements, one line each>
 
 ---

package/templates/spec-template.md

@@ -16,13 +16,13 @@
 
 ## Architecture
 
-<!-- REQUIRED if this spec has flows or architecture: render a mermaid diagram (workflow_present_flow). -->
+<!-- REQUIRED if this spec has flows or architecture: render a mermaid diagram (workit_present_flow). -->
 ```mermaid
 flowchart TD
   A[Start] --> B[Step]
 ```
 
-<!-- REQUIRED if this spec touches UI: render an ASCII wireframe (workflow_present_ascii). -->
+<!-- REQUIRED if this spec touches UI: render an ASCII wireframe (workit_present_ascii). -->
 ```text
 ┌──────────────┐
 │ Header       │

package/templates/superpowers-doc-contract.md

@@ -27,31 +27,31 @@ Plans require:
 
 `bugfix/<slug>` is also valid. Never use `main`, `develop`, `master`, or `prod`. Use plain backtick paths. Top-level headings are exactly `### Task N: Title`; steps use `- [ ] **Step N:** ...`; task headings never appear inside fences.
 
-Before writing **Branch:** into a new spec or plan, call `workflow_docs_branch` and write the returned `branch` verbatim. When `action` is `keep`, use the current feature/bugfix branch. When `action` is `create_from_develop` or `create_from_base`, create the branch only through `workflow_branch_setup`; it uses the configured workspace/global target branch.
+Before writing **Branch:** into a new spec or plan, call `workit_docs_branch` and write the returned `branch` verbatim. When `action` is `keep`, use the current feature/bugfix branch. When `action` is `create_from_develop` or `create_from_base`, create the branch only through `workit_branch_setup`; it uses the configured workspace/global target branch.
 
 ## Execution and handoff
 
 - Implementation uses `wk-implement` and subagent-driven development, with native `todowrite` and `task`.
 - Commits use `wk-commit` after its native `question` confirmation.
-- Continuation uses `wk-handoff`, whose `workflow_handoff_session` creates and seeds the OpenCode session automatically.
-- Never use worktrees. Resolve the declared branch with `workflow_resolve_branch`, preview dirty-tree stash choices with `question`, and apply an approved in-place checkout through `workflow_branch_setup` with `confirmed: true` (grounded in the recorded NativeChoiceEvidence).
-- Flow-tool confirmations are never agent-typed booleans and never caller-supplied evidence objects: on OpenCode the plugin records the user's native-`question` answer as a host-observed one-use receipt (`attested: true`, `callID`, `selectedLabel`, `recordedAt`) consumed by `workflow_spec_approve` / `workflow_plan_approve` / `workflow_plan_menu` — no evidence argument exists, and delegated worker status comes from host session parentage (`parentID`), never a caller `role` field. On Cursor, confirmations are policy-only (`attested: false`) and subagent-driven execution is rejected as unsupported.
-- Keep all SDD state under the gitignored `docs/<slug>/sdd/`; use `workflow_sdd_context` and the registered `workflow_sdd_*` tools.
-- After implementation, use `question` before an approved stash reapply through `workflow_branch_setup` with `confirmed: true`.
+- Continuation uses `wk-handoff`, whose `workit_handoff_session` creates and seeds the OpenCode session automatically.
+- Never use worktrees. Resolve the declared branch with `workit_resolve_branch`, preview dirty-tree stash choices with `question`, and apply an approved in-place checkout through `workit_branch_setup` with `confirmed: true` (grounded in the recorded NativeChoiceEvidence).
+- Flow-tool confirmations are never agent-typed booleans and never caller-supplied evidence objects: on OpenCode the plugin records the user's native-`question` answer as a host-observed one-use receipt (`attested: true`, `callID`, `selectedLabel`, `recordedAt`) consumed by `workit_spec_approve` / `workit_plan_approve` / `workit_plan_menu` — no evidence argument exists, and delegated worker status comes from host session parentage (`parentID`), never a caller `role` field. On Cursor, confirmations are policy-only (`attested: false`) and subagent-driven execution is rejected as unsupported.
+- Keep all SDD state under the gitignored `docs/<slug>/sdd/`; use `workit_sdd_context` and the registered `workit_sdd_*` tools.
+- After implementation, use `question` before an approved stash reapply through `workit_branch_setup` with `confirmed: true`.
 
 ## YouTrack content
 
-Chat follows the user's language. YouTrack task comments are Spanish (`es-CL`) and use `workflow_youtrack_draft` followed by reviewed `workflow_youtrack_post` with `confirmed: true`. Preserve the user's paragraph voice; do not inject commits, file paths, or robotic bullet reports.
+Chat follows the user's language. YouTrack task comments are Spanish (`es-CL`) and use `workit_youtrack_draft` followed by reviewed `workit_youtrack_post` with `confirmed: true`. Preserve the user's paragraph voice; do not inject commits, file paths, or robotic bullet reports.
 
 ## Final self-check
 
-Before handoff, call `workflow_docs_validate` on the linked spec/plan pair. Hard-fail on any error; never offer execution when validation fails.
+Before handoff, call `workit_docs_validate` on the linked spec/plan pair. Hard-fail on any error; never offer execution when validation fails.
 
 Before handoff, verify the saved spec path, plan path, declared branch, top-level task numbering, and workflow-managed SDD directory through the registered read-only workflow tools. Report structured failures; never infer success.
 
 ## Post-plan execution choice
 
-After saving a plan, call `workflow_docs_validate` on the spec/plan pair. On failure, stop and fix docs — do not offer execution.
+After saving a plan, call `workit_docs_validate` on the spec/plan pair. On failure, stop and fix docs — do not offer execution.
 
 On success, use native `question` / Cursor `AskQuestion` with exactly these options (no stay, no A/B/C prose duplicate):
 
@@ -62,7 +62,7 @@ On success, use native `question` / Cursor `AskQuestion` with exactly these opti
 5. Review plan first
 6. Change model first
 
-`Change model first` is display-only deferral: it ends the turn without calling `workflow_plan_menu` and re-presents the menu on the next turn. Every other choice must call `workflow_plan_menu` immediately after the answer and before any skill, branch question, mutation, or handoff.
+`Change model first` is display-only deferral: it ends the turn without calling `workit_plan_menu` and re-presents the menu on the next turn. Every other choice must call `workit_plan_menu` immediately after the answer and before any skill, branch question, mutation, or handoff.
 
 Never emit Superpowers text beginning “Two execution options”.
 

package/vendor/superpowers/skills/subagent-driven-development/SKILL.md

@@ -63,7 +63,7 @@ digraph process {
     "Read plan, note context and global constraints, create todos" [shape=box];
     "More tasks remain?" [shape=diamond];
     "Dispatch final code reviewer subagent (../requesting-code-review/code-reviewer.md)" [shape=box];
-    "Run verification, then workflow_plan_complete once the ledger is complete and verification passes" [shape=box];
+    "Run verification, then workit_plan_complete once the ledger is complete and verification passes" [shape=box];
     "Use superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];
 
     "Read plan, note context and global constraints, create todos" -> "Dispatch implementer subagent (./implementer-prompt.md)";
@@ -79,12 +79,12 @@ digraph process {
     "Mark task complete in todo list and progress ledger" -> "More tasks remain?";
     "More tasks remain?" -> "Dispatch implementer subagent (./implementer-prompt.md)" [label="yes"];
     "More tasks remain?" -> "Dispatch final code reviewer subagent (../requesting-code-review/code-reviewer.md)" [label="no"];
-    "Dispatch final code reviewer subagent (../requesting-code-review/code-reviewer.md)" -> "Run verification, then workflow_plan_complete once the ledger is complete and verification passes";
-    "Run verification, then workflow_plan_complete once the ledger is complete and verification passes" -> "Use superpowers:finishing-a-development-branch";
+    "Dispatch final code reviewer subagent (../requesting-code-review/code-reviewer.md)" -> "Run verification, then workit_plan_complete once the ledger is complete and verification passes";
+    "Run verification, then workit_plan_complete once the ledger is complete and verification passes" -> "Use superpowers:finishing-a-development-branch";
 }
 ```
 
-**Mandatory completion:** after the final whole-branch review, run repository verification. Once the SDD ledger is complete and verification passes, end the run by calling `workflow_plan_complete` (or the CLI `workit flow complete`) — a complete ledger and green verification are the tool's gates. Never finish while the plan is still `active`.
+**Mandatory completion:** after the final whole-branch review, run repository verification. Once the SDD ledger is complete and verification passes, end the run by calling `workit_plan_complete` (or the CLI `workit flow complete`) — a complete ledger and green verification are the tool's gates. Never finish while the plan is still `active`.
 
 ## Pre-Flight Plan Review