ablation-planner
Use when main results pass result-to-claim (claim_supported=yes or partial) and ablation studies are needed for paper submission.
Write the full patent specification from claims and invention disclosure. Use when user says \"撰写说明书\", \"write specification\", \"写说明书\", \"patent description\", or wants to draft the complete patent specification.
$ npx -y skills add wanshuiyin/Auto-claude-code-research-in-sleep --skill specification-writing --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/specification-writingContext preview
The summary Claude sees to decide when to auto-load this skill.
Write the full patent specification from claims and invention disclosure. Use when user says \"撰写说明书\", \"write specification\", \"写说明书\", \"patent description\", or wants to draft the complete patent specification.
name: specification-writing description: "Write the full patent specification from claims and invention disclosure. Use when user says \"撰写说明书\", \"write specification\", \"写说明书\", \"patent description\", or wants to draft the complete patent specification." argument-hint: "[claims-path]" allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob, Skill, WebSearch, WebFetch, mcp__codex__codex, mcp__codex__codex-reply
Write the patent specification based on: **$ARGUMENTS**
Adapted from `/paper-write` for patent specifications. The specification supports the claims -- it is not a paper.
1. `patent/CLAIMS.md` — the drafted claims (primary source) 2. `patent/INVENTION_DISCLOSURE.md` — invention decomposition 3. `patent/PRIOR_ART_REPORT.md` — for background section 4. User-provided figures (if any)
Load `../shared-references/patent-writing-principles.md` for specification writing rules, language guidelines, and reference numeral conventions. Load `../shared-references/patent-format-cn.md` or `patent-format-us.md` or `patent-format-ep.md` based on jurisdiction.
Create the output directory and section files:
patent/specification/ ├── title.md ├── technical_field.md ├── background.md ├── summary.md ├── drawings_description.md ├── detailed_description.md └── abstract.md
1-2 paragraphs identifying the technical domain:
This is NOT a literature review. It directly sets up the problem.
Structure: 1. Describe the closest prior art approaches (2-3 paragraphs) 2. Identify specific technical deficiencies of each approach 3. The deficiencies must be technical, not commercial or social 4. DO NOT admit the prior art is "superior" or "better" 5. DO NOT cite specific patent numbers unless they are known prior art (citations go in IDS for US, or Background section for CN)
CN format: "背景技术" section describing existing technology and its shortcomings.
Three parts, directly mirroring INVENTION_DISCLOSURE.md:
**Technical Problem (要解决的技术问题)**:
**Technical Solution (技术方案)**:
**Advantages (有益效果)**:
Invoke `/figure-description` as a sub-skill if user has provided figures:
/figure-description "patent/figures/"
If no user figures, describe what figures should exist based on the claims.
Format:
Invoke `/embodiment-description` as a sub-skill:
/embodiment-description "patent/CLAIMS.md"
This section must:
Jurisdiction-specific word limits:
| Jurisdiction | Word Limit | Notes | |-------------|-----------|-------| | CN | 300 words (Chinese characters) | Include most representative claim reference | | US | 150 words (2500 characters) | Enable efficient searching, no legal phrases | | EP | ~150 words | No statements on merits or value |
The abstract summarizes: 1. The technical field 2. The problem being solved 3. The technical solution (core features) 4. Key advantages
Verify every claim element finds support in the specification:
| Claim | Element | Specification Section | Paragraph(s) | Reference Numeral | |-------|---------|----------------------|-------------|-------------------| | 1 | step a | detailed_description | ¶3 | 202 | | 1 | step b | detailed_description | ¶4 | 204 | | X | component A | detailed_description | ¶2 | 102 |
If any element lacks support, add the necessary description before proceeding.
Call `REVIEWER_MODEL` via `mcp__codex__codex` with xhigh reasoning:
mcp__codex__codex:
model: gpt-6-astra
config: {"model_reasoning_effort": "xhigh"}
prompt: |
You are a patent examiner reviewing a specification for completeness.
CLAIMS: [all claims]
SPECIFICATION: [all speci· · · · · · -orange?style=flat) · · 💬 Join Community · 💡 Use ARIS as a skill-based workflow in Claude Code / Codex CLI / Cursor / Trae / Antigravity / GitHub Copilot CLI / OpenClaw / DeepSeek Harness, or get the full experience with the standalone ARIS-Code
Use when main results pass result-to-claim (claim_supported=yes or partial) and ablation studies are needed for paper submission.
Quick single-paper lookup via AlphaXiv LLM-optimized summaries with tiered source fallback. Use when user says "explain this paper", "summarize paper", pastes…
Analyze ML experiment results, compute statistics, generate comparison tables and insights. Use when user says "analyze results", "compare", or needs to…
Search, download, and summarize academic papers from arXiv. Use when user says "search arxiv", "download paper", "fetch arxiv", "arxiv search", "get paper…
Autonomously improve a generated paper via GPT-6-Astra xhigh review → implement fixes → recompile, for 2 rounds. Use when user says \"改论文\", \"improve paper\",…
Autonomous research review loop using any OpenAI-compatible LLM API. Configure via llm-chat MCP server or environment variables. Trigger with "auto review loop…