@brainervirus/workit-core 0.11.0 → 1.0.0

package/scripts/update-superpowers.sh

@@ -1,82 +0,0 @@
-#!/usr/bin/env bash
-# Re-sync vendored Superpowers skills from upstream. Never pushes or commits.
-set -euo pipefail
-
-REPO="https://github.com/obra/superpowers.git"
-VENDOR="vendor/superpowers"
-PIN=""
-for arg in "$@"; do
-  case "$arg" in
-    --https) REPO="https://github.com/obra/superpowers.git" ;;
-    --ssh) REPO="git@github.com:obra/superpowers.git" ;;
-    --pin=*) PIN="${arg#--pin=}" ;;
-    *) if [ -z "$PIN" ]; then PIN="$arg"; fi ;;
-  esac
-done
-
-ROOT="$(CDPATH= cd -- "$(dirname -- "$0")/.." && pwd)"
-STAGE="$(mktemp -d)"
-trap 'rm -rf "$STAGE"' EXIT
-
-echo "Cloning upstream..."
-git clone --quiet --depth 1 "$REPO" "$STAGE/sp"
-cd "$STAGE/sp"
-if [ -n "$PIN" ]; then
-  git fetch --quiet --depth 1 origin "refs/tags/$PIN" 2>/dev/null || {
-    echo "ERROR: pin $PIN not found upstream" >&2
-    exit 1
-  }
-  git checkout --quiet "$PIN"
-fi
-VERSION="$(grep -m1 '"version"' package.json | sed -E 's/.*"version": "([^"]+)".*/\1/')"
-
-cd "$ROOT"
-rm -rf "$VENDOR/skills"
-mkdir -p "$VENDOR"
-cp -R "$STAGE/sp/skills" "$VENDOR/skills"
-
-# Patch vendored skills to the toolkit's docs layout and contract rules.
-# The upstream skills teach docs/superpowers/... and the forbidden
-# "Two execution options" menu — both overridden by our contract.
-find "$VENDOR/skills" -type f \( -name '*.md' -o -name '*.ts' \) -print0 | while IFS= read -r -d '' f; do
-  sed -i \
-    -e 's|docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md|docs/<slug>/plan.md|g' \
-    -e 's|docs/superpowers/plans/<filename>.md|docs/<slug>/plan.md|g' \
-    -e 's|docs/superpowers/plans/feature-plan.md|docs/<slug>/plan.md|g' \
-    -e 's|docs/superpowers/plans/deployment-plan.md|docs/deployment-plan/plan.md|g' \
-    -e 's|docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md|docs/<slug>/spec.md|g' \
-    -e 's|docs/superpowers/specs/|docs/<slug>/|g' \
-    -e 's|docs/superpowers/plans/|docs/<slug>/|g' \
-    -e 's|"Plan complete and saved to `docs/<slug>/plan.md`. Two execution options:\*\*|"Plan complete and saved to `docs/<slug>/plan.md`.**|g' \
-    "$f"
-done
-
-# Re-apply the per-task commit-range rule (CA-02) to the vendored
-# subagent-driven-development skill after every re-sync: upstream does not
-# carry it, and the hand-edit is current truth. Idempotent — when the rule is
-# already present the block is a no-op, so re-running leaves one copy. The awk
-# temp file lives in $STAGE (already trap-cleaned), so a failed awk leaves no
-# .tmp behind in the vendor dir, and if the marker headings were renamed or
-# reordered upstream the rule is appended at end-of-file instead of silently
-# no-oping.
-SDD_SKILL="$VENDOR/skills/subagent-driven-development/SKILL.md"
-RULE="- Each task produces exactly one contiguous non-empty commit range: fix rounds append commits to it, never amend or rewrite an active review range, and the ledger progress line records the task's real base..head shas."
-if [ -f "$SDD_SKILL" ] && ! grep -qF "one contiguous non-empty commit range" "$SDD_SKILL"; then
-  TMP="$STAGE/sdd-skill.tmp"
-  awk -v rule="$RULE" '
-    /^## Durable Progress$/ { in_section=1 }
-    in_section && !inserted && /^## Prompt Templates$/ {
-      print rule;
-      inserted=1;
-    }
-    { print }
-  ' "$SDD_SKILL" > "$TMP"
-  if ! grep -qF "one contiguous non-empty commit range" "$TMP"; then
-    printf '%s\n' "$RULE" >> "$TMP"
-  fi
-  mv "$TMP" "$SDD_SKILL"
-fi
-
-printf '%s\n' "$VERSION" > "$VENDOR/VERSION"
-echo "Vendored superpowers $VERSION -> $VENDOR (patched to docs/<slug>/ layout)"
-echo "Review with: git status && git diff --stat"

package/scripts/vendor-assets.ts

@@ -1,37 +0,0 @@
-import { cpSync, existsSync, readFileSync, statSync, writeFileSync } from "node:fs";
-import path from "node:path";
-
-const vendorFilter = (source: string): boolean => {
-  if (source.endsWith(".sh")) return false;
-  const stat = statSync(source);
-  return (
-    stat.isDirectory() ||
-    ((stat.mode & 0o111) === 0 && readFileSync(source).subarray(0, 2).toString("latin1") !== "#!")
-  );
-};
-
-export const copySanitizedVendor = (source: string, dest: string): void => {
-  cpSync(source, dest, { recursive: true, filter: vendorFilter });
-
-  const companion = path.join(dest, "brainstorming/visual-companion.md");
-  if (!existsSync(companion)) return;
-  let md = readFileSync(companion, "utf8");
-  const fromStart = md.indexOf("## Starting a Session");
-  const toLoop = md.indexOf("## The Loop", fromStart);
-  const fromCleanup = md.indexOf("## Cleaning Up");
-  const toReference = md.indexOf("## Reference", fromCleanup);
-  if (fromStart !== -1 && toLoop !== -1 && fromCleanup !== -1 && toReference !== -1) {
-    md =
-      md.slice(0, fromStart) +
-      "The packaged browser-companion runtime is not shipped with this package; its\n" +
-      "launcher scripts are excluded as vendored shell. Consult the upstream skill\n" +
-      "source for launch instructions.\n\n" +
-      md.slice(toLoop, fromCleanup) +
-      md.slice(toReference);
-  }
-  md = md.replace(
-    /If it has shut down, restart it with `start-server\.sh` using the \*\*same `--project-dir`\*\*[\s\S]*?you don't need to send a new URL\. /,
-    "",
-  );
-  writeFileSync(companion, md);
-};

package/skills/wk-changelog/SKILL.md

@@ -1,15 +0,0 @@
----
-name: wk-changelog
-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 `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 `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

@@ -1,16 +0,0 @@
----
-name: wk-commit
-description: Preview and create a structured local commit without staging.
-disable-model-invocation: true
----
-
-# Commit
-
-1. Load this skill explicitly through OpenCode's `skill` tool.
-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 `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: `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

@@ -1,15 +0,0 @@
----
-name: wk-docs-refresh
-description: Refresh stale repository documentation from structured change context.
----
-
-# Docs refresh
-
-1. Load this skill explicitly through OpenCode's `skill` tool.
-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 `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

@@ -1,20 +0,0 @@
----
-name: wk-handoff
-description: Create and optionally select a seeded OpenCode continuation session.
-disable-model-invocation: true
----
-
-# Handoff
-
-1. Load this skill explicitly through OpenCode's `skill` tool.
-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 `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.
-
-Never emit a continuation prompt, use the clipboard, or ask the user to copy text. If selected, report the session ID only if the current session remains visible. If staying, report the seeded session ID. On failure, report `stage` and `error`; preserve any returned session for the session picker and never recreate it automatically. `todowrite` and `task` are unnecessary here.

package/skills/wk-implement/SKILL.md

@@ -1,47 +0,0 @@
----
-name: wk-implement
-description: Coordinate a tracked Superpowers plan with delegated implementation and reviews.
-disable-model-invocation: true
----
-
-# Implement
-
-The parent agent is coordinator-only. It must not edit product code or perform delegated exploration.
-
-## Native setup
-
-1. Load this skill explicitly through OpenCode's `skill` tool.
-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 `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 `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 `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.
-
-## Per-task loop
-
-For every plan task whose ID is absent from `completed_task_ids`:
-
-1. Mark it `in_progress` with `todowrite`.
-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 `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 `workit_sdd_*`) stays with the coordinator session.
-
-## Final gate
-
-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 `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-init/SKILL.md

@@ -1,31 +0,0 @@
----
-name: wk-init
-description: Preview and apply one-time workit configuration.
-disable-model-invocation: true
----
-
-# Init
-
-1. Load this skill explicitly through OpenCode's `skill` tool.
-2. Call the read-only `workit_init_status` context tool; its result is ground truth.
-3. Draft an exact preview of each missing scaffold and the active VCS provider.
-4. For each guarded mutation, use native `question` with concise choices and allow a custom answer.
-5. Call `workit_init_apply` only after approval with `confirmed: true` and the chosen action.
-6. Report the structured success, failure stage, or partial result; never infer success.
-
-Never ask for or accept tokens in chat. For missing YouTrack configuration, preview `youtrack_scaffold`; for missing VCS configuration, ask GitLab or GitHub, preview `vcs_scaffold`, and pass `vcs_provider`. Both provider token placeholders may be created, but identify which one is active. Show the returned token-create URL and local edit path after apply. Verification remains a separate `wk-status` run. `todowrite` and `task` are unnecessary here.
-
-## Guided config (action: "config")
-
-When the user wants to personalize the toolkit (locale, timezone, branch policy), ask native questions one at a time:
-
-1. **Locale** — present a combobox of `localeOptions` (en, es-CL, es-MX, es-AR, pt-BR) + custom answer; validate the answer against BCP-47 (`^[a-z]{2,3}(-(?:[A-Z]{2}|[0-9]{3}))?$`, so `es-419` is valid) before passing it.
-2. **Timezone** — e.g. `America/Santiago`, custom allowed.
-3. **Branch policy preset** — gitflow / github-flow / trunk-based / custom.
-4. **Custom branch lists** (only when preset = custom): allowed patterns (`feature/*`, `codex/*`, …) and protected names (`main`, …).
-
-Then call `workit_init_apply` with `action: "config"`, `confirmed: true`, and the answered values. Report the written `config.json` path and its contents.
-
-After config, call `workit_init_apply` with `action: "gitignore"` and `confirmed: true` to ensure the project `.gitignore` covers `docs/*/sdd/` and common OS/editor entries (creates it if missing, preserves existing entries).
-
-After gitignore, call `workit_init_apply` with `action: "hygiene"`, `confirmed: true`, and `include_open_source: true` for open-source repos — creates CHANGELOG.md (Keep a Changelog), README.md, .editorconfig, .gitattributes, and optionally LICENSE + CONTRIBUTING.md. Never overwrites existing files.

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

@@ -1,27 +0,0 @@
----
-name: wk-issue-update
-description: Draft and post a reviewed es-CL YouTrack task update with time.
-disable-model-invocation: true
----
-
-# Issue update
-
-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 `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 `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.
-
-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 === "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,81 +0,0 @@
-# YouTrack update style (Cristhofer / es-CL)
-
-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
-
-**@Alejandra.Flores is the primary reader — she is not a developer.** Write for a technical project manager:
-
-- Lead with **what you worked on and why it mattered**, not implementation mechanics.
-- If you mention something technical (OpenAPI, flags, component names, GUAS, MFE), add **one short plain-language clause** so the reader understands impact without knowing the stack.
-- Prefer product/feature language: *data sources*, *integración con el backend*, *selector de color*, *vista del segundo factor*.
-
-### Technical detail — clarify, don't drop
-
-| Too dev (avoid alone) | Better for manager |
-|-----------------------|-------------------|
-| overlays fuera del shadow DOM en el host | el selector de color no se veía bien cuando el reporte está embebido en la web principal |
-| `replaceUrl: true` en el interceptor | para que al volver atrás no se repitiera el mismo error en bucle |
-| Migré a `daisy-overlay-tokens` | ajusté los estilos del overlay para que respeten el tema de la web |
-
-Only include dev terms the user actually brought up — then **translate or contextualize** in the same breath.
-
-## Shape
-
-1. `# Actualización` (single H1)
-2. Blank line
-3. `@Alejandra.Flores` + greeting (`Hola, buenos días.` / `Hola, buenas tardes.`) — same line or next paragraph OK
-4. **Body: paragraphs**, not bullet dumps
-
-Optional second H1 when the user has a long tangent block:
-
-- `## Off-topic` — only when the user's material is clearly a side topic (tooling, proceso, ideas). Keep the main work under `# Actualización`.
-
-## Openers (only if the user's material implies it)
-
-- `Hoy estuve trabajando en…` / `Hoy por la tarde he estado full con…`
-- `Hoy estuve full con <proyecto>.`
-- `Dado lo que conversamos,…`
-
-Do **not** force an opener.
-
-## Voice
-
-- First person, Chilean Spanish: *harto*, *darle una vuelta*, *al día*, *trasteando*, *ojalá*.
-- Honest: *al parecer*, *creo que*, *imagino que*, *no alcancé a*, *entiendo que*.
-- Explain **why** and **what's next**, not file trees.
-- Close with forward look when relevant: *Mañana…*, *me falta…*, *de momento va bien*.
-
-## Tangents
-
-Natural bridges: `Por otro lado,…`, `Como comentario adicional,…`, `Como punto aparte,…`, `Quiero comentar algo que puede ser interesante.`
-
-Long tooling/process tangents → `## Off-topic` (exemplar 4).
-
-## Allowed formatting
-
-- Backticks for product/component names the user mentioned: `` `color-picker` ``, `` `button` ``
-- Links and screenshots the user attached
-- Short inline lists **only** when comparing options the manager needs to understand (exemplar 4: OpenAPI vs backend vs frontend) — as **prose or one flowing sentence**, not a task checklist
-
-## Forbidden (unless user wrote them verbatim)
-
-- Branch names, SHAs, `src/...` paths
-- Nested `###` subsections for work items
-- Bullet lists of completed tasks (PR style)
-- Stacked changelog verbs: *Implementé*, *Migré*, *Alineé*
-- Invented work or metrics
-- Pasting `git log`, agent session, or `facts.*` into the comment
-- Jargon without a plain-language gloss
-
-## Polish level (ChatGPT-thread)
-
-1. Grammar and spelling.
-2. Smooth sentences; similar length to input.
-3. Split wall-of-text into paragraphs; add bridges only when needed.
-4. **Do not** add facts the user did not supply.
-5. **Do** add a brief gloss when the user used opaque tech terms.
-
-## Length
-
-Match the user. Never pad.

package/skills/wk-meetings/SKILL.md

@@ -1,17 +0,0 @@
----
-name: wk-meetings
-description: Log meeting time only to the configured YouTrack meeting issue.
-disable-model-invocation: true
----
-
-# Meetings
-
-1. Load this skill explicitly through OpenCode's `skill` tool.
-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 `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 `workit_youtrack_post`. `todowrite` and `task` are unnecessary here.

package/skills/wk-pr/SKILL.md

@@ -1,27 +0,0 @@
----
-name: wk-pr
-description: Preview and create a pull or merge request from branch-exclusive facts.
-disable-model-invocation: true
----
-
-# Pull request
-
-1. Load this skill explicitly through OpenCode's `skill` tool.
-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 `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 `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.
-3. **Skip linking** — no issue line in the PR body.
-
-Pass the chosen issue to pr-create via env: `WORKFLOW_GH_ISSUE=<n>` and, when the PR does NOT resolve the issue, `WORKFLOW_GH_ISSUE_RELATION=related` (default `closes`). The youtrack linking flow (`youtrack.link_issues`) for work workspaces is unchanged.
-
-Only feature or bugfix branches may target the configured base; never create from a protected branch. The body must describe only branch-exclusive changes, follow the repository template when present, and disclose failed or skipped verification. Never expose tokens, edit product files, or fall back to provider CLIs. `todowrite` and `task` are unnecessary here.

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

@@ -1,15 +0,0 @@
----
-name: wk-release-notes
-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 `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.
-6. Report the structured success, failure stage, or partial result; never infer success.
-
-Write for users: supported highlights, fixes, upgrade notes, and known issues only. Omit empty sections except Highlights, and say directly when the resolved range contains no user-facing changes. Do not edit files, publish a release, or infer a range. `todowrite` and `task` are unnecessary here.

package/skills/wk-status/SKILL.md

@@ -1,16 +0,0 @@
----
-name: wk-status
-description: Report workit, YouTrack, and VCS health.
-disable-model-invocation: true
----
-
-# Status
-
-1. Load this skill explicitly through OpenCode's `skill` tool.
-2. Call the read-only `workit_status` context tool once; its result is ground truth.
-3. Draft the health report from structured facts.
-4. This workflow has no guarded mutation and does not need `question`.
-5. Do not call any mutation tool.
-6. Report the structured success, failure stage, or partial result; never infer success.
-
-Show every `items[]` result, the resolved YouTrack settings and verification, the VCS provider and verification, and the exact `ready` verdict. For placeholders, point to the returned token creation and edit paths; never request tokens in chat. Use only `workit_status` and report its structured state. Do not run shell, Git, direct HTTP, isolated token verification, or any mutation. `todowrite` and `task` are unnecessary for this read-only workflow.

package/skills/wk-verify/SKILL.md

@@ -1,16 +0,0 @@
----
-name: wk-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 `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 `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.