[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NN9PJS9NHWPDG4QP93BP8F":3,"skill-same:01M6NN9PJS9NHWPDG4QP93BP8F":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":13,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M6NN9PJS9NHWPDG4QP93BP8F","webmcpify",null,"Make a web app agent-ready — propose a WebMCP tool manifest, integrate, verify in a real browser, heal; unrelated code stays untouched. Use for \"webmcpify\", \"add WebMCP\", or \"expose app actions to AI agents\".","JiayiV\u002Fquestion_mixing","JiayiV","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F54466889?v=4","01M6JFJYYMRZ3QRGP9339JNQ2K","01M6JFJZ35KB0QVT50NAHPJA7G",0,"MIT","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fwebmcpify\u002FSKILL.md",[],[5,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"inventory","webmcp","for","scope","app","unrelated","ready","use","tool","verify","github","manifest","actions","https","browser","code","notes","web","ai agents","2026-11-10 10:12:30",false,"---\nname: webmcpify\ndescription: 'Make a web app agent-ready — propose a WebMCP tool manifest, integrate, verify in a real browser, heal; unrelated code stays untouched. Use for \"webmcpify\", \"add WebMCP\", or \"expose app actions to AI agents\".'\nargument-hint: \"[inventory|integrate|verify|status|full] [scope notes]\"\nlicense: MIT\nmetadata:\n  source: https:\u002F\u002Fgithub.com\u002FTueJon\u002Fwebmcpify\n---\n\n# webmcpify — make any web app agent-ready, verifiably\n\nYou are running the webmcpify pipeline. It takes an existing web application and\nexposes its user-facing functionality as [WebMCP](https:\u002F\u002Fwebmachinelearning.github.io\u002Fwebmcp\u002F)\ntools (`document.modelContext` — a proposed web standard incubated in the W3C Web\nMachine Learning Community Group, currently a Chrome origin trial), so browser AI\nagents can operate the app through structured tool calls instead of guessing at the DOM.\n\n```\nDETECT ──▶ INVENTORY ──▶ [HUMAN GATE: manifest approval] ──▶ INTEGRATE ──▶ VERIFY ──▶ HEAL ──▶ AUDIT\n              ▲  loop            per-area batches on big apps    ▲  loop      ▲ loop    ▲ loop\n              └── per area                                       └── per manifest entry ──┘\n```\n\nEverything you need ships inside this skill directory: phase guides in\n`references\u002F`, and vendorable code in `templates\u002F` (runtime, ambient types,\nJS variant, React JSX typings, verification spec). Never assume files exist\noutside the skill dir.\n\n**Out of scope** (stop and say so): backend-only MCP servers (that's classic MCP,\nnot WebMCP), automating third-party sites you don't control, and generic SEO work.\n\n## Invocation modes\n\nThe user may pass an argument (`\u002Fwebmcpify \u003Cmode>` or plain words):\n\n| Argument | Run | Stop at |\n|---|---|---|\n| *(none)* or `full` | all phases, resuming from current manifest state | done |\n| `inventory` \u002F `map` | DETECT + INVENTORY loops only — **zero code changes** | present the manifest table for review |\n| `integrate` | INTEGRATE loop only (requires approved tools in the manifest) | integrated + built |\n| `verify` | VERIFY + HEAL loops on integrated\u002Fverified tools | green\u002Fskipped report |\n| `status` | read `.webmcpify\u002Fmanifest.json` — **read-only** | report phase, per-status tool counts, and the recommended next command |\n\nAny other text is scoping guidance (e.g. \"only the checkout area\", \"read-only tools only\").\n\n## Ground rules (non-negotiable, enforce in every phase)\n\n1. **Zero unrelated changes.** Every diff hunk you produce must trace to a manifest\n   entry or the recorded one-time setup. Never refactor, reformat, rename, or\n   \"improve\" anything else — note problems in the report instead. Files that were\n   already dirty at baseline (recorded in the manifest) are **untouchable**: never\n   modify or revert them.\n2. **Read-only tools first.** Mutations are tri-state: `mutating: false`,\n   `\"client\"` (browser-local only: prefs, localStorage), or `\"server\"` (data\n   leaves the browser). Server-mutating tools require explicit **per-tool** human\n   approval recorded in the manifest; client-mutating tools may be approved as a\n   batch at the gate. Never expose destructive, irreversible, or payment actions\n   in a first integration.\n3. **The server is the only trust boundary.** A tool's `execute()` may only call code\n   paths the UI already uses (same endpoints, same validation, same auth). Never\n   create new endpoints, never bypass existing checks, never put secrets in tools.\n4. **Spec-shaped and dependency-free.** Register via `document.modelContext.registerTool()`\n   with AbortSignal lifecycle (feature-detect the deprecated `navigator.modelContext`\n   fallback). No third-party WebMCP runtime dependencies. Everything feature-detected:\n   the app behaves identically in browsers without WebMCP.\n5. **Never `toolautosubmit` on state-changing forms** — neither `mutating: \"client\"`\n   nor `\"server\"`. Only on pure read forms (search, filter, availability).\n6. **State lives in files, not in your context.** Read\u002Fwrite `.webmcpify\u002F` constantly;\n   assume your context can be wiped between any two steps. Write the manifest\n   atomically (write `manifest.json.tmp`, then rename over `manifest.json`).\n7. **Commits are opt-in.** Never commit unless the human chose a commit policy at\n   the gate (see below). Without git or without permission, leave changes in the\n   working tree and record progress in the manifest only.\n\n## Fresh, authoritative guidance\n\nWebMCP is an evolving origin-trial API — the surface has already changed during the\ntrial (testing API removed 2026-07; `navigator` → `document`). Before Phase 2, if\nnetwork is available, pull Google's current official guides rather than relying on\nmemory:\n\n```sh\nnpx -y modern-web-guidance@latest retrieve \"webmcp,agentic-forms,agentic-javascript-tools\"\n```\n\nIf offline, use `references\u002Fintegrate.md` — but prefer the live guides when they conflict.\n\n## The state protocol — `.webmcpify\u002F` in the target repo\n\n| File | Purpose |\n|---|---|\n| `manifest.json` | Single source of truth (schema below; atomic writes) |\n| `areas\u002F\u003Cid>.tools.json` | Sub-agent shard output during inventory fan-out (merged, then deleted) |\n| `report.md` | Human-facing running report; finalized at the end |\n\n**Resume rule:** if `manifest.json` exists, resume — recompute nothing already\nrecorded. **Merge leftover shards FIRST**: any existing `areas\u002F\u003Cid>.tools.json`\nfiles are merged into the manifest (mark those areas `inventoried`, delete the\nshards) before redispatching any sub-agents. Then continue at `pipeline.phase`,\nthe first `pending` area, or the first tool whose status is not terminal.\nTerminal statuses: `verified`, `skipped`, `rejected`.\n\n**Phase transitions** (make the atomic manifest write the moment the condition holds):\n\n- `detect → inventory`: `app` recorded, `baselineSha`\u002F`baselineDirty` captured.\n- `inventory → gate`: no area `pending`, completeness pass has run.\n- `gate → integrate`: every `discovered` tool is `approved`\u002F`rejected`, and\n  `commitPolicy` + `commitWebmcpifyDir` are set.\n- `integrate → verify`: no `approved` tools remain (each `integrated` or terminal),\n  build green.\n- `verify → heal`: verify loop visited every `integrated` tool and ≥1 is `failed`\n  (none failed → straight to `audit`).\n- `heal → audit`: no tool `failed` and post-heal full re-verify passed.\n- `audit → done`: every hunk mapped-or-flagged, `report.md` finalized.\n\nManifest schema (Webmcpify Manifest v3):\n\n```jsonc\n{\n  \"webmcpify\": 3,\n  \"app\": { \"stack\": \"react-vite\", \"typescript\": true, \"entry\": \"src\u002Fmain.tsx\",\n           \"baseUrl\": \"http:\u002F\u002Flocalhost:5173\", \"startCommand\": \"npm run dev\",\n           \"authFixtures\": {                    \u002F\u002F how verify OBTAINS each session\n             \"member\": { \"obtain\": \"npm run seed:test-user, then sign in at \u002Flogin\",\n                         \"account\": \"member@example.test\",\n                         \"env\": [\"TEST_MEMBER_PASSWORD\"] }  \u002F\u002F env var NAMES only — never secret values\n           } },\n  \"pipeline\": {\n    \"phase\": \"inventory\",          \u002F\u002F detect|inventory|gate|integrate|verify|heal|audit|done — transition rules above\n    \"setup\": {                     \u002F\u002F PATHS created\u002Fmodified per one-time setup step ([] = not done yet)\n      \"runtimeVendored\": [\"src\u002Fwebmcp\u002Fwebmcpify.ts\", \"src\u002Fwebmcp\u002Fwebmcp.d.ts\"],\n      \"harnessInstalled\": [\".webmcpify\u002Fwebmcp.spec.ts\"],\n      \"originTrialNoted\": [\"README.md\"]\n    },\n    \"baselineSha\": \"abc1234\",      \u002F\u002F HEAD at pipeline start; null if no git\n    \"baselineDirty\": [\"src\u002Fwip.ts\"], \u002F\u002F paths dirty at start — untouchable (ground rule 1)\n    \"commitPolicy\": null,          \u002F\u002F set at the gate: \"commit-per-batch\" | \"no-commit\"\n    \"commitWebmcpifyDir\": null,    \u002F\u002F set at the gate: commit .webmcpify\u002F itself? true | false\n    \"blockers\": []                 \u002F\u002F e.g. \"app won't start locally: needs $API_KEY\" — surfaced at the gate\n  },\n  \"areas\": [\n    { \"id\": \"checkout\", \"paths\": [\"src\u002Ffeatures\u002Fcheckout\u002F\"], \"status\": \"pending\" } \u002F\u002F pending|inventoried\n  ],\n  \"tools\": [\n    {\n      \"id\": \"create_ticket\",\n      \"area\": \"tickets\",\n      \"kind\": \"imperative\",        \u002F\u002F imperative | declarative\n      \"mutating\": \"server\",        \u002F\u002F false | \"client\" (browser-local only: prefs, localStorage) | \"server\" (data leaves the browser)\n      \"priority\": 1,               \u002F\u002F 1 = expose first; 2\u002F3 = later waves\n      \"description\": \"Creates a new ticket in the currently open project.\",\n      \"inputSchema\": { \u002F* JSON Schema *\u002F },\n      \"annotations\": { \"readOnlyHint\": false, \"untrustedContentHint\": false }, \u002F\u002F verify asserts these on the enumerated tool\n      \"source\": [\"src\u002Ffeatures\u002Ftickets\u002FNewTicket.tsx:42\"], \u002F\u002F the UI code path it wraps\n      \"route\": \"\u002Fprojects\u002Fdemo\u002Ftickets\",                    \u002F\u002F where verify navigates\n      \"auth\": [\"role:member\"],     \u002F\u002F \"none\" | \"session\" | [\"role:\u003Cname>\", ...] — keys into app.authFixtures; verify runs once per listed role\n      \"examples\": { \"valid\": { \"title\": \"Test ticket\" }, \"invalid\": {} },\n                                   \u002F\u002F invalid: null ONLY for readOnlyHint tools with no\u002Fempty params —\n                                   \u002F\u002F verify then asserts dual-outcome: rejects OR resolves with no side effect\n      \"expect\": { \"result\": \"created\", \"navigation\": null, \"ui\": \"new row appears in the ticket list\" },\n                                   \u002F\u002F exactly one of result|navigation: result = substring of the resolved string;\n                                   \u002F\u002F navigation = destination URL\u002Fpattern when executeTool resolves null (it navigated)\n      \"cleanup\": \"delete the created ticket via the UI's own delete path (test data only)\", \u002F\u002F required for mutating:\"server\", recommended for \"client\"\n      \"status\": \"discovered\",      \u002F\u002F discovered|approved|rejected*|integrated|verified*|failed|skipped*  (* = terminal)\n      \"approval\": null,            \u002F\u002F server-mutating tools, once approved: { \"note\": \"...\", \"at\": \"2026-07-12\",\n                                   \u002F\u002F   \"productionSideEffect\": null } — set only when verification unavoidably\n                                   \u002F\u002F   causes a real production effect (see VERIFY: production side-effect policy)\n      \"attempts\": 0,               \u002F\u002F heal-fix cycles; the triggering verify failure is attempt 0\n      \"batchCommit\": null,         \u002F\u002F sha under commit-per-batch — lands in the manifest one commit LATER\n      \"notes\": \"\"\n    }\n  ],\n  \"log\": [ \"2026-07-12 inventory: area checkout done, 4 candidates\" ]\n}\n```\n\n**v2→v3 migration:** resuming a `\"webmcpify\": 2` manifest migrates in place on\nfirst write — `auth` string → array; `setup` booleans → path arrays (`false` →\n`[]`; `true` → recover paths from git\u002F`log`, else `null` = done-but-unrecorded,\naudit treats those files flag-only); `mutating: true` → `\"server\"`; add\n`annotations` (defaults from the inventory table), `blockers: []`,\n`commitWebmcpifyDir: null`, `expect.navigation: null`; then bump to 3.\n\n## Phase 0 — DETECT\n\nIdentify stack, build + dev-server commands, TypeScript or not, auth model\n(including how verify obtains each test session → `app.authFixtures`), test\nsetup, and how the app starts locally; record under `app`. Record the git baseline:\n`pipeline.baselineSha` = current HEAD and `pipeline.baselineDirty` = `git status\n--porcelain` paths (both `null`\u002F`[]` without git). If the app cannot be started\nlocally, append the blocker to `pipeline.blockers` — integration may proceed, but\nverification will be blocked and this must be surfaced at the gate. Details:\n`references\u002Finventory.md`.\n\n## Phase 1 — INVENTORY (loop; scales to any size)\n\n**Never map a large codebase in one pass.**\n\n1. **Area map first (cheap, structural):** enumerate routes\u002Fviews\u002Ffeature modules\n   from the router config, pages directory, or navigation — without reading\n   implementation files. Write every area to `areas` with `\"pending\"`.\n2. **Inventory loop — one area per iteration:** deep-read only that area's files;\n   draft a candidate tool per user action (conventions, tool-count budget, and\n   overlap rules: `references\u002Finventory.md`) with ALL manifest fields filled,\n   including `route`, `auth`, `annotations`, `examples`, `expect`, and `cleanup`\n   (required for `mutating: \"server\"`, recommended for `\"client\"`) — the verify\n   phase runs from these fields alone. Append as `\"discovered\"`, mark the area\n   `\"inventoried\"`, write the manifest, repeat.\n   - **Sub-agent fan-out:** sub-agents never write `manifest.json`. Each writes only\n     its own `areas\u002F\u003Cid>.tools.json` shard — schema\n     `{ \"webmcpifyShard\": 3, \"area\": \"\u003Cid>\", \"tools\": [ \u002F* full v3 tool entries *\u002F ] }`,\n     written atomically (tmp + rename). You (the coordinator) merge shards into\n     the manifest sequentially, then delete them; on resume, merge existing\n     shards FIRST before redispatching (Resume rule).\n3. **Exit:** no `pending` areas remain, plus one completeness pass — walk the app's\n   navigation and ask \"is any visible user action missing?\"\n\n## GATE — manifest approval (the one main checkpoint)\n\nPresent the manifest compactly (id, area, kind, mutating, priority, one-line\ndescription) — per-area batches on large apps. Ask the human to decide, in one\nexchange where possible:\n\n1. Which tools are `approved` vs `rejected` (**`rejected` is terminal** — rejected\n   tools are excluded from every later phase and from exit conditions).\n   `mutating: \"server\"` tools need individual acknowledgment → record in\n   `approval`; `mutating: \"client\"` tools may be approved as a batch.\n2. **Commit policy**: `commit-per-batch` (each integration batch committed,\n   revertable — recommended on a clean baseline) or `no-commit` (leave changes\n   uncommitted for the human to review\u002Fcommit) → `pipeline.commitPolicy`. Also\n   whether `.webmcpify\u002F` itself should be committed (recommended: yes — it\n   documents the integration) → `pipeline.commitWebmcpifyDir`.\n3. Every entry in `pipeline.blockers` (e.g. app won't start). If verifying a tool\n   will unavoidably cause a real production side effect (e.g. a mailer with an\n   Origin-allow-listed endpoint), get that approved HERE and record it in the\n   tool's `approval.productionSideEffect` — see VERIFY.\n\nApply `references\u002Fsecurity.md` to every mutating tool **before** presenting.\n\n## Phase 2 — INTEGRATE (loop)\n\nOne-time setup first — record the created\u002Fmodified file **paths** in\n`pipeline.setup` (e.g. `runtimeVendored: [\"src\u002Fwebmcp\u002Fwebmcpify.ts\", ...]`):\nvendor the runtime from this skill's `templates\u002F` (`webmcpify.ts`, or\n`webmcpify.js` for non-TS projects, plus `webmcp.d.ts` for TS and\n`webmcp-jsx.d.ts` for React TSX — keep the full MIT header; see\n`references\u002Fruntime.md`) and note the origin-trial\u002Fflag requirement in the target\nREADME (`originTrialNoted`). Then loop:\n\n1. Pick the next batch of `approved` tools — one area or ≤5 tools.\n2. Implement per `references\u002Fintegrate.md`: declarative attributes for standard\n   HTML forms (including framework-rendered and fetch-intercepted ones);\n   imperative registration via the vendored runtime for non-form or\n   controlled-state actions.\n3. Build + typecheck; fix only what the batch broke.\n4. Mark tools `\"integrated\"`, write the manifest. Under `commit-per-batch`:\n   require a **clean index** before staging (unrelated staged changes → stop and\n   surface); stage **only the batch's files by path** — never `git add -A`, `-u`,\n   `.`, or `commit -a`; commit `feat(webmcp): expose \u003Cids> (webmcpify)`. The\n   commit sha lands in `batchCommit` on the **next** manifest write — one commit\n   later (the manifest can't contain its own commit's sha). Never amend a\n   previous batch commit.\n5. Repeat until no `approved` tools remain.\n\n## Phase 3 — VERIFY (loop)\n\nSet up once from `templates\u002Fwebmcp.spec.ts` per `references\u002Fverify.md` (real headed\nChrome; production `getTools()`\u002F`executeTool()` surface with legacy fallback probe).\nThen loop over every `integrated` tool, using its manifest `route`, `auth`,\n`examples`, `expect`, and `annotations` fields:\n\n- assert the tool is registered with the expected schema (enumerated `inputSchema`\n  is a *stringified* JSON Schema — parse before comparing) **and** the manifest\n  `annotations`;\n- execute the valid example (mutating tools: dev\u002Ftest data only, then run\n  `cleanup`) and one invalid example (`invalid: null` zero-param read tools:\n  dual-outcome assertion — see `references\u002Fverify.md`);\n- assert on the returned result **and** the resulting UI state per `expect`\n  (a UI **delta**, or `expect.navigation` when execution resolves `null`).\n\nPass → `\"verified\"`. Fail → `\"failed\"` + failure note. Role-scoped tools: run the\nloop once per role listed in `auth`, signing in via the matching\n`app.authFixtures` entry.\n\n**Production side-effect policy** — when a tool's verification unavoidably causes\na real production effect (e.g. an email actually sent), ALL THREE are required:\n(1) the human approved it at the gate, recorded in `approval.productionSideEffect`;\n(2) every test payload is marked `[webmcpify verification]`; (3) the effect is\nlisted in `report.md`. Without the recorded approval, don't execute the live\npath — mark the tool `skipped` with a blocker note.\n\n## Phase 4 — HEAL (loop)\n\nWhile any tool is `\"failed\"`: diagnose via `references\u002Fheal.md`, fix **only** that\ntool's integration — **implementation-only** fixes; if the fix would change the\napproved contract (schema, description, `mutating` class, `annotations`,\n`expect`), go back to the gate for re-approval instead of silently changing the\nmanifest. The triggering verify failure is attempt 0; increment `attempts` per\nfix cycle and re-verify. At `attempts` = 3 → `\"skipped\"` with a clear blocker\nnote (an explicit escalation to the human, not a silent drop). Never widen the\ndiff or fake a pass. After healing, re-run verification once for **all** tools\nwith status `integrated` or `verified` (healing one tool can break another —\nscope collisions).\n\n**Exit:** every tool is `verified`, `skipped`, or `rejected`; build green.\n\n## Final — AUDIT + report\n\n1. **Diff audit (flag-only, never auto-revert):** collect the pipeline's changes —\n   `git diff \u003CbaselineSha>..HEAD` **plus the index and untracked files** under\n   `commit-per-batch`, or the working tree + index + untracked under `no-commit`.\n   Every hunk must map to a manifest entry or a recorded `pipeline.setup` path.\n   An unmapped hunk → **flag it in the report** with file\u002Fline and a suggested\n   disposition; never revert anything yourself. A hunk in a `baselineDirty` file\n   → untouchable, flag only. Without a `baselineSha`, audit the files named in\n   manifest `source` fields and `pipeline.setup` paths (setup entries recorded as\n   `null` by the v2→v3 migration: fall back to flag-only for those files).\n2. Finalize `.webmcpify\u002Freport.md`: tool coverage per area, skipped\u002Frejected tools\n   with reasons, security notes (which mutating tools exist, what guards them,\n   any recorded production side effects), how to test manually (flag, DevTools\n   WebMCP pane, inspector extension), and every blocker that needs a human.\n3. Tell the human: what's exposed, what's skipped and why, and how to try it.\n\n## References (read on demand, not upfront)\n\n- `references\u002Finventory.md` — area mapping, naming\u002Fschema conventions, budgets\u002Foverlap\n- `references\u002Fintegrate.md` — declarative + imperative patterns per stack\n- `references\u002Fruntime.md` — vendoring + wiring the `templates\u002F` runtime\n- `references\u002Fverify.md` — harness setup: flags, surfaces, Playwright\u002FPuppeteer, evals\n- `references\u002Fheal.md` — failure taxonomy → fixes\n- `references\u002Fsecurity.md` — the security checklist (apply before the gate and at audit)\n","# webmcpify — make any web app agent-ready, verifiably\n\nYou are running the webmcpify pipeline. It takes an existing web application and\nexposes its user-facing functionality as [WebMCP](https:\u002F\u002Fwebmachinelearning.github.io\u002Fwebmcp\u002F)\ntools (`document.modelContext` — a proposed web standard incubated in the W3C Web\nMachine Learning Community Group, currently a Chrome origin trial), so browser AI\nagents can operate the app through structured tool calls instead of guessing at the DOM.\n\n```\nDETECT ──▶ INVENTORY ──▶ [HUMAN GATE: manifest approval] ──▶ INTEGRATE ──▶ VERIFY ──▶ HEAL ──▶ AUDIT\n              ▲  loop            per-area batches on big apps    ▲  loop      ▲ loop    ▲ loop\n              └── per area                                       └── per manifest entry ──┘\n```\n\nEverything you need ships inside this skill directory: phase guides in\n`references\u002F`, and vendorable code in `templates\u002F` (runtime, ambient types,\nJS variant, React JSX typings, verification spec). Never assume files exist\noutside the skill dir.\n\n**Out of scope** (stop and say so): backend-only MCP servers (that's classic MCP,\nnot WebMCP), automating third-party sites you don't control, and generic SEO work.\n\n## Invocation modes\n\nThe user may pass an argument (`\u002Fwebmcpify \u003Cmode>` or plain words):\n\n| Argument | Run | Stop at |\n|---|---|---|\n| *(none)* or `full` | all phases, resuming from current manifest state | done |\n| `inventory` \u002F `map` | DETECT + INVENTORY loops only — **zero code changes** | present the manifest table for review |\n| `integrate` | INTEGRATE loop only (requires approved tools in the manifest) | integrated + built |\n| `verify` | VERIFY + HEAL loops on integrated\u002Fverified tools | green\u002Fskipped report |\n| `status` | read `.webmcpify\u002Fmanifest.json` — **read-only** | report phase, per-status tool counts, and the recommended next command |\n\nAny other text is scoping guidance (e.g. \"only the checkout area\", \"read-only tools only\").\n\n## Ground rules (non-negotiable, enforce in every phase)\n\n1. **Zero unrelated changes.** Every diff hunk you produce must trace to a manifest\n   entry or the recorded one-time setup. Never refactor, reformat, rename, or\n   \"improve\" anything else — note problems in the report instead. Files that were\n   already dirty at baseline (recorded in the manifest) are **untouchable**: never\n   modify or revert them.\n2. **Read-only tools first.** Mutations are tri-state: `mutating: false`,\n   `\"client\"` (browser-local only: prefs, localStorage), or `\"server\"` (data\n   leaves the browser). Server-mutating tools require explicit **per-tool** human\n   approval recorded in the manifest; client-mutating tools may be approved as a\n   batch at the gate. Never expose destructive, irreversible, or payment actions\n   in a first integration.\n3. **The server is the only trust boundary.** A tool's `execute()` may only call code\n   paths the UI already uses (same endpoints, same validation, same auth). Never\n   create new endpoints, never bypass existing checks, never put secrets in tools.\n4. **Spec-shaped and dependency-free.** Register via `document.modelContext.registerTool()`\n   with AbortSignal lifecycle (feature-detect the deprecated `navigator.modelContext`\n   fallback). No third-party WebMCP runtime dependencies. Everything feature-detected:\n   the app behaves identically in browsers without WebMCP.\n5. **Never `toolautosubmit` on state-changing forms** — neither `mutating: \"client\"`\n   nor `\"server\"`. Only on pure read forms (search, filter, availability).\n6. **State lives in files, not in your context.** Read\u002Fwrite `.webmcpify\u002F` constantly;\n   assume your context can be wiped between any two steps. Write the manifest\n   atomically (write `manifest.json.tmp`, then rename over `manifest.json`).\n7. **Commits are opt-in.** Never commit unless the human chose a commit policy at\n   the gate (see below). Without git or without permission, leave changes in the\n   working tree and record progress in the manifest only.\n\n## Fresh, authoritative guidance\n\nWebMCP is an evolving origin-trial API — the surface has already changed during the\ntrial (testing API removed 2026-07; `navigator` → `document`). Before Phase 2, if\nnetwork is available, pull Google's current official guides rather than relying on\nmemory:\n\n```sh\nnpx -y modern-web-guidance@latest retrieve \"webmcp,agentic-forms,agentic-javascript-tools\"\n```\n\nIf offline, use `references\u002Fintegrate.md` — but prefer the live guides when they conflict.\n\n## The state protocol — `.webmcpify\u002F` in the target repo\n\n| File | Purpose |\n|---|---|\n| `manifest.json` | Single source of truth (schema below; atomic writes) |\n| `areas\u002F\u003Cid>.tools.json` | Sub-agent shard output during inventory fan-out (merged, then deleted) |\n| `report.md` | Human-facing running report; finalized at the end |\n\n**Resume rule:** if `manifest.json` exists, resume — recompute nothing already\nrecorded. **Merge leftover shards FIRST**: any existing `areas\u002F\u003Cid>.tools.json`\nfiles are merged into the manifest (mark those areas `inventoried`, delete the\nshards) before redispatching any sub-agents. Then continue at `pipeline.phase`,\nthe first `pending` area, or the first tool whose status is not terminal.\nTerminal statuses: `verified`, `skipped`, `rejected`.\n\n**Phase transitions** (make the atomic manifest write the moment the condition holds):\n\n- `detect → inventory`: `app` recorded, `baselineSha`\u002F`baselineDirty` captured.\n- `inventory → gate`: no area `pending`, completeness pass has run.\n- `gate → integrate`: every `discovered` tool is `approved`\u002F`rejected`, and\n  `commitPolicy` + `commitWebmcpifyDir` are set.\n- `integrate → verify`: no `approved` tools remain (each `integrated` or terminal),\n  build green.\n- `verify → heal`: verify loop visited every `integrated` tool and ≥1 is `failed`\n  (none failed → straight to `audit`).\n- `heal → audit`: no tool `failed` and post-heal full re-verify passed.\n- `audit → done`: every hunk mapped-or-flagged, `report.md` finalized.\n\nManifest schema (Webmcpify Manifest v3):\n\n```jsonc\n{\n  \"webmcpify\": 3,\n  \"app\": { \"stack\": \"react-vite\", \"typescript\": true, \"entry\": \"src\u002Fmain.tsx\",\n           \"baseUrl\": \"http:\u002F\u002Flocalhost:5173\", \"startCommand\": \"npm run dev\",\n           \"authFixtures\": {                    \u002F\u002F how verify OBTAINS each session\n             \"member\": { \"obtain\": \"npm run seed:test-user, then sign in at \u002Flogin\",\n                         \"account\": \"member@example.test\",\n                         \"env\": [\"TEST_MEMBER_PASSWORD\"] }  \u002F\u002F env var NAMES only — never secret values\n           } },\n  \"pipeline\": {\n    \"phase\": \"inventory\",          \u002F\u002F detect|inventory|gate|integrate|verify|heal|audit|done — transition rules above\n    \"setup\": {                     \u002F\u002F PATHS created\u002Fmodified per one-time setup step ([] = not done yet)\n      \"runtimeVendored\": [\"src\u002Fwebmcp\u002Fwebmcpify.ts\", \"src\u002Fwebmcp\u002Fwebmcp.d.ts\"],\n      \"harnessInstalled\": [\".webmcpify\u002Fwebmcp.spec.ts\"],\n      \"originTrialNoted\": [\"README.md\"]\n    },\n    \"baselineSha\": \"abc1234\",      \u002F\u002F HEAD at pipeline start; null if no git\n    \"baselineDirty\": [\"src\u002Fwip.ts\"], \u002F\u002F paths dirty at start — untouchable (ground rule 1)\n    \"commitPolicy\": null,          \u002F\u002F set at the gate: \"commit-per-batch\" | \"no-commit\"\n    \"commitWebmcpifyDir\": null,    \u002F\u002F set at the gate: commit .webmcpify\u002F itself? true | false\n    \"blockers\": []                 \u002F\u002F e.g. \"app won't start locally: needs $API_KEY\" — surfaced at the gate\n  },\n  \"areas\": [\n    { \"id\": \"checkout\", \"paths\": [\"src\u002Ffeatures\u002Fcheckout\u002F\"], \"status\": \"pending\" } \u002F\u002F pending|inventoried\n  ],\n  \"tools\": [\n    {\n      \"id\": \"create_ticket\",\n      \"area\": \"tickets\",\n      \"kind\": \"imperative\",        \u002F\u002F imperative | declarative\n      \"mutating\": \"server\",        \u002F\u002F false | \"client\" (browser-local only: prefs, localStorage) | \"server\" (data leaves the browser)\n      \"priority\": 1,               \u002F\u002F 1 = expose first; 2\u002F3 = later waves\n      \"description\": \"Creates a new ticket in the currently open project.\",\n      \"inputSchema\": { \u002F* JSON Schema *\u002F },\n      \"annotations\": { \"readOnlyHint\": false, \"untrustedContentHint\": false }, \u002F\u002F verify asserts these on the enumerated tool\n      \"source\": [\"src\u002Ffeatures\u002Ftickets\u002FNewTicket.tsx:42\"], \u002F\u002F the UI code path it wraps\n      \"route\": \"\u002Fprojects\u002Fdemo\u002Ftickets\",                    \u002F\u002F where verify navigates\n      \"auth\": [\"role:member\"],     \u002F\u002F \"none\" | \"session\" | [\"role:\u003Cname>\", ...] — keys into app.authFixtures; verify runs once per listed role\n      \"examples\": { \"valid\": { \"title\": \"Test ticket\" }, \"invalid\": {} },\n                                   \u002F\u002F invalid: null ONLY for readOnlyHint tools with no\u002Fempty params —\n                                   \u002F\u002F verify then asserts dual-outcome: rejects OR resolves with no side effect\n      \"expect\": { \"result\": \"created\", \"navigation\": null, \"ui\": \"new row appears in the ticket list\" },\n                                   \u002F\u002F exactly one of result|navigation: result = substring of the resolved string;\n                                   \u002F\u002F navigation = destination URL\u002Fpattern when executeTool resolves null (it navigated)\n      \"cleanup\": \"delete the created ticket via the UI's own delete path (test data only)\", \u002F\u002F required for mutating:\"server\", recommended for \"client\"\n      \"status\": \"discovered\",      \u002F\u002F discovered|approved|rejected*|integrated|verified*|failed|skipped*  (* = terminal)\n      \"approval\": null,            \u002F\u002F server-mutating tools, once approved: { \"note\": \"...\", \"at\": \"2026-07-12\",\n                                   \u002F\u002F   \"productionSideEffect\": null } — set only when verification unavoidably\n                                   \u002F\u002F   causes a real production effect (see VERIFY: production side-effect policy)\n      \"attempts\": 0,               \u002F\u002F heal-fix cycles; the triggering verify failure is attempt 0\n      \"batchCommit\": null,         \u002F\u002F sha under commit-per-batch — lands in the manifest one commit LATER\n      \"notes\": \"\"\n    }\n  ],\n  \"log\": [ \"2026-07-12 inventory: area checkout done, 4 candidates\" ]\n}\n```\n\n**v2→v3 migration:** resuming a `\"webmcpify\": 2` manifest migrates in place on\nfirst write — `auth` string → array; `setup` booleans → path arrays (`false` →\n`[]`; `true` → recover paths from git\u002F`log`, else `null` = done-but-unrecorded,\naudit treats those files flag-only); `mutating: true` → `\"server\"`; add\n`annotations` (defaults from the inventory table), `blockers: []`,\n`commitWebmcpifyDir: null`, `expect.navigation: null`; then bump to 3.\n\n## Phase 0 — DETECT\n\nIdentify stack, build + dev-server commands, TypeScript or not, auth model\n(including how verify obtains each test session → `app.authFixtures`), test\nsetup, and how the app starts locally; record under `app`. Record the git baseline:\n`pipeline.baselineSha` = current HEAD and `pipeline.baselineDirty` = `git status\n--porcelain` paths (both `null`\u002F`[]` without git). If the app cannot be started\nlocally, append the blocker to `pipeline.blockers` — integration may proceed, but\nverification will be blocked and this must be surfaced at the gate. Details:\n`references\u002Finventory.md`.\n\n## Phase 1 — INVENTORY (loop; scales to any size)\n\n**Never map a large codebase in one pass.**\n\n1. **Area map first (cheap, structural):** enumerate routes\u002Fviews\u002Ffeature modules\n   from the router config, pages directory, or navigation — without reading\n   implementation files. Write every area to `areas` with `\"pending\"`.\n2. **Inventory loop — one area per iteration:** deep-read only that area's files;\n   draft a candidate tool per user action (conventions, tool-count budget, and\n   overlap rules: `references\u002Finventory.md`) with ALL manifest fields filled,\n   including `route`, `auth`, `annotations`, `examples`, `expect`, and `cleanup`\n   (required for `mutating: \"server\"`, recommended for `\"client\"`) — the verify\n   phase runs from these fields alone. Append as `\"discovered\"`, mark the area\n   `\"inventoried\"`, write the manifest, repeat.\n   - **Sub-agent fan-out:** sub-agents never write `manifest.json`. Each writes only\n     its own `areas\u002F\u003Cid>.tools.json` shard — schema\n     `{ \"webmcpifyShard\": 3, \"area\": \"\u003Cid>\", \"tools\": [ \u002F* full v3 tool entries *\u002F ] }`,\n     written atomically (tmp + rename). You (the coordinator) merge shards into\n     the manifest sequentially, then delete them; on resume, merge existing\n     shards FIRST before redispatching (Resume rule).\n3. **Exit:** no `pending` areas remain, plus one completeness pass — walk the app's\n   navigation and ask \"is any visible user action missing?\"\n\n## GATE — manifest approval (the one main checkpoint)\n\nPresent the manifest compactly (id, area, kind, mutating, priority, one-line\ndescription) — per-area batches on large apps. Ask the human to decide, in one\nexchange where possible:\n\n1. Which tools are `approved` vs `rejected` (**`rejected` is terminal** — rejected\n   tools are excluded from every later phase and from exit conditions).\n   `mutating: \"server\"` tools need individual acknowledgment → record in\n   `approval`; `mutating: \"client\"` tools may be approved as a batch.\n2. **Commit policy**: `commit-per-batch` (each integration batch committed,\n   revertable — recommended on a clean baseline) or `no-commit` (leave changes\n   uncommitted for the human to review\u002Fcommit) → `pipeline.commitPolicy`. Also\n   whether `.webmcpify\u002F` itself should be committed (recommended: yes — it\n   documents the integration) → `pipeline.commitWebmcpifyDir`.\n3. Every entry in `pipeline.blockers` (e.g. app won't start). If verifying a tool\n   will unavoidably cause a real production side effect (e.g. a mailer with an\n   Origin-allow-listed endpoint), get that approved HERE and record it in the\n   tool's `approval.productionSideEffect` — see VERIFY.\n\nApply `references\u002Fsecurity.md` to every mutating tool **before** presenting.\n\n## Phase 2 — INTEGRATE (loop)\n\nOne-time setup first — record the created\u002Fmodified file **paths** in\n`pipeline.setup` (e.g. `runtimeVendored: [\"src\u002Fwebmcp\u002Fwebmcpify.ts\", ...]`):\nvendor the runtime from this skill's `templates\u002F` (`webmcpify.ts`, or\n`webmcpify.js` for non-TS projects, plus `webmcp.d.ts` for TS and\n`webmcp-jsx.d.ts` for React TSX — keep the full MIT header; see\n`references\u002Fruntime.md`) and note the origin-trial\u002Fflag requirement in the target\nREADME (`originTrialNoted`). Then loop:\n\n1. Pick the next batch of `approved` tools — one area or ≤5 tools.\n2. Implement per `references\u002Fintegrate.md`: declarative attributes for standard\n   HTML forms (including framework-rendered and fetch-intercepted ones);\n   imperative registration via the vendored runtime for non-form or\n   controlled-state actions.\n3. Build + typecheck; fix only what the batch broke.\n4. Mark tools `\"integrated\"`, write the manifest. Under `commit-per-batch`:\n   require a **clean index** before staging (unrelated staged changes → stop and\n   surface); stage **only the batch's files by path** — never `git add -A`, `-u`,\n   `.`, or `commit -a`; commit `feat(webmcp): expose \u003Cids> (webmcpify)`. The\n   commit sha lands in `batchCommit` on the **next** manifest write — one commit\n   later (the manifest can't contain its own commit's sha). Never amend a\n   previous batch commit.\n5. Repeat until no `approved` tools remain.\n\n## Phase 3 — VERIFY (loop)\n\nSet up once from `templates\u002Fwebmcp.spec.ts` per `references\u002Fverify.md` (real headed\nChrome; production `getTools()`\u002F`executeTool()` surface with legacy fallback probe).\nThen loop over every `integrated` tool, using its manifest `route`, `auth`,\n`examples`, `expect`, and `annotations` fields:\n\n- assert the tool is registered with the expected schema (enumerated `inputSchema`\n  is a *stringified* JSON Schema — parse before comparing) **and** the manifest\n  `annotations`;\n- execute the valid example (mutating tools: dev\u002Ftest data only, then run\n  `cleanup`) and one invalid example (`invalid: null` zero-param read tools:\n  dual-outcome assertion — see `references\u002Fverify.md`);\n- assert on the returned result **and** the resulting UI state per `expect`\n  (a UI **delta**, or `expect.navigation` when execution resolves `null`).\n\nPass → `\"verified\"`. Fail → `\"failed\"` + failure note. Role-scoped tools: run the\nloop once per role listed in `auth`, signing in via the matching\n`app.authFixtures` entry.\n\n**Production side-effect policy** — when a tool's verification unavoidably causes\na real production effect (e.g. an email actually sent), ALL THREE are required:\n(1) the human approved it at the gate, recorded in `approval.productionSideEffect`;\n(2) every test payload is marked `[webmcpify verification]`; (3) the effect is\nlisted in `report.md`. Without the recorded approval, don't execute the live\npath — mark the tool `skipped` with a blocker note.\n\n## Phase 4 — HEAL (loop)\n\nWhile any tool is `\"failed\"`: diagnose via `references\u002Fheal.md`, fix **only** that\ntool's integration — **implementation-only** fixes; if the fix would change the\napproved contract (schema, description, `mutating` class, `annotations`,\n`expect`), go back to the gate for re-approval instead of silently changing the\nmanifest. The triggering verify failure is attempt 0; increment `attempts` per\nfix cycle and re-verify. At `attempts` = 3 → `\"skipped\"` with a clear blocker\nnote (an explicit escalation to the human, not a silent drop). Never widen the\ndiff or fake a pass. After healing, re-run verification once for **all** tools\nwith status `integrated` or `verified` (healing one tool can break another —\nscope collisions).\n\n**Exit:** every tool is `verified`, `skipped`, or `rejected`; build green.\n\n## Final — AUDIT + report\n\n1. **Diff audit (flag-only, never auto-revert):** collect the pipeline's changes —\n   `git diff \u003CbaselineSha>..HEAD` **plus the index and untracked files** under\n   `commit-per-batch`, or the working tree + index + untracked under `no-commit`.\n   Every hunk must map to a manifest entry or a recorded `pipeline.setup` path.\n   An unmapped hunk → **flag it in the report** with file\u002Fline and a suggested\n   disposition; never revert anything yourself. A hunk in a `baselineDirty` file\n   → untouchable, flag only. Without a `baselineSha`, audit the files named in\n   manifest `source` fields and `pipeline.setup` paths (setup entries recorded as\n   `null` by the v2→v3 migration: fall back to flag-only for those files).\n2. Finalize `.webmcpify\u002Freport.md`: tool coverage per area, skipped\u002Frejected tools\n   with reasons, security notes (which mutating tools exist, what guards them,\n   any recorded production side effects), how to test manually (flag, DevTools\n   WebMCP pane, inspector extension), and every blocker that needs a human.\n3. Tell the human: what's exposed, what's skipped and why, and how to try it.\n\n## References (read on demand, not upfront)\n\n- `references\u002Finventory.md` — area mapping, naming\u002Fschema conventions, budgets\u002Foverlap\n- `references\u002Fintegrate.md` — declarative + imperative patterns per stack\n- `references\u002Fruntime.md` — vendoring + wiring the `templates\u002F` runtime\n- `references\u002Fverify.md` — harness setup: flags, surfaces, Playwright\u002FPuppeteer, evals\n- `references\u002Fheal.md` — failure taxonomy → fixes\n- `references\u002Fsecurity.md` — the security checklist (apply before the gate and at audit)\n",{"name":5,"license":14,"metadata":42,"description":7,"argument-hint":44},{"source":43},"https:\u002F\u002Fgithub.com\u002FTueJon\u002Fwebmcpify","[inventory|integrate|verify|status|full] [scope notes]","main","068c2486ccc0f8d200a3db4d21ec137064eda3b4","skills\u002Fwebmcpify","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing","https:\u002F\u002Fgithub.com\u002FJiayiV","2026-08-25 16:30:52",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add JiayiV\u002Fquestion_mixing --skill webmcpify",{"tool":57,"command":58},"bunx","bunx skills add JiayiV\u002Fquestion_mixing --skill webmcpify",{"tool":60,"command":61},"pnpm","pnpm dlx skills add JiayiV\u002Fquestion_mixing --skill webmcpify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fwebmcpify\u002FSKILL.md",true,[],[66,94,127,155,190,213],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":70,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":37},"01M6NN6KZE5RBN6NGHN2WXV1RE","vardoger-analyze","Use when the user asks to personalize the GitHub Copilot CLI assistant, adapt Copilot to their style, use vardoger, or analyze their Copilot CLI conversation history. Reads the local session directory at `~\u002F.copilot\u002Fsession-state\u002F`, extracts recurring preferences and conventions, and writes a fenced personalization block into `~\u002F.copilot\u002Fcopilot-instructions.md`. Runs entirely on the user's machine via the local `vardoger` CLI (`pipx install vardoger`); no network calls and no uploads. Triggers: 'personalize my copilot', 'analyze my copilot history', 'tailor copilot to me', 'run vardoger', 'update my copilot instructions from history', 'make copilot learn my style'.","Apache-2.0","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fvardoger-analyze\u002FSKILL.md",[],[74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93],"vardoger analyze","analyze","directory","cli","github copilot","copilot","run","update","learn","network","my style","install","conversation","me","local","github copilot cli","pipx","my","at","copilot instructions",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":108,"publishedAt":37},"01M6NN3CZGQP3XAJ04BM1NNYGT","transloadit-media-processing","Process media files (video, audio, images, documents) using Transloadit. Use when asked to encode video to HLS\u002FMP4, generate thumbnails, resize or watermark images, extract audio, concatenate clips, add subtitles, OCR documents, or run any media processing pipeline. Covers 86+ processing robots for file transformation at scale.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Ftransloadit-media-processing\u002FSKILL.md",[100,105],{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":106,"categoryName":107,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000023","Skill与智能体开发",[109,110,111,112,113,114,115,116,117,118,119,120,121,25,122,123,124,125,20,126],"transloadit media processing","Media","media processing","processing","MCP","mcp server","documents","subtitles","pipeline","ocr","Video","Audio","mp4","images","files","transformation","free","hls",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":136,"publishedAt":37},"01M6NN28E92F9GH4WFYQ2H1Y15","terraform-azurerm-set-diff-analyzer","Analyze Terraform plan JSON output for AzureRM Provider to distinguish between false-positive diffs (order-only changes in Set-type attributes) and actual resource changes. Use when reviewing terraform plan output for Azure resources like Application Gateway, Load Balancer, Firewall, Front Door, NSG, and other resources with Set-type attributes that cause spurious diffs due to internal ordering changes.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fterraform-azurerm-set-diff-analyzer\u002FSKILL.md",[133],{"categoryNo":134,"categoryName":135,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000011","运维与部署",[137,138,139,140,141,142,143,144,145,25,146,147,148,149,150,151,152,153,154,20],"terraform","SET","terraform azurerm set diff analyzer","diff","analyzer","diffs","azure","gateway","firewall","only","resource changes","provider","resources","load balancer","attributes","front","load","balancer",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":172,"publishedAt":37},"01M6NN1QMH2TDYWTH3XY3N5XPV","technical-job-search","Use this skill when a software engineer asks for help with job search tasks: parsing or analyzing a job description, tailoring a CV\u002Fresume, writing a cover letter, evaluating a job offer, or drafting a post-interview follow-up email. Do not activate for general career advice unrelated to an active job search action.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Ftechnical-job-search\u002FSKILL.md",[161,164,169],{"categoryNo":162,"categoryName":163,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":165,"categoryName":166,"taxonomyType":167,"taxonomyTypeDesc":168},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":170,"categoryName":171,"taxonomyType":167,"taxonomyTypeDesc":168},"01JBSEEDCAT000000000000038","人力资源",[173,174,175,176,177,178,179,180,75,181,25,182,183,184,185,186,187,188,20,189],"search","Job Search","technical job search","technical","writing","tasks","email","parsing","interview","up","engineer","general","activate","do","task","cv","letter",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":37},"01M6NMZFA67XYS1GS09WT42235","steno-mode","Shorthand-first response compression that cuts ~40% of response tokens while preserving technical precision and exact literals. Use when the user says \"steno mode\", \"shorthand mode\", \"compressed responses\", \"token reduction\", \"brief structured output\", or invokes \u002Fsteno. Supports four compression levels: lite, brief, court, machine. Do not trigger for requests needing polished prose such as onboarding\u002Ftutorial content, stakeholder or customer-facing copy, or teaching-focused explanations.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fsteno-mode\u002FSKILL.md",[],[197,198,199,200,201,176,202,25,186,203,204,205,206,207,208,209,210,211,20,212],"steno mode","mode","customer","brief","first","tutorial","teaching","tokens","as","trigger","structured output","machine","output","court","requests","response compression",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":217,"categories":218,"keywords":220,"publishedAt":37},"01M6NMWBB6MFD7NNR80W10ZW2W","shopify-review-triage","Use this skill when someone wants public Shopify App Store reviews, low-star reviews, or merchant feedback triaged, prioritized, clustered, or turned into a product or support brief. Trigger for prompts like \"triage these app store reviews\", \"what should we fix first from this feedback\", \"cluster our 1-star reviews\", or \"write a weekly low-star review brief\", for a single Shopify app or a portfolio plus watched competitors. Produces a P0-P3 brief covering incident risk, repeated friction, pricing confusion, feature requests, and an explicit needs-human-read bucket, where every item keeps its public source link and stays labeled first pass or human-checked. Do not trigger for support tickets, order data, or any other private merchant data, and never use it to reply to or contact a reviewer.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fshopify-review-triage\u002FSKILL.md",[219],{"categoryNo":106,"categoryName":107,"taxonomyType":103,"taxonomyTypeDesc":104},[221,222,223,224,225,226,200,227,228,229,230,231,232,22,233,234,235,236,237,238],"review","triage","shopify review triage","shopify","review triage","packages","api","access","reviewer","fix","never","incident","io","guides","reviews","weekly","api keys","app store"]