@brainervirus/workit-cursor 0.4.0

package/skills/wk-handoff/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: wk-handoff
+description: Emit copy-paste implementation prompt for a new chat via workflow_handoff_prompt. Explicit /wk-handoff only.
+disable-model-invocation: true
+---
+
+# Handoff
+
+Emit a copy-paste prompt for a **new** implementation chat.
+
+## Step 1 — Gather facts (required)
+
+Call MCP tool `workflow_handoff_prompt` with the **full** user message as `message`.
+
+**Workspace root:** defaults to the Cursor workspace. Pass `workspace_root` when spec/plan paths are relative to a different repository.
+
+**Thread context:** If this thread has a known spec/plan pair (from brainstorming, writing-plans, or open files), append both paths to `message` even when the user only typed `/wk-handoff`. Without explicit paths, the tool picks the **most recently touched** linked pair under `docs/<slug>/` (plan `**Spec:**` link + file mtimes) — not “only one file in the folder.”
+
+Use the tool return value as ground truth. Do not read git, run npm, or infer repo state yourself.
+If the tool errors, report the error and stop.
+
+The pasted prompt includes instructions to call `workflow_sdd_context`, **Cursor TodoWrite** (with returned `todos`), and `workflow_plan_tasks` in Chat B before Task 1. SDD artifacts go to `docs/<plan-basename>/sdd/` — never `.superpowers/sdd`. TodoWrite is required for the native Cursor task list UI (remaining/completed); the SDD ledger is persistence only. The fenced `prompt` does not contain `section_text`. **Branch** is resolved automatically in the prompt (from spec/plan or derived as `feature/*` / `bugfix/*`). **No worktrees** — Chat B uses `workflow_resolve_branch` + `workflow_branch_setup` in-place. Commits use workit **/wk-commit** skill — no separate commit-policy field.
+
+`workflow_handoff_prompt` also returns `tasks[]`, `branch`, `sdd_dir`, `completed_task_ids`, and `todos` for same-session MCP use — not copy-paste transport.
+
+## Output (success)
+
+When the tool returns `{ prompt }`, output **only** one fenced code block containing `prompt` verbatim. No preamble, no explanation outside the fence.
+
+## Output (failure)
+
+When the tool returns `{ error }` (and optional `candidates`):
+
+- Plain text only — **no fenced block**
+- State the error clearly
+- If multiple specs or plans exist, list candidate paths from `candidates`
+- Instruct the user to re-run with explicit paths in the message:
+
+```text
+/wk-handoff
+docs/my-feature/spec.md
+docs/my-feature/plan.md
+```
+
+Example:
+
+```text
+Could not resolve spec and plan. Mention both paths in your message, or ensure the newest plan links to its spec via **Spec:**.
+Re-run with paths from this thread, e.g.:
+/wk-handoff
+docs/<slug>/spec.md
+docs/<slug>/plan.md
+```

package/skills/wk-implement/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: wk-implement
+description: Execute a Superpowers plan as SDD coordinator with subagent-per-task and mandatory review loops. Use for /wk-implement or "implement from plan using subagent-driven-development".
+disable-model-invocation: true
+---
+
+# Implement
+
+Execute a plan as **coordinator only** (subagent-driven-development). Do not edit product code in this thread.
+
+## Step 1 — Gather facts (required)
+
+Call MCP tool `workflow_plan_tasks` with `plan_path` from the user's message and `spec_path` when known.
+
+**Workspace root:** defaults to the Cursor workspace. Pass `workspace_root` when plan/spec paths are relative to a different repository.
+
+Use the returned `tasks[]` as ground truth. Cache each `section_text` for subagent prompts. Do not read the plan file for task text.
+
+## Step 2 — Load execution contract
+
+Resolve plugin root: `WORKFLOW_TOOLKIT_ROOT` env or `~/.cursor/plugins/local/workflow-toolkit/`.
+
+Load `templates/execution-contract.md`. Substitute `<SPEC_PATH>`, `<PLAN_PATH>`, `<BRANCH>`, `<SDD_DIR>`, `<TASK_LIST>` from MCP. If template missing, stop with error.
+
+## Step 3 — Follow contract
+
+Announce: "Using implement + subagent-driven-development."
+
+**Before Task 1 — validate + SDD + TodoWrite UI + branch (no worktrees):**
+
+0. `workflow_docs_validate` with spec + plan paths — hard-fail before any SDD mutation
+1. `workflow_sdd_context` with `plan_path` — cache `sdd_dir`, `completed_task_ids`, **`todos`**
+2. **TodoWrite** with `todos` from step 1 (`merge: false`) — required for Cursor native task list UI (SDD is not a UI substitute)
+3. `workflow_resolve_branch` with spec + plan paths
+4. If `needs_checkout` and `dirty` → native **AskQuestion** asks whether to stash before checkout
+5. `workflow_branch_setup` with `target_branch`, `stash`, `sdd_dir` from step 1
+
+Follow the contract verbatim. Keep TodoWrite `in_progress`/`completed` in sync each task. At verify/commit phase use `workflow_verify` and `workflow_git_context` MCP tools.
+
+Do not emit a handoff fence — this is in-session execution.

package/skills/wk-init/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: wk-init
+description: One-time workit setup — MCP deps, YouTrack, and VCS (GitLab/GitHub) config. Tokens edited locally only. Use /wk-init.
+disable-model-invocation: true
+---
+
+# Init
+
+Scaffold config via MCP. **Never paste API tokens in chat.**
+
+**Agent language:** English unless the user writes in another language.
+
+## Step 1 — Status (required)
+
+Call MCP `workflow_toolkit_init_status`. Show `items[]` in English.
+
+### YouTrack settings (when `youtrack_config` present)
+
+| Setting | Value |
+|---------|-------|
+| Config file | clickable `config_edit_path` |
+| Base URL | `baseUrl` |
+| Meeting issue | `meetingIssue` + `meetingIssueUrl` |
+| Manager mention | `defaultMention` |
+| Timezone / locale | `timezone` / `locale` |
+| Meeting time | `/wk-meetings` |
+| Task updates | `/wk-issue-update` |
+
+### VCS / PR settings (when `vcs_config` present)
+
+| Setting | Value |
+|---------|-------|
+| Config file | `config_edit_path` → `vcs.json` |
+| Provider | `provider` (`gitlab` or `github`) |
+| Target branch | `defaultTargetBranch` (usually `develop`) |
+| PR skill | `/wk-pr` |
+| Squash on merge | `pr.squashOnMerge` |
+| Remove source branch | `pr.removeSourceBranch` (default `true`) |
+| Switch provider | `switchHint` |
+
+## Step 2 — Apply missing pieces
+
+### mcp_deps
+
+Native `AskQuestion` asks whether to install MCP dependencies → on yes: `workflow_toolkit_init_apply` action=`npm_install` confirmed=`true`
+
+### YouTrack scaffold
+
+Native `AskQuestion` asks whether to create the YouTrack scaffold → on yes: `workflow_toolkit_init_apply` action=`youtrack_scaffold` confirmed=`true`
+
+### VCS scaffold (GitLab + GitHub token files)
+
+Only when `items[vcs_json].ok` is **false**:
+
+1. Native `AskQuestion` asks for GitLab or GitHub → remember `provider` (`gitlab` | `github`).
+2. Native `AskQuestion` asks `Create vcs.json and token placeholders for <provider>?`
+   → on yes: `workflow_toolkit_init_apply` action=`vcs_scaffold` confirmed=`true` **`vcs_provider=<chosen provider>`**
+
+Both `gitlab.token` and `github.token` are always created (switch later by editing `provider` in `vcs.json`). Tell the user which token file is **active** for `/wk-pr` based on the chosen provider.
+
+Optional: `vcs_target_branch` if user states a non-`develop` default.
+
+## Step 3 — User edits tokens (outside chat)
+
+### YouTrack
+
+Show from `youtrack_config.tokenCreate` or `items[youtrack_token]`:
+
+| Field | Source |
+|-------|--------|
+| Create token (click) | `token_create_url` — opens Profile → **Account Security** (Tokens section) |
+| Paste token into | `token_edit_path` on `youtrack_token` item |
+| Prefilled name | `token_name` → `workit` |
+| Scope | `token_scopes` → `YouTrack` only |
+
+YouTrack does **not** support URL prefill for name/scopes — after the link opens, click **New token** and enter name + scope manually (`token_create_steps` if present).
+
+1. [Create YouTrack token](<token_create_url>) → **New token** → name **workit**, scope **YouTrack** → **Create token**
+2. Copy token → open [youtrack.token](<token_edit_path>) → replace `YOUR_TOKEN_HERE` → save
+3. **`/wk-status`**
+
+### VCS (active provider)
+
+For the **active** provider (`vcs_config.provider`), show from `vcs_config.tokenCreate` or `items[gitlab_token|github_token].token_create_url`:
+
+| Field | Source |
+|-------|--------|
+| Create token (click) | `token_create_url` — opens provider form with **name**, **description**, and **scopes/permissions** prefilled |
+| GitHub classic fallback | `token_create_url_classic` on `github_token` item only |
+| Paste token into | `token_edit_path` on the active provider item |
+| Prefilled name | `workit` |
+| GitLab scopes | `api` |
+| GitHub permissions | `pull_requests:write`, `contents:write`, `metadata:read` |
+
+**Active provider (gitlab example):**
+
+1. [Create GitLab token](<token_create_url>) — form opens with name/scopes filled → click **Create**
+2. Copy token → open [gitlab.token](<token_edit_path>) → replace `YOUR_TOKEN_HERE` → save
+3. **`/wk-status`**
+
+**Inactive provider:** show `vcs_config.tokenCreateUrls.<other>` link for later; only the active token file is required now.
+
+## Rules
+
+- Never ask for or accept tokens in chat.
+- Mutations only via `workflow_toolkit_init_apply` with `confirmed: true`.
+- Verification is **`/wk-status`** only — not part of init.

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

@@ -0,0 +1,99 @@
+---
+name: wk-issue-update
+description: Draft and post ES-CL YouTrack task update with time tracking via MCP only. Use /wk-issue-update.
+disable-model-invocation: true
+---
+
+# Issue Update — time + ES-CL comment
+
+Post a Spanish comment and log time on a **task** issue (not the meeting issue).
+
+**Agent language:** English unless the user writes in another language. **Comment body:** Spanish (`es-CL`) only.
+
+**Style contract:** Read [references/youtrack-update-style.md](references/youtrack-update-style.md) before every draft or polish pass. Output should read like the user's ChatGPT revision thread — **their voice, manager-friendly**, not an agent status report.
+
+**Audience:** @Alejandra.Flores — not a developer. Clarify technical terms in plain language when they appear.
+
+## Step 0 — Toolkit ready
+
+If unsure, call `workflow_toolkit_status`. Stop if `ready: false`.
+
+## Step 1 — Issue (required)
+
+**Always** confirm which YouTrack issue this update is for.
+
+1. If the user did **not** already paste a YouTrack URL or issue id (`NSR-40`) in the message that started this flow, ask:
+   > Paste the YouTrack issue URL or id for this update (e.g. `https://…/issue/NSR-40` or `NSR-40`).
+2. Wait for their reply. Do **not** guess from spec/plan unless they explicitly say to use the plan's issue.
+3. Call `workflow_youtrack_parse_issue` with `issue_ref` = what they pasted.
+4. On error, ask again with the parse error. On success, note `issueId`.
+
+## Step 2 — Context (required)
+
+Call `workflow_youtrack_context` with `issue_id` from Step 1 (or `issue_url` / `issue_ref` directly). Stop on error.
+
+Show the resolved issue once in chat: `Updating **{issueId}**` (+ `issueUrl` if returned).
+
+## Step 3 — How to start (required)
+
+Use native `AskQuestion`: title `Draft mode`; prompt `How should we start the YouTrack update?`; options `I have notes` (recommended), `Help me remember`, and `Draft for me`.
+
+### Mode `paste` — I have notes (Recommended)
+
+Ask user to paste rough notes, half-written update, or bullets. Skip to Step 5.
+
+### Mode `remind` — Help me remember
+
+1. Optionally call `workflow_git_context` (and read spec/plan title) **only to remind the user in English chat** — short prose: what repo, branch, themes of commits, not a pasteable comment.
+2. Ask conversational follow-ups: *¿Qué te costó más? ¿Qué queda para mañana? ¿Algo bloqueado?*
+3. User replies in their words (Spanish messy notes OK).
+4. Treat their reply as the draft → Step 5.
+
+**Never** post git context or commit list directly to YouTrack.
+
+### Mode `auto` — Draft for me to edit
+
+1. Use `workflow_git_context` + conversation context to infer what they likely worked on.
+2. Write a **first draft in Spanish** per **youtrack-update-style.md** (paragraphs, manager-friendly, no file paths).
+3. Show draft in a fenced block. Ask user to correct, add, or replace — user may reply with a full rewrite.
+4. Use their corrected version as input → Step 5.
+
+## Step 4 — Duration
+
+Ask time spent on this task issue. User text → `workflow_youtrack_parse_duration`. **Do not compute minutes yourself.**
+
+## Step 5 — Polish (ChatGPT pass)
+
+Polish the approved draft per **youtrack-update-style.md**:
+
+- Paragraphs, not PR bullets
+- Technical terms get a short plain-language gloss for the manager
+- Keep `# Actualización` + greeting — if user already included them, do not duplicate `@Alejandra.Flores`
+- `## Off-topic` only if user's material has a clear tangent section
+
+Call `workflow_youtrack_draft` with:
+
+- `issueId` from Step 1
+- `userNotes` = polished **body only** (no `# Actualización`, no greeting line)
+- `greeting` from context
+- **Do not pass** `projectName`, `facts`, `includeProjectOpener`, or `includeFacts`
+
+## Step 6 — Review
+
+Show returned `markdown` in a fenced block. User may edit in chat (apply edits and re-show if they change wording).
+
+## Step 7 — Post
+
+Use native `AskQuestion`: title `Post to YouTrack`; prompt `Post this reviewed update to YouTrack and log the approved time?`; options `Post and log time` and `Cancel`. On confirm:
+
+`workflow_youtrack_post` with `confirmed: true`, `issueId`, `markdown`, `minutes`. **Do not pass `date`.**
+
+If the result has `partial: true`, the comment already posted. Report the time-log failure and retry only with `workflow_youtrack_log_time` using the same `issueId` and `minutes`; never call `workflow_youtrack_post` again.
+
+## Rules
+
+- Never call YouTrack HTTP directly.
+- Never post without `confirmed: true`.
+- Never skip Step 1 — each run targets the issue the user names.
+- If it sounds robotic, remove structure you added and re-read the style reference.
+- End state is always: **user reviewed → post + log time**.

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

@@ -0,0 +1,81 @@
+# 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.
+
+## 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

@@ -0,0 +1,50 @@
+---
+name: wk-meetings
+description: Log meeting time only via workit MCP — general (IRPT-12) or web (NSXFT-21). No comments. Use /wk-meetings.
+disable-model-invocation: true
+---
+
+# Meetings — time only
+
+Log meeting time to a **meeting issue** from config. **Never post a comment.**
+
+**Agent language:** English unless the user writes in another language.
+
+## Step 0 — Toolkit ready
+
+If unsure, call `workflow_toolkit_status`. Stop if `ready: false`.
+
+## Step 1 — Context (required)
+
+Call MCP `workflow_youtrack_context` with `mode: "meetings"` (no `issue_id` yet). Stop on error.
+
+## Step 2 — Pick meeting type (required)
+
+Use native **AskQuestion** with `meetingOptions` from context:
+
+- Title: `Meeting type`
+- Prompt: `Where should this time be logged?`
+- Options: one `id:label` pair per option — use `key` as id, `label` as label (include issue id in label, e.g. `IRPT-12 — General meetings`)
+
+→ **AskQuestion** → map selected `key` to `issue` and `workItemText` from `meetingOptions`.
+
+## Step 3 — Duration
+
+Ask how much meeting time today (English UI). User text → `workflow_youtrack_parse_duration`. **Do not compute minutes yourself.**
+
+## Step 4 — Preview + confirm
+
+Show preview: chosen issue, label, minutes, work-item text.
+
+Use native **AskQuestion** to confirm logging the shown meeting time; on yes:
+
+## Step 5 — Log time only
+
+Call `workflow_youtrack_log_time` with `issueId`, `minutes`, `text` (from `workItemText`). **Do not pass `date`** — tool uses epoch ms automatically.
+
+**Never** call `workflow_youtrack_post` from this skill.
+
+## Rules
+
+- Tools only — no direct YouTrack HTTP.
+- No comment on meeting issues.

package/skills/wk-pr/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: wk-pr
+description: Draft or create PR/MR via workflow_pr_context + glab/gh. Squash on merge + delete source branch. Use /wk-pr.
+---
+
+# PR — Draft or Create
+
+Draft a merge request / pull request body, or create it on GitLab (`glab`) / GitHub (`gh`) using `~/.config/workflow-toolkit/vcs.json`.
+
+**Setup:** `/wk-init` → pick provider → VCS scaffold → edit active token file.
+
+**Active provider:** read `vcs_config.provider` from `workflow_pr_context` (or `provider` in `~/.config/workflow-toolkit/vcs.json`). That decides `glab` vs `gh`.
+
+## Step 1 — Gather facts (required)
+
+Call MCP `workflow_pr_context` with **no `range` argument** unless the user supplied an explicit git range string.
+
+On `feature/*` or `bugfix/*`, the tool compares **only against `develop`** (never `main`).
+
+Use the tool return as ground truth. Pay attention to:
+
+- `body_style_rules` and `merged_pr_style.examples` — match your recent merged MRs
+- `vcs_config` — provider, `defaultTargetBranch`, `pr.squashOnMerge`, `pr.removeSourceBranch`
+- `commits`, `diff_stat`, `files` — **for drafting only**, never paste into the published body
+
+## Step 2 — Draft body (required)
+
+Write title + body per rules below. Read `merged_pr_style` if present.
+
+### Body rules (from your merged MRs)
+
+**Include:**
+
+- `## Summary` — short outcome bullets (what changed for the user/reviewer)
+- `## Validation` or `## Test plan` — only checks you actually ran (`[x]` when done)
+
+**Never include:**
+
+- `## Notes` with branch names, `develop..HEAD`, commit counts, or file counts
+- Commit log, `diff_stat`, or changed-files list
+- Git sync warnings, `range_mode`, or agent meta
+- Long nested `###` sections duplicating the diff
+- Scope disclaimers ("scoped to branch X…") unless the user explicitly asks
+
+Title: Conventional Commits — `type(scope): subject`, imperative, lowercase, no trailing period.
+
+## Step 3 — Review (show before confirm)
+
+Show:
+
+```md
+Title:
+<copy-paste title>
+
+Body:
+<copy-paste body>
+```
+
+## Step 4 — Create (optional)
+
+Use native `AskQuestion`: title `Create MR/PR`; prompt `Create the reviewed MR/PR now?`; options `Create` and `Cancel`. On `Create`:
+
+`workflow_pr_create` with `confirmed: true`, `title`, `body`, optional `target_branch` (defaults from vcs.json).
+
+**On failure:** show the tool `error` / `stderr` / `hint` and stop. **Never** fall back to running `glab` or `gh` in the shell — creation must go through `workflow_pr_create` only.
+
+Creation uses vcs.json flags (both default `true`):
+
+- **squash on merge** — single commit when you merge in GitLab/GitHub UI
+- **remove source branch** — branch deleted after merge (clean `develop`, no stale `feature/*`)
+- **push branch** — pushes current branch before create
+
+GitLab: `glab mr create` with `-t`, `-d` (required in non-interactive mode), `--squash-before-merge`, `--remove-source-branch`  
+GitHub: use **Squash and merge** + **Delete branch** in the UI (or `gh pr merge --squash --delete-branch`); create step sets title/body only.
+
+## Branch policy (tool-enforced)
+
+| Current branch | `/wk-pr` without args |
+| -------------- | --------------------- |
+| `feature/*`, `bugfix/*` | OK — base `develop` |
+| protected branches | Error |
+
+## Rules
+
+- Do not edit product files in this skill (except user asks to fix PR template).
+- Never paste VCS tokens in chat.
+- **Never run `glab` or `gh` directly** — only `workflow_pr_create`.
+- Do not claim validation passed unless evidence exists.

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

@@ -0,0 +1,57 @@
+---
+name: wk-release-notes
+description: Draft release notes via workflow_release_notes_context. Use for /wk-release-notes or "draft release notes".
+---
+
+# Release Notes — User-Facing Release Notes
+
+Draft release notes for a given release, version, tag, or commit range.
+
+## Step 1 — Gather facts (required)
+
+If the user did not provide an exact tag, version, or commit range, ask for it before calling the tool.
+
+Call MCP tool `workflow_release_notes_context` with arguments from the user's message (range, version, paths, etc.).
+
+**Workspace root:** defaults to the Cursor workspace. Pass `workspace_root` when the user names a different repository path.
+
+Use the tool return value as ground truth. Do not read git, run npm, or infer repo state yourself.
+If the tool errors, report the error and stop.
+
+Pass tag or range strings as `range_or_tag`.
+
+## Rules
+
+- Do not edit files unless the user explicitly asks for an edit target.
+- Do not create or publish a release.
+- Write for users, not maintainers.
+- Mention features, behavior changes, fixes, migration notes, installation/update notes, and known issues when supported by context.
+- Do not mention CI, tests, refactors, formatting, dependency bumps, or internal tooling unless they directly affect users.
+- If the requested release/range is missing or ambiguous, ask for the exact tag, version, or commit range.
+- If there are no user-facing changes, say that directly.
+
+## Output
+
+Return only:
+
+```md
+# <Release title>
+
+## Highlights
+
+- ...
+
+## Fixes
+
+- ...
+
+## Upgrade Notes
+
+- ...
+
+## Known Issues
+
+- ...
+```
+
+Omit empty sections except `Highlights`. If `Highlights` would be empty, output a short note explaining why.

package/skills/wk-status/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: wk-status
+description: Full workit health check — MCP deps, YouTrack + VCS (GitLab/GitHub) API verify. Use /wk-status after editing token files.
+disable-model-invocation: true
+---
+
+# Status
+
+Deterministic health check. **Tools only — no manual git/curl.**
+
+**Agent language:** English unless the user writes in another language.
+
+## Step 1 — Full status (required)
+
+Call MCP `workflow_toolkit_status` once.
+
+Use the return value as ground truth. Do not infer state yourself.
+
+## Step 2 — Report (English)
+
+Show a table from `items[]`:
+
+| Item                 | OK                       | Notes                              |
+| -------------------- | ------------------------ | ---------------------------------- |
+| MCP npm dependencies | items[mcp_deps].ok       | path                               |
+| YouTrack config      | items[youtrack_json].ok  | path                               |
+| YouTrack token file  | items[youtrack_token].ok | placeholder? → show `token_create_url` + `token_edit_path` |
+| VCS config           | items[vcs_json].ok       | path                               |
+| GitLab token         | items[gitlab_token].ok   | required when provider=gitlab      |
+| GitHub token         | items[github_token].ok   | required when provider=github      |
+
+### YouTrack settings (required when `youtrack_config` present)
+
+Always show this block from tool output — user expects to see meeting issue and time-logging targets:
+
+| Setting | Value |
+|---------|-------|
+| Config file | clickable `youtrack_config.config_edit_path` |
+| Meeting issue | `meetingIssue` — time only via `/wk-meetings` |
+| Meeting URL | `meetingIssueUrl` as markdown link |
+| Manager tag | `@` + `defaultMention` |
+| Task issue (time + comment) | from active spec/plan `**YouTrack:**` — not stored in json |
+| Timezone | `timezone` |
+
+Then **YouTrack API** from `youtrack_verify`:
+
+- `ok: true` → show `login`, `name`, `meetingIssue`, `meetingIssueSummary` if present
+- `ok: false` → show `error` and `next_step` from tool
+
+### VCS / PR settings (when `vcs_config` present)
+
+| Setting | Value |
+|---------|-------|
+| Config | `vcs_config.config_edit_path` |
+| Provider | `provider` (`gitlab` / `github`) |
+| Target branch | `defaultTargetBranch` |
+| Squash on merge | `pr.squashOnMerge` |
+| Remove source branch | `pr.removeSourceBranch` |
+
+**VCS API** from `vcs_verify`:
+
+- `ok: true` → show `username`, `provider`
+- `ok: false` → show `vcs_token_edit_path` or token `fix` from items when placeholder
+
+## Step 3 — Verdict
+
+- `ready: true` → "All checks passed. Toolkit is ready."
+- `ready: false` with `placeholder: true` on **YouTrack** → show both links:
+
+```markdown
+1. [Create YouTrack token](<token_create_url>) — New token → name **workit**, scope **YouTrack**
+2. Paste into [youtrack.token](<token_edit_path>) — replace `YOUR_TOKEN_HERE`, save, then `/wk-status`
+```
+
+Use `items[youtrack_token].token_create_url` / `token_edit_path`, or top-level `token_create_url` + `token_edit_path` from tool output.
+
+- `ready: false` with VCS placeholder → show **`vcs_token_edit_path`** and active provider `token_create_url` from items.
+
+- `ready: false` (other) → show `next_step` and `youtrack_verify.error` from tool output.
+
+## Rules
+
+- Do not call YouTrack HTTP directly — `workflow_toolkit_status` includes verify.
+- Do not ask user to paste token — point them to edit the token file if `placeholder: true`.
+- Optional: `workflow_youtrack_verify_token` only if user asks to re-test API alone.