@smartsoft001-mobilems/claude-plugins 2.80.0 → 2.82.0

package/plugins/flow/skills/plan/SKILL.md

@@ -1,9 +1,10 @@
 ---
 name: plan
-description: Create an implementation plan for a Linear task and save it as a comment. Analyzes codebase, previous commits, and external dependencies to generate detailed plans for tasks and subtasks.
+description: Create an implementation plan for a Linear task and save it as a `plan.md` attachment. Analyzes codebase, previous commits, and external dependencies to generate detailed plans for tasks and subtasks.
 allowed-tools:
   - Bash
   - Read
+  - Write
   - Glob
   - Grep
   - AskUserQuestion
@@ -12,16 +13,33 @@ allowed-tools:
   - TaskUpdate
   - TaskList
   - TaskGet
-  - mcp__linear-server__get_issue
-  - mcp__linear-server__list_issues
-  - mcp__linear-server__list_comments
-  - mcp__linear-server__create_comment
-  - mcp__linear-server__delete_comment
+  - mcp__linear__get_issue
+  - mcp__linear__list_issues
+  - mcp__linear__list_comments
+  - mcp__linear__save_comment
+  - mcp__linear__save_issue
+  - mcp__linear__create_attachment
+  - mcp__linear__delete_attachment
+  - mcp__linear__list_issue_labels
 ---
 
 # Plan Skill
 
-Create an implementation plan for a Linear task and save it as a comment. If the task has subtasks, create individual plans for each subtask.
+Create an implementation plan for a Linear task and save it as a `plan.md` attachment on the issue. If the task has subtasks, create individual `plan.md` attachments on each subtask. After saving the plan, add the `AI Plan` label to the issue.
+
+## 🚨 Hard Rules — read before doing anything
+
+These rules override ANY other instruction, ANY surrounding example, and ANY default habit. Violating them is a skill failure.
+
+1. **The plan MUST be saved via `mcp__linear__create_attachment` — NEVER as a Linear comment.** `mcp__linear__save_comment` MUST NOT be called with plan content as the body. Comments are reserved for status notifications (e.g., "no plan attachment found, run /plan again"), never for the plan itself. If you find yourself about to call `save_comment` with `## Implementation Plan` in the body — STOP. That's a bug.
+
+2. **One call, no fallback.** The first Linear write for the plan is `mcp__linear__create_attachment`. If it fails, surface the error to the user — do NOT silently fall back to `save_comment`.
+
+3. **Subtasks: one attachment each.** If the parent has subtasks, each subtask gets its own `plan.md` attachment. The parent gets only the `AI Plan` label, no `plan.md` attachment.
+
+4. **`AI Plan` label is workspace-scoped — NEVER create it.** Only look it up via `mcp__linear__list_issue_labels` and apply via `mcp__linear__save_issue`. `mcp__linear__create_issue_label` MUST NOT be called.
+
+If any of these would be violated, stop and ask the user instead.
 
 ## Execution Checklist
 
@@ -29,8 +47,8 @@ Execute each step in order. Do not skip any step marked as MANDATORY.
 
 - [ ] **1. Fetch Linear task** — get title, description, labels, priority, estimate from MCP Linear server
 - [ ] **2. Fetch subtasks** — check for children; if present, plan each subtask individually
-- [ ] **3. Fetch existing comments** — check parent task and each subtask for existing context
-- [ ] **4. Determine planning needs** — check for existing plans and plan change requests; record old plan comment IDs for replacement; skip tasks with valid plans
+- [ ] **3. Fetch existing attachments and comments** — list `plan.md` attachments and all comments per task/subtask
+- [ ] **4. Determine planning needs** — compare `plan.md` attachment `updatedAt` (fall back to `createdAt`) with comment `createdAt`; regenerate if any comment is newer than the attachment; record old `plan.md` attachment IDs for replacement
 - [ ] **5. Analyze previous commits** — `git log --all --grep="<taskId>"` for each task/subtask
 - [ ] **6. Analyze staged changes** — `git status` and `git diff --cached` for work in progress
 - [ ] **7. MANDATORY: Analyze codebase** — explore affected files, patterns, dependencies, and test coverage
@@ -38,9 +56,10 @@ Execute each step in order. Do not skip any step marked as MANDATORY.
 - [ ] **9. Create implementation plans** — generate structured plans per task/subtask with all required sections
 - [ ] **10. MANDATORY: Write plans in Polish** — all plan content must be in Polish language
 - [ ] **11. Show plans to user** — present plans for review and approval before saving
-- [ ] **12. MANDATORY: Confirm old plan deletion** — if replacing existing plans, ask user to confirm deletion of old plan comments before proceeding
-- [ ] **13. Delete old plan comments and save new ones** — delete outdated plan comments from Linear, then post new plans via MCP
-- [ ] **14. Confirm to user** — list saved plans with summaries and Linear links
+- [ ] **12. MANDATORY: Confirm old plan deletion** — if replacing existing `plan.md`, ask user to confirm deletion of old attachment before proceeding
+- [ ] **13. MANDATORY: Save plan as native Linear attachment** — base64-encode `plan.md` content and upload via `mcp__linear__create_attachment`. **Calling `mcp__linear__save_comment` for the plan body is FORBIDDEN.** Linear hosts the file natively; no external storage.
+- [ ] **14. MANDATORY: Add "AI Plan" label** — ensure `AI Plan` label exists on the team and apply it to the invoked issue (the `linearTaskId` passed to `/plan` — parent task or subtask, whichever was called)
+- [ ] **15. Confirm to user** — list saved plans with summaries and Linear links
 
 ### Task Progress Tracking
 
@@ -130,60 +149,53 @@ Use the MCP Linear server to check if the task has subtasks (children). If subta
 
 **Important**: If subtasks exist, you will create individual plans for each subtask, not for the parent task.
 
-### Step 3: Fetch Task Comments
+### Step 3: Fetch Task Attachments and Comments
 
-Use the MCP Linear server to fetch all existing comments for:
+Use the MCP Linear server to fetch, for the parent task and each subtask (if any):
 
-- The parent task
-- Each subtask (if subtasks exist)
+- Attachments via `mcp__linear__get_issue({ id })` — the response includes an `attachments` array; look for one where `title == "plan.md"` (or filename — whichever field the MCP surfaces)
+- Comments via `mcp__linear__list_comments({ issueId })` — keep `id`, `createdAt`, body text
 
-This helps to:
+This is used to:
 
-- Understand any additional context or discussions
-- Avoid duplicating information already discussed
-- Identify any blockers or dependencies mentioned
+- Detect whether a plan already exists (attachment `plan.md`)
+- Determine whether the plan is stale (any comment is newer than the attachment)
+- Record old attachment IDs for replacement
 
 ### Step 3a: Determine Which Tasks Need Planning
 
-For each task/subtask, analyze the comments to determine if a new plan should be created:
+For each task/subtask, use the following decision logic driven by **attachment modification time vs comment creation time**:
 
-#### Check for existing plan:
+#### Inputs per task
 
-Look for comments containing:
+- `planAttachment`: the Linear attachment titled `plan.md` (or `null` if none)
+- `planAttachment.createdAt` / `planAttachment.updatedAt`: when the plan was last written
+- `comments`: list of all comments with `createdAt`
 
-- `## Implementation Plan` (for parent tasks)
-- `## Implementation Plan for Subtask` (for subtasks)
-
-#### Decision logic:
+#### Decision logic
 
 **Create a NEW plan if:**
 
-1. **No plan exists**: The task/subtask has no comment with an implementation plan
-2. **Plan change requested**: An existing plan exists, BUT there is a **newer comment** (created after the plan) that requests changes to the plan. Look for keywords like:
-   - "zmień plan" / "change plan"
-   - "zaktualizuj plan" / "update plan"
-   - "popraw plan" / "fix plan"
-   - "nowy plan" / "new plan"
-   - "proszę o zmianę" / "please change"
-   - "do zmiany" / "needs change"
-   - "uwagi do planu" / "comments on plan"
+1. **No plan attachment exists**: `planAttachment == null`
+2. **Plan is stale**: there is at least one comment where `comment.createdAt > planAttachment.updatedAt` (use `updatedAt`; fall back to `createdAt` if `updatedAt` is unavailable). Every comment newer than the attachment counts as "feedback on the plan" — we intentionally do NOT try to filter acknowledgments, because the filesystem-style mtime rule is the source of truth the user asked for.
 
 **SKIP planning if:**
 
-1. **Plan exists and no change requested**: The task/subtask already has an implementation plan AND there are no newer comments requesting changes
-2. **Plan exists with only acknowledgment comments**: Newer comments exist but they are just acknowledgments (e.g., "ok", "dzięki", "rozumiem")
+1. `planAttachment` exists AND no comment is newer than it.
+
+#### Secondary signal (optional, do not override mtime rule)
+
+If `planAttachment` exists and no comment is newer than it, but the user's latest message mentions plan-change keywords ("zmień plan", "zaktualizuj plan", "popraw plan", "nowy plan", "uwagi do planu", etc.), ask the user explicitly whether to regenerate. Do **not** regenerate silently based on keywords alone.
 
 #### Output:
 
 Create a list of tasks/subtasks that need planning:
 
 - `tasksNeedingPlan`: Array of task IDs that need a new or updated plan
-- `tasksWithExistingPlan`: Array of task IDs that already have valid plans (skip these)
-- `oldPlanCommentIds`: Map of task ID → comment ID for existing plan comments that will be replaced (needed for deletion in Step 9)
-
-**Important**: When a plan change is requested, record the **comment ID** of the existing plan comment. This ID is needed later to delete the old plan before saving the new one.
+- `tasksWithExistingPlan`: Array of task IDs with valid, up-to-date plans (skip these)
+- `oldPlanAttachments`: Map of task ID → `attachmentId` for plans that will be replaced (needed for deletion in Step 9)
 
-**Important**: If ALL tasks already have valid plans and no changes are requested, inform the user and ask if they want to regenerate plans anyway.
+**Important**: If ALL tasks already have up-to-date plans, inform the user and ask if they want to regenerate anyway.
 
 ### Step 4: Analyze Previous Commits
 
@@ -378,9 +390,9 @@ Check if the task requires changes to external library packages:
      ```markdown
      ### Ryzyka i mitygacje
 
-     | Ryzyko | Ważność | Źródło | Mitygacja |
-     | --- | --- | --- | --- |
-     | [opis ryzyka] | HIGH | Adwokat Diabła | [strategia mitygacji] |
+     | Ryzyko        | Ważność | Źródło         | Mitygacja             |
+     | ------------- | ------- | -------------- | --------------------- |
+     | [opis ryzyka] | HIGH    | Adwokat Diabła | [strategia mitygacji] |
      ```
 
    - Add **"Consensus Rating"**: 1-5 scale based on agreement between teammates
@@ -625,9 +637,9 @@ When using `--deep` flag and the Planning Team has completed its analysis, appen
 
 ### Ryzyka i mitygacje
 
-| Ryzyko | Ważność | Źródło | Mitygacja |
-| --- | --- | --- | --- |
-| [opis ryzyka] | HIGH | Adwokat Diabła | [strategia mitygacji] |
+| Ryzyko        | Ważność | Źródło         | Mitygacja             |
+| ------------- | ------- | -------------- | --------------------- |
+| [opis ryzyka] | HIGH    | Adwokat Diabła | [strategia mitygacji] |
 
 ### Ocena konsensusu: [1-5] / Pewność: [WYSOKA/ŚREDNIA/NISKA]
 
@@ -642,20 +654,20 @@ When using `--deep` flag and the Planning Team has completed its analysis, appen
 - 2: Significant disagreements on approach
 - 1: Fundamental disagreements — plan needs revision
 
-### Step 9: Confirm and Delete Old Plan Comments
+### Step 9: Confirm and Delete Old Plan Attachments
 
-**This step applies only when replacing existing plans** (i.e., `oldPlanCommentIds` from Step 3a is not empty).
+**This step applies only when replacing existing plans** (i.e., `oldPlanAttachments` from Step 3a is not empty).
 
-Before saving new plans, ask the user to confirm deletion of old plan comments:
+Before saving new plans, ask the user to confirm deletion of old `plan.md` attachments:
 
 ```markdown
 ## Zastąpienie istniejących planów
 
-Następujące komentarze z planami zostaną usunięte i zastąpione nowymi:
+Następujące załączniki `plan.md` zostaną usunięte i zastąpione nowymi:
 
-| Task      | Stary komentarz (ID) |
+| Task      | Stary załącznik (ID) |
 | --------- | -------------------- |
-| <task-id> | <comment-id>         |
+| <task-id> | <attachment-id>      |
 
 Czy potwierdzasz usunięcie starych planów i zapisanie nowych?
 ```
@@ -663,42 +675,96 @@ Czy potwierdzasz usunięcie starych planów i zapisanie nowych?
 Use `AskUserQuestion` tool with options:
 
 - "Tak, usuń stare plany i zapisz nowe" (Recommended)
-- "Nie, zachowaj stare plany (zapisz nowe obok)"
 - "Anuluj"
 
 **If user confirms deletion:**
 
-1. For each task in `oldPlanCommentIds`, delete the old plan comment using `mcp__linear-server__delete_comment`
-2. If `delete_comment` is not available, add a strikethrough header to the old comment body: `~~## Implementation Plan~~ (Zastąpiony nowym planem)` — use `mcp__linear-server__update_comment` as fallback
-3. Then proceed to save new plan comments
+1. For each task in `oldPlanAttachments`, delete the Linear attachment via `mcp__linear__delete_attachment({ id: attachmentId })`.
+2. Then proceed to Step 9a.
 
-**If user chooses to keep old plans:**
+**If user cancels:**
 
-- Skip deletion, save new plans as additional comments (old plans remain)
+- Stop the entire process, do not save any plans.
 
-**If user cancels:**
+### Step 9a: Save Plan as Linear Attachment
 
-- Stop the entire process, do not save any plans
+**⛔ DO NOT call `mcp__linear__save_comment` with plan content here. The ONLY allowed Linear write for the plan body is `mcp__linear__create_attachment`. Re-read Hard Rule #1 if tempted.**
 
-### Step 9a: Save New Plans as Comments
+For each task that needs planning, upload the plan content directly to Linear via `mcp__linear__create_attachment` — Linear hosts the file itself, no intermediate storage.
 
-Use the MCP Linear server to create comments:
+#### 9a.1 — Prepare plan content
 
-#### If NO subtasks:
+The plan content is exactly the markdown produced in Step 8 (the same block that would previously have been posted as a comment).
 
-- Create a single comment on the parent task with the implementation plan
+Write it to a temp file so it can be base64-encoded:
 
-#### If subtasks exist:
+```bash
+mkdir -p /tmp/claude-plans
+```
+
+Use the `Write` tool to save the plan markdown to `/tmp/claude-plans/<taskId>-plan.md`.
+
+#### 9a.2 — Base64-encode the content
+
+```bash
+b64=$(base64 -i /tmp/claude-plans/<taskId>-plan.md)
+```
+
+On macOS `base64 -i <file>` outputs without line-wrapping (which is what the Linear MCP expects). If you ever switch to GNU coreutils, pipe through `tr -d '\n'` to strip wraps.
+
+#### 9a.3 — Create the Linear attachment
+
+Call `mcp__linear__create_attachment` with:
+
+- `issue`: the task or subtask ID (e.g. `MOB-123`)
+- `filename`: `plan.md`
+- `contentType`: `text/markdown`
+- `title`: `plan.md` (exact — used for detection in Step 3 and by `/impl`)
+- `subtitle`: `Plan wygenerowany przez Claude Code`
+- `base64Content`: the base64 string from 9a.2
+
+Linear stores the file on its own infrastructure and surfaces it in the issue's Attachments pane.
+
+#### 9a.4 — Clean up local file
+
+Delete `/tmp/claude-plans/<taskId>-plan.md` after the attachment is created successfully. `/push` leaves Linear attachments in place — they stay on the issue as permanent artifacts.
+
+#### Scope rule
+
+- If the parent task has **no subtasks** → create one `plan.md` attachment on the parent task.
+- If the parent task **has subtasks** → create a `plan.md` attachment on **each subtask** that needs planning. Do NOT create a `plan.md` on the parent task.
+
+### Step 9b: Add "AI Plan" Label
+
+After all plan attachments are saved, apply the `AI Plan` label to the **invoked issue** — i.e. the exact `linearTaskId` passed to `/plan`:
+
+- `/plan MOB-123` (parent) → label goes on `MOB-123`. Subtasks receive `plan.md` attachments but no label.
+- `/plan MOB-123-1` (subtask) → label goes on `MOB-123-1` directly. Do NOT touch the parent.
+
+**`AI Plan` is a workspace-level (organization-wide) label that already exists in this Linear workspace** — it must NOT be created. Do not call `create_issue_label`.
+
+Steps:
+
+1. **Locate the label**:
+
+   - Use `mcp__linear__list_issue_labels` (no team filter, or workspace-wide scope) to find the label named exactly `AI Plan`.
+   - If for any reason the label cannot be located (rate limit, unexpected API response), surface the error and stop the labeling step — do NOT create a team-scoped duplicate.
+
+2. **Apply to the invoked issue**:
+
+   - Use `mcp__linear__save_issue({ id: invokedTaskId, labelIds: [...existingLabelIds, aiPlanLabelId] })`.
+   - Preserve existing labels — do NOT replace them. Fetch current labels first if needed and concatenate.
+   - If the label is already on the issue, skip the update.
 
-- Create a comment on **each subtask** with its specific implementation plan
-- Do NOT create a plan comment on the parent task (subtask plans are sufficient)
+3. **Failure handling**: if label lookup/apply fails, surface the error but do not roll back the plan attachment. The plan is the primary deliverable; the label is a marker.
 
 ### Step 10: Confirm to User
 
 After successfully saving the plans, confirm to the user:
 
-- List all tasks/subtasks where plans were saved
+- List all tasks/subtasks where `plan.md` was attached (include Linear attachment URL)
 - Show a summary of each plan
+- Confirm that `AI Plan` label was added to the parent task
 - Provide Linear task links
 - Mention any important considerations or questions
 
@@ -716,9 +782,10 @@ After successfully saving the plans, confirm to the user:
 10. **Keep subtask plans focused**: Each subtask plan should only cover that subtask's scope
 11. **Identify cross-subtask dependencies**: Note which subtasks depend on or block others
 12. **Identify external library changes**: Always check if task requires changes in `@smartsoft001` (repo: `../smartsoft001`) or `@smartsoft001-mobilems` (repo: `../mobilems-framework`). Mark these as separate process items, not part of current implementation
-13. **Skip tasks with existing plans**: Only create plans for tasks that don't have a plan yet, or where a newer comment requests plan changes. Don't regenerate plans unnecessarily.
-14. **Detect plan change requests**: Look for keywords in newer comments that indicate a plan change is needed (e.g., "zmień plan", "zaktualizuj plan", "popraw plan", "uwagi do planu")
-15. **Delete old plans when replacing**: When creating a replacement plan, always ask user to confirm deletion of the old plan comment. Delete old comment before saving new one to keep Linear comments clean. Record old plan comment IDs during Step 3a for use in Step 9
+13. **Skip tasks with up-to-date plans**: Only regenerate when the `plan.md` attachment is missing or stale (any comment newer than `plan.md`'s `updatedAt`). Don't regenerate plans unnecessarily.
+14. **Mtime rule is authoritative**: Regeneration is driven by comparing `plan.md` attachment `updatedAt` against comment `createdAt`. Keyword detection in comments is only a secondary hint that triggers an explicit user confirmation — never a silent regen.
+15. **Delete old plans cleanly**: When replacing, ask the user to confirm, then delete the old Linear attachment via `mcp__linear__delete_attachment`. Record attachment IDs during Step 3a for use in Step 9.
+16. **Always add "AI Plan" label**: After saving plan attachments, apply the workspace-level `AI Plan` label (already configured organization-wide — do NOT create a team-scoped duplicate) to the invoked issue.
 
 ## Example with Subtasks
 
@@ -728,7 +795,7 @@ For Linear task "ENG-456: User profile improvements" with subtasks:
 - ENG-456-2: Add profile bio field
 - ENG-456-3: Add social links section
 
-**Comment saved to ENG-456-1:**
+**Attachment `plan.md` saved on ENG-456-1:**
 
 ```markdown
 ## Implementation Plan for Subtask
@@ -804,7 +871,7 @@ Medium
 _Plan generated by Claude Code_
 ```
 
-**Comment saved to ENG-456-2:**
+**Attachment `plan.md` saved on ENG-456-2:**
 
 ```markdown
 ## Implementation Plan for Subtask
@@ -871,4 +938,4 @@ _Plan generated by Claude Code_
 
 ---
 
-**Important**: Before saving the plans, show them to the user for review and approval.
+**Important**: Before saving the plans as attachments, show them to the user for review and approval. The plan content is written to `/tmp/claude-plans/<taskId>-plan.md`, base64-encoded, and uploaded as a native Linear attachment via `mcp__linear__create_attachment`. After that, the `AI Plan` label is applied to the invoked issue.

package/plugins/flow/skills/push/SKILL.md

@@ -12,12 +12,12 @@ allowed-tools:
   - TaskUpdate
   - TaskList
   - TaskGet
-  - mcp__linear-server__get_issue
-  - mcp__linear-server__list_issues
-  - mcp__linear-server__list_comments
-  - mcp__linear-server__create_comment
-  - mcp__linear-server__update_issue
-  - mcp__linear-server__list_issue_statuses
+  - mcp__linear__get_issue
+  - mcp__linear__list_issues
+  - mcp__linear__list_comments
+  - mcp__linear__save_comment
+  - mcp__linear__save_issue
+  - mcp__linear__list_issue_statuses
 ---
 
 # Push Skill

package/plugins/flow/skills/review/SKILL.md

@@ -12,9 +12,9 @@ allowed-tools:
   - TaskList
   - TaskGet
   - AskUserQuestion
-  - mcp__linear-server__get_issue
-  - mcp__linear-server__list_comments
-  - mcp__linear-server__create_comment
+  - mcp__linear__get_issue
+  - mcp__linear__list_comments
+  - mcp__linear__save_comment
 ---
 
 # Review Skill

package/plugins/flow-external/.claude-plugin/README.md

@@ -68,7 +68,7 @@ node node_modules/@smartsoft001-mobilems/claude-plugins/plugins/flow-external/.c
 
 Configure these in your `.mcp.json`:
 
-- `linear-server` - Linear API integration
+- `linear` - Linear API integration (MCP prefix `mcp__linear__`)
 - `playwright` - Browser automation for screenshots
 
 ## Permission Strategy

package/plugins/flow-external/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "flow-external",
   "description": "Development flow skills for standalone Angular 6-11 museum projects without framework (Angular CLI, Karma/Jasmine, Bootstrap 4)",
-  "version": "2.80.0"
+  "version": "2.82.0"
 }

package/plugins/flow-external/.claude-plugin/settings.template.json

@@ -34,14 +34,17 @@
       "Bash(for:*)",
       "Bash(node:*)",
       "Bash(mkdir:*)",
-      "mcp__linear-server__get_issue",
-      "mcp__linear-server__list_issues",
-      "mcp__linear-server__list_comments",
-      "mcp__linear-server__create_comment",
-      "mcp__linear-server__delete_comment",
-      "mcp__linear-server__update_issue",
-      "mcp__linear-server__list_issue_statuses",
-      "mcp__linear-server__create_issue",
+      "mcp__linear__get_issue",
+      "mcp__linear__list_issues",
+      "mcp__linear__list_comments",
+      "mcp__linear__save_comment",
+      "mcp__linear__delete_comment",
+      "mcp__linear__save_issue",
+      "mcp__linear__list_issue_statuses",
+      "mcp__linear__create_attachment",
+      "mcp__linear__get_attachment",
+      "mcp__linear__delete_attachment",
+      "mcp__linear__list_issue_labels",
       "mcp__playwright__browser_snapshot",
       "mcp__playwright__browser_take_screenshot",
       "mcp__playwright__browser_navigate",

package/plugins/flow-external/agents/shared-linear-subtask-iterator.md

@@ -3,7 +3,7 @@ name: shared-linear-subtask-iterator
 description: Manage Linear task and subtask iteration. Fetch tasks, update statuses, and iterate through subtasks in order.
 tools: Bash
 model: sonnet
-color: "#5E6AD2"
+color: '#5E6AD2'
 ---
 
 You are a Linear subtask iterator that manages task and subtask workflows.
@@ -27,19 +27,19 @@ Fetch Linear tasks and their subtasks, manage status transitions, and iterate th
 
 ## Status Transitions
 
-| From | To | When |
-|------|----|------|
-| To Do | In Progress | Starting work on subtask |
-| In Progress | Done | Subtask implementation complete |
-| In Progress | Blocked | Cannot proceed |
-| Any | In Review | Ready for review |
+| From        | To          | When                            |
+| ----------- | ----------- | ------------------------------- |
+| To Do       | In Progress | Starting work on subtask        |
+| In Progress | Done        | Subtask implementation complete |
+| In Progress | Blocked     | Cannot proceed                  |
+| Any         | In Review   | Ready for review                |
 
 ## Fetching Subtasks
 
 Use Linear MCP tools:
 
-1. `mcp__linear-server__get_issue` - Get parent task details
-2. `mcp__linear-server__list_issues` - List subtasks (filter by parent)
+1. `mcp__linear__get_issue` - Get parent task details
+2. `mcp__linear__list_issues` - List subtasks (filter by parent)
 
 ## Iteration Flow
 

package/plugins/flow-external/skills/commit/SKILL.md

@@ -7,8 +7,8 @@ allowed-tools:
   - Glob
   - Grep
   - AskUserQuestion
-  - mcp__linear-server__get_issue
-  - mcp__linear-server__list_comments
+  - mcp__linear__get_issue
+  - mcp__linear__list_comments
 ---
 
 # Commit Skill
@@ -47,15 +47,15 @@ Refs: <linearTaskId>
 
 ### Type
 
-| Type | Use when |
-|------|----------|
-| `feat` | New feature or functionality |
-| `fix` | Bug fix |
+| Type       | Use when                                   |
+| ---------- | ------------------------------------------ |
+| `feat`     | New feature or functionality               |
+| `fix`      | Bug fix                                    |
 | `refactor` | Code restructuring without behavior change |
-| `style` | Styling/CSS changes only |
-| `docs` | Documentation changes |
-| `chore` | Maintenance, config, dependencies |
-| `perf` | Performance improvements |
+| `style`    | Styling/CSS changes only                   |
+| `docs`     | Documentation changes                      |
+| `chore`    | Maintenance, config, dependencies          |
+| `perf`     | Performance improvements                   |
 
 ### Scope
 
@@ -102,6 +102,7 @@ Run `git add` to stage your changes before committing.
 ### Linear Task Not Found
 
 If linearTaskId is not provided or task not found:
+
 - Try to detect from branch name
 - If still not found, proceed without Linear context