chore(skills): fix broken tool names, commands and paths across agent skills

.agent-marketplace.json

@@ -15,7 +15,7 @@
 			},
 			"category": "development",
 			"source": "./plugins/github",
-			"version": "1.0.3"
+			"version": "1.0.4"
 		},
 		{
 			"name": "linear",
@@ -25,7 +25,7 @@
 			},
 			"category": "productivity",
 			"source": "./plugins/linear",
-			"version": "1.5.5"
+			"version": "1.5.6"
 		},
 		{
 			"name": "notion",
@@ -35,7 +35,7 @@
 			},
 			"category": "productivity",
 			"source": "./plugins/notion",
-			"version": "1.0.5"
+			"version": "1.0.6"
 		},
 		{
 			"name": "slack",
@@ -55,7 +55,7 @@
 			},
 			"category": "development",
 			"source": "./plugins/sentry",
-			"version": "1.0.2"
+			"version": "1.0.3"
 		},
 		{
 			"name": "gmail",
@@ -75,7 +75,7 @@
 			},
 			"category": "productivity",
 			"source": "./plugins/granola",
-			"version": "1.0.2"
+			"version": "1.0.3"
 		},
 		{
 			"name": "circleback",
@@ -85,7 +85,7 @@
 			},
 			"category": "productivity",
 			"source": "./plugins/circleback",
-			"version": "1.0.2"
+			"version": "1.0.3"
 		},
 		{
 			"name": "ynab",
@@ -115,7 +115,7 @@
 			},
 			"category": "development",
 			"source": "./plugins/stripe",
-			"version": "1.0.2"
+			"version": "1.0.3"
 		},
 		{
 			"name": "superhuman",
@@ -125,7 +125,7 @@
 			},
 			"category": "communication",
 			"source": "./plugins/superhuman",
-			"version": "1.0.2"
+			"version": "1.0.3"
 		},
 		{
 			"name": "neon",
@@ -195,7 +195,7 @@
 			},
 			"category": "data & apis",
 			"source": "./plugins/peec",
-			"version": "1.0.0"
+			"version": "1.0.1"
 		},
 		{
 			"name": "sazabi",

.agents/commands/ci-check.md

@@ -15,7 +15,7 @@ Run the two fixers first, since they rewrite files the other checks read:
 Then run these three **in parallel** and report all results:
 
 3. `bun run typecheck` — TypeScript type checking across all packages
-4. `bun test` — Run all tests
+4. `bun run test` — Every package's suite through turbo, as CI runs it
 5. `bun run check:i18n` — Regenerates the translation catalogs and fails on missing or stale translations
 
 ## Output

.agents/commands/create-plan.md

@@ -1,12 +1,14 @@
+---
+description: Write a self-contained ExecPlan in the right plans/ directory
+---
+
 # Paradev Execution Plans (ExecPlans)
 
 > **DO NOT EDIT THIS FILE**
 > This file is the ExecPlan template and guide only.
 > Create plans in the appropriate location:
 > - **Desktop app work**: `apps/desktop/plans/<timestamp>-<plan-name>.md`
-> - **Web app work**: `apps/web/plans/<timestamp>-<plan-name>.md`
 > - **Marketing site work**: `apps/marketing/plans/<timestamp>-<plan-name>.md`
-> - **API work**: `apps/api/plans/<timestamp>-<plan-name>.md`
 > - **Shared packages/cross-app work**: `plans/<timestamp>-<plan-name>.md` (root)
 
 This document describes the requirements for an execution plan ("ExecPlan"), a design document that a coding agent can follow to deliver a working feature or system change. Treat the reader as a complete beginner to this repository: they have only the current working tree and the single ExecPlan file you provide. There is no memory of prior plans and no external context.
@@ -23,25 +25,23 @@ Steps:
 7. Closeout: write Outcomes & Retrospective; ensure the plan remains self-contained and accurate.
 8. Write your plan to the appropriate location:
    - Desktop app: `apps/desktop/plans/<timestamp>-<plan-name>.md`
-   - Web app: `apps/web/plans/<timestamp>-<plan-name>.md`
    - Marketing: `apps/marketing/plans/<timestamp>-<plan-name>.md`
-   - API: `apps/api/plans/<timestamp>-<plan-name>.md`
    - Cross-app/shared: `plans/<timestamp>-<plan-name>.md`
    Use `<timestamp>` in `YYYYMMDD-HHmm` format (e.g., `20260103-1045-my-feature-plan.md`). This ensures plans are sorted from most recent to oldest.
 9. Plan Lifecycle: When the plan is complete and a PR is created, move it to the `done/` folder within the same directory. If abandoned, move it to `abandoned/`.
 
 Example questions:
-    I reviewed apps/desktop/src/main/lib/workspace-manager.ts to understand workspace patterns.
+    I reviewed apps/desktop/src/lib/trpc/routers/workspaces/ to understand workspace patterns.
 
     Where should this new feature live?
     a) apps/desktop/src/main/lib/ (main process)
-    b) apps/desktop/src/renderer/src/ (renderer process)
+    b) apps/desktop/src/renderer/ (renderer process)
     c) packages/shared/ (shared across apps)
     d) Other (specify)
 
     How should we handle errors?
     a) Return TRPCError at boundary
-    b) Use type-safe IPC error channel
+    b) Use type-safe tRPC error handling
     c) Other (specify)
 
 ## How to use ExecPlans
@@ -85,7 +85,7 @@ The agent executing your plan can list files, read files, search, run the projec
 - **Code Quality**: Biome at root level
 - **Database**: Drizzle ORM + Neon PostgreSQL
 - **UI**: React + TailwindCSS v4 + shadcn/ui (in `packages/ui`)
-- **Desktop**: Electron with type-safe IPC
+- **Desktop**: Electron with type-safe IPC over tRPC
 
 ### Common Commands
     # Development
@@ -106,8 +106,7 @@ The agent executing your plan can list files, read files, search, run the projec
 For Electron/desktop work, remember:
 - **Main process** (`src/main/`): Can use Node.js modules
 - **Renderer process** (`src/renderer/`): Browser environment only, NO Node.js imports
-- **IPC**: Always type-safe via `src/shared/ipc-channels.ts`
-- Run `bun run lint:check-node-imports` to detect Node.js import violations
+- **IPC**: tRPC routers in `src/lib/trpc/routers/`; subscriptions return `observable`
 
 ### Code Patterns
 - Functions with 2+ params use object signatures: `({ param1, param2 }: { ... }) => {}`
@@ -162,19 +161,18 @@ For each milestone, include:
 
 **Example milestone structure:**
 
-    ### Milestone 1: IPC Channel Foundation
+    ### Milestone 1: tRPC Procedure Foundation
 
-    This milestone establishes the type-safe IPC channel for workspace operations.
+    This milestone establishes the tRPC procedure for workspace operations.
     At completion, the main process can receive workspace requests and return
     typed responses, though no UI integration exists yet.
 
     Scope:
-    - Define IpcChannels types in src/shared/ipc-channels.ts
-    - Implement handler in src/main/lib/workspace-ipcs.ts
-    - Add unit tests for the handler
+    - Add the procedure to src/lib/trpc/routers/workspaces/
+    - Add unit tests for it
 
     Acceptance:
-        bun test apps/desktop/src/main/lib/workspace-ipcs.test.ts
+        bun test apps/desktop/src/lib/trpc/routers/workspaces/
         # Expected: All tests pass
 
     Verify before proceeding: Types compile, tests pass, handler logs correctly.
@@ -289,7 +287,7 @@ Document parallel implementation strategies in the Plan of Work and include clea
     For this Paradev monorepo, always mention:
     - Which app(s) are affected (desktop, web, marketing, api, admin, docs)
     - Which packages are involved (db, ui, shared, trpc, queries, local-db)
-    - Any IPC channels if desktop work is involved
+    - Any tRPC procedures if desktop work is involved
 
     ## Plan of Work
 
@@ -332,14 +330,14 @@ Document parallel implementation strategies in the Plan of Work and include clea
 
     Be prescriptive. Name the libraries, modules, and services to use and why. Specify the types and function signatures that must exist at the end of the milestone.
 
-    For IPC channels (desktop), define in apps/desktop/src/shared/ipc-channels.ts:
+    For a desktop procedure, add it to a router in apps/desktop/src/lib/trpc/routers/:
 
-        export interface IpcChannels {
-          "my-new-channel": {
-            request: { param1: string };
-            response: { success: boolean; data: MyData };
-          };
-        }
+        export const createMyRouter = () =>
+          router({
+            doThing: publicProcedure
+              .input(z.object({ param1: z.string() }))
+              .mutation(async ({ input }): Promise<MyData> => { ... }),
+          });
 
 If you follow the guidance above, a single, stateless agent -- or a human novice -- can read your ExecPlan from top to bottom and produce a working, observable result. That is the bar: SELF-CONTAINED, SELF-SUFFICIENT, NOVICE-GUIDING, OUTCOME-FOCUSED.
 
@@ -356,7 +354,7 @@ ExecPlans have a defined lifecycle that keeps the plans folders clean and provid
     ├── done/
     └── abandoned/
 
-    apps/web/plans/            # Web app plans
+    apps/marketing/plans/      # Marketing site plans
     ├── <active-plans>.md
     ├── done/
     └── abandoned/

.agents/commands/create-pr.md

@@ -1,3 +1,7 @@
+---
+description: Review the diff against AGENTS.md, then create a PR with gh and a body scaled to the change
+---
+
 # Persona & Goal
 
 You are an expert Paradev engineer and technical writer creating high-signal PR descriptions for this repository.
@@ -187,7 +191,6 @@ Use **High-risk/Complex** when any of these are true:
     - `bun run typecheck` (required)
     - `bun run lint` (required)
     - `bun test <suite-or-file>` (when touching logic)
-    - `bun run lint:check-node-imports` (when touching Desktop renderer/shared)
     - `bun turbo run build --filter=@superset/desktop` (when touching Desktop)
 
     ## Design Decisions (optional)
@@ -282,7 +285,6 @@ For PRs bundling multiple features, use Part headers to organize (like PR #559):
     - `bun run typecheck` (required)
     - `bun run lint` (required)
     - `bun test` (required)
-    - `bun run lint:check-node-imports` (when touching Desktop renderer/shared)
     - `bun turbo run build --filter=@superset/desktop` (when touching Desktop)
 
     ## Design Decisions
@@ -326,7 +328,7 @@ Use these as templates for the Manual QA Checklist section. Pick categories appr
 - [ ] App launches without errors
 - [ ] No console errors in DevTools (main + renderer)
 - [ ] Feature works after app restart
-- [ ] Ran `bun run lint:check-node-imports` (no Node.js in renderer)
+- [ ] No Node.js imports in `apps/desktop/src/renderer/`
 
 ### tRPC over Electron IPC
 - [ ] tRPC router changes validated from renderer call-sites
@@ -523,7 +525,6 @@ Use these as templates for the Manual QA Checklist section. Pick categories appr
     ## Testing
     - `bun run typecheck`
     - `bun run lint`
-    - `bun run lint:check-node-imports`
     - Manual testing in dev mode
 
     ## Design Decisions

.agents/commands/deslop.md

@@ -15,15 +15,7 @@ Apply clean code philosophy to the code, with special emphasis on comments:
 - Are commented-out code blocks (delete them - version control exists)
 - Are TODO/FIXME that will never be addressed
 
-**Keep or add comments only when:**
-- Explaining *why* a non-obvious decision was made
-- Documenting design intent or architectural decisions (e.g., "shared by X and Y paths", "deferred because Z")
-- Documenting external constraints or business rules not evident from code
-- Warning about non-intuitive behavior or edge cases
-- Noting the origin of a pattern when it aids future maintenance (e.g., "VS Code pattern")
-- Required for public API documentation (JSDoc, docstrings)
-
-**When in doubt, keep the comment.** Removing a comment that captured intent is destructive — the reasoning is lost and cannot be recovered from code alone. Only remove a comment when you are confident the code *fully* communicates the same information.
+**Keep or add a comment only when** it states an external constraint or a trap the code cannot express (AGENTS.md "Comments"): first try to name, structure, or type it. Rationale goes in the commit message and the PR, not the code.
 
 ## Code Simplification
 

.agents/commands/draft.md

@@ -82,16 +82,16 @@ On **Discard**, confirm in one short sentence that nothing was created, and stop
 
 After — and only after — the user picks **Accept**:
 
-1. Resolve the team. Call `mcp__linear-server__list_teams`. If exactly one team is returned, use it. If multiple teams exist, call `ask_user` with the team names as options and use the chosen team's id.
-2. Call `mcp__linear-server__save_issue` with:
+1. Resolve the team. Call the Linear MCP `list_teams` tool (whatever the server is named here). If exactly one team is returned, use it. If multiple teams exist, call `ask_user` with the team names as options and use the chosen team's id.
+2. Call the Linear MCP `save_issue` tool with:
    - `team`: the resolved team id
    - `title`: the accepted title (without the `**Title:**` prefix)
    - `description`: the accepted markdown description body (the contents of the fenced block, not the fence itself; use real newlines, not literal `\n`)
 3. After it succeeds, report the new issue's identifier (e.g. `ENG-123`) and URL in one line. Do not set assignee, labels, status, project, or cycle unless the user asked for it during the review loop.
 
 ## Rules
 
-- **No silent writes.** Never call `mcp__linear-server__save_issue` or any other Linear write tool until the user has explicitly chosen **Accept** in step 5.
+- **No silent writes.** Never call Linear's `save_issue` or any other Linear write tool until the user has explicitly chosen **Accept** in step 5.
 - **No extra mutations.** Don't assign, label, set status, add to a project, or otherwise mutate Linear state beyond creating the issue with the accepted title and description.
 - Read-only Linear lookups (`list_teams`, optionally `list_issues` for duplicate check) are fine, but skip them unless directly useful.
 - Don't guess at file paths — verify with Glob/Grep/Read before citing them in the draft.