@brainervirus/workit-cursor 0.11.0 → 1.0.0

package/skills/wk-handoff/SKILL.md

@@ -1,55 +0,0 @@
----
-name: wk-handoff
-description: Emit copy-paste implementation prompt for a new chat via workit_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 `workit_handoff_prompt` with the **full** user message as `message`.
-
-**Repository calls:** For every repository-scoped `workit_*` call, pass the active Cursor workspace as `workspace_root`; never rely on the MCP process default.
-
-**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 `workit_sdd_context`, **Cursor TodoWrite** (with returned `todos`), and `workit_plan_tasks` in Chat B before Task 1. SDD artifacts go to `docs/<slug>/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 `workit_resolve_branch` + `workit_branch_setup` in-place. Commits use workit **/wk-commit** skill — no separate commit-policy field.
-
-`workit_handoff_prompt` also returns `tasks[]`, `branch`, `sdd_dir`, `completed_task_ids`, and `todos` for same-session MCP use — not copy-paste transport.
-
-A destination run that executes the plan must still end with `workit_plan_complete` once the SDD ledger is complete and repository verification passes, and never finish the run while the plan is still `active`.
-
-## 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

@@ -1,58 +0,0 @@
----
-name: wk-implement
-description: Execute an approved Superpowers plan on Cursor as the coordinator session in either approved execution mode. Subagent-driven dispatches Cursor-native subagents through a lease/token capability; Inline executes every task in this session. Use for /wk-implement or "implement from plan".
-disable-model-invocation: true
----
-
-# Implement
-
-Execute the plan in the **approved execution mode** recorded by `workit_plan_menu` (call `workit_flow_status` to read it). In Subagent-driven mode this session never edits product code — dispatch Cursor-native subagents; in Inline mode it executes every task itself. Plan-level edits stay coordinator-gated.
-
-## Step 1 — Gather facts (required)
-
-Call MCP tool `workit_plan_tasks` with `plan_path` from the user's message and `spec_path` when known.
-
-**Repository calls:** For every repository-scoped `workit_*` call, pass the active Cursor workspace as `workspace_root`; never rely on the MCP process default.
-
-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/workit/`.
-
-Load `templates/execution-contract.md`. Substitute `<SPEC_PATH>`, `<PLAN_PATH>`, `<BRANCH>`, `<SDD_DIR>`, `<TASK_LIST>` from MCP. OMIT the `## Handoff destination` section and its `<workflow-handoff-destination>` marker line — that section is only for sessions started from a `workit_handoff_prompt` destination prompt. This executor is NOT a destination and must never present itself as one (five-choice source menu, Handoff still available). If template missing, stop with error.
-
-## Step 3 — Route by execution mode
-
-Announce: "Using implement + <mode>."
-
-**Before Task 1 — validate + SDD + TodoWrite UI + branch (no worktrees):**
-
-0. `workit_docs_validate` with spec + plan paths — hard-fail before any SDD mutation
-1. `workit_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. `workit_resolve_branch` with spec + plan paths
-4. If `needs_checkout` and `dirty` → native **AskQuestion** asks whether to stash before checkout
-5. `workit_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 `workit_verify` and `workit_git_context` MCP tools.
-
-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.
-
-Do not emit a handoff fence — this is in-session execution.
-
-### Subagent-driven
-
-Requires the flow's execution mode `subagent-driven` (set by `workit_plan_menu`).
-
-1. `workit_plan_menu` returned the raw **`coordinator_lease`** exactly once — use that stored value; the flow state persists only its hash.
-2. Per task: call MCP `workit_delegate` with `{slug, plan_path, task_id, coordinator_lease, workspace_root}` to mint a task-scoped **`delegation_token`**.
-3. Dispatch a Cursor-native subagent whose prompt includes the task brief and the raw `delegation_token`; the worker passes it as `delegation_token` on its mutation calls (`workit_sdd_task_brief`, `workit_sdd_review_package`, `workit_sdd_append_progress`, `workit_branch_setup`, `workit_pr_create`, …). The MCP validates the token against the flow state and fails closed on invalid, wrong-task, wrong-workspace, or revoked tokens.
-4. Coordinator product edits stay blocked — implementation, reviews, and fix rounds happen in the dispatched subagents.
-5. Appending the task's progress line with the worker's token via `workit_sdd_append_progress` revokes that task's token; mint a fresh token per task.
-
-### Inline
-
-Load and follow `executing-plans` in the current session. Every task runs in this agent — single-agent, no dispatch, no token minting.
-
-**Mandatory:** end the run by calling MCP `workit_plan_complete` 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,107 +0,0 @@
----
-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 `workit_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: `workit_init_apply` action=`npm_install` confirmed=`true`
-
-### YouTrack scaffold
-
-Native `AskQuestion` asks whether to create the YouTrack scaffold → on yes: `workit_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: `workit_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 `workit_init_apply` with `confirmed: true`.
-- Verification is **`/wk-status`** only — not part of init.

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

@@ -1,101 +0,0 @@
----
-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.
-
-**Repository calls:** For every repository-scoped `workit_*` call, pass the active Cursor workspace as `workspace_root`; never rely on the MCP process default.
-
-## Step 0 — Toolkit ready
-
-If unsure, call `workit_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 `workit_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 `workit_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 `workit_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 `workit_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 → `workit_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 `workit_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:
-
-`workit_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 `workit_youtrack_log_time` using the same `issueId` and `minutes`; never call `workit_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

@@ -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,50 +0,0 @@
----
-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 `workit_status`. Stop if `ready: false`.
-
-## Step 1 — Context (required)
-
-Call MCP `workit_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 → `workit_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 `workit_youtrack_log_time` with `issueId`, `minutes`, `text` (from `workItemText`). **Do not pass `date`** — tool uses epoch ms automatically.
-
-**Never** call `workit_youtrack_post` from this skill.
-
-## Rules
-
-- Tools only — no direct YouTrack HTTP.
-- No comment on meeting issues.

package/skills/wk-pr/SKILL.md

@@ -1,90 +0,0 @@
----
-name: wk-pr
-description: Draft or create PR/MR via workit_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/workit/vcs.json`.
-
-**Setup:** `/wk-init` → pick provider → VCS scaffold → edit active token file.
-
-**Active provider:** read `vcs_config.provider` from `workit_pr_context` (or `provider` in `~/.config/workit/vcs.json`). That decides `glab` vs `gh`.
-
-## Step 1 — Gather facts (required)
-
-Call MCP `workit_pr_context` with **no `range` argument** unless the user supplied an explicit git range string.
-
-**Repository calls:** For every repository-scoped `workit_*` call, pass the active Cursor workspace as `workspace_root`; never rely on the MCP process default.
-
-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`:
-
-`workit_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 `workit_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 `workit_pr_create`.
-- Do not claim validation passed unless evidence exists.

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

@@ -1,57 +0,0 @@
----
-name: wk-release-notes
-description: Draft release notes via workit_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 `workit_release_notes_context` with arguments from the user's message (range, version, paths, etc.).
-
-**Repository calls:** For every repository-scoped `workit_*` call, pass the active Cursor workspace as `workspace_root`; never rely on the MCP process default.
-
-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.