一键在 Manus 中运行任何 Skill

gsv-package-review

星标114

分支15

更新时间2026年6月27日 08:30

Guide on how to review GSV packages before approval, including source inspection, manifests, capabilities, entrypoints, staged edits, refs, and trust boundaries.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

deathbyknowledge

deathbyknowledge/gsv

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

GSV Package Review

Review Procedure

Start from metadata, then verify with source:

pkg list
pkg show <package>
pkg manifest <package>
pkg capabilities <package>
pkg source <package>
rgit refs --here
rgit log --here --limit 20
rgit status --here

A review should usually start from clean source. If staged edits exist, explain what they are before trusting the tree.

Inspect the path reported by pkg source <package> directly. Identify browser, backend, CLI, public route, daemon, signal, and package profile entrypoints.

What To Check

Requested Kernel capabilities match code paths that need them.
Filesystem writes/deletes are scoped and intentional.
Shell execution is justified and bounded.
Repository mutation uses the correct repo and ref.
Package lifecycle calls such as install, checkout, sync, approve, enable, and public visibility are justified.
Process spawning, IPC, schedules, adapter calls, notifications, and public routes are explicit.
Browser code does not abuse parent-window messaging or host bridge assumptions.
Backend/public routes do their own webhook signature or route-specific authorization.
Network access, dynamic import, eval-like behavior, and destructive actions are called out.

Mutating Commands

Use these only when the user asked for that action:

pkg add --repo owner/repo --ref main --subdir .
pkg approve <package>
pkg enable <package>
pkg disable <package>
pkg checkout <ref> <package>
pkg public on <package>
pkg public off <package>

Approval and enablement are separate. Approval trusts a package for its requested grants. Enablement activates entrypoints.

Verdict

Lead with findings when risks exist. End with one clear verdict:

approve
do not approve
approve only after named fixes

Do not approve based on display name, description, screenshots, or UI polish alone.

同仓库更多 Skills

同仓库

skill-authoring

deathbyknowledge/gsv

Create or revise reusable GSV agent workflows under skills.d. Use when the user asks to automate, save, teach, repeat, or reuse a workflow, or accepts an offer to preserve a proven workflow for later.

2026-07-18114

browser-target

deathbyknowledge/gsv

Use extension-provided browser targets to inspect and operate active browser state through the target's advertised filesystem and shell commands.

2026-07-13114

gsv-package-development

deathbyknowledge/gsv

Guide on how to build and modify GSV packages, including source checkout, app/backend/CLI changes, manifests, validation, staged commits, and syncing.

2026-06-27114

gsv-manual

deathbyknowledge/gsv

Use the GSV Manual for questions about GSV's operating model, user workflows, settings, devices, users and agents, packages, automation, integrations, filesystem, desktop, updates, and source/debug orientation.

2026-06-11114

name	gsv-package-review
description	Guide on how to review GSV packages before approval, including source inspection, manifests, capabilities, entrypoints, staged edits, refs, and trust boundaries.

GSV Package Review

Review Procedure

Start from metadata, then verify with source:

pkg list
pkg show <package>
pkg manifest <package>
pkg capabilities <package>
pkg source <package>
rgit refs --here
rgit log --here --limit 20
rgit status --here

A review should usually start from clean source. If staged edits exist, explain what they are before trusting the tree.

Inspect the path reported by pkg source <package> directly. Identify browser, backend, CLI, public route, daemon, signal, and package profile entrypoints.

What To Check

Requested Kernel capabilities match code paths that need them.
Filesystem writes/deletes are scoped and intentional.
Shell execution is justified and bounded.
Repository mutation uses the correct repo and ref.
Package lifecycle calls such as install, checkout, sync, approve, enable, and public visibility are justified.
Process spawning, IPC, schedules, adapter calls, notifications, and public routes are explicit.
Browser code does not abuse parent-window messaging or host bridge assumptions.
Backend/public routes do their own webhook signature or route-specific authorization.
Network access, dynamic import, eval-like behavior, and destructive actions are called out.

Mutating Commands

Use these only when the user asked for that action:

pkg add --repo owner/repo --ref main --subdir .
pkg approve <package>
pkg enable <package>
pkg disable <package>
pkg checkout <ref> <package>
pkg public on <package>
pkg public off <package>

Approval and enablement are separate. Approval trusts a package for its requested grants. Enablement activates entrypoints.

Verdict

Lead with findings when risks exist. End with one clear verdict:

approve
do not approve
approve only after named fixes

Do not approve based on display name, description, screenshots, or UI polish alone.