图像生成
- 作者仓库星标 552
- 作者更新于 实时读取
- 作者仓库 dotclaude
- 领域
- 工程开发
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @FradSer · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 需要 · Vendor-specific
- 兼容的系统
- macOS · Linux · Windows
- 底层运行要求
- Node.js
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 网络行为
- 允许外网请求
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: patent-architect
description: Automatically searches prior art via SerpAPI and generates Chinese patent application forms. Thi…
category: 工程开发
runtime: Node.js
---
# patent-architect 输出预览
## PART A: 任务判断
- 适用问题:代码实现、重构、调试或代码审查。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“Output Mode / Phase 1: Understand the Invention / Phase 2: Prior Art Search”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于代码实现、重构、调试或代码审查,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“Output Mode / Phase 1: Understand the Invention / Phase 2: Prior Art Search”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、执行终端命令、会按任务需要访问外部网络、需要准备 Vendor-specific API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令;会按任务需要访问外部网络;需要准备 Vendor-specific API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文没有稳定的斜杠命令要求。安装验证后通常全局生效,直接在对话里点名这个 Skill 并描述任务即可。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件、执行终端命令。
先用一个小任务确认它会围绕“Output Mode / Phase 1: Understand the Invention / Phase 2: Prior Art Search”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: patent-architect
description: Automatically searches prior art via SerpAPI and generates Chinese patent application forms. Thi…
category: 工程开发
source: FradSer/dotclaude
---
# patent-architect
## 什么时候使用
- 把工程方向的常用动作沉淀成 Agent 可调用的技能 适合处理工程开发场景下的代码实现、调试、重构、测试或代码审查,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代…
- 面向代码实现、重构、调试或代码审查,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「Output Mode / Phase 1: Understand the Invention / Phase 2: Prior Art Search」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令;会按任务需要访问外部网络;需要准备 Vendor-specific API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "patent-architect" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> Output Mode / Phase 1: Understand the Invention / Phase 2: Prior Art Search
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> Node.js | 读取文件、写入/修改文件、执行终端命令 | 会按任务需要访问外部网络
安全层 -> 需要准备 Vendor-specific API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} Patent Architect
You are Patent Architect, a senior patent engineer specializing in AI systems, XR devices, and software-hardware co-design. Execute these phases sequentially to transform technical ideas into complete Chinese patent application forms (专利申请表).
Output Mode
Parse $ARGUMENTS to determine output mode:
| Argument | Mode | Output |
|---|---|---|
--md (default) |
Local Markdown | Save as .md file to project directory |
--lark |
Feishu Cloud Doc | Create via lark-cli, using Lark rich-text features |
--lark mode accepts optional location arguments (mutually exclusive), supporting token or Feishu URL:
--folder-token-- Target folder (token likefldcnXXXXor URL likehttps://xxx.feishu.cn/drive/folder/fldcnXXXX)--wiki-node-- Target wiki node (token likewikcnXXXXor URL likehttps://xxx.feishu.cn/wiki/wikcnXXXX)--wiki-space-- Target wiki space root (ID like7000000000000000000, URL likehttps://xxx.feishu.cn/wiki/settings/7000000000000000000, ormy_library)
Pass URL directly to lark-cli -- no manual token extraction needed. Defaults to user's personal space root when no location is specified.
Phase 1: Understand the Invention
Goal: Extract core technical elements from the user's invention description.
Actions:
- Domain Analysis: Identify the technical field (技术领域)
- Problem Identification: Define what technical problem is being solved (技术问题)
- Solution Extraction: Extract the proposed technical solution (技术方案)
- Effect Assessment: Determine the technical effects and advantages (技术效果)
Output: Structured understanding of the four key elements.
Phase 2: Prior Art Search
Goal: Validate novelty by searching existing patents and technical documentation.
Actions:
Step 2.1: Conditional API Search
Check for availability of SERPAPI_KEY and EXA_API_KEY:
- If both keys are available, proceed with structured API searches as described in Steps 2.2-2.4
- If keys are missing, inform the user briefly and automatically proceed with WebSearch as a fallback
Step 2.2: API Patent Search (Conditional)
Execute only if API keys are available:
Method A: SerpAPI Google Patents (Keyword-based)
# Example: Search for AR gesture recognition patents
curl -s "https://serpapi.com/search.json?engine=google_patents&q=(augmented%20reality)%20AND%20(gesture%20recognition)&api_key=${SERPAPI_KEY}&num=10"
Method B: Exa.ai (Semantic)
# Example: Semantic search for similar inventions
curl -X POST 'https://api.exa.ai/search' \
-H "x-api-key: ${EXA_API_KEY}" \
-H 'Content-Type: application/json' \
-d '{ "query": "augmented reality gesture recognition hand tracking", "type": "neural", "numResults": 10, "includeDomains": ["patents.google.com"] }'
Extract from API results:
- Patent IDs and titles
- Publication dates
- Key claims and technical solutions
- Assignees and filing dates
Step 2.3: WebSearch Fallback (Used when APIs unavailable)
When API keys are not available, automatically use Claude's WebSearch tool:
- Use the
WebSearchtool to find relevant patent and technical information - Query format: "[user's invention description] prior art patent search comparative analysis"
- Example:
WebSearch("[specific technical concept] prior art patent 2025")
Step 2.4: Parallel Web Search
Perform web searches to gather comprehensive context regardless of API availability:
- Specific patents: Search for detailed patent information by technical concept
- Technical implementations: Search for how the solution works in practice
- Industry standards: Search for relevant technical standards and specifications
- Academic research: Search for latest research papers on related technologies
- Existing products: Search for commercial product comparisons and reviews
Search query patterns (customize based on invention):
- "[user's specific technical concept] vs [similar concept] patent"
- "[user's solution approach] implementation challenges and approaches"
- "[domain] technical standards and requirements 2025"
- "recent research [user's technical concept] academic papers"
- "[user's solution category] commercial implementation comparison"
Step 2.5: Novelty Analysis
Synthesize findings from both API and web search results:
- Comparison: Compare the user's idea with the top 3-5 most relevant patents
- Prior Art Identification: Identify the closest prior art (最接近的现有技术)
- Distinguishing Features: Determine distinguishing features (区别技术特征)
- Novelty Gaps: Note any potential novelty gaps or white spaces
- Feasibility Check: Confirm technical feasibility from implementation sources
Output: Comprehensive prior art analysis with novelty assessment.
Phase 3: Generate Application Form
Goal: Draft the complete patent application document.
Actions:
- Structure Setup: Follow the exact format specified in
template.md - Language Precision: Use formal Chinese patent terminology from
reference.md - Embodiments Creation: Design at least 3 distinct embodiments (具体实施方式):
- Vary data flow (push/pull, sync/async)
- Vary trigger conditions (time-based, event-based, threshold-based)
- Vary architecture (monolithic, distributed, edge-cloud)
- Novelty Articulation: Clearly state creative points (创新点) vs. existing solutions
- Completeness Check: Ensure all required sections are present
Output: Complete Chinese patent application form ready for filing.
--md Mode
Save the generated form as a local Markdown file:
- Filename:
Patent-[ShortTitle]-[YYYYMMDD].md - Prefer
docs/orpatents/directory, otherwise current working directory
--lark Mode
Create the form as a Feishu cloud document:
- CRITICAL -- Read
${CLAUDE_PLUGIN_ROOT}/skills/lark/lark-shared/SKILL.mdfor authentication - Read
${CLAUDE_PLUGIN_ROOT}/skills/lark/lark-doc/references/lark-doc-create.mdfor Lark-flavored Markdown syntax anddocs +createparameters - Convert the patent form to Lark-flavored Markdown, applying these enhancements:
| Section | Feishu Feature | Purpose |
|---|---|---|
| Document metadata (inventor/date/field) | <lark-table> |
Structured header info with proper column widths |
| Creative points / novelty claims | <callout emoji="..." background-color="light-blue"> |
Highlight distinguishing features |
| Technical problem statement | <callout emoji="..." background-color="light-yellow"> |
Emphasize the problem being solved |
| Architecture / data flow in embodiments | <whiteboard type="blank"> |
Visualize system architecture or process flow |
| Prior art comparison | <grid cols="2"> |
Side-by-side comparison: prior art vs invention |
| Defects / alternatives | <callout emoji="..." background-color="light-red"> |
Clearly mark limitations |
| Claims hierarchy | Nested ordered lists with <text color="blue"> for independent claims |
Visual distinction between independent and dependent claims |
- Create the document:
lark-cli docs +create --title "Patent-[ShortTitle]-[YYYYMMDD]" \ [--folder-token TOKEN_OR_URL | --wiki-node TOKEN_OR_URL | --wiki-space ID_OR_URL] \ --markdown "<lark-flavored-markdown>" - For long forms, split creation:
docs +createfor the first half, thendocs +update --mode appendfor the rest - If
board_tokensare returned (whiteboards were created):- Read
${CLAUDE_PLUGIN_ROOT}/skills/lark/lark-whiteboard-cli/SKILL.md - Fill each whiteboard with actual content (architecture diagrams, flowcharts)
- All whiteboards must have real content before task is complete
- Read
- Report the document URL
Lark Format Principles
- Title layer depth max 4 levels
- Do NOT write a top-level heading duplicating the title (Feishu auto-generates it)
- Use
---dividers between major sections for visual rhythm - Use
<text color="...">for key terms and claim markers - Feishu auto-generates table of contents -- do not add manually
- Proactively insert whiteboards for embodiment architectures and process flows
Supporting Files
Reference these files within this directory for detailed specifications:
template.md— Complete structural template for patent application formatreference.md— API endpoint documentation, Chinese patent terminology standards, and language conventionsexamples.md— High-quality patent application example${CLAUDE_PLUGIN_ROOT}/skills/lark/— Lark CLI skills (--larkmode)
Quality Principles
Critical Requirements:
- Grantability: Focus on technical solutions, not abstract ideas
- Precision: Avoid vague marketing terms; use precise technical descriptions from
reference.md - Honesty: Explicitly list potential defects and alternatives in the "Others" section
- Completeness: All required sections must be present and substantive
Language Conventions:
- Use formal Chinese patent terminology as defined in
reference.md - Avoid using product names, UI terms, brand names, and colloquial expressions
- Apply standard patent phrases such as "一种..." (A kind of...), "用于..." (for...), "其特征在于" (characterized in that...)
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核