agentleFS
raja21068raja21068/AutoResearch/skills/aris/embodiment-description/SKILL.md

embodiment-description

Skill2 starsChanged 6 months agoMITView on GitHub

Write detailed embodiment descriptions for patent specifications. Use when user says \"撰写实施例\", \"write embodiment\", \"实施例描述\", \"detailed description\", or wants to describe how to practice an invention.

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write detailed embodiments for: $ARGUMENTS

    line 10
  2. Distinctive:

    Ensure consistent reference numeral usage:

    line 70
  3. Distinctive:

    Every component mentioned must have a numeral

    line 72
  4. Distinctive:

    If any claim element lacks embodiment support, add the necessary description.

    line 90
  5. Distinctive:

    Do NOT include tables of experimental results, graphs of measurement data, or comparisons with prior art performance.

    line 123
  6. Distinctive:

    CRITICAL — An embodiment is NOT an experiment: Do NOT describe "repeated experiments", "accuracy evaluation", "precision testing", …

    line 124
  7. Distinctive:

    Do NOT copy experimental sections from source papers verbatim.

    line 125
  8. Distinctive:

    If the source material is a paper, extract ONLY: (1) what was built, (2) what materials/parameters were used, (3) how it operates.

    line 126
  9. Distinctive:

    Do NOT use subjective language ("excellent", "surprising", "superior").

    line 129

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Embodiment Description

Write detailed embodiments for: $ARGUMENTS

Embodiments describe HOW to make and use the invention -- they are the patent equivalent of experiment sections, but describe the invention rather than evaluating it empirically.

Constants

  • MIN_EMBODIMENTS = 1 — At least one complete embodiment required
  • MAX_EMBODIMENTS = 3 — Practical limit; more embodiments strengthen enablement
  • EMBODIMENT_STYLE = detailed — detailed (full working example) or outline (sketch)
  • REFERENCE_NUMERAL_PREFIX = 100 — Starting reference numeral for first figure's components

Inputs

  1. patent/INVENTION_DISCLOSURE.md — invention decomposition (core/supporting/optional features)
  2. patent/CLAIMS.md — drafted claims that the embodiments must support
  3. User-provided figures (if any) in any directory
  4. patent/figures/numeral_index.md if it exists (from /figure-description)

Workflow

Step 1: Plan Embodiments

For each claim category (method, system, etc.), plan at least one embodiment:

EmbodimentCovers ClaimsTypeKey Variations
1Claims 1, XBest mode / preferred[primary implementation]
2Claims 2, 3Alternative[different parameters/materials]
3Claims 4, 5Additional alternative[different configuration]

Step 2: Write Each Embodiment

For each embodiment, write a detailed description following this structure:

Opening paragraph: "In one embodiment, [invention summary with reference to what is being described]."

Component/step-by-step description:

For method embodiments:

  • Describe each step in order
  • Reference figure numerals: "As shown in FIG. 1, at step 202, the processor 102 receives the input data 104..."
  • Include specific parameters, ranges, and conditions
  • Describe what happens at each decision point

For system/apparatus embodiments:

  • Describe each component
  • Reference figure numerals: "Referring to FIG. 1, the system 100 comprises a processor 102, a memory 104, and a communication interface 106..."
  • Describe interconnections between components
  • Describe operation of the system step-by-step

Variations and alternatives:

  • "In some embodiments, the processor 102 may be a GPU, an FPGA, or an ASIC."
  • "In another embodiment, the memory 104 may be replaced with a distributed storage system."
  • "The parameters described above are exemplary; other values within the range [X, Y] are also contemplated."

These variations are critical -- they support broader claim interpretation.

Step 3: Reference Numeral Integration

Ensure consistent reference numeral usage:

  1. Every component mentioned must have a numeral
  2. Numeral must appear first in parentheses after the component name: "the processor (102)"
  3. Subsequent references: "the processor 102" (no parentheses)
  4. Numbering follows figure series: 100-series for FIG. 1, 200-series for FIG. 2

Format:

  • First mention: "the processor (102)"
  • Later in same embodiment: "the processor 102"
  • Cross-figure: "the processor 102 (shown in both FIG. 1 and FIG. 2)"

Step 4: Claim Support Verification

For each claim element, verify it appears in at least one embodiment:

Claim ElementEmbodimentReference NumeralDescription Paragraph
[element][which][numeral][paragraph reference]

If any claim element lacks embodiment support, add the necessary description.

Step 5: Software/Algorithm Embodiments (if applicable)

For method/software inventions, include:

  • Pseudocode or algorithmic description (NOT actual code)
  • Flowchart description tied to figures
  • Data structure descriptions
  • Interface specifications

Example:

In one embodiment, the method comprises the following steps:
At step 202, the processor 102 receives input data from the input device 108.
At step 204, the processor 102 extracts feature vectors from the input data using a convolutional neural network.
At step 206, the processor 102 applies the attention mechanism 110 to the feature vectors...

Step 6: Output

Embodiment sections are written to patent/specification/detailed_description.md (or appended to the specification structure).

Each embodiment section should be self-contained but cross-reference other embodiments when describing alternatives.

Key Rules

  • Embodiments must teach a POSITA to make and use the invention without undue experimentation.
  • Include at least one "best mode" embodiment (US requirement).
  • Multiple embodiments strengthen the specification against enablement challenges.
  • Describe the invention, do NOT evaluate it empirically ("The embodiment achieves 95% accuracy" is wrong; "The processor classifies the input data" is correct).
  • CRITICAL — NO experimental data, test results, accuracy percentages, detection rates, precision values, or comparative performance data. These belong in papers, not patents. The embodiment teaches HOW to make and use, not HOW WELL it performs.
  • WRONG: "传感器对直径超过150μm的金属颗粒实现了100%的检测精度,即使在检测限处仍保持94%的高精度。"
  • RIGHT: "当不锈钢颗粒通过间隙传感区域时,谐振频率下降。颗粒直径越大,频率偏移幅度越大。"
  • Do NOT include tables of experimental results, graphs of measurement data, or comparisons with prior art performance.
  • CRITICAL — An embodiment is NOT an experiment. Do NOT describe "repeated experiments", "accuracy evaluation", "precision testing", "calibration experiments", or "comparison with reference methods". An embodiment describes ONE way to make and use the invention — it is a recipe, not a test report.
  • Do NOT copy experimental sections from source papers verbatim. Transform the experimental setup into a manufacturing/operation description.
  • If the source material is a paper, extract ONLY: (1) what was built, (2) what materials/parameters were used, (3) how it operates. Ignore all test methodology, results, and performance metrics.
  • Include specific parameters where possible, but frame them as exemplary, not limiting.
  • Reference numerals must be consistent with the figures.
  • Do NOT use subjective language ("excellent", "surprising", "superior").

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.