agentleFS
Sign inStart free
openvinotoolkitopenvinotoolkit/openvino.genai/.github/skills/update-docs/SKILL.md

update-docs

Skill608 starsChanged 34 days agoApache-2.0View on GitHub

Update OpenVINO GenAI site documentation for API or feature changes. Use when: new pipelines, models, or use-cases are introduced; site docs need to reflect new capabilities.

We split this skill into the rules it gives an agent

4 rules. 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 75 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the description is not provided, derive it from the git diff against master (see Step 1).

    line 23
  2. Very specific:

    Use the get_changed_files tool to list files changed relative to master.

    line 29
  3. Distinctive:

    Do not invent model names, benchmark numbers, or unverified capabilities.

    line 50
  4. Distinctive:

    Run the following checklist before declaring the documentation update done:

    line 76

“Common” is measured: kept by at least 6 in 10 of the 75 edited versions of this file we could read. “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

Update Docs

Updates Docusaurus site pages under /site/docs/ after a code change.

When to Use

  • New pipeline, model type, or use-case was introduced
  • The supported-models table needs a new entry
  • A new public API, config option, guide, or concept needs to be documented on the site

Inputs

The user must provide (or the agent infers from the diff):

  • change_description: what was added or changed (e.g. "added VisualLanguageModelPipeline", "changed GenerationConfig.max_new_tokens default")

If the description is not provided, derive it from the git diff against master (see Step 1).

Procedure

Step 1: Identify Changed Files

Use the get_changed_files tool to list files changed relative to master. Focus on paths under src/cpp/include/, src/python/, src/js/lib/.

To understand what changed in each relevant file, prefer using appropriate tool calls over custom bash commands.

Step 2: Update Site Documentation

Decide which site sections need updating based on what changed:

Change typeSection to update
New pipeline / use-casesite/docs/use-cases/<category>/index.mdx
New model type supportedsite/docs/supported-models/_components/
New public API or config optionRelevant guide in site/docs/guides/
New concept or algorithmsite/docs/concepts/
New or changed VLM prompt tagVisual processing usage options

Rules:

  • MDX format; match surrounding file structure.
  • Code snippets must have both C++ and Python tabs (see existing index.mdx in use-cases for the tab component pattern).
  • Code snippets must have JavaScript tab if NodeJS API changed.
  • Do not invent model names, benchmark numbers, or unverified capabilities.
  • Cross-link to related pages using relative links (e.g., [Supported Models](/docs/supported-models/)).
  • For VLM prompt tags, update the native image and video tag lists in site/docs/use-cases/visual-processing/_sections/_usage_options/index.mdx, verify each tag against the model's prompt normalization implementation or tokenizer configuration.

Rules for models.ts entries:

  • Architecture (optional): verify the architecture value against the model's config.json ("architectures" field) or HuggingFace model card. Do not guess from the model name.
  • Name: use the existing models.ts as the source of truth for naming style. The name is usually the marketing / family name grouping related versions under one entry (e.g. name: 'Phi3' covers Phi-3, Phi-3.5, Phi-4). Strip organisation prefixes and per-size suffixes (-7B, -Instruct), but preserve hyphens and version numbers when the existing table uses them (e.g. Qwen2.5, Phi-3.5-MoE).
  • Order: insert new entries in alphabetical order by architecture.

Step 3: Lint and Build

From the site/ directory, run lint and then a production build to catch any errors:

cd site
npm run lint:fix
npm run build

Fix any errors reported before proceeding. Do not skip this step — a passing build confirms MDX syntax, broken imports, and broken internal links are all resolved.

Step 4: Verify Completeness

Run the following checklist before declaring the documentation update done:

  • Site docs cover the new capability (use-case page, guide, or model table entry).
  • npm run lint:fix passes with no errors.
  • npm run build completes successfully.

Step 5: Report

Summarize to the user:

  • Files changed and what was added/updated in each.
  • Any gaps where documentation could not be written because implementation details are unclear — list those explicitly and ask the user to clarify.

Download now (ZIP)

  • Other versions81 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 81

    1. vercel/next.js★ 143ksame name
    2. pipecat-ai/pipecat★ 17ksame name
    3. anyproto/anytype-ts★ 9ksame name
    4. vladmandic/sdnext★ 7.4ksame name
    5. ArcReel/ArcReel★ 6ksame name
    6. dotnet/sdk★ 3.2ksame name
    7. meta-pytorch/OpenEnv★ 2.8ksame name
    8. huggingface/OpenEnv★ 2.8ksame name
    9. man-group/ArcticDB★ 2.6ksame name
    10. fabro-sh/fabro★ 1.8ksame name

    71 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use get-pr-reviews, push-everything and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • saffron-healthSkill

      get-pr-reviews

      Get nicely formatted output of the last review comments on a PR. Used internally by other skills.

      Also in 3 projects that use this

    • saffron-healthSkill

      push-everything

      Stage ALL changes in the repository (not just session changes), commit, and push. Use when you need to commit all pending changes.

      Also in 3 projects that use this

    • TheKREATORSSkill

      instinct-export

      Export instincts from project/global scope to a file

      Also in 3 projects that use this

    • TheKREATORSSkill

      instinct-import

      Import instincts from file or URL into project/global scope

      Also in 3 projects that use this

    • NVIDIASkill

      generate-spec

      Produce a feature specification covering API changes, backward compatibility, cross-language impact, performance, and a file-level change plan. Use when designing a new feature, planning a significant change, or the user asks to spec something out.

      Also in 3 projects that use this

    • belokonmSkill

      fullstack-developer

      End-to-end feature expert specializing in frontend-backend integration, system architecture, and complete application development

      Also in 4 projects that use this

    • +1 more from saffron-health
    • +1 more from TheKREATORS
  • In this repository8 other files it gives its agents.

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.

Check your setup, free