Update Cursor Team Kit workflows

.cursor-plugin/marketplace.json

@@ -21,7 +21,7 @@
     {
       "name": "cursor-team-kit",
       "source": "cursor-team-kit",
-      "description": "Internal team workflows used by Cursor developers for CI, code review, and shipping."
+      "description": "Internal team workflows used by Cursor developers for CI, code review, shipping, local automation, and verification."
     },
     {
       "name": "create-plugin",

README.md

@@ -7,7 +7,7 @@ Official Cursor plugins for popular developer tools, frameworks, and SaaS produc
 | `name` | Plugin | Author | Category | `description` (from marketplace) |
 |:-------|:-------|:-------|:---------|:-------------------------------------|
 | `continual-learning` | [Continual Learning](continual-learning/) | Cursor | Developer Tools | Incremental transcript-driven memory updates for AGENTS.md using high-signal bullet points only. |
-| `cursor-team-kit` | [Cursor Team Kit](cursor-team-kit/) | Cursor | Developer Tools | Internal team workflows used by Cursor developers for CI, code review, and shipping. |
+| `cursor-team-kit` | [Cursor Team Kit](cursor-team-kit/) | Cursor | Developer Tools | Internal team workflows used by Cursor developers for CI, code review, shipping, local automation, and verification. |
 | `create-plugin` | [Create Plugin](create-plugin/) | Cursor | Developer Tools | Scaffold and validate new Cursor plugins. |
 | `agent-compatibility` | [Agent Compatibility](agent-compatibility/) | Cursor | Developer Tools | CLI-backed repo compatibility scans plus Cursor agents that audit startup, validation, and docs against reality. |
 | `cli-for-agent` | [CLI for Agents](cli-for-agent/) | Cursor | Developer Tools | Patterns for designing CLIs that coding agents can run reliably: flags, help with examples, pipelines, errors, idempotency, dry-run. |

cursor-team-kit/.cursor-plugin/plugin.json

@@ -1,8 +1,8 @@
 {
   "name": "cursor-team-kit",
   "displayName": "Cursor Team Kit",
-  "version": "1.0.0",
-  "description": "Internal workflows used by Cursor developers for CI, code review, and shipping. Covers the full dev loop: CI monitoring and fixing, PR creation, merge conflicts, smoke tests, compiler checks, code cleanup, and work summaries.",
+  "version": "1.1.0",
+  "description": "Internal workflows used by Cursor developers for CI, code review, shipping, control-cli, control-ui, verify-this, test reliability, code cleanup, and work summaries. Designed to work without requiring third-party service integrations.",
   "author": {
     "name": "Cursor",
     "email": "plugins@cursor.com"
@@ -16,13 +16,17 @@
     "ci",
     "code-review",
     "shipping",
-    "testing"
+    "testing",
+    "verification",
+    "local-automation"
   ],
   "category": "developer-tools",
   "tags": [
     "internal-workflows",
     "quality",
-    "delivery"
+    "delivery",
+    "review",
+    "automation"
   ],
   "skills": "./skills/",
   "agents": "./agents/",

cursor-team-kit/README.md

@@ -1,6 +1,6 @@
 # Cursor Team Kit plugin
 
-Internal-style workflows for CI, code review, shipping, and test reliability.
+Internal-style workflows for CI, code review, shipping, and test reliability. The kit is designed to be plug and play without requiring third-party service integrations.
 
 ## Installation
 
@@ -17,6 +17,10 @@ Internal-style workflows for CI, code review, shipping, and test reliability.
 | `loop-on-ci` | Watch CI runs and iterate on failures until checks pass |
 | `review-and-ship` | Run a structured review, commit changes, and open a PR |
 | `pr-review-canvas` | Generate an interactive HTML PR walkthrough with annotated, categorized diffs |
+| `verify-this` | Prove or disprove claims with baseline/treatment artifacts and a clear verdict |
+| `control-cli` | Build or adapt a local harness to drive and profile interactive CLIs or TUIs |
+| `control-ui` | Build or adapt a local browser/CDP harness for web or Electron UIs |
+| `make-pr-easy-to-review` | Clean noisy PR history, improve descriptions, and add reviewer guidance |
 | `run-smoke-tests` | Run Playwright smoke tests and triage failures |
 | `fix-ci` | Find failing CI jobs, inspect logs, and apply focused fixes |
 | `new-branch-and-pr` | Create a fresh branch, complete work, and open a pull request |
@@ -26,6 +30,7 @@ Internal-style workflows for CI, code review, shipping, and test reliability.
 | `weekly-review` | Generate a weekly recap of shipped work with bugfix/tech-debt/net-new highlights |
 | `fix-merge-conflicts` | Resolve merge conflicts, validate build/tests, and summarize decisions |
 | `deslop` | Remove AI-generated code slop and clean up code style |
+| `workflow-from-chats` | Extract durable working preferences from chats into skills, rules, or docs |
 
 ### Agents
 

cursor-team-kit/agents/ci-watcher.md

@@ -1,13 +1,13 @@
 ---
 name: ci-watcher
-description: Watch GitHub CI for the current branch and report pass/fail with relevant failure logs. Use when waiting for CI results or CI has failed. Use proactively to monitor branch CI.
+description: Watch PR CI for the current branch and report pass/fail with relevant failure links. Use when waiting for CI results or CI has failed. Use proactively to monitor branch CI.
 model: fast
 is_background: true
 ---
 
 # CI watcher
 
-CI monitoring specialist for GitHub Actions.
+CI monitoring specialist for PR-attached checks.
 
 ## Trigger
 
@@ -16,12 +16,13 @@ Use when waiting for CI results, CI has failed, or when proactively monitoring b
 ## Workflow
 
 1. Determine current branch: `git branch --show-current`
-2. Find latest run for that branch: `gh run list --branch <branch> --limit 1`
-3. Watch to completion: `gh run watch <run-id> --exit-status`
-4. If failed, fetch failed logs: `gh run view <run-id> --log-failed`
+2. Resolve the PR: `gh pr view --json number,url,headRefName`
+3. Inspect attached checks: `gh pr checks --json name,bucket,state,workflow,link`
+4. If checks are pending, watch: `gh pr checks --watch --fail-fast`
+5. If a GitHub Actions check failed, fetch logs with `gh run view <run-id> --log-failed`; otherwise, return the check link and concise next step.
 
 ## Output
 
 - CI status (passed/failed)
-- Workflow/run metadata
-- If failed: concise failure excerpt and likely next step
+- PR and check metadata
+- If failed: concise failure excerpt or external check link and likely next step

cursor-team-kit/skills/control-cli/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: control-cli
+description: Build or adapt a local harness to drive, inspect, and profile an interactive CLI or TUI without external services. Use for CLI UX checks, startup regressions, memory leaks, hangs, prompt flows, or terminal demos.
+---
+
+# Control CLI
+
+Use a repeatable local harness to exercise an interactive CLI instead of poking at it manually. First reuse the repo's own test/demo harness if it exists; otherwise assemble a temporary harness from standard local tools.
+
+## What It Is Used For
+
+- Reproducing CLI/TUI bugs with deterministic input.
+- Verifying keyboard flows, prompts, interrupts, resize behavior, and terminal layout.
+- Capturing before/after transcripts for bug fixes.
+- Profiling startup time, slow operations, hangs, or memory growth.
+- Recording a short terminal demo when output is easier to show than explain.
+
+## Harness Loop
+
+1. Identify the command under test and the smallest reproducible workspace.
+2. Discover existing local harnesses: package scripts, e2e tests, demo recorders, expect scripts, or PTY helpers.
+3. If no harness exists, launch the CLI in an isolated terminal session with deterministic env vars.
+4. Capture the current screen before interacting.
+5. Send one action at a time: text, Enter, arrows, Escape, Ctrl-C, resize.
+6. Wait for a concrete screen pattern or prompt before the next action.
+7. Save the transcript and any profile artifacts.
+8. Kill the session cleanly.
+
+## Harness Options
+
+- Repo-native harness: prefer checked-in scripts because they know the app's startup, env, and prompts.
+- `tmux`: managed sessions, `capture-pane`, `send-keys`, attach/detach.
+- PTY probe: use a short Python, Node, or Expect script when tmux is unavailable.
+- Runtime inspector: use Node or Bun inspector for CPU profiles, heap snapshots, and live evaluation.
+- Terminal recorder: use repo-local demo tools or asciinema-compatible tools when the user asks for a demo.
+
+## Minimal tmux Harness
+
+```bash
+SESSION="cli-harness-$(date +%s)"
+tmux new-session -d -s "$SESSION" -- <command-under-test>
+tmux capture-pane -pt "$SESSION"
+tmux send-keys -t "$SESSION" "help" Enter
+tmux capture-pane -pt "$SESSION"
+tmux kill-session -t "$SESSION"
+```
+
+For Node CLIs:
+
+```bash
+NODE_OPTIONS="--inspect=127.0.0.1:0" tmux new-session -d -s "$SESSION" -- <node-cli-command>
+```
+
+Read the terminal output to find the inspector URL, then use Chrome DevTools-compatible tooling if profiling is needed.
+
+## Minimal PTY Harness
+
+Use a PTY script when you need deterministic waits in a repo that does not have tmux or a demo harness. Keep it temporary unless the user asks to add a reusable test.
+
+```python
+import os
+import pty
+import select
+import subprocess
+import time
+
+master_fd, slave_fd = pty.openpty()
+proc = subprocess.Popen(
+    ["<command>", "<arg>"],
+    stdin=slave_fd,
+    stdout=slave_fd,
+    stderr=slave_fd,
+    close_fds=True,
+)
+os.close(slave_fd)
+
+deadline = time.time() + 30
+buffer = b""
+while time.time() < deadline:
+    ready, _, _ = select.select([master_fd], [], [], 0.25)
+    if not ready:
+        continue
+    chunk = os.read(master_fd, 4096)
+    buffer += chunk
+    if b"<ready text>" in buffer:
+        os.write(master_fd, b"help\n")
+        break
+
+print(buffer.decode(errors="replace"))
+proc.terminate()
+os.close(master_fd)
+```
+
+If the CLI needs richer terminal control, use `pty.fork()` or an existing PTY library.
+
+## Profiling Recipes
+
+- Startup regression: capture baseline and treatment startup timings under the same machine, env, and command.
+- Slow operation: start a CPU profile, perform the operation, stop the profile, and compare top self-time functions.
+- Memory leak: force GC if available, take a heap snapshot, perform the operation repeatedly, force GC again, and take another snapshot.
+- Hang: capture the screen, active handles/resources, and a stack/CPU sample before interrupting.
+
+## Guardrails
+
+- Prefer deterministic waits over sleeps. If you must sleep, explain why.
+- Do not send credentials or destructive commands into a controlled session.
+- Keep the harness in `/tmp` unless the repo already has a testing/demo harness.
+- Do not hard-code paths from another repository. Adapt commands to the current repo's scripts and runtime.
+- Clean up tmux sessions, temp dirs, inspector processes, and demo artifacts unless the user asks to keep them.

cursor-team-kit/skills/control-ui/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: control-ui
+description: Build or adapt a local browser/CDP harness to drive and inspect a web, IDE, or Electron UI. Use for local UI verification, screenshots, accessibility snapshots, perf profiles, visual diffs, or reproducing UI bugs.
+---
+
+# Control UI
+
+Use local browser automation to verify UI behavior with evidence. First reuse the repo's own Playwright, browser, or Electron harness if it exists; otherwise assemble a temporary local harness around the app's dev server or Chromium debug port.
+
+## What It Is Used For
+
+- Reproducing UI bugs that depend on real browser focus, keyboard input, scrolling, resizing, or rendering.
+- Verifying visual or accessibility changes with screenshots and snapshots.
+- Checking local web, IDE, or Electron behavior before shipping.
+- Capturing console logs, network logs, CPU profiles, traces, or heap snapshots.
+- Creating before/after evidence for `verify-this`.
+
+## Setup Pattern
+
+1. Start the app locally using the repo's documented dev command.
+2. Discover existing local harnesses: Playwright tests, Cypress specs, Storybook, browser scripts, Electron launch scripts, or snapshot tools.
+3. For a web app, connect to the local URL with the existing browser tooling.
+4. For Electron/Chromium, enable a remote debugging port when supported.
+5. Select the correct page by stable app markers, not by tab order alone.
+6. Prefer accessibility roles, labels, and stable `data-*` selectors over coordinates.
+
+## Generic Web Harness
+
+Use the repo's installed browser tooling when possible. If the repo already has Playwright, a minimal one-off probe looks like:
+
+```javascript
+import { chromium } from "playwright";
+
+const browser = await chromium.launch();
+const page = await browser.newPage({ viewport: { width: 1280, height: 800 } });
+await page.goto("http://127.0.0.1:<port>");
+await page.getByRole("button", { name: /submit/i }).click();
+await page.screenshot({ path: "/tmp/ui-harness-after.png", fullPage: true });
+await browser.close();
+```
+
+Do not add Playwright as a project dependency just for this probe unless the user asks. Prefer existing dev dependencies or external browser tools already available in the environment.
+
+## Generic CDP Harness
+
+For Electron or a Chromium app launched with `--remote-debugging-port=<port>`, connect over CDP:
+
+```javascript
+import { chromium } from "playwright";
+
+const browser = await chromium.connectOverCDP("http://127.0.0.1:<debug-port>");
+const pages = browser.contexts().flatMap((context) => context.pages());
+let page;
+for (const candidate of pages) {
+  if (await candidate.locator("<app-root-selector>").count()) {
+    page = candidate;
+    break;
+  }
+}
+
+if (!page) {
+  console.log(await Promise.all(pages.map(async (p) => ({
+    title: await p.title(),
+    url: p.url(),
+  }))));
+  throw new Error("No matching app page found");
+}
+
+await page.screenshot({ path: "/tmp/ui-harness-cdp.png", fullPage: true });
+await browser.close();
+```
+
+Replace `<app-root-selector>` with a stable marker from the current repo, such as a root app node, landmark, or product-specific `data-*` attribute.
+
+## Interaction Loop
+
+1. Capture a page snapshot or screenshot before acting.
+2. Choose a target from the latest page structure.
+3. Perform exactly one structural action: click, type, keypress, drag, scroll, navigate, or resize.
+4. Capture a fresh snapshot/screenshot.
+5. Verify the expected state change.
+6. Save artifacts for before/after comparisons when the user asked for proof.
+
+## CDP Capabilities
+
+Use raw CDP only when higher-level browser APIs are insufficient:
+
+- Performance: CPU profiles, traces, paint flashing, FPS meter, layout shift inspection.
+- Memory: heap snapshots and forced GC for leak investigations.
+- Network: request blocking, throttling, cache disablement, request/response logs.
+- Rendering: viewport changes, color scheme emulation, reduced motion, accessibility checks.
+- Debugging: console streaming, exception capture, DOM snapshots.
+
+## Page Selection
+
+When multiple app windows/tabs share a debug port:
+
+- Prefer a positive marker for the surface under test, such as an app root selector.
+- Use a negative marker to avoid the wrong surface when necessary.
+- If no page matches, list available page titles and URLs instead of guessing.
+
+## Guardrails
+
+- Do not rely on stale element references after navigation or structural changes.
+- Avoid coordinate clicks unless a fresh screenshot was captured immediately before the click.
+- Keep test data local and disposable.
+- Do not store screenshots or heap snapshots from privacy-sensitive workspaces unless the user explicitly agrees.
+- Do not hard-code selectors, ports, or script paths from another repository. Discover the current repo's local app markers.
+- Clean up dev servers, debug sessions, and temp profiles when done.

cursor-team-kit/skills/fix-ci/SKILL.md

@@ -1,25 +1,26 @@
 ---
 name: fix-ci
-description: Find failing CI jobs, inspect logs, and apply focused fixes
+description: Find failing PR checks, inspect logs or external check links, and apply focused fixes
 ---
 
 # Fix CI
 
 ## Trigger
 
-Branch CI is failing and needs a fast, iterative path to green checks.
+Branch or PR CI is failing and needs a fast, iterative path to green checks.
 
 ## Workflow
 
-1. Identify the latest run for the current branch.
-2. Inspect failed jobs and extract the first actionable error.
+1. Resolve the active PR and inspect `gh pr checks --json name,bucket,state,workflow,link`.
+2. Inspect failed jobs and extract the first actionable error. Use GitHub Actions logs when available; otherwise use the check link to identify the failing command or service.
 3. Apply the smallest safe fix.
-4. Re-run CI and repeat until green.
+4. Push, re-check the PR check set, and repeat until green.
 
 ## Guardrails
 
 - Fix one actionable failure at a time.
 - Prefer minimal, low-risk changes before broader refactors.
+- Keep `gh pr checks` as the source of truth for overall PR CI state.
 
 ## Output
 

cursor-team-kit/skills/get-pr-comments/SKILL.md

@@ -20,4 +20,4 @@ Need a concise, actionable summary of feedback on the active pull request.
 
 - Grouped feedback summary
 - Action list ordered by priority
-- Open questions that still need clarification
+- Open questions that still need clarification