comment-policy
Skill1.1k starsChanged 13 days agoApache-2.0View on GitHub
Cleanup pass on a diff or file set that deletes comments carrying no information the code cannot, removes lint suppressions that hide real bugs, and flags the symbol that made a comment necessary as MUST KILL. Report and delete only; never writes application code. Use for "strip comments", "comment pass", "clean up comments on this diff".
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 6 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Default is delete. A comment survives only by matching one clause of the keep list below.
- Distinctive: line 15
Never shorten a bad comment into a better-sounding justification.
- Very specific: line 16
Every flag names a real symbol inside scope at a real file:line.
- Distinctive: line 20
Only these survive. Everything else is deleted.
- Very specific: line 32
Delete on sight: narration (bind the polynomial), section banners, commented-out code, history and migration notes (used to be…, renamed …
- Distinctive: line 36
When a deleted comment was carrying weight the code should carry, flag the symbol:
- Very specific: line 46
Every suppression claims the rule is wrong at that site.
- Very specific: line 69
Per-file pass: Read the whole file, not just the comment lines: a comment's truth is decided by the code around it.
- Distinctive: line 70
Delete: Remove comment lines and dead suppressions.
- Distinctive: line 79
Report: Never send raw diffs.
≈ “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.
Files
Comment policy
Delete comments. Report what was deleted, what was kept and why, and which symbols need a refactor so the comment is no longer needed. Touch comments and lint suppressions only. Never write, move, or reshape application code; that is the MUST KILL list's job, handed to a separate change.
Posture
- Default is delete. A comment survives only by matching one clause of the keep list below. If unsure whether a clause applies, delete.
IMPORTANT,do not remove,too risky,fine for now, and any long justification are signals to read the nearby code before judging. If no keep clause applies, the comment is covering for the code: delete it and flag the symbol.- A kept comment must be true today: the enforcement point, bug, coupled file, or external constraint it names exists on a live path. Unproven after reading the code: delete.
- Never shorten a bad comment into a better-sounding justification. Delete it, or keep it whole.
- Every flag names a real symbol inside scope at a real
file:line. Invent nothing.
Keep list
Only these survive. Everything else is deleted.
- License or legal headers.
- Non-obvious behaviour forced by an external dependency, platform, vendor, or protocol the repo cannot reshape (arkworks fork behaviour, RISC-V spec corner cases, guest toolchain quirks).
- Directives a tool reads:
#[rustfmt::skip],# fmt: skip, shebangs,# shellcheck shell=/source=, encoding and schema pragmas. Lint suppressions are judged below, not here. - Doc comments that define a public API contract (
///,//!, Python docstrings, JavaScript/** */on exported items). One that only restates the signature is not a contract. - Issue or RFC links explaining a constraint the code cannot express, including
TODO(#issue)only when the linked issue explains that constraint; algorithm explanations, with paper/spec links where applicable. - Invariants or contracts the type system cannot express, stating WHERE they are enforced (name the checking function or specific fixture). Without the where, delete. Never keep a comment that calls a property constraint-enforced when it holds only for the honest prover or under a
debug_assert. - Why-not notes and warnings for non-obvious gotchas that prevent reintroducing a known bug, soundness gap, deadlock, or race.
- Pointers to non-local coupling: keep-in-sync with another file, crate, or format (relation ordering owned by
jolt-claims, serialized enum discriminants, transcript absorption order mirrored by prover and verifier, constants mirrored incommon). - Soundness or security reasoning (why this bound check suffices, why this input is trusted).
// SAFETY:onunsafebelongs here.
Delete on sight: narration (bind the polynomial), section banners, commented-out code, history and migration notes (used to be…, renamed from…, after the refactor…), behaviour descriptions that no longer match the code, TODOs not meeting clause 5, restated signatures and type names, end-of-block markers.
MUST KILL
When a deleted comment was carrying weight the code should carry, flag the symbol:
MUST KILL <exact symbol> — <one line: what would make the behaviour obvious without prose> — <file:line>Rename, extract, type, or restructure are the usual fixes; name the one that applies. The flag ends the job on that symbol. Do not apply it.
Lint suppressions
Every suppression claims the rule is wrong at that site. The Rust workspace denies allow_attributes; use #[expect(..)], not #[allow(..)]. Inspect both forms, including inner attributes. Look up the rule before judging.
- Stays: the rule is style, pedantic, or naming only, or it is a known false positive, linked or evident at that site. A
reasonon it is fine. - Stays: test-inappropriate lints on test modules, including panic-family rules (
unwrap_used,expect_used,panic,indexing_slicing), as permitted byCLAUDE.md; a panic is how a test fails. - Stays: function-level
#[expect(clippy::unwrap_used)]/expect_usedwhere avoiding the call significantly hurts readability (e.g. infallible conversions), as permitted by the Lint Policy inCLAUDE.md. - Stays: in the jolt-verifier runtime closure crates (
specs/verifier-closure-lints.md), an#[expect(clippy::.., reason = "..")]at the narrowest scope with a verified justification for that rule (e.g. a lossless cast, structurally guaranteed indexing, or a fail-closed wildcard). Apply the clause 6/9 evidence standard; a vague or missing reason: delete + MUST KILL. - Everything else is deleted with the guilty symbol flagged
MUST KILL: correctness, safety, suspicious, complexity, and perf rules, and any rule that cannot be identified. - Rule levels in config files (Cargo
[lints], crate-root#![deny(..)]/#![forbid(..)],clippy.toml) are repo policy, not suppressions: leave them.
Language matrix
| Language | Comment forms | Suppressions | Verdict on suppressions |
| Rust | // /// //! /* */ | #[expect(.., reason = "..")], inner #![expect(..)] | clippy::style/pedantic may stay; outside tests clippy::correctness/suspicious/complexity/perf, unwrap_used, expect_used, panic, indexing_slicing, unreachable → delete + MUST KILL unless an exception above applies |
| Python | # """docstring""" | # noqa, # type: ignore, # pylint: disable | # type: ignore hides real bugs → delete + MUST KILL unless the stub is broken (clause 2); public-contract docstrings stay under clause 4 |
| JavaScript | // /* */ /** */ (including scripts in HTML) | // eslint-disable*, @ts-ignore, @ts-expect-error, // biome-ignore lint/... | Type-error suppressions → delete + MUST KILL unless third-party types are broken (clause 2); otherwise by rule class |
| HTML/CSS | <!-- --> /* */ | /* stylelint-disable */ | By rule class |
| Shell | # | # shellcheck disable=SCxxxx | SC2086 and quoting rules are correctness → delete + MUST KILL; style codes may stay |
| TOML/YAML | # | # yamllint disable* | By rule class |
Procedure
- Scope. The files or diff given by the caller. Otherwise
git diff origin/main --name-only. For a diff, judge only comments and suppressions on changed lines. Never widen scope. - Per-file pass. Read the whole file, not just the comment lines: a comment's truth is decided by the code around it. Tag each comment with a keep clause number or
delete. Tag each suppression with its rule and class. - Delete. Remove comment lines and dead suppressions; for a trailing comment strip only the comment. Leave the code untouched, including blank lines that were not the comment's. Do not reflow.
- Prove comment-only. For touched Rust, run sequentially:
For other touched languages, use the repository's configured check commands; do not invent a runner or apply Rust checks to Python, shell, or HTML. Record unavailable checks as skips, not passes. Never let the formatter rewrite code. A lint failure caused only by a removed suppression is expected: keep the deletion, it is already a MUST KILL. Then runcargo fmt -q --message-format=short --all --check cargo clippy --all --features host -q --message-format=short --all-targets -- -D warnings cargo clippy --all --features host,zk -q --message-format=short --all-targets -- -D warningsgit diff --statandgit diff --no-ext-diff --no-color --ignore-blank-lines --word-diffon the touched files: every removed hunk must be comment or suppression text. Revert any other hunk. - Report. Never send raw diffs.
Report
- Touched files — list with
file:lineranges. - Deleted — number of comment lines removed, number of suppressions removed.
- MUST KILL — the flag lines, one per symbol.
- Kept — tally by keep clause (
clause 6: 3, clause 8: 1); list any kept suppression with its rule. - Skips — files or hunks left alone and why (generated code, vendored, out of scope, did not build).
Trending
More talk lately.about the whole repository
Who's talking about a16z/jolt
- coset-io/zkp-academy“[2024.4.23-2024.5.21] Lasso & Jolt 学习小组”GitHub · Apr 27, 2024 · 2 reactions
- LayerZero-Labs/akita“perf(verifier): batch verifier dot products through jolt-field row kernels”GitHub · Oct 6, 2026
- sudosubin/agents.nix“agent-skills.github.a16z.jolt: 1.1.1-unstable-2026-09-02 → 1.1.1-unstable-2026-09-25”GitHub · Oct 3, 2026
- LayerZero-Labs/jolt“chore(akita): bump dependency to e2c49ed”GitHub · Oct 2, 2026
- jruizaranguren/best-of-digital-identity“Add privacy-preserving identity category”GitHub · Sep 30, 2026
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
- Apr 27, 2024[2024.4.23-2024.5.21] Lasso & Jolt 学习小组 — coset-io/zkp-academy2 reactions · 1 comment
- Oct 6, 2026perf(verifier): batch verifier dot products through jolt-field row kernels — LayerZero-Labs/akita0 reactions · 15 comments
- Oct 3, 2026agent-skills.github.a16z.jolt: 1.1.1-unstable-2026-09-02 → 1.1.1-unstable-2026-09-25 — sudosubin/agents.nix0 reactions
- Oct 2, 2026chore(akita): bump dependency to e2c49ed — LayerZero-Labs/jolt0 reactions · 3 comments
- Sep 30, 2026Add privacy-preserving identity category — jruizaranguren/best-of-digital-identity0 reactions
28 more on GitHub
- Sep 30, 2026build: jolt as public git deps at a16z/jolt feat/inline-extension-external — 0xAndoroid/jeth0 reactions
- Sep 24, 2026agent-skills.github.a16z.jolt: init at 1.1.1-unstable-2026-09-02 — sudosubin/agents.nix0 reactions
- Aug 10, 2026Feat/jolt prover akita — LayerZero-Labs/jolt0 reactions · 1 comment
- Jul 31, 2026feat: port the demo to the modular prover on Akita (non-zk) — 0xAndoroid/jolt-wasm-prover0 reactions · 1 comment
- Jul 23, 2026Feat/jolt legacy prover akita integration — LayerZero-Labs/jolt0 reactions
- Jul 22, 2026[arXiv] zkML ONNX inference-proof harness — Jolt Atlas: Verifiable Inference via Lookup Arguments in Zero Knowledge — mnemonik-dev/nightly-research0 reactions
- May 21, 2026docs: document precommitted polynomial reductions — LayerZero-Labs/jolt0 reactions · 2 comments
- May 21, 2026feat: integrate bytecode and program image reductions — LayerZero-Labs/jolt0 reactions · 2 comments
- May 21, 2026feat: add committed bytecode foundation — LayerZero-Labs/jolt0 reactions · 2 comments
- May 21, 2026refactor: add precommitted polynomial reductions — LayerZero-Labs/jolt0 reactions · 2 comments
- May 21, 2026refactor: split stage 6 sumchecks — LayerZero-Labs/jolt0 reactions · 2 comments
- Apr 15, 2026build(deps): bump jolt-sdk from `b10e80a` to `3d5e431` — gg-archive/ruma-zk0 reactions
- Feb 3, 2026Implement Jolt Keccak-256 benchmark — ethereum/csp-benchmarkssays it tested it0 reactions
- Feb 3, 2026Implement Jolt ECDSA benchmark — ethereum/csp-benchmarkssays it tested it0 reactions
- Nov 11, 2025fix: correct calculation of max_log_n in VerifierSetup — markosg04/dory0 reactions
- Aug 15, 2025Update Jolt to v0.3.0-alpha — eth-act/ere0 reactions
- Aug 4, 2025Wire up PCS to jolt-prover — ICME-Lab/jolt-atlas0 reactions · 1 comment
- Aug 2, 2025Implement output proof — ICME-Lab/zkml-jolt0 reactions
- Mar 22, 2025no rust-toolchain-aarch64-unknown-linux-gnu.tar.gz release version — a16z/rust0 reactions · 1 comment
- Mar 21, 2025Implement `CanonicalSerialize` and `CanonicalDeserialize` for signed integers — a16z/arkworks-algebra0 reactions
- Mar 5, 2025Trait solver taking >10s to finish in auto complete — rust-lang/rust-analyzer0 reactions · 2 comments
- Feb 28, 2025Add Jolt zkVM Support to ProofLab — ProofLabDev/prooflab-rs0 reactions
- Feb 25, 2025chore: fix typos — a16z/helios0 reactions
- Jan 15, 2025Benchmark ICICLE and `arkmsm` — piotr-roslaniec/wasm-multiexp-benchsays it tested it0 reactions
- Nov 22, 2024chore: Update toolchain to nightly-2024-09-30 — a16z/rust0 reactions
- Jun 26, 2024Optimize polynomial batching computation — microsoft/Nova0 reactions · 1 comment
- May 27, 2024Summary from our mail threads — mab-xyz/verifiable-client-diversity0 reactions
- May 15, 2024List of Existing ZkVMs — vacp2p/zk-explorations0 reactions
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- fusebase-dev/fusebase-flow★ 9same name
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.
In this repository9 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- analyze-specSkill
- ci-code-reviewSkill
- implement-specSkill
- new-invariantSkill
- new-objectiveSkill
- new-specSkill
- test-policySkill
- update-docsSkill
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
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.

