agentleFS
Sign inStart free
a16za16z/jolt/.claude/skills/update-docs/SKILL.md

update-docs

Skill1.1k starsChanged 13 days agoApache-2.0View on GitHub

Analyze code changes since a base commit and update the Jolt docs (book/) accordingly

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 75 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If no base commit was provided, ask the user for one before proceeding.

    line 11
  2. Distinctive:

    Read the diff carefully. Focus on understanding:

    line 25
  3. Very specific:

    Read book/src/SUMMARY.md to understand the current documentation structure and what topics are already covered.

    line 33
  4. Distinctive:

    Not every code change requires a docs update.

    line 37
  5. Distinctive:

    Before making any changes, present a summary to the user:

    line 63
  6. Distinctive:

    If the user requested documentation edits, proceed to Step 5.

    line 72
  7. Distinctive:

    Read the full current content of the doc page

    line 78
  8. Very specific:

    Create the markdown file in the appropriate subdirectory under book/src/

    line 81
  9. Very specific:

    Add the entry to book/src/SUMMARY.md in the correct location

    line 82
  10. Distinctive:

    Keep documentation accurate and concise — match the existing style in the book

    line 83
  11. Distinctive:

    Use concrete examples and code snippets where helpful

    line 87
  12. Distinctive:

    Use standard mdBook conventions

    line 89

“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

You are updating the Jolt documentation in book/ based on code changes since a base commit.

The base commit is: $ARGUMENTS

If no base commit was provided, ask the user for one before proceeding.

Step 1: Gather the diff

Run:

git diff $ARGUMENTS..HEAD -- '*.rs'

Also get a summary of changed files:

git diff --stat $ARGUMENTS..HEAD -- '*.rs'

Read the diff carefully. Focus on understanding:

  • What functionality changed or was added
  • Whether public APIs changed (new types, renamed functions, changed signatures)
  • Whether new features, protocols, or subsystems were introduced
  • Whether existing behavior was modified in user-visible ways

Step 2: Read the docs outline

Read book/src/SUMMARY.md to understand the current documentation structure and what topics are already covered.

Step 3: Triage — decide what needs updating

Not every code change requires a docs update. Apply this decision framework:

Changes that DO NOT need docs updates:

  • Internal refactors that don't change behavior or APIs
  • Performance optimizations (unless they change usage patterns or add new features like new CLI flags)
  • Bug fixes (unless they change documented behavior)
  • Test changes
  • CI/CD changes
  • Dependency bumps
  • Code style / formatting changes
  • Changes to internal implementation details that aren't documented

Changes that DO need docs updates:

  • New user-facing features (new CLI commands, new macros, new configuration options)
  • Changes to the proving/verification API that users interact with
  • New architectural components that are significant enough to document
  • Changes to existing documented behavior
  • New optimizations or techniques that are novel and worth explaining in "How it works"
  • Removed or deprecated features that are currently documented

Changes that may warrant a NEW doc page:

  • A major new subsystem or feature (e.g., a new commitment scheme, a new lookup argument)
  • A new user-facing workflow (e.g., a new way to profile, a new SDK feature)

Step 4: Report your findings

Before making any changes, present a summary to the user:

  1. Overview of code changes: Brief description of what changed
  2. Docs verdict: One of:
    • No docs update needed — explain why the changes don't affect documentation
    • Existing pages need updates — list which pages and what needs changing
    • New page(s) warranted — describe what the new page would cover and where it fits in SUMMARY.md
  3. Proposed changes: For each doc file you plan to modify or create, describe specifically what you'll change

If the user requested documentation edits, proceed to Step 5. If they requested only analysis or required approval before edits, stop after the findings and await authorization.

Step 5: Make the changes

For each doc update:

  1. Read the full current content of the doc page
  2. Make targeted edits — preserve the existing style, tone, and structure
  3. For new pages:
    • Create the markdown file in the appropriate subdirectory under book/src/
    • Add the entry to book/src/SUMMARY.md in the correct location
  4. Keep documentation accurate and concise — match the existing style in the book

Writing style guidelines (match the existing book):

  • Technical but accessible — assume the reader has basic cryptography/ZK knowledge
  • Use concrete examples and code snippets where helpful
  • Link to related pages within the book using relative paths
  • Use standard mdBook conventions

Download now (ZIP)

Trending

More talk lately.about the whole repository

Dec 2025: 0 mentionsJan 2026: 0 mentionsFeb 2026: 2 mentionsMar 2026: 0 mentionsApr 2026: 1 mentionMay 2026: 5 mentionsJun 2026: 0 mentionsJul 2026: 3 mentionsAug 2026: 1 mentionSep 2026: 3 mentionsOct 2026: 3 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the a16z/jolt repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about a16z/jolt

The biggest 5 of 33 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 33

Talked about on GitHub (33 times).

On GitHub · 33

28 more on GitHub
  • 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 repository9 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.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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