菜单
Use this when the user wants to draft a third-party vendor or product privacy and security review document for consumer use.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use to execute an implementation plan yourself, inline in this conversation, with review checkpoints. The simpler alternative to subagent-driven-development - use it for small plans or when the agents feature is off. Works in an isolated git worktree.
Use when implementation is complete and tests pass, to integrate the work. Verifies the build/tests, then presents clear options - merge locally, open a pull request, keep as-is, or discard - and carries out the choice, including cleaning up the git worktree.
Use to execute an implementation plan task-by-task by dispatching a fresh sub-agent per task with a review gate after each. Preferred when the agents feature is on - it keeps the main conversation's context lean and cheap. Works in an isolated git worktree.
Use this before any creative or building work - new features, components, behavior changes, or non-trivial fixes. Explores intent, requirements, and design through dialogue, then writes an agreed spec before any implementation begins.
Use before implementing a plan, to set up an isolated git worktree to work in. Creates a linked worktree under .worktrees/ and changes into it, so the feature's work never touches the main checkout - and a second conversation can work a different feature in parallel.
Use when you have an agreed spec or requirements for a multi-step task, before touching code. Turns the spec into a bite-sized, test-driven implementation plan with exact files, code, and commands - then hands off to execution.
| name | Third-Party Vendor Review |
| description | Use this when the user wants to draft a third-party vendor or product privacy and security review document for consumer use. |
This skill produces a consumer-focused TPRM review document in markdown. The document is neutral and analytical in tone, concise (3-5 pages of findings), and organized into a fixed set of section headings. The primary questions are always: can this vendor be trusted with the consumer's data, do they respect privacy, and is their security posture sound?
These definitions inform your grading judgment. Do not include a grade key in the output.
Privacy grade:
Security grade:
Vendor response to incidents is a named factor in the security grade. Strong, transparent, and effective remediation after a breach or CVE is a positive signal and can raise a grade. Dismissive, slow, or deceptive response is a negative signal and can lower one.
Verified post-incident architectural improvements are among the strongest positive signals available. If a vendor demonstrably changed how data is stored, transmitted, or controlled following an incident - for example by moving to local-only storage, adding end-to-end encryption, or removing cloud dependencies for sensitive data - this should be weighted heavily in the security grade and noted prominently in the report. A press statement without verifiable follow-through carries little weight.
Read the user's request and determine:
If the request is ambiguous, ask before proceeding.
Read resources.md in this skill folder before beginning research. It contains the confirmed working tools, endpoints, and search techniques to use for this investigation.
Web research agent: If the web-research agent is available, delegate multi-step web research tasks to it via dispatch_agent. The agent has access to web__search, web__extract, and web__get. Give each dispatched task a complete, self-contained description - include the vendor name, the specific questions to answer, and the investigative techniques from resources.md that apply.
Dispatch in two waves to respect dependencies:
First wave - dispatch in parallel, no dependencies:
Wait for first-wave results before dispatching the second wave.
Second wave - dispatch in parallel, depends on first wave:
Do not delegate single-item direct fetches or tasks that cannot be accomplished with those three web tools: the NVD CVE API call, the MITRE CVE detail API call, and the nslookup DNS checks must be run directly (they use a command shell or a single known URL, not open-ended web research). These direct calls may run concurrently with the first wave.
If the web-research agent is not available, perform all research steps directly using the techniques in resources.md.
Follow the investigative steps in that file. At minimum, cover:
Collect the raw findings before drafting. Quote exact CVE IDs, CVSS scores, DNS record values, and regulatory finding language. Do not paraphrase primary source data.
Using the definitions above and the collected findings, assign:
Be prepared to justify each grade from the findings in the body of the document.
Read template.md in this skill folder before drafting. It contains the exact section headings and formatting conventions to follow.
Keep the document to 3-5 pages of findings (excluding the grades and executive summary). Write for a mixed audience: one reader is a software developer, the other is a non-technical TPRM manager. Technical details (CVE IDs, CVSS scores, DNS records) are acceptable but should not dominate the prose. Plain-language interpretation must accompany any technical finding.
Key Risks section rules: The Key Risks section lists only current, unresolved risks. Do not list:
A patched CVE belongs in Security Posture with its resolution noted. A remediated incident belongs in Breach and Regulatory History with its follow-up described. Neither belongs in Key Risks. Slow or absent patching, or ineffective remediation, is itself a current risk and may be listed.
Do not make a recommendation. The grades and findings speak for themselves.
Before delivering the document, check:
