CSlawyer1985
CSlawyer1985/legal-skillhub
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/CSlawyer1985/legal-skillhub --skill legal-page-generator-checklist命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
88查企业风险查询与分析工具 —— 专注于中国大陆企业的法务风险查询与分析，覆盖经营异常、行政处罚、监管措施、被执行人、失信被执行人、司法案件等风险类型。支持公司名称、统一社会信用代码、companyId 三种输入方式，自动完成风险查询并输出结构化风险分析总结。 触发场景：仅当用户意图为查询企业风险/法务风险时触发。包括但不限于：企业风险查询、公司风险、经营异常、行政处罚、监管措施、被执行人、失信被执行人、司法风险、风险扫描、风险评估、企业合规审查、风险报告、XX公司有什么风险、XX公司安全吗、XX公司有没有处罚、XX公司被执行过吗。 不触发场景：纯粹的企业信息查询（如查公司、搜企业、工商信息、注册资本、法人代表、股东结构、专利商标等）不应触发本技能，请使用其他 cha88 系列工具。
Manages Rule 30(b)(6) corporate representative deposition workflows — drafting notice topics with reasonable particularity, building examination outlines, defending designees, handling objections, and preserving binding admissions for summary judgment or trial. Use when drafting or responding to 30(b)(6) notices, selecting and preparing designees, building topic-by-topic outlines, or triaging scope and privilege disputes. Trigger keywords: 30(b)(6), corporate representative deposition, topic list, designee, notice analysis, deposition objections, corporate admissions.
Guides taking and defending Rule 30(b)(6) corporate representative depositions. Drafts topic lists with reasonable particularity, builds examination outlines for binding corporate admissions, analyzes noticed topics for objections, and prepares designees. Use when drafting 30(b)(6) notices, preparing corporate deposition topics, selecting or preparing designees, or defending corporate representative depositions.
基于 SOC 职业分类
正在显示 SKILL.md
| name | legal-page-generator-checklist |
| slug | legal-page-generator-checklist |
| version | 1.0.2 |
| displayName | 软件服务上线法律页面清单｜简诗 AI |
| summary | 根据免费、订阅、企业、API或开发者产品类型规划隐私、条款等上线所需页面结构与内容要点，并提示专业审查边界。 |
| description | 根据免费、订阅、企业、API或开发者产品类型规划隐私、条款等上线所需页面结构与内容要点，并提示专业审查边界。 |
| tags | ["content-copy","jianshi-ai"] |
Guides legal page content, structure, compliance, and platform readiness for AI/SaaS products.
When invoking: On first use, if helpful, open with 1–2 sentences on what this skill covers and why it matters, then provide the main output. On subsequent use or when the user asks to skip, go directly to the main output.
Identify:
The legal page structure depends heavily on the product category. Identify which one applies before drafting:
| Category | Key Legal Characteristics | Sections to INCLUDE | Sections to SKIP |
|---|---|---|---|
| Free Anonymous | No accounts, no payment, no persistent storage, GA4 analytics | What we DON'T collect, no-training statement, fair-use limits, free/no-SLA | Payment, account responsibilities, refund, data portability |
| Free with Account | Login required, user data stored, may have social features | Account security, data access/portability, user responsibilities | Payment, billing, refund |
| Freemium | Free + paid tiers, payment data, auto-renewal | Payment terms, billing, tier differences, data handling per tier | — |
| Subscription SaaS | Recurring billing, auto-renewal, cancellation | Payment, billing cycles, auto-renewal disclosure, cancellation process | — |
| Enterprise / B2B | DPA, SOC 2, zero-training guarantees, SCCs | DPA reference, sub-processor list, security certifications, data processing roles, custom retention | Fair-use limits (usually N/A) |
| API / Developer | Data processor role, rate limits, API keys | Rate limits, API key security, data processor terms, uptime/SLA | End-user account sections |
| Marketplace / Platform | Multi-party, UGC responsibility, submission licensing | Content moderation, takedown process, submitter licenses, third-party content disclaimer | — |
| E-commerce | Physical/digital goods, refunds, shipping | Refund policy, shipping policy, consumer rights, payment security | — |
| Content / Media | Copyright, DMCA, content licensing | DMCA contact, content ownership, republication terms | Payment (unless paid content) |
| Mobile App | App store review, privacy nutrition labels, permissions | App store compliance notes, permission justifications, data collection summary | — |
| AI Agent / MCP | Automated decisions, tool invocation, sub-processor chains | AI decision transparency, sub-processor chain disclosure, autonomous action limits |
Many external platforms require posted Privacy Policy and/or Terms of Service before the product can be listed, advertised, or operate in compliance. These should be flagged to the user during generation.
Most AI tool directories, MCP/Skills marketplaces, and software directories require both Privacy Policy and Terms of Service to be publicly accessible before a listing can be approved. Common requirements across these platforms:
| Platform | Requires | Consequence if Missing |
|---|---|---|
| Google Ads | Privacy Policy link during account setup | Cannot launch campaigns |
| Meta Ads (Facebook/Instagram) | Privacy Policy for ad account verification | Ad account suspended |
| TikTok Ads | Privacy Policy for account review | Cannot launch |
| Apple App Store | Privacy Policy URL + privacy nutrition labels | App rejected |
| Google Play Console | Privacy Policy URL for all apps | App rejected |
| LinkedIn Ads | Privacy Policy for business page verification | Restricted access |
| Requirement | What's Needed |
|---|---|
| Google Analytics ToS §7 | Posted privacy policy that discloses GA usage |
| Stripe / payment processors | Privacy Policy URL during onboarding |
| OAuth providers (Google, GitHub) | Privacy Policy URL for app verification |
| SOC 2 / ISO 27001 | Both pages are standard vendor-assessment prerequisites |
| Enterprise procurement | Both pages are due-diligence checklist items |
| Accelerators (YC, Techstars, etc.) | Legal pages are standard application requirements |
Use a three-layer approach to determine which laws apply:
Layer 1 — Operator location → determines primary governing law and venue in Terms.
Layer 2 — User locations → determines which privacy regulations apply and whether regional supplements are needed. If the product is accessible globally, assume GDPR (EU), CCPA (California), and the operator's home jurisdiction at minimum.
Layer 3 — Data storage location → determines data localization obligations. China (PIPL) and India (DPDP) may require local storage.
| Jurisdiction | Law | Consent Model | Max Penalty | Notable |
|---|---|---|---|---|
| EU/EEA | GDPR | Opt-in | €20M / 4% global revenue | 72h breach notification; DPO required for certain entities |
| UK | UK GDPR + DPA 2018 | Opt-in | £17.5M / 4% | Post-Brexit independent; UK Representative required |
| California | CCPA/CPRA | Opt-out | $7,988/violation (no cap) | 19 US states now enforce; ADMT rules effective Jan 2026 |
| China | PIPL | Opt-in + separate consent for sensitive data | ¥50M / 5% revenue | Data localization mandatory; cross-border transfer requires security assessment |
| Brazil | LGPD | Opt-in | R$50M (~$10M USD) | DPO required for larger orgs |
| India | DPDP Act 2023 | Consent-centric | ₹250Cr (~$30M USD) | Under-18 requires parental consent; phased enforcement 2025–2027 |
| Canada | PIPEDA + Quebec Law 25 | Opt-in | CAD $10M+ | Quebec has independent requirements |
| South Korea | PIPA | Opt-in | 3% of revenue | Criminal penalties possible; among the strictest globally |
| Japan | APPI | Opt-in for transfers | Criminal penalties | "Pseudonymized" data concept |
| Australia | Privacy Act 1988 + 2025 amendments | Opt-in | AUD $50M+ | New "fair and reasonable" test; children's privacy code |
Follow the model used by leading AI platforms: one main policy covering universal practices, plus regional supplement sections for jurisdictions with unique requirements. At minimum, provide:
Other regional supplements (China, Brazil, India, etc.) should be added when the product has significant users in those jurisdictions.
| Pattern | Use Case | Venue Clause |
|---|---|---|
| Single jurisdiction | Operator and users in same country | Governing law of [State], venue in [County] |
| Dual jurisdiction (fallback) | Operator has ties to two countries | Primary: [Jurisdiction A]; Alternate: [Jurisdiction B] only where A is unavailable |
| EU-first | Primarily EU users | Ireland or Estonia (English-language EU courts) |
| Arbitration | Crypto/Web3 or international | Binding arbitration (JAMS, SIAC, HKIAC); opt-out window for users |
These are mandatory disclosures for any product using AI models (generation, processing, or analysis):
In Privacy Policy:
In Terms of Service:
| Pitfall | Why It Matters | Fix |
|---|---|---|
| Over-promising data deletion | Saying "we delete everything immediately" while keeping server logs for 30 days creates a false statement | Specify retention per category: submitted data (immediate), analytics (14 months), logs (30 days) |
| Missing GA4 cookie disclosure | Google Analytics sets _ga and _ga_* cookies — must be in the cookie table | Always include GA4 cookies when using Google Analytics |
| Skipping "no training" statement | Users assume AI tools train on their data by default; silence = assumed training | Explicitly state "not used for AI model training" if true |
| Jurisdiction mismatch | Operator in one country but Terms only list another — users may challenge forum convenience | Use dual-jurisdiction fallback pattern when operator has cross-border ties |
| No DMCA/copyright complaint channel | US-hosted sites need a takedown contact; even free tools get requests | Include copyright complaint email in Terms §Contact |
| Liability cap without jurisdictional carve-out | EU, AU, NZ don't allow blanket disclaimers or very low caps | Add: "Some jurisdictions do not allow these limitations, so they may not apply to you" |
| Confusing cookie notice with cookie consent | Notice = "we use cookies, here they are" (sufficient for analytics only). Consent = "click accept/reject" (required for ads/tracking) | Classify cookies by type and recommend the right mechanism |
| Updating Terms without "continued use = acceptance" | Without this clause, existing users can argue they never agreed to new terms | Always include: "Your continued use after changes are posted constitutes acceptance" |
Legal page indexing is not one-size-fits-all. The decision depends on the product's goals:
| Scenario | Strategy | Reason |
|---|---|---|
| Submission/directory listing required | Index | Many AI tool directories and submission platforms crawl the site to verify legal pages exist; noindex blocks this verification |
| General SaaS / content site | Noindex | Legal pages are low-value for organic search; noindex keeps them out of search results while remaining accessible |
| Multiple language versions | Canonical | Point all language variants to the primary (usually English) version |
| Regional variants | Index + canonical | If legally required to have jurisdiction-specific versions, index each and self-canonical |
Default recommendation: Index both pages unless the product has a specific reason not to. The SEO cost of indexing two utility pages is negligible, and the platform-verification benefit of indexable legal pages is significant.
Quick-reference section frameworks by page type:
For each legal page type, provide:
获取使用帮助和更多实用 Skill，请关注公众号「简诗 AI」，或在 SkillHub 搜索「简诗 AI」| — |