Sync third-party and MCP marketplace plugins

Constraint: Public skills are published only by explicit administrator action unless they are tracked third-party market sources.
Confidence: high
Scope-risk: narrow
Directive: Keep private/internal skills out of the public marketplace and preserve normal incremental market Git history.
Tested: Marketplace validation passed.
This commit is contained in:
KeyInfo Bot committed 2026-09-29 00:02:01 +08:00
1 parent ef6dd4b5f0
commit 8558505b13
9 files changed
+38 -32

No files matched your search

+7 -7
View File
@@ -42,8 +42,8 @@
"repo": "https://github.com/shadcn-ui/ui.git",
"ref": "main",
"adapter": "claude-skill",
"commit": "984f4351cb3877fc60726ccec8c4d0bc1631bc0d",
"syncedAt": "2026-09-28T10:12:45Z"
"commit": "db2db460a26fa84fb65c8d903b213925fbdee9ed",
"syncedAt": "2026-09-28T16:00:01Z"
},
{
"id": "frontend-slides",
@@ -130,10 +130,10 @@
"id": "artemis-automation",
"pluginName": "artemis-automation",
"repo": "https://git.playones.com/chenmingxuan/Artemis-Eapil.git",
"ref": "v1.2.1",
"ref": "v1.2.2",
"adapter": "claude-skill",
"commit": "1dc2b0c6867da5a505e558974bb330743e4c30c6",
"syncedAt": "2026-09-28T10:12:45Z"
"commit": "e1e26772d91a1e608673d34464212d4361ee1f60",
"syncedAt": "2026-09-28T16:00:01Z"
},
{
"id": "embedded-app-pc-debug",
@@ -168,8 +168,8 @@
"repo": "https://github.com/vercel/next.js.git",
"ref": "canary",
"adapter": "skill-collection",
"commit": "705a28453296df17c5d269a4248ca36758a6fce2",
"syncedAt": "2026-09-28T10:12:45Z"
"commit": "3a5205b89de504f88066d267eafaabec0c774b74",
"syncedAt": "2026-09-28T16:00:01Z"
},
{
"id": "shuorenhua",
@@ -1,6 +1,6 @@
{
"name": "artemis-automation",
"version": "1.2.1",
"version": "1.2.2",
"description": "使用 ARTEMIS MCP 完成 Android 自动化测试、批量执行、失败诊断、历史检索和报告交付。",
"author": {
"name": "chenmingxuan",
@@ -1,9 +1,9 @@
{
"sourceId": "artemis-automation",
"repo": "https://git.playones.com/chenmingxuan/Artemis-Eapil.git",
"ref": "v1.2.1",
"commit": "1dc2b0c6867da5a505e558974bb330743e4c30c6",
"ref": "v1.2.2",
"commit": "e1e26772d91a1e608673d34464212d4361ee1f60",
"adapter": "claude-skill",
"sourcePath": "skills/artemis-automation",
"syncedAt": "2026-09-28T10:12:45Z"
"syncedAt": "2026-09-28T16:00:01Z"
}
@@ -3,5 +3,5 @@
"name": "playwright浏览器自动化操作",
"version": "20260605",
"keySource": "none",
"syncedAt": "2026-09-28T10:27:38Z"
"syncedAt": "2026-09-28T16:02:01Z"
}
@@ -2,8 +2,8 @@
"sourceId": "next-skills",
"repo": "https://github.com/vercel/next.js.git",
"ref": "canary",
"commit": "705a28453296df17c5d269a4248ca36758a6fce2",
"commit": "3a5205b89de504f88066d267eafaabec0c774b74",
"adapter": "skill-collection",
"sourcePath": "skills",
"syncedAt": "2026-09-28T10:12:45Z"
"syncedAt": "2026-09-28T16:00:01Z"
}
@@ -200,7 +200,7 @@ Per route:
### loop notes
- The [three blocker classes from background](#background) often get missed when fixing in place. Caching a downstream fetch (`getThing(id)`) doesn't clear an `await params` at the top of the page body — push the param promise into the `<Suspense>`-wrapped child.
- Ambiguous calls are user check-ins, not agent judgment. When you're not sure which fix fits, the blocking code looks security-sensitive, or the user might want to keep the route blocking on purpose — read [references/per-page-decisions.md](./references/per-page-decisions.md) before editing. Show the route while you ask: the `next-dev-loop` session runs the browser headed, so drive to the page and leave it on screen so the user is looking at the thing they're deciding about, with a screenshot as the fallback when a headed browser isn't possible. "Should this stay blocking?" is much easier to answer while looking at the page than at a file path.
- Ambiguous calls are user check-ins, not agent judgment. When you're not sure which fix fits, the blocking code looks security-sensitive, or the user might want to keep the route blocking on purpose — read [references/per-page-decisions.md](./references/per-page-decisions.md) before editing. Show the route while you ask using `next-dev-loop`'s browser handoff, with a screenshot as the fallback. "Should this stay blocking?" is much easier to answer while looking at the page than at a file path.
- Don't narrate the refactor with comments. The only comment the codemod (or you) should leave is `// TODO: Cache Components adoption` on opt-outs, and the user's existing comments. Don't annotate every `<Suspense>` boundary or `"use cache"` call with what it does — the code says that. Drop a comment only when the _why_ isn't clear from the code (e.g. a deliberate Block with a reason).
- For many routes with the same mechanical fix, verify one representative route first. Then batch disjoint route groups using the same recipe, and run the shared build and browser checks together.
@@ -220,7 +220,7 @@ Then check in with the user. Same rule as the pre-step: speak their language. Do
- What you did: which routes you touched, and the user-visible result per route (e.g. "the post page now streams the article body behind a skeleton while the layout stays static").
- What changed: opt-outs removed, fallbacks added, caching boundaries introduced.
- Show, don't tell. The `next-dev-loop` session runs the browser headed, so drive the route live for the user so they see the static shell → fallback → final content sequence in real time. If you can't drive a live browser, attach the before/after screenshots you captured instead.
- Show, don't tell. Follow `next-dev-loop`'s browser handoff and drive the route live so the user sees the static shell → fallback → final content sequence. If live presentation is unavailable, attach the before/after screenshots you captured.
- Give them the click-through: a short table of the feature's routes — the URL to open and what to look for (what renders instantly, which fallbacks appear, what streams in) — so they can verify each one themselves.
- The question: "Want to open this feature as a PR and move on to the next, or stop here?" Wait for the answer.
@@ -60,7 +60,7 @@ Once per session, confirm both views are live.
Then open the target URL:
```bash
agent-browser --session "$SESSION" --restore --headed --enable react-devtools open <url>
agent-browser --session "$SESSION" --restore --enable react-devtools open <url>
```
`--scope worktree` keeps parallel worktrees and copied checkouts
@@ -70,11 +70,17 @@ Once per session, confirm both views are live.
launch flags on `open`; agent-browser will reuse, relaunch, or restart
its scoped background state as needed.
The browser is the user's. If state was not restored (first run,
expired session) and the page is gated, the user drives the login —
pause until they confirm. After login, continue using the same session
and restore context; `agent-browser close` saves the cookie state so
the next `open` restores it.
Keep routine verification headless. If the user asks to see the UI, open the
current URL in the coding harness's inline browser. It is a separate browser
context, so do not assume state carries over. When login or existing
`agent-browser` state must carry over, reopen that session headed instead:
```bash
agent-browser --session "$SESSION" --restore --headed --enable react-devtools open <url>
```
Pause while the user drives login, then continue with the same session and
keep it headed for the rest of the loop.
2. Probe `/_next/mcp` (`tools/list`) — confirm it's reachable and
lists `get_compilation_issues`. First read the port off the
@@ -141,11 +147,11 @@ manual rather than from memory.
- A blank read, empty snapshot, `about:blank`, or a "no browser
session" error — right after `open` or after a click (even if `open`
reported the page) — is the browser dropping the page (a stale
session), not a broken route. Reopen your session at the URL with
`--session "$SESSION" --restore` and re-snapshot; if still blank,
run `agent-browser --session "$SESSION" --restore close`, then open
again. Don't fall back to `curl`; it bypasses the browser you're
testing.
session), not a broken route. Reopen your session at the URL with the
same launch flags as the active loop, then re-snapshot. If still blank, run
`agent-browser --session "$SESSION" --restore close`, then reopen with
those same flags. Don't fall back to `curl`; it bypasses the browser
you're testing.
- React introspection output is stale after navigation. Re-run.
- `/_next/mcp` replies are SSE — read the JSON off the `data:` line
with `sed -n 's/^data: //p'` (a plain `sed 's/^data: //'` leaves the
@@ -138,16 +138,16 @@ follow the static-shell documentation used by
authorization behavior. Change only what the selected contract requires.
When reusable UI should wait for navigation, follow the
[`unstable_navigation()`](https://nextjs.org/docs/app/api-reference/functions/navigation)
[`navigation()`](https://nextjs.org/docs/app/api-reference/functions/navigation)
reference, including its comparison with `connection()`. Then verify both
properties independently. The `instant()` assertion proves that the UI is
absent from the prefetch; it does not prove that the underlying work stayed
reusable. Verify that reusable work remains cached below the stage boundary.
When the contract needs an explicit runtime stage, follow the API references
for [`unstable_prefetch()`](https://nextjs.org/docs/app/api-reference/functions/prefetch)
for [`prefetch()`](https://nextjs.org/docs/app/api-reference/functions/prefetch)
and
[`unstable_navigation()`](https://nextjs.org/docs/app/api-reference/functions/navigation).
[`navigation()`](https://nextjs.org/docs/app/api-reference/functions/navigation).
Work one accepted navigation to GREEN before moving to another. Do not create
an app-wide Link or cache abstraction from a single case.
@@ -2,8 +2,8 @@
"sourceId": "shadcn",
"repo": "https://github.com/shadcn-ui/ui.git",
"ref": "main",
"commit": "984f4351cb3877fc60726ccec8c4d0bc1631bc0d",
"commit": "db2db460a26fa84fb65c8d903b213925fbdee9ed",
"adapter": "claude-skill",
"sourcePath": "skills/shadcn",
"syncedAt": "2026-09-28T10:12:45Z"
"syncedAt": "2026-09-28T16:00:01Z"
}